송신자 정책 프레임워크

Sender Policy Framework
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

SPF(Sender Policy Framework)는 전자 [1]메일을 배달하는 동안 위조된 보낸 사람 주소를 탐지하도록 설계된 전자 메일 인증 방법입니다.단, SPF 만으로는 이메일의 [1]봉투에서 메일을 반송할 때 사용되는 위조된 발신인 클레임을 탐지할 수 있습니다.DMARC 와 조합하는 경우에만, 피싱이나 전자 메일 스팸에 자주 사용되는 기술인 전자 메일의 가시적인 송신자의 위조(전자 메일 스푸핑)를 검출할[2] 수 있습니다.

SPF를 통해 수신 메일 서버는 메일 배달 중에 특정 도메인에서 왔다고 주장하는 메일이 해당 도메인의 [3]관리자가 승인한 IP 주소로 제출되었는지 확인할 수 있습니다.도메인의 허가된 송신 호스트와 IP 주소의 리스트는, 그 도메인의 DNS 레코드에 공개됩니다.

송신자 정책 프레임워크는 2014년 4월호 RFC 7208에서 "제안된 표준"[4]으로 정의되어 있습니다.

역사

이 컨셉은 2000년에 처음 공개되었지만,[5] 대부분 눈에 띄지 않았다.SPF와 같은 사양에 대한 첫 시도가 2002년 IETF의 "namedroppers"[6][2][5] 메일링 리스트에 발표될 때까지 이 개념은 다시 언급되지 않았습니다.그는 2000년 이 아이디어에 대한 언급을 알지 못했습니다.바로 다음날, Paul Vixie는 같은 목록에 [7][5]자신의 SPF와 같은 사양을 게시했습니다.이러한 투고는 많은 관심을 불러일으켰고, IETF Anti-Spam Research Group(ASRG; 안티스팸 연구 그룹)과 그 메일링 리스트의 형성에 이어 SPF 아이디어가 더욱 발전했다.ASRG에 제출된 제안으로는 Hadmut Danish의 "Reverse MX"(RMX)와 Gordon Fecyk의 [8]"Designated Mailer Protocol"(DMP)이 있다.

2003년 6월, 멩 Weng 웡과 타인으로부터의 주의. 측은 RMX과 DMP specifications[9]합병했다.다음 6개월 동안 변화 많은 수와 큰 지역 사회 SPF에 일하기 만들어졌다.[10]자외선 차단 지수가 보낸 사람 허가에부터이며 또한 때때로 SMTP+SPF를 부르는 것이었습니다;프로그램 이름을 메일 서버 등록제 2월 2004년에 바뀌었다.

2004년 초에서, 국제 인터넷 기술 위원회와 자외선 차단 지수와 마이크로 소프트의 발신자를 사용하려는 MARID 작업 그룹을 만들었다.지금 발신자 ID로입니다. 그러나 이와 라이센싱 기술 분쟁으로 인해 붕괴된 것을 기초로 ID제안.[11]

그 SPF사회 SPF의 원래"고전적인"버전으로 돌아왔다.2005년 7월,는 규격 버전에서 인터넷 기술 관리 그룹에 의해 IETF실험으로, 발표 이후는 2년 동안 자외선 차단 지수를 관찰하기 위해 이 지역 초대해 승인되었다.2006년 4월 28일 SPFRFC실험 RFC4408으로 발행되었다.

4월 2014년에 IETFRFC7208에서"표준 제안된"로 자외선 차단 지수를 발표했다.

동작 원리

상세 정보:보낸 사람 Rewriting 방안(SRS)

그 단순 우편 전송 규약 어떤 컴퓨터 이메일 어떤 소스 주소에서 운영한다고 주장하면서 보낼 수 있습니다.이 스팸 메일을 보내는 사람들 종종 더 어려워의 출처를 위해 책임을 피하기 위해 스팸 메일들은 신원을 감추기 쉬운 해당 메시지를 추적하고 addresses,[12]위조 메일을 이용하지 않고 사기꾼들에 의해 이용된다.그것은 또한 사용자 이메일 이에 들어가는 은행 등의 조직에 의해 보내진에 대응하여 개인 정보를 공개 속아설 수 있피싱 기법에 사용된다.

