이메일 인증

Email authentication

전자 메일 인증 또는 검증은 메시지 전송 및 수정에 참여한 모든 메시지 전송 에이전트(MTA)의 도메인 소유권을 검증하여 전자 메일 메시지의 발신원에 대한 검증 가능한 정보를 제공하는 것을 목적으로 하는 기술 모음입니다.

인터넷 전자 메일의 원래 기반인 Simple Mail Transfer Protocol(SMTP)에는 이러한 기능이 없기 때문에 전자 메일의 위조 발신인 주소(전자 메일 스푸핑이라고 알려진 관행)는 피싱, 전자 메일 스팸 및 다양한 유형의 사기에 널리 사용되어 왔습니다.이에 대처하기 위해 많은 경쟁 이메일 인증 제안이 개발되었지만 SPF, DMIM 및 DMARC의 [1][2]세 가지가 널리 채택되었습니다.이러한 검증 결과는 자동 전자 메일 필터링에 사용하거나 적절한 액션을 선택할 때 수신자를 지원할 수 있습니다.

이 문서에서는, 전자 메일의 송신 및 취득에 관한 사용자 인증에 대해서는 설명하지 않습니다.

근거

1980년대 초, Simple Mail Transfer Protocol(SMTP)이 설계되었을 때, 그것은 송신 사용자나 시스템에 대한 실질적인 검증을 제공하지 않았다.이것은 신뢰할 수 있는 기업이나 대학이 이메일 시스템을 운영하는 동안에는 문제가 되지 않았지만, 1990년대 초 인터넷이 상용화된 이후 스팸, 피싱 및 기타 범죄가 이메일을 수반하는 경우가 증가하고 있습니다.

전자 메일 인증은 메시지의 발신지를 식별하기 위한 필수 첫 번째 단계이며, 이를 통해 정책 및 법률을 보다 효과적으로 적용할 수 있습니다.

도메인 소유권에 의존하는 것은 2000년 [3][4]초에 등장한 자세이다.도메인이 전자 메일 주소의 오른쪽에서 앳 기호 뒤에 나타나기 때문에 대략적인 인증을 의미합니다.사용자 레벨에서의 세밀한 인증은 Pretty Good Privacy나 S/MIME 등 다른 방법으로도 가능합니다.현재로서는 디지털 ID를 개인별로 관리해야 합니다.

전자 메일 인증의 뛰어난 근거는, 수신 서버의 전자 메일 필터링을 자동화하는 기능입니다.이렇게 하면 스푸핑된 메시지는 사용자의 받은 편지함에 도착하기 전에 거부될 수 있습니다.프로토콜은 신뢰할 수 있는 방법으로 신뢰할 수 없는 메일을 차단하기 위해 노력하지만 보안 표시기는 여전히 받은 편지함에 도달하는 인증되지 않은 메시지에 태그를 지정할 수 있습니다.2018년 연구에 따르면 보안 표시기는 스푸핑된 [5]메시지를 여는 사용자의 48.9%에서 37.2%로 클릭률을 10포인트 이상 낮출 수 있습니다.

문제의 성질

SMTP는 메시지 내용이 아닌 메시지 전송을 정의합니다.따라서 메일 봉투 및 봉투 발송인 등의 매개 변수를 정의하지만 헤더(트레이스 정보 제외)나 메시지 본문 자체는 정의하지 않습니다.STD 10 및 RFC5321은 SMTP(엔벨로프)를 정의하고 STD 11 및 RFC5322는 메시지(헤더 및 본문)를 정의합니다.이 메시지는 정식적으로는 인터넷메시지 형식이라고 불립니다.

SMTP 는 메시지의 트레이스 정보를 정의합니다.이 정보는 다음 2개의 [6]필드를 사용하여 헤더에 저장됩니다.

  • 수신: SMTP 서버는 메시지를 수신하면 헤더 상단에 이 트레이스 레코드를 삽입합니다(마지막에서 첫 번째).
  • Return-Path: 전달 SMTP 서버가 메시지를 최종 전달하면 헤더 상단에 이 필드를 삽입합니다.

메일 사용자 에이전트(MUA)는 설정에서 발신 메일 SMTP 서버를 인식합니다.일반적으로 MTA(또는 릴레이 서버)는 각 수신인의 도메인 이름에 대한 MX(Mail eXchange) DNS 리소스 레코드를 검색하여 연결할 서버를 결정합니다.

다음에 나타내는 경로는 [6]각 호스트가 메시지를 수신했을 때 헤더 상단에 추가하는 트레이스 헤더필드의 그라운드에서 재구성할 수 있습니다.

