SPF 레코드 중간에 "~ all"이 구문 분석 될 때 레코드의 끝을 표시합니까?

당사의 SPF 레코드 형식은 다음과 같습니다.

"v = spf1 include : _spf.google.com ~ all a mx ip4 : XX0.0 / 23 include : spf.example.com? all"

SPF 레코드 중간에 "~ all"이 있습니다. 온 openspf.com 웹 사이트 , 그들은 "모든"메커니즘에 관한 이런 말 :

이 메커니즘은 항상 일치합니다. 일반적으로 SPF 레코드의 끝에서갑니다.

따라서 그들은 SPF 레코드의 끝에 "모든"HAS가 있다고 말하지 않지만, 일반적으로 마지막에갑니다.

우리 회사에서는 최근 SPF 레코드에 나열된 서버에서 전송 된 전자 메일에서 일부 오류가 발생했지만 SPF 레코드는 지금까지 찾은 모든 유효성 검사 도구를 통과했습니다.

내가 궁금한 점은 Google Apps 포함 (_spf.google.com) 바로 다음에 "~ all"이 발생하여 구문 분석이 중지되고 SPF 레코드의 나머지 부분을 인식하지 못합니까? 합격과 불합격은 누가 파싱하고 누가 SPF 레코드를 처리하는지에 대한 구체적인 구현에 달려 있습니까? SPF 레코드의 끝에 있지 않은 "전체"메커니즘을 사용해야하는 이유가 있습니까?

그렇습니다. SPF 레코드 만 변경할 수 있다는 것을 알고 있습니다. 이 질문은 이것이 어떻게 작동하는지 명확하게 설명하는 것이지, 특정 상황을 해결하는 데 필요한 것은 아닙니다.

RFC 7208 § 5.1 은 이에 대해 명시 적입니다. all나타난 후에 는 반드시 무시해야합니다.

"all"이후의 메커니즘은 테스트되지 않습니다. "모두"뒤에 나열된 메커니즘은 무시해야합니다. 용어의 상대적인 순서에 관계없이 레코드에 "전체"메커니즘이있는 경우 "리디렉션"수정 자 ( 섹션 6.1 )를 무시해야합니다.

폐기 된 RFC 인 RFC 4408 은 거의 동일한 내용을 언급했다. RFC의 최신 버전은 단순히 의도를 명확하게합니다.

"all"이후의 메커니즘은 테스트되지 않습니다. "전체"메커니즘이있는 경우 "리디렉션"수정 자 ( 섹션 6.1 )는 적용되지 않습니다.

따라서 적합한 SPF 구현은 첫 번째 이후의 모든 것을 완전히 무시합니다 ~all. 그러나 이것이 모든 구현이 사양을 준수한다는 의미는 아닙니다. 특히, 이는 하나 이상의 구현이 일치하지 않기 때문에 명확하게 설명 할 가치가 있다고 생각되었습니다 .

온라인 유효성 검사 도구가 이러한 잘못된 구성을 포착하지 못하는 이유는 아직 확실하지 않지만, 처음 all사용 된 이후에 무언가를 사용하려는 경우 적절한 구현에서는 무시하므로 레코드를 수정해야합니다.

"v = spf1 include : _spf.google.com ~ all a mx ip4 : XX0.0 / 23 include : spf.example.com? all"

순서대로 말한다 :

"SPF 레코드를 전달하는 이메일 _spf.google.com이 도메인에 유효합니다"

"도메인의 다른 모든 발신자에게 소프트 실패"

"A 레코드에서 온 이메일은 도메인에 유효합니다"

"MX 레코드에서 오는 이메일은 도메인에 유효합니다"

"IP 범위에서 오는 이메일 x.x.0.0/23은 도메인에 유효합니다"

"SPF 레코드를 전달하는 이메일 spf.example.com이 도메인에 유효합니다"

"도메인의 다른 모든 발신자로부터 온 이메일을 확인할 수 없습니다."

레코드 구문에 따라 :

메커니즘은 순서대로 평가됩니다. 일치하는 메커니즘이나 수정자가 없으면 기본 결과는 "중립"입니다.

따라서 일단 "다른 모든 사람들을위한 softfail"에 부딪 치면 여러분이 지정한 나머지 메커니즘을 무시해야합니다.

SPF 레코드는 가능한 간결해야합니다. 도메인에 이메일을 보내거나 전체 A 레코드를 보내지 않아야하는 / 23 네트워크 전체가 의심 스럽습니다. 어쩌면 ...하지만 아마도 아닐 것입니다.

멋진 SPF 레코드는 다음과 같아야합니다.

"v = spf1 include : _spf.google.com include : spf.example.com mx -all"

기본적으로 _spf.google.com, spf.example.com 및 MX 레코드는 도메인에서 유일하게 유효한 발신자입니다. 다른 모든 것은 유효하지 않은 것으로 취급해야합니다.

제대로 구현 SPF 검사기는의 단락 것이다 기구 원정 check_host () 함수는 결과로 규정 된 값을 반환한다. 대부분의 이메일 서버가 RFC를 따르는 지 여부와 관련하여 제공 할 "실제"데이터가 없습니다.

출처 : RFC7208 (17 페이지 참조)