SPF인터넷 도메인의 소유자 컴퓨터 저 도메인에서 envelope-from 주소와, 도메인 이름 시스템(DNS)기록을 사용하여 전자 메일 보내도록 허가 받고 있지정할 수 있습니다.수신기 TXT의 자외선 차단 지수 정보를 확인하는 메세지를 받기 전에 불법 소스에서의 메시지를 거부할 수 있다.따라서, 작업의 원칙은DNS-basedblackhole 목록, SPF가 DNS의 권위 대표단 계획을 사용하여 제외하고(도메인 이름 서비스 기반 블랙 홀 목록)와 비슷하다.현재의 관행에서는 초기 구현과 마찬가지로 TXT [13]레코드를 사용해야 합니다.한동안 새로운 레코드 타입(SPF, 타입 99)이 등록되어 공통 DNS 소프트웨어에서 사용할 수 있게 되었습니다.SPF를 위한 TXT 레코드의 사용은 당시 과도적 메커니즘으로 의도되었다.실험 RFC, RFC 4408 섹션 3.1.1에서는 "SPF 준거 도메인 이름에는 양쪽 RR 유형의 SPF 레코드가 있어야 한다"[14]고 제안했습니다.제안된 표준 RFC 7208에서는 "대체 DNS RR 타입의 사용은 SPF의 실험 단계에서 지원되었지만 중단되었습니다."[13]라고 기술되어 있습니다.

엔벨로프 송신원주소는, SMTP 다이얼로그의 선두에 송신됩니다.서버가 도메인을 거부하면 부정한 클라이언트는 거부 메시지를 수신해야 합니다.또, 그 클라이언트가 Relaying Message Transfer Agent(MTA; 릴레이 메시지 전송 에이전트)인 경우, 원래의 엔벨로프 발신인 주소로 바운스메시지가 생성될 수 있습니다.서버가 도메인을 받아들인 후 메시지 수신자와 본문도 받아들인 경우 메시지 헤더에 [Return-Path]필드를 삽입하여 엔벨로프 발신인 주소를 저장해야 합니다.리턴 패스내의 주소는, 메일 헤더의 헤더 송신원주소등의 다른 송신원주소와 일치하고 있는 경우가 많지만, 반드시 그렇지만은 않습니다.SPF 를 사용해도, 송신원 헤더등의 다른 주소가 위조되는 것을 막을 수 없습니다.

스팸 발송자는 보낸 사람 정책을 가진 도메인에 계정이 있는 경우 SPF PASS 결과가 포함된 전자 메일을 보내거나 이 도메인의 손상된 시스템을 악용할 수 있습니다.그러나 그렇게 하면 스팸 발송자를 추적하기가 쉬워집니다.

SPF의 주요 이점은 리턴 경로에서 위조된 전자 메일 주소의 소유자에게 있습니다.이들은 다수의 불필요한 오류 메시지 및 기타 자동 복제를 수신합니다.이러한 리시버가 SPF 를 사용해 정당한 송신원IP 주소를 지정하고, 그 외의 모든 주소의 FAIL 결과를 나타내는 경우, SPF 를 체크하고 있는 리시버는 위조를 거부해, 백스캐터량을 줄이거나 없앨 수 있습니다.

SPF에는 불필요한 메일을 식별하는 데 도움이 될 뿐만 아니라 잠재적인 이점이 있습니다.특히, 송신자가 SPF 정보를 제공하는 경우, 수신자는 SPF PASS 결과를 허가 목록과 조합하여 사용하여 신뢰할 수 있는 기존의 송신자를 식별할 수 있습니다.손상된 시스템 및 공유 발송 메일러와 같은 시나리오는 이러한 사용을 제한합니다.

도입 이유

도메인이 SPF 레코드를 게시하는 경우 위조된 이메일이 SPF 레코드를 확인하는 스팸 필터에 포착될 가능성이 높기 때문에 스팸 발송자와 피싱자가 해당 도메인에서 온 것처럼 가장한 이메일을 위조할 가능성은 낮아집니다.따라서 SPF로 보호되는 도메인은 스팸 발송자 및 피싱자에게 그다지 매력적이지 않습니다.SPF로 보호된 도메인은 스푸핑된 주소로서 매력이 떨어지기 때문에 스팸 필터에 의해 거부될 가능성이 낮아지고 최종적으로는 도메인으로부터의 정규 이메일이 [15]통과할 가능성이 높아집니다.

FAIL 및 전송

