Simple Email Service - SES

공식문서

 

SMTP vs POP3 vs IMAP

SMTP (Simple Mail Transfer Protocol)

• SMTP는 메일을 이메일 서버로 전송할 때(sending out email to an email server) 사용되는 프로토콜이다.
• e.g. Microsoft Outlook, Thunderbird, Apple Mail
• 포트는 보통 25를 사용하나 587 또는 465를 사용하는 경우도 있다(보통 사용을 안한다).

POP3 vs IMAP

• POP3와 IMAP은 이메일을 받을때 (retrieve email from a mail server) 사용되는 프로토콜이다
• POP3는 110 포트를 IMAP은 143(또는 SSL/TLS는 993)을 사용한다
• 두 프로토콜에 대한 대표적인 차이
  • POP3은 전송이 끝난후에 바로 메세지를 이메일 서버에서 삭제하지만(server storage space) 
  • IMAP은 전송이 끝나도 메세지의 카피본을 이메일 서버에 유지한다 (anytime, anywhere access)
  • 그러므로 용량을 고려한다면 POP3 만약 여러 Device를 통해 이메일을 받아야된다면 IMAP을 고르는것이 좋다.

출처 : www.jscape.com/blog/smtp-vs-imap-vs-pop3-difference

 

스팸 메일을 방지 하기위한 기법

DKIM (Domain Keys Identified Mail)

• 메일 헤더에 서명값을 넣은 뒤 공개키를 이용해 메일의 위.변조 여부 확인
  • 발신 측에서는 자신의 DNS에 공개키를 등록하고, 메일에는 개인키로 서명을 한 뒤 전송한다.
    (공개키, 개인키를 이용한 해시값을 포함)
  • 수신 측에서는 발시자 DNS로부터 공개키를 받아 만든 해시값과 메일에 포함된 해시값을 비교하여 일치 여부를 확인한다.

 

SPF (Sender Policy Framcework)

• 메일 수신 측에서 발신서버에 직접 메일 전송 여부를 확인
  • 발신 측에서는 DNS에 SPF Record를 설정하여 등록한다.
  • SPF Record에는 메일 서버 IP정보, 사칭 메일에 대한 필터링 정책을 담고 있다.
  • 수신 측에서는 받은 메일에 표기된 발신자 DNS에 SPF 레코드를 조회하여 사칭 메일 여부를 확인하다
    (SPF의 IP정보와 발신 IP가 다르다면 차단)

 

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

• 위의 SPF, DKIM 기술을 모두 활용하여 메일을 확인하고, 자신의 메일 또는 도메인을 사칭한 메일에 대한 보고
  • 발신 측에서는 메일에 DKIM 헤더를 첨부한다.
  • 수신 측에서는 발신자 DNS로부터 DMARC 정책을 조회하고, 이에 따라 DKIM, SPF를 확인한다. 이후 격리/거부 된 메일에 대하여 발신 측에 전달 오류를 보고한다.DMARC를 사용하면 조직 또는 도메인에서 메일을 받는 이메일 서버에서 보고서를 요청함
  • DKIM 기반으로 DMARC를 준수하도록 하려면 
    1. 메세지에 유효한 DKIM 서명이 있어야 한다.
    2. 이메일 헤더의 From 주소가 DKIM 서명의 d= 도메인과 일치해야 한다(Sub 도메인이어도 무방).

DMARC의 배경

대부분의 메일 서비스는 다수의 시스템으로 구성된 복잡한 환경이다. SPF, DKIM 기술이 지원되고 있지만 모든 시스템에서 메시지들이 SPF, DKIM을 통해 인증된다는 보장은 없다. 이 때문에 수신측은 인증되지 않은 메일이라도 모두 거부할 수 없다. 인증되지 않은 정상 메일과 부정 메일이 섞여 받을 수 밖에 없다.

발신측은 자신들이 전달한 메일 인증 결과 피드백도 받지 않는다. 정상 메시지 중 인증 실패 비율, 사칭 메일 비율 등을 파악하지 못하므로 전체적인 문제점을 해결하지 못한다.

이를 위해서는 발신 측과 수신 측이 정보를 공유해야 한다.

 

출처 : itsandtravels.blogspot.com/2019/09/spf-dkim-dmarc.html

 

다른 AWS 제품과의 연동

Amazon S3과의 연동