이메일 인증 중간 계전기의 존재에 의해 복잡할 수 있다.는 네트워크의 D와 E부분 A와 B분명하게 작가의 행정 관리 도메인에 속한다.C가 어떤 역할을 하니?
Return-Path:<>작가 @ example.com&gt은 SMTP와 함께E.example.org에 의해D.example.org수령, 화요일, 2월 5일 2013년 킬러:02-0500:SMTP와 함께D.example.org에 의해C.example.net수령, 화요일, 2월 5일 2013년 킬러:02-0500:B.example.com(b.example.com[192.0.2.1]에서)ESMTP 아이디 936년과C.example.net(저는)에서 환영 받다.ADB8838C<>;different-recipient @ example.net>화요일, 2월 5일 2013년 08:44:50-0800(물품 거래세):SMTP와 함께B.example.com에 의해A.example.com수령, 화요일, 2월 5일 2013년 17:44:47+0100:SMTP와 함께A.example.com에 의해[192.0.2.27]수령, 화요일, 2월 5일 2013년 17:44:42+0100.

헤더 상단의 첫 번째 몇 행은 보통 수신자가 신뢰하는 행임을 인식하는 것이 중요합니다.실제로, 이러한 행은, 수신자의 관리 도메인(ADMD)에 있는 머신에 의해서 작성됩니다.ADMD는 수신자 또는 수신자의 명시적인 권한에 따라 동작합니다.반면 A와 B의 관련성을 입증하는 대사, 작가로 추정되는 MUA는 C가 만든 위조품일 수 있다.그Received:위의 필드는 헤더의 획기적인 부분입니다.그Return-Path:는 메일 배달 에이전트(MDA) E에 의해 메시지 봉투에 근거해 작성됩니다.이메일 인증용으로 설계된 추가 트레이스 필드는 헤더 상단에 입력할 수 있습니다.

일반적으로 작성자의 ADMD에 의해 전송되는 메시지는 대상의 MX로 직접 전송됩니다(그림에서는 B → D).발신인의 ADMD는 메시지가 상자를 통과하는 경우에만 인증 토큰을 추가할 수 있습니다.가장 일반적인 사례는 다음과 같이 도식화할 수 있습니다.

전자 메일 메시지를 작성자에서 수신자에게 전송할 수 있는 가장 일반적인 방법을 개략적으로 나타냅니다.

ADMD 네트워크(MUA 1)에서 송신

  • ADMD의 MSA는 IP 주소 또는 기타 SMTP 인증 수단을 기반으로 사용자를 인증합니다.메시지는 수신인 주소에 따라 일반 경로를 따르거나 메일 목록 또는 포워딩 서비스를 [note 1]통과할 수 있습니다.B 는, 발신 SMTP 프록시 또는 [note 2]SMarthost 로 할 수 있습니다.
  • 로컬 네트워크가 발신 포트 25 [note 3]접속을 차단하지 않는 경우 사용자는 몇 가지 "direct-to-mx"[note 4] 소프트웨어를 도입할 수 있습니다.일반적으로 좀비 및 기타 악의적인 호스트는 이와 같이 동작합니다.
  • MUA가 올바르게 설정되어 있지 않은 경우는, 구식의 오픈 릴레이 등, 사용자를 인증하지 않는 다른 릴레이를 사용할 수도 있습니다.

로밍 사용자(MUA 2)

  • 대부분의 경우 자신의 ADMD [note 5]MSA를 사용할 수 있습니다.
  • 포트 25 에의 발신 접속을 대행 수신해, 트랜스페어런트프록시에 [note 4]터널링 할 수 있습니다.
  • 로컬 네트워크 공급자가 보너스로 [note 4]제공하는 SMTP 릴레이를 사용하도록 MUA를 설정할 수 있습니다.

절단된 사용자

  • 전자 카드는 로컬 키보드로 이메일 주소를 입력한 고객을 대신하여 메일을 보낼 수 있습니다. 일부 웹 양식도 [note 4]비슷하게 작동하는 것으로 간주할 수 있습니다.