SPF는 플레인메시지 전송을 중단합니다.도메인이 SPF FAIL 정책을 퍼블리시할 때 다음 중 하나에 해당하는 경우 메일을 제3자에게 전송하는 수신자에게 발송된 정규 메시지가 거부되거나 반환될 수 있습니다.

  1. 포워더는 메일링 리스트와 달리 리턴 패스를 다시 작성하지 않습니다.
  2. 넥스트 홉은 포워더를 허가하지 않습니다.
  3. 이 홉은 SPF를 체크합니다.

이것은 SPF의 필수적이고 명백한 기능입니다.수신기의 "경계" MTA(MX) 배후에 있는 체크는 직접 동작할 수 없습니다.

SPF FAIL 정책의 게시자는 합법적인 전자 메일이 거부되거나 반환될 위험을 감수해야 합니다.결과에 만족할 때까지 (예를 들어 SOFTFAIL 정책을 사용하여) 테스트해야 합니다.일반 메시지 전송의 대체 방법 목록은 아래를 참조하십시오.

HELO 테스트

오류 메시지 및 기타 자동 리플리케이션에서 사용되는 빈 리턴 패스의 경우 HELO ID의 SPF 체크는 필수입니다.

가짜 HELO ID의 경우 NONE은 도움이 되지 않지만 유효한 호스트 이름의 경우 SPF가 HELO ID를 보호합니다.이 SPF 기능은 리시버 옵션으로서 항상 지원되고 있었습니다.최종 사양을 포함한 이후의 SPF 초안에서는 항상 HELO를 확인하는 것이 좋습니다.

이것에 의해, 수신자는 HELO PASS 에 근거해 메일러를 송신하는 것을 허가하거나, HELO FAIL 후에 모든 메일을 거부할 수 있습니다.레퓨테이션 시스템에서도 사용할 수 있습니다(허가 또는 거부 목록은 레퓨테이션 시스템의 단순한 경우입니다).

실행

SPF 준수는 다음과 같은 3가지 느슨한 관련 작업으로 구성됩니다.

  • 정책 게시:도메인과 호스트는 자신을 대신하여 전자 메일을 보낼 수 있는 권한이 부여된 시스템을 식별합니다.이를 수행하려면 기존 DNS 정보에 레코드를 추가합니다.A 레코드 또는 MX 레코드가 있는 모든 도메인 이름 또는 호스트에는 정책을 지정하는 SPF 레코드가 있어야 합니다(이메일 주소 또는 HELO/EHLO 인수로 사용되는 경우).메일을 송신하지 않는 호스트에는 이러한 SPF 레코드("v=spf1 -all")가 게시되어 있어야 합니다.
  • SPF 정보 확인 및 사용:리시버는 통상적인 DNS 쿼리를 사용합니다.일반적인 DNS 쿼리는 퍼포먼스를 향상시키기 위해 캐시됩니다.그런 다음 수신자는 지정된 대로 SPF 정보를 해석하고 결과에 따라 행동합니다.
  • 메일 전달 수정: 일반 메일 전달은 SPF에서 허용되지 않습니다.대체 방법은 다음과 같습니다.
    • 재전송(즉, 원래 송신자를 로컬 도메인에 속하는 송신자로 대체)
    • 거부(즉, 응답)551 User not local; please try <user@example.com>)
    • 전달된 메시지를 거부하지 않도록 대상 서버에 허용 목록 표시
    • 발신인 개서 방식: 원래 발신인에게 라우팅된 배달되지 않은 통지를 처리하는 보다 복잡한 메커니즘

따라서 SPF의 주요 문제는 도메인과 리시버가 사용하는 새로운 DNS 정보의 사양입니다.다음에 나타내는 레코드는 일반적인 DNS 구문입니다.다음은 예를 제시하겠습니다.

"v=spf1 ip4:192.0.2.0/24 ip4:192.51.100.123 a -all"

"v="는 사용된 SPF 버전을 정의합니다.다음 단어는 도메인이 메일을 발송할 수 있는지 확인하는 데 사용할 메커니즘을 제공합니다."ip4" 및 "a"는 지정된 도메인에 대한 메시지 전송이 허용된 시스템을 지정합니다.마지막 "all"은 이전 메커니즘이 일치하지 않을 경우 메시지를 거부하도록 지정합니다.

메커니즘

8개의 메커니즘이 정의되어 있습니다.