• 받은 이메일에 대한 S3 저장 기능을 제공한다.
• AWS Lambda를 통해 받은 이메일에 대한 Action을 정할 수 있다(메일을 통한 Alert 등 자동화가 필요한 상황을 위한 기능인듯).
• AWS Key Management Service (AWS KMS)를 통해 S3에 저장된 이메일을 암호화를 시킬 수 있다.
• AWS CloudTrail을 통해 Amazon SES API Logging이 가능하다.

 

Amazon SES and Delieverability

Deliverability = the percentage of your emails that arrive in your recipients' inboxes.

Email Deliverability를 극대화 시키기 위해서는 Email Delivery Issue에 대해 이해할 필요가 있다.

 

Understand Email Delivery Issues

• Bounce : 수신기(예:이메일 공급자)가 수신자에게 메세지를 전달 못하는 경우 수신기는 메세지를 Amazon SES로 반송합니다. 이에 Amazon SES는 이메일또는 Amaon SNS(Simple Notification Service)를 통해 사용자에게 반송된 이메일을 알립니다.
  • Hard Bounce : 지속적인 이메일 전송 실패 (예: 메일박스가 존재하지 않음), 왠만하면 해당 문제에선 지속적으로 이메일을 전송하지않게 하자.
  • Soft Bounce : 일시적인 이메일 전송 실패 (예: 메일박스가 꽉참, 메일박스에 대한 Connection이 꽉참[Throttling], Connection Times Out). Amazon SES는 해당 문제에 대해 추가적인 시도를 하게되지만, 끝까지 실패한다면 시도를 멈춘다.
• Complaint : 스팸으로 처리된 경우
• Global Suppression List : 최근에 Hard Bounce를 발생시킨 수신자 이메일 주소 목록. 금지된 이메일은 최대 14일까지 발송 금지 목록에 남는다.

결국 정리하자면 Issue는 두가지가 있다 : 시스템적인 문제 or 받는사람의 요청에 의한 문제
시스템 문제인 경우에 Soft Bounce면 일시적인 오류일 수 있기때문에 계속 시도하며 Hard Bounce면 영구적인 오류로 간주하여 Global Suppression List에 저장되어 다시 시도하지 못하게 한다.

 

Be Proactive

Amazon SES는 이메일 공급자로부터 신뢰할 수 있는 평판을 유지하고 있다. 평판 유지를 위해 아래의 요소들을 자동으로 수행한다.

• Verification : 전송 자격 증명 보호(이메일 헤더 조작, 발신 이메일 스푸핑 방지)
• Authentication : 발신자가 계정의 소유자며 메세지가 수정되지 않았음을 제공한다.
  • SPF 와 DKIM을 사용하여 Authentication을 수행한다.
• Sending Quotas : 특정 시간의 보낼 수 있는 이메일수를 제한함으로 스패머로 의심 받는일을 방지
  • 허용가능한 내에 할당량이 서서히 증가된다.
• Content Filtering : 이메일의 의심스러운 컨텐츠를 검색하여 검색된다면 해당 이메일을 차단한다(바이러스 차단도 포함).
• Reputation : 품질이 높은 콘텐츠를 전송함으로 Reputation을 유지
• High-Quality Email : 높은 품질의 이메일을 전송함으로 차단 방지

Stay Informed

이메일 전송 실패여부 또는 거부되었는지 여부를 알림으로 제공하고 통계치 모니터링을 제공한다

• Notifications : 알림기능
• Usage Statistics :통계치를 제공하는 기능

 

Improve Your Email-Sending Program

만약 이메일 Complaining 수가 증가하고 있다면 이메일 전송을 재 평가되며 만약 침해 사례가 인정 된다면 AWS 계정이 종료될 수 있다.
결국 SES사용자는 중요 이메일이나 수신자가 받아들일만한 이메일만을 전송해야 한다.

 

Email Format

Header : Routing Instruction, Routring Information

• To, CC, From, Subject, Date

Body : The text of the message itself

• HTML or Plain Text

Envelope : Email Client와 Mail 서버간의 Actual Routing Information (SMTP Session중의 Routing Information)

• Header와 Envelope에 있는 Routing 정보는 서로 다를 수 있다.

Response Codes

설명응답 코드추가 정보