섹션 노트

  1. ^ 예를 들어, 수신자는 Gmail에 메시지를 다른 전자 메일 주소로 전달하도록 지시할 수 있습니다.송신자가 반드시 그것을 알고 있는 것은 아닙니다.
  2. ^ 적절하게 설정된 프록시는 작성자 ADMD의 일부로 나타납니다.
  3. ^ 일부 ADMD는 이를 피하기 위해 포트 25(SMTP)로의 발신 접속을 차단합니다.이 프로 액티브한 수법은 RFC 5068에 기재되어 있습니다.또, 다이얼 업/DSL/케이블로서 리스트 되고 있는 IP로부터의 착신 SMTP 접속을 차단하는 것도 있습니다.
  4. ^ a b c d 이 경우 저자의 ADMD는 전혀 관여하지 않습니다.
  5. ^ 일부 ISP는 포트 587을 차단하지만 RFC 5068에는 다음과 같이 명시되어 있습니다.

    액세스 공급자는 사용자가 SUBMSION 포트 587을 사용하여 외부 인터넷에 액세스하는 것을 차단하지 마십시오.

널리 사용되는 인증 방식

SPF

주요 기사:송신자 정책 프레임워크
SPF 는, 송신원IP 주소를 인증합니다.

SPF 를 사용하면, 수신자는, 특정 도메인으로부터 송신되었다고 하는 전자 메일이, 그 도메인의 관리자가 허가한 IP 주소로부터 송신되고 있는 것을 확인할 수 있습니다.통상, 도메인 관리자는, 프록시 또는 SMarthost [7][8]를 포함한 독자적인 발신 MTA 에 의해서 사용되는 IP 주소를 허가합니다.

송신측 MTA 의 IP 주소는, 리모트호스트가 [9]도달 가능한 것을 체크하는 것으로 접속을 확립하기 때문에, Transmission Control Protocol 에 의해서 유효하게 됩니다.수신 메일 서버는,HELO 접속 셋업 직후 SMTP 명령어 및Mail from:각 메시지의 선두에 표시됩니다.둘 다 도메인 이름을 포함할 수 있습니다.SPF 검증자는 일치하는 SPF 레코드를 Domain Name System(DNS; 도메인네임 시스템)에 문의합니다.SPF 레코드가 있는 경우 해당 도메인 관리자가 인가한IP 주소를 지정합니다.결과는 "합격", "실패" 또는 일부 중간 결과가 될 수 있습니다. 시스템은 일반적으로 안티스팸 [10]필터링에서 이 점을 고려합니다.

DKIM

주요 기사:도메인 키 식별 메일
DKIM은 메시지 내용의 일부를 인증합니다.

DKIM은 디지털 서명을 전개하여 메시지 내용을 확인합니다.디지털 증명서를 사용하는 것이 아니라, 서명 검증용의 키는 DNS 경유로 배포됩니다.이렇게 하면 메시지가 도메인 [11]이름에 관련지어집니다.

DKIM 준거 도메인 관리자는 1개 또는 여러 쌍의 비대칭 키를 생성하여 서명 MTA에 개인 키를 건네고 DNS에 공개 키를 공개합니다.DNS 라벨은 다음과 같이 구성됩니다.selector._domainkey.example.com여기서 selector는 키쌍을 식별합니다._domainkey는 고정 키워드이며, 그 뒤에 서명 도메인의 이름이 계속되기 때문에 해당 도메인의 ADMD 권한으로 퍼블리싱이 이루어집니다.SMTP 트랜스포트 시스템에 메시지를 삽입하기 직전에 서명 MTA는 헤더와 본문의 선택된 필드(또는 그 시작 부분)를 커버하는 디지털 서명을 작성합니다.시그니처는 다음과 같은 실질적인 헤더필드를 커버해야 합니다.From:,To:,Date:,그리고.Subject:메시지 헤더 자체에 트레이스 필드로 추가됩니다.임의의 수의 릴레이가 메시지를 수신 및 전송할 수 있으며 홉마다 DNS에서 [12]공용 키를 검색하여 서명을 확인할 수 있습니다. 중간 릴레이가 메시지의 서명 부분을 수정하지 않는 한 DKIM 서명은 유효합니다.

DMARC

주요 기사:도메인 기반 메시지 인증, 보고서 작성 및 적합성

DMARC를 사용하면 인증된 메시지에 대한 정책을 지정할 수 있습니다.Sender Policy Framework(SPF; 발신자 정책 프레임워크)와 DomainKeys Identified Mail(DKIM; 도메인 키 식별 메일)의 2개의 기존 메커니즘 위에 구축되어 있습니다.