모든. 항상 일치하며 다음과 같은 기본 결과에 사용됩니다.-all모든 IP가 이전 메커니즘에 의해 일치하지 않습니다.
A 도메인명에 송신자의 주소로 해결 가능한 주소 레코드(A 또는 AAAA)가 있는 경우는, 일치합니다.
IP4 송신자가 소정의 IPv4 주소 범위내에 있는 경우는, 일치합니다.
IP6 송신자가 소정의 IPv6 주소 범위내에 있는 경우는, 일치합니다.
MX 도메인 이름에 발신인 주소로 확인되는 MX 레코드가 있는 경우, 일치합니다(즉, 메일은 도메인의 수신 메일 서버 중 하나).
PTR 클라이언트 주소의 도메인 이름(PTR 레코드)이 지정된 도메인에 있고 해당 도메인 이름이 클라이언트의 주소(전송 확인 역 DNS)로 해결되면 일치합니다.이 메커니즘은 권장되지 않으므로 가능하면 [13]피해야 합니다.
존재한다 지정된 도메인 이름이 임의의 주소로 해결되면 (해결된 주소에 관계없이) 일치시킵니다.이것은 거의 사용되지 않습니다.SPF 매크로 언어와 함께 DNSBL 쿼리와 같은 보다 복잡한 일치를 제공합니다.
포함하다 다른 도메인의 정책을 참조합니다.해당 도메인의 정책이 통과하면 이 메커니즘이 통과합니다.그러나 포함된 정책이 실패하면 처리가 계속됩니다.다른 도메인의 정책에 완전히 위임하려면 리디렉션 확장을 사용해야 합니다.

자격