인증 성공	235 Authentication successful	SMTP 클라이언트가 성공적으로 연결되어 SMTP 서버에 로그인했습니다.
전송 성공	250 Ok MessageID	MessageID 독특한 문자열로 Amazon SES 메시지를 식별하는 데 사용합니다.
서비스 사용 불가	421 Too many concurrent SMTP connections	현재, SMTP 서버에 대한 연결이 너무 많아 Amazon SES가 요청을 처리할 수 없습니다.
로컬 처리 오류	451 Temporary service failure	Amazon SES에서 요청을 처리할 수 없습니다. 요청이 처리되지 못하도록 막는 요청 관련 문제가 있을 수 있습니다.
Timeout	451 Timeout waiting for data from client	요청 간에 너무 많은 시간이 경과하여 SMTP 서버가 연결을 차단했습니다.
일일 전송 할당량을 초과함	454 Throttling failure: Daily message quota exceeded	Amazon SES가 24시간 기준으로 전송을 허용한 최대 이메일 수를 초과했습니다. 자세한 정보는 Managing Your Amazon SES sending quotas 단원을 참조하십시오.
최대 전송 속도를 초과함	454 Throttling failure: Maximum sending rate exceeded	Amazon SES가 초당 전송할 수 있도록 허용한 최대 이메일 수를 초과했습니다. 자세한 정보는 Managing Your Amazon SES sending quotas 단원을 참조하십시오.
SMTP 자격 증명 검증 시 Amazon SES 문제	454 Temporary authentication failure	이 문제의 원인일 수 있는 문제에는 다음이 포함되지만 이에 국한되지는 않습니다. There is a problem with the encryption between your email-sending application and Amazon SES. Note that you have to use an encrypted connection when you connect to Amazon SES. For more information, see Connecting to an Amazon SES SMTP endpoint. Amazon SES could be experiencing an issue. Check the AWS 서비스 상태 대시보드 for updates.
요청 수신 중 오류 발생	454 Temporary service failure	Amazon SES에서 요청을 수신하지 못했습니다. 따라서 메시지가 전송되지 않았습니다.
잘못된 자격 증명	530 Authentication required	이메일을 보내는 데 사용하는 애플리케이션이 Amazon SES SMTP 인터페이스에 연결할 때 인증을 시도하지 않았습니다.
인증 자격 증명이 유효하지 않음	535 Authentication Credentials Invalid	이메일을 전송하는 데 사용하는 애플리케이션이 Amazon SES에 대해 올바른 SMTP 자격 증명을 제공하지 않았습니다. SMTP 자격 증명과 AWS 자격 증명은 동일하지 않습니다. 자세한 정보는 Obtaining your Amazon SES SMTP credentials 단원을 참조하십시오.
계정이 Amazon SES에 가입되지 않음	535 Account not subscribed to SES	SMTP 자격 증명을 소유한 AWS 계정이 Amazon SES에 가입되지 않았습니다.
메시지가 너무 김	552 Message is too long.	전송하려는 메시지의 크기가 10MB보다 큽니다.
계정이 Amazon SES에 가입되지 않음	535 Account not subscribed to SES	SMTP 자격 증명을 소유한 AWS 계정이 Amazon SES에 가입되지 않았습니다.
사용자가 Amazon SES SMTP 엔드포인트를 호출할 권한이 없음	554 Access denied: User UserARN is not authorized to perform ses:SendRawEmail on resource IdentityARN	SMTP 자격 증명을 소유한 사용자의 AWS Identity and Access Management(IAM) 정책 또는 Amazon SES 전송 권한 부여 정책이 Amazon SES SMTP 엔드포인트를 호출하도록 허용되지 않습니다.
확인되지 않은 이메일 주소	554 Message rejected: Email address is not verified. The following identities failed the check in region region: identity0, identity1, identity2	Amazon SES 계정에서 이메일을 전송하도록 확인되지 않은 이메일 주소 또는 도메인에서 이메일을 전송하려고 합니다. 이 오류는 "From", "Source", "Sender" 또는 "Return-Path" 주소에 해당할 수 있습니다. 계정이 여전히 샌드박스에 있을 경우 Amazon SES 메일박스 시뮬레이터에서 제공하는 수신자를 제외한 모든 수신자 이메일 주소를 확인해야 합니다. Amazon SES에서 확인 점검에 실패한 ID를 모두 볼 수 없는 경우 오류 메시지가 마침표 세 개(...)로 끝납니다. 참고 Amazon SES는 여러 AWS 리전에 엔드포인트가 있으며 이메일 주소 확인 상태는 AWS 리전마다 서로 다릅니다. 사용하려는 AWS 리전에서 각 발신자에 대해 확인 프로세스를 완료해야 합니다.