SPF 레코드에서 FAIL을 통한 SOFTFAIL 사용이 모범 사례로 간주됩니까?

아니면 다른 방법으로 사용하는 v=spf1 a mx ~all것이 좋습니다 v=spf1 a mx -all. RFC 는 권장 사항을 제시하지 않습니다. 필자는 항상 FAIL을 사용하는 것이 좋았 기 때문에 문제가 즉시 명백해졌습니다. SOFTFAIL을 사용하면 아무도 알지 못하므로 잘못 구성된 SPF 레코드가 무기한으로 유지 될 수 있습니다.

그러나 온라인에서 본 모든 예제는 SOFTFAIL을 사용하는 것으로 보입니다. SPF 구성에 대한 Google Apps 지침 을 보았을 때 제가 선택해야 할 질문은 다음과 같습니다.

이 텍스트가 포함 된 TXT 레코드를 만듭니다. v = spf1 include : _spf.google.com ~ all

~ all 대신 -all을 사용하는 SPF 레코드를 게시하면 배달 문제가 발생할 수 있습니다. Google Apps 메일 서버의 주소에 대한 자세한 내용은 Google IP 주소 범위를 참조하십시오.

SOFTFAIL의 사용을 밀어서 예제가 지나치게 신중합니까? SOFTFAIL을 사용하는 것이 가장 좋은 이유는 무엇입니까?

글쎄, 그것은 사양을 대신하여 사용하려는 사양의 의도가 아니 었습니다. softfail은 메시지를 완전히 거부하지 않고 표시 할 수있는 전환 메커니즘으로 고안되었습니다.

알다시피, 실패한 메시지는 문제를 일으키는 경향이 있습니다. 예를 들어 일부 합법적 인 서비스는 사용자 대신 메일을 보내기 위해 도메인 주소를 스푸핑합니다.

이 때문에 드라코 니안 소프트 페일은 통증이 덜한 방법으로 SPF가 제공하는 많은 도움을받을 수있는 두통이 거의없는 것이 좋습니다. 받는 사람의 스팸 필터는 여전히 메시지가 스팸 일 수 있다는 강력한 힌트로 소프트 페일을 취할 수 있습니다 (많은 사람이 할 수 있음).

지정한 노드 이외의 다른 노드에서 메시지를 보내지 않아야한다고 확신하는 경우 반드시 SPF 표준이 의도 한대로 실패를 사용하십시오. 그러나 관찰 한대로 softfail은 원래 의도 한 것 이상으로 성장했습니다. 용도.

-all은 항상 예외 없음으로 사용해야합니다. 사용하지 않으려면 도메인 이름을 스푸핑하는 사람에게 자신을 열어 주어야합니다. 예를 들어 Gmail에는 ~ all이 있습니다. 스패머 스푸핑 gmail.com은 항상 주소를 지정합니다. 표준에 따르면 ~ all 때문에 전자 메일을 수락해야합니다. SPF 레코드를 잘못 설정했다는 것을 깨달았 기 때문에 개인적으로 이것에 대한 표준을 따르지 않습니다. 나는 -all,? all, 내가하는 것처럼 모든 것을 시행한다. SPF 구문 SPF 실수

내 이해에 따르면 Google은 SPF뿐만 아니라 DKIM 및 궁극적으로 DMARC를 사용하여 전자 메일을 평가합니다. DMARC는 SPF와 DKIM 서명을 모두 고려합니다. 둘 중 하나라도 유효하면 Gmail은 이메일을 수락하지만 둘 다 실패 (또는 소프트 실패)하면 이메일이 사기 일 수 있음을 분명히 알 수 있습니다.

Google의 DMARC 페이지 에서 가져온 것입니다 .

SPF 및 DKIM 검사 모두에 실패하면 DMARC도 실패해야합니다. 두 기술 중 하나를 사용한 단일 검사 실패로 메시지가 DMARC를 통과 할 수 있습니다.

따라서 SPF가 더 큰 메일 분석 알고리즘에 들어갈 수 있도록 softfail 모드에서 SPF를 사용하는 것이 좋습니다.

아마도 softfail이 여전히 사용되는 이유는 많은 사용자가 (올바른 또는 잘못 된) 설치 전자 메일에서 집으로 전달하기 때문일 수 있습니다. hardfail이 활성화되어 있으면 거부됩니다.