각 메커니즘은 다음 4가지 수식자 중 하나와 조합할 수 있습니다.

  • + PASS 결과를 얻습니다.이는 생략할 수 있습니다. 예를 들어,+mx와 같다mx.
  • ? NONE(정책 없음)으로 해석되는 중립 결과입니다.
  • ~ (tilde) SOFTFAIL의 경우 중립과 FAIL 사이의 디버깅 지원.일반적으로 SOFTFAIL을 반환하는 메시지는 받아들여지지만 태그가 부착됩니다.
  • - (단, FAIL의 경우 메일은 거부되어야 합니다(아래 참조).

수식자

이 수식자에 의해 향후 프레임워크 확장이 가능하게 됩니다.지금까지 RFC 4408에 정의되어 있는2개의 수식자만이 널리 전개되어 왔습니다.

  • exp=some.example.com에 DNS TXT 레코드가 있는 도메인 이름(SPF 매크로 언어를 사용하여 해석됨)을 나타냅니다.FAIL 결과에 대한 설명을 얻을 수 있습니다(통상은 SMTP 에러 코드에 추가되는 URL).이 기능은 거의 사용되지 않습니다.
  • redirect=some.example.com다른 도메인의 정책 레코드에 링크하기 위해 ALL 메커니즘 대신 를 사용할 수 있습니다.이 수식어는 다소 유사한 INCLUDE 메커니즘보다 이해하기 쉽습니다.

에러 처리

SPF 실장은 송신자 정책에서 구문 오류를 검출하면 즉시 평가를 중단하고 결과 PERMERROR을 생성해야 합니다.잘못된 메커니즘을 건너뛰는 것은 예상대로 작동하지 않습니다.include:bad.example그리고.redirect=bad.examplePERMERROR도 발생합니다.

또 하나의 안전장치는 DNS를 조회하는 메커니즘(IP4, IP6, ALL을 제외한 모든 메커니즘)의 최대 10개입니다.구현은 시간이 너무 오래 걸리거나 DNS 쿼리가 타임아웃된 경우 TEMPERROR 결과를 사용하여 평가를 중단하거나 쿼리가 데이터를 반환하지 않은 척을 계속할 수 있습니다. 이를 "회피 검색"이라고 합니다.단, 정책에 직간접적으로 메커니즘에 대해 10개 이상의 쿼리가 필요한 경우에는 PERMERROR를 반환해야 합니다.또, 2개 이상의 「회피한 검색」이 발생하면, 곧바로 PERMERROR를 반환할 필요가 있습니다.조금도redirect=또한 이 처리 [16]제한에도 반영됩니다.

일반적인 SPF HELO 정책v=spf1 a mx ip4:192.0.2.0 -all는 4개 이상의 DNS 쿼리를 실행할 수 있습니다. (1) TXT 레코드(SPF 타입은 RFC 7208에 의해 폐지됨), (2) 메커니즘의 A 또는 AAAA.a, (3) MX 레코드 및 (4+) 각 MX 이름에 대해 (A 또는 AAAA), 메커니즘mx첫 번째 쿼리를 제외하고 모든 쿼리는 10으로 카운트됩니다.또, 예를 들면, 송신측이 IPv6 주소를 가지고 있는 경우, 그 이름과 그 2개의 MX명이 IPv4 주소만을 가지고 있는 경우, 최초의 2개의 메카니즘을 평가하면, 이미 3개 이상의 보이드 룩업이 발생하고, 따라서 PERMERROR가 발생합니다.이 메커니즘에 주의해 주십시오.ip4,ip6그리고.allDNS 조회가 필요 없습니다.

문제들

DNS SPF 레코드

신속한 테스트와 전개를 가능하게 하기 위해 SPF의 초기 버전에서는 송신 도메인의 DNS TXT 레코드에서 설정이 확인되었습니다.이 레코드는 일반적으로 시멘틱스가 [17]부가되지 않은 자유 형식의 텍스트입니다.2005년 7월에 IANA는 SPF에 특정 자원 레코드 타입 99를 할당했습니다만, 의 사용율이 높은 경우는 없었습니다.또한 2개의 메커니즘으로 인해 사용자에게 혼란을 주고 있었습니다.2014년 SPFbis 작업 그룹이 "...가까운 장래에 SPF RR 유형으로의 중대한 이행은 거의 없을 것이며, 이 상호 운용성 문제를 해결하기 위한 최선의 해결책은 SPF [13]RR 유형에 대한 지원을 중단하는 것"이라고 결론 내린 후 이 기록의 사용이 중단되었다.

헤더 제한

SPF에 의해 스팸 발송자가 봉투 발신인 주소를 스푸핑하는 것을 점차 방지함에 따라 많은 경우 메일헤더의 [From]필드에 있는 주소만 스푸핑하는 것으로 이행하고 있습니다.이 주소는 수신인의 Message Transfer Agent(MTA; 메시지 전송 에이전트)에 의해서만 처리되는 것이 아니라 실제로 수신인에게 표시됩니다.SPF(또는 DKIM)를 DMARC와 함께 사용하여 메일헤더의 [From]필드를 체크할 수도 있습니다.이를 '식별자 정렬'이라고 합니다.

이러한 표시명의 스푸핑으로부터 보호하려면 , 커스텀 독자적인 실장이 필요하기 때문에,[18][19][20] SPF 를 이용할 수 없습니다.

도입

SpamAssin 버전 3.0.0 및 ASSP와 같은 안티스팸 소프트웨어는 SPF를 구현합니다.많은 Mail Transfer Agent(MTA; 메일 전송 에이전트)는 Courier, CommuniGate Pro, Wildcat, MDaemon, Microsoft Exchange 등의 SPF를 직접 지원하거나 Postfix, Sendmail, Exim, Qmtpd [21]등의 SPF를 지원하는 패치 또는 플러그인을 보유하고 있습니다.2017년 현재 800만 개 이상의 도메인이 SPF FAIL을 게시하고 있습니다.-all정책입니다.[22]2007년에 발표된 설문조사에 따르면.com그리고..net도메인에는 일종의 SPF 정책이 있습니다.2009년 Nokia Research에서 실시한 연속적인 조사에 따르면 테스트된 도메인의 51%가 SPF [23]정책을 지정하고 있습니다.이러한 결과에는 다음과 같은 사소한 정책이 포함될 수 있습니다.v=spf1 ?all를 클릭합니다.[24][25][needs update]

2007년 4월 Financial Services Roundtable의 부문인 BITS는 SPF [26]도입을 포함한 멤버에 대한 이메일 보안 권장사항을 발표했습니다.2008년에 Messaging Anti-Ause Working Group(MAAWG)은 SPF, Sender ID 및 DomainKeys Identified Mail(DKIM;[27] 도메인키 식별 메일)에 관한 전자 메일 인증에 관한 논문을 발표했습니다.MAAWG는 "송신자 베스트 커뮤니케이션 프랙티스"에서 "송신자는 적어도 자신의 메일링 [28]도메인에 SPF 레코드를 포함해야 한다"고 명시했습니다.2015년 MAAWG(Messaging Anti-Ause Working Group)는 SPF, DomainKeys Identified Mail(DMARC; 도메인키 식별 메일) 및 DMARC(DMARC)에 관한 이메일 인증에 관한 논문을 개정했습니다.MAAWG는 개정된 "발신자 베스트 커뮤니케이션 프랙티스"에서 다음과 같이 기술했다. "인증에서는 메시지의 발신자를 추가로 식별함으로써 투명성을 지원함과 동시에 위장 및 위조된 [29]주소의 감소 또는 제거에도 기여한다."

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Carranza, Pablo (16 July 2013). "How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability". DigitalOcean. Archived from the original on 20 April 2015. Retrieved 23 September 2019. A carefully tailored SPF record will reduce the likelihood of your domain name getting fraudulently spoofed and keep your messages from getting flagged as spam before they reach your recipients. Email spoofing is the creation of email messages with a forged sender address; something that is simple to do because many mail servers do not perform authentication. Spam and phishing emails typically use such spoofing to mislead the recipient about the origin of the message.
  2. ^ a b David, Green. "Mail-Transmitter RR". marc.info. Retrieved 15 May 2019.
  3. ^ "Sender Policy Framework: Introduction". Archived from the original on 2019-02-22.
  4. ^ RFC7208 상태
  5. ^ a b c "The History of SPF". DMARCian. DMARCian.org. 2019-03-18. Retrieved 15 May 2019.
  6. ^ 데이비드 그린으로 쓰다
  7. ^ Paul, Vixie. "Re: Mail-Transmitter RR". marc.info. Retrieved 15 May 2019.
  8. ^ "SPF: History/Pre-SPF". Retrieved 16 May 2009.
  9. ^ RMX, DMP 및 SPF의 비교에 대해서는 이력 openspf 사이트의 Wayback Machine에서 RMX 및 DMP의 아카이브 완료 2008-04-25를 참조해 주세요.
  10. ^ "SPF: History/SPF-2003". Retrieved 16 May 2009.
  11. ^ Seltzer, Larry (22 September 2004). "Internet Task Force Shuts Down Anti-Spam Working Group". eWeek. Retrieved 15 May 2019.
  12. ^ Dan Schlitt (29 August 2013). "Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard". IETF Discussion List. IETF. Retrieved 16 December 2013.
  13. ^ a b c d Scott Kitterman (April 2014). "DNS Resource Records". Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF. sec. 3.1. doi:10.17487/RFC7208. RFC 7208. Retrieved 26 April 2014.
  14. ^ 왕, M, W. 슐릿.RFC 4408.2006년 4월 <http://tools.ietf.org/html/rfc4408>
  15. ^ "Why should I implement a SPF record on my domain?". Email Manual. May 2009. Archived from the original on January 29, 2010. Retrieved 2010-01-01.
  16. ^ Atkins, Steve (14 March 2016). "SPF: The rule of ten". wordtothewise.com. Retrieved 23 September 2019.
  17. ^ Steve Bellovin이 Wayback Machine에서 아카이브된 2004-04-13 (2004년 1월)에 의문을 나타냄
  18. ^ "Create an MIMECAST inbound lockout policy to STOP Email SPOOFING". Retrieved 25 August 2017.
  19. ^ "Prevent spoofed messages with spoofed senders detection". Retrieved 25 August 2017.
  20. ^ "How antispoofing protection works in Office 365". Retrieved 25 August 2017.
  21. ^ "Qpsmtpd SPF plugin". 2013. Archived from the original on 2013-06-29.
  22. ^ "SPF -all Domain Survey". 2017. Retrieved 2017-11-07.
  23. ^ "Nokia Research Report on SPF Adoption". Fit.Nokia.com. Nokia. 2011-09-19. Archived from the original on 2011-09-20. Retrieved 2016-04-05.
  24. ^ Liu, Cricket (January 2007). "Handicapping New DNS Extensions and Applications". ONLamp. Retrieved 2007-10-04.
  25. ^ "SPF Authentication: SPF-all vs ~all". EasyDMARC. 2020-12-04. Retrieved 2021-04-08.
  26. ^ "BITS Email Security Toolkit" (PDF). BITS. April 2007. Retrieved 2008-06-13.
  27. ^ Crocker, Dave (March 2008). "Trust in Email Begins with Authentication" (PDF). MAAWG. Archived from the original (PDF) on 2013-01-29. Retrieved 2011-07-28.
  28. ^ "MAAWG Sender Best Communications Practices Executive Summary" (PDF). MAAWG. 2011-10-07. Retrieved 2012-04-27.
  29. ^ "M3AAWG Sender Best Common Practices" (PDF). MAAWG. 2015-02-01. Retrieved 2016-09-01.

외부 링크