도메인 관리자 소유자는 DNS 레코드에 정책을 게시하여 도메인에서 전자 메일을 보낼 때 어떤 메커니즘(DKIM, SPF 또는 둘 다)을 사용할지 지정할 수 있습니다.또한 도메인에서 전자 메일을 보낼 때 어떤 메커니즘(DKIM, SPF 또는 둘 다)을 사용하는지,From:최종 사용자에게 표시되는 필드, 수신자가 장애에 대처하는 방법, 그리고 이러한 정책에 따라 수행되는 액션에 대한 보고 메커니즘.

기타 방법

다양한 다른 방법들이 제안되었지만, 지금은 폐지되었거나 아직 광범위한 지지를 얻지 못했다.여기에는, 송신자 ID, 인정 서버 검증, 도메인 키, 및 이하가 포함됩니다.

ADSP

주요 기사:작성자 도메인 서명 방법

ADSP는 작성자의 도메인에 의해 서명된 메시지에 대한 정책 지정을 허용했습니다.메시지는 처음에 DKIM 인증을 통과해야 합니다.그 후 ADSP는 메시지가 작성자 도메인에 의해 서명되지 않은 경우 다음과 같이 가혹한 처리를 요구할 수 있습니다.From:헤더 [13]필드

ADSP는 2013년 [14]11월에 역사로 강등되었다.

VBR

주요 기사:참조에 의한 보증

VBR은 이미 인증된 ID에 보증을 추가합니다.이 방법을 사용하려면 도메인 평판을 인증하는 글로벌하게 인정된 기관이 필요합니다.

송신자는, 보증 기관에 참조를 신청할 수 있습니다.참조가 받아들여질 경우 해당 기관이 관리하는 DNS 브랜치에 게시됩니다.보증된 송신자는,VBR-Info:[ header ]필드를 지정합니다.또한 DKIM 시그니처를 추가하거나 SPF 등의 다른 인증 방식을 사용해야 합니다.수신자는, 송신자의 ID를 검증한 후에, 다음의 장소에서 청구된 보증인을 검증할 수 있습니다.VBR-Info:참고 [15]자료를 찾아보세요.

iprev

주요 기사:Forward-Confirmed 리버스 DNS

애플리케이션은 [16]인증 수단으로 이 방법을 사용하지 않도록 해야 합니다.그럼에도 불구하고, 그것은 종종 수행되고 그 결과는 있는 경우,Received:SMTP 사양에 필요한 TCP 정보 이외의 헤더필드를 지정합니다.

IP 리버스(IP reverse)는, 방금 검출된 이름의 IP 주소를 검색해 확인할 수 있습니다.이것은, DNS 로 IP 가 올바르게 설정되어 있는 것을 나타내고 있는 것에 지나지 않습니다.IP 주소 범위의 역방향 해결은 [17]IP 주소를 사용하는 ADMD에 위임하거나 네트워크 공급자가 계속 관리할 수 있습니다.후자의 경우 메시지와 관련된 유용한 ID를 얻을 수 없습니다.

DNSWL

DNSWL(DNS 기반 화이트리스트)를 검색하면, 송신자의 식별 정보를 포함해, 송신자를 평가할 수 있습니다.

인증 결과

RFC 8601은 트레이스 헤더필드를 정의하고 있습니다.Authentication-Results:수신자가 수행한 [16]전자 메일 인증 확인 결과를 기록할 수 있습니다.여러 메서드에 대한 여러 결과를 세미콜론으로 구분하여 같은 필드에 보고할 수 있으며 필요에 따라 래핑할 수 있습니다.

예를 들어, 다음 필드는 다음과 같이 기술되어 있습니다.receiver.example.org및 SPF 및 DKIM 결과를 보고합니다.

인증 결과: receiver.example.org, spf=pass smtp.mail from=example.com, dkim=pass 헤더.i=@module.com

필드 이름 뒤의 첫 번째 토큰,receiver.example.org는 인증 서버의 ID로 authserv-id라고 불리는 토큰입니다.RFC 8601을 지원하는 리시버는 다운스트림필터가 혼동되지 않도록 자신의 도메인에 속해 있다고 주장하는 잘못된 헤더를 삭제(또는 이름 변경)할 책임이 있습니다.다만, 이러한 필터는, 도메인이 사용할 수 있는 ID 를 인식할 필요가 있기 때문에,

