SMTP 인증

SMTP Authentication

SMTP Authentication은 흔히 SMTP AUTH(Simple Mail Transfer Protocol)의 확장자로, 클라이언트는 서버가 지원하는 인증 메커니즘을 사용하여 로그인할 수 있다.주로 제출 서버가 사용하며, 인증이 필수적이다.[1]

역사

1970년대에 Jon Postel이 지정한 SMTP는 이메일 메시지 전송을 위한 패스워드를 사용할 수 있도록 제공하지 않았다. 각 서버는 오픈 메일 릴레이를 설계했다.그 결과, 스팸과 벌레는 처음에는 문제가 되지 않았지만, 90년대 후반에는 전염병이 되었다.[2]SMTP AUTH 이전에는 접속을 제공하는 동일한 인터넷 서비스 제공자(ISP)가 제공하는 이메일 서비스나 SMTP 이전의 POP와 같은 특정 해킹을 이용하는 것에 한해서만 릴레이 클라이언트를 IP 주소로 식별해야 했다.

존 가디너 마이어스는 1995년에 SMTP AUTH의 초안을 발표하였으며,[3] 메일 제출 프로토콜, 확장 SMTP(Extended SMTP), SASL(Simple Authentication and Security Layer) 등과 함께 IETF에서 연속적으로 개발, 논의되어 왔다.ESMTP 인증(ESMTPA)을 위한 이전 SASL 메커니즘은 CRAM-MD5이며, HMAC에서 MD5 알고리즘(해시 기반 메시지 인증 코드)의 사용은 여전히 건전하다고 간주된다.[4]

인터넷메일 컨소시엄(IMC)은 1998년 메일 서버의 55%가 공개 릴레이였지만 2002년에는 1%에도 미치지 못했다고 보고했다.[5][6]

메일 전송 시스템의 역할

일반적으로 포트 587에서 메일 제출 에이전트(MSA)를 사용하는 것은 SMTP AUTH를 의미한다. MSA 사용은 대부분의 소프트웨어에서[7] 지원되며, 특히 여러 네트워크 허브가 포트 25를 차단하거나 SMTP 프록시를 사용하기 때문에 유목민 사용자를 지원하기 위해 권장된다.MSA는 메시지 봉투에 양호한 주소가 포함되어 있는지 확인할 책임이 있으며 헤더 필드에 대한 로컬 정책을 시행할 수 있다.DKIM을 사용하여 메시지에 서명하는 도메인에는 SPF 및 From 주소에 사용되는 봉투 발신인(.k.a.)이 인증된 사용자 ID와 일치하는지 확인하는 것이 특히 중요하다.

다음과 같은 "A"로 끝나는 키워드ESMTPA그리고ESMTPSA 는 SMTP AUTH로 메시지가 수신될 때 헤더 필드의 절에 대해 제공된다."[8]키워드는 통계 또는 진단 목적으로 제공된다."(RFC 3848); 일부 클라이언트(예: Spamassassassin)에 의해 확인된다.

세부 사항