메일 사용자 에이전트(MUA)의 경우 신뢰할 수 있는 ID를 파악하는 것이 약간 어렵습니다.사용자는 여러 도메인(예를 들어 여러 개의 이메일 주소가 있는 경우)에서 이메일을 수신할 수 있기 때문에 이러한 도메인은 모두Authentication-Results:필드는 중립적으로 보이기 때문에 통과합니다.이렇게 하면 악의적인 송신자는 메시지가 다른 도메인에서 도착했을 때 사용자가 신뢰할 수 있는 authserv-id를 위조할 수 있습니다.합법적Authentication-Results:보통 바로 위에 나타나다Received:[ ] 필드(메시지가 릴레이된 도메인과 동일한 도메인)를 참조해 주세요.추가의Received:같은 신뢰할 수 있는 ADMD에 속하는 서버 간에 내부적으로 메시지가 전송되기 때문에 이 필드 및 헤더 상단에 필드가 표시될 수 있습니다.

Internet Assigned Numbers Authentication Parameters(인터넷 할당 번호 기관)는 전자 메일 인증 매개 변수의 레지스트리를 관리합니다.단, 모든 파라미터를 등록할 필요는 없습니다.예를 들어 로컬 구성에 대응하여 등록할 필요가 없는 사이트 내부용으로만 설계된 로컬 "정책" 값이 있을 수 있습니다.

참고 항목

레퍼런스

  1. ^ Hang Hu; Peng Peng; Gang Wang (2017). "Towards the Adoption of Anti-spoofing Protocols". arXiv:1711.06654 [cs.CR].
  2. ^ kerner, Sean Michael. "DMARC Email Security Adoption Grows in U.S. Government". eWeek. Retrieved 24 November 2018.
  3. ^ "Email Authentication Summit". workshop. Federal Trade Commission. November 9–10, 2004. Archived from the original on 3 June 2012. Retrieved 4 February 2013. The Report, however, identified domain-level authentication as a promising technological development{{cite web}}: CS1 유지보수: 부적합한 URL(링크)
  4. ^ Michael Hammer (14 August 2020). "third party authorization". dmarc-ietf (Mailing list). Retrieved 14 August 2020.
  5. ^ Hang Hu; Gang Wang (15 August 2018). "End-to-End Measurements of Email Spoofing Attacks". 27th USENIX Security Symposium.
  6. ^ a b John Klensin (October 2008). "Trace Information". Simple Mail Transfer Protocol. IETF. sec. 4.4. doi:10.17487/RFC5321. RFC 5321. Retrieved 1 February 2013. When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. This trace record indicates the identity of the host that sent the message, the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines.
  7. ^ Scott Kitterman (April 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. IETF. doi:10.17487/RFC7208. RFC 7208. Retrieved 26 April 2014. There are three places that techniques can be used to ameliorate unintended SPF failures with mediators.
  8. ^ J. Klensin (October 2008). "Alias". Simple Mail Transfer Protocol. IETF. sec. 3.9.1. doi:10.17487/RFC5321. RFC 5321. Retrieved 15 February 2013.
  9. ^ IP 주소의 위조가 가능하지만, 일반적으로는, 일반적인 해커나 스팸 송신자, 또는 RFC 1948 를 실장하고 있지 않은 시큐러티한 서버에는 너무 위험한, 보다 낮은 레벨의 범죄 행위(침입, 도청 등)를 수반합니다.「 Transmission Control Protocol # Connection Hijacking 」도 참조해 주세요.
  10. ^ Scott Kitterman (Nov 21, 2009). "How reliable is it to block/reject on SPF fail?". spf-help. gossamer-threads.com. I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders.
  11. ^ D. Crocker; T. Hansen; M. Kucherawy, eds. (September 2011). DomainKeys Identified Mail (DKIM) Signatures. IETF. doi:10.17487/RFC6376. RFC 6376. Retrieved 18 February 2013. DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message, which they are authorized to use.
  12. ^ Dave Crocker (16 Oct 2007). "DKIM Frequently Asked Questions". DKIM.org. Retrieved 17 February 2013.
  13. ^ E. Allman; J. Fenton; M. Delany; J. Levine (August 2009). DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). IETF. doi:10.17487/RFC5616. RFC 5616. Retrieved 18 February 2013.
  14. ^ Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF.
  15. ^ P. Hoffman; J. Levine; A. Hathcock (April 2009). Vouch By Reference. IETF. doi:10.17487/RFC5518. RFC 5518. Retrieved 18 February 2013.
  16. ^ a b Murray Kucherawy (August 2015). Message Header Field for Indicating Message Authentication Status. IETF. doi:10.17487/RFC7601. RFC 7601. Retrieved 30 September 2015.
  17. ^ H. Eidnes; G. de Groot; P. Vixie (March 1998). Classless IN-ADDR.ARPA delegation. IETF. doi:10.17487/RFC2317. RFC 2317. Retrieved 18 February 2013.