모든 SMTP 확장자와 마찬가지로, SMTP AUTH는 지원되는 인증 방법 목록과 함께 EHLO 응답에 광고된다.이러한 방법은 STARTLS를 발행한 후에 변경될 수 있으며, 일반적으로 후자의 경우에만 일반 텍스트 암호를 허용한다.RFC 4954는 다음과 같은 예("C:"와 "S:"는 프로토콜의 일부가 아니며, 각각 클라이언트와 서버가 전송한 라인을 나타낸다. 

S: 220 smtp.example.com ESMTP 서버 C: EHLO client.example.com S: 250-smtp.example.com S: client.example.com Hello S: 250-AUTH GSSAPI 다이제스트-MD5 S: 250-ENGHEDSTATIODS S: 250 STARTLS C: 220 TLS 시작 준비... TLS 협상이 진행되다.TLS 계층에 의해 보호되는 추가 명령...C: EHLO client.example.com S: 250-smtp.example.com Hello S: client.example.com S: 250 AUTH GSSAPI 다이제스트-MD5 PLINE C: AUTH 플레인 dGVzdAB0ZXN0ADEyMzQ=S: 235 2.7.0 인증 성공

SMTP AUTH는 포트 25에서도 사용할 수 있다.일반적으로 서버는 인증 자격 증명이 승인되지 않은 경우 릴레이를 암시하는 RCPT TO 명령을 거부한다.서버가 인증을 요구하도록 구성되고 클라이언트가 아직 인증하지 않은 경우 대부분의 명령에 대해 서버가 필요한 530 5.7.0 인증을 발급할 것을 명문화했다.포트 587에서 수신하는 서버, 즉 프라이빗 서버만 MX(Message eXchange)가 아닌 그런 방식으로 구성해야 한다. 다만, SMTP가 기본적으로 인증되지 않는 과거의 특성은 액세스 프로토콜에 관하여, 예를 들어, STARTLS 후 AUTH EXTERNERTERNE를 사용할 때, 다른 동작으로 귀결된다.[9]

AUTH 명령 외에도, 확장은 MAIL FROM 명령에 AUTH 매개 변수를 제공하여 인증과 권한 부여를 구별할 수 있도록 한다.그렇게 하면, 송신자는 자신을 식별할 수 있고 같은 세션 동안 여러 개의 메시지를 전송할 수 있다.인증이 변경될 필요는 없지만 일단 설정되면 서로 다른 계약에 따라 서로 다른 메시지가 전송될 수 있으므로 다른 인증이 필요할 수 있다.예를 들어, 메시지는 다른 사용자를 대신하여 전달될 수 있다.이 매개변수의 사용은 명령을 사용하여 릴레이 권한을 부여하는 것보다 훨씬 덜 인기 있다.

SMTP 인증은 SMTP 용어로 "확장"이므로 서버 및 클라이언트가 구식 HELO 인사말과는 달리 확장 지원을 나타내는 인사말을 EHLO 동사를 사용해야 한다.[10]역호환성을 위해 확장자를 사용하지 않을 때 HELO 인사말을 수락할 수 있다.

AUTH 명령 뒤에 대문자로 표시된 텍스트는 SMTP 서버가 허용할 권한 유형의 목록이다.

승인 프로토콜의 일부 예는 다음과 같다.

표준

  • RFC 3207, Transport Layer Security를 통한 Secure SMTP를 위한 SMTP Service Extension, Paul Hoffman, 2002년 2월.
  • RFC 3848, ESMTP 및 LMTP 전송 유형 등록, Chris Newman, 2004년 7월.
  • RFC 6409, 메일 메시지 제출, 랜달 겔렌스, 존 C. Klensin, 2011년 11월 (RFC 4409, 2006년 이후, 1998년 12월부터 RFC 2476을 대체)
  • RFC 4422, SASL(Simple Authentication and Security Layer), 알렉세이 멜니코프 및 커트 D.Zeilenga, 2006년 6월.
  • RFC 4616, 더 플레인 SASL 메커니즘, K. Zeilenga, Ed, 2006년 8월.
  • RFC 4954, 인증을 위한 SMTP 서비스 확장, Robert Siemborski 및 알렉세이 멜니코프, 2007년 7월.
  • RFC 7628, OAuth, W. Mills, T를 위한 SASL(Simple Authentication and Security Layer) 메커니즘 세트.쇼월터와 H.쵸페니그, 2015년 8월.

기타

참고 항목

참조

  1. ^ 참조를 위한 관련 RFC는 #표준 섹션에 명시되어 있다.
  2. ^ The Trustees of Indiana University (2008-04-01). "In Unix, what is an open mail relay?". University Information Technology Services. Indiana University. Archived from the original on 2007-06-17. Retrieved 2008-04-07.
  3. ^ John Gardiner Myers (April 1995). "SMTP Service Extension for Authentication". IETF. Retrieved 2010-05-30.
  4. ^ Sean Turner, Lily Chen (March 2011). "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms". IETF.
  5. ^ Paul Hoffman (February 1, 1998). "Allowing Relaying in SMTP: A Survey". Internet Mail Consortium. Retrieved 2010-05-30.
  6. ^ Paul Hoffman (August 2002). "Allowing Relaying in SMTP: A Series of Surveys". Internet Mail Consortium. Archived from the original on 2007-01-18. Retrieved 2010-05-30.
  7. ^ Randall Gellens (January 19, 2005). "Message Submission Interoperability Report". IETF. Retrieved 2019-07-05.
  8. ^ "Mail parameters". IANA registry. Retrieved 2011-07-23.
  9. ^ Chris Newman (30 Apr 2010). "Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL". IETF. Retrieved 2010-05-30.
  10. ^ https://tools.ietf.org/html/rfc5321; 그러나, 이전과 호환되는 구현과의 호환성을 위해 SMTP 클라이언트와 서버는 반드시 원래의 HELO 메커니즘을 예비로 지원해야 한다.
  11. ^ K. 머치슨과 M.Crispin, The LOGIN SASL Mechanism, 2003년 8월 28일, 초안이 만료되었다.LOGIN은 SASL 메커니즘 문서에서 구식이라고 설명되지만 메커니즘은 여전히 사용 중이다.
  12. ^ Gmail의 XOAuth2 SASL 프로토콜