먼저 메일 사용자 에이전트 또는 MUA를 사용하여 기기(예:gmail 또는 Apple 기기의 메일 앱)에서 이메일을 읽고 보냅니다. 이 프로그램은 사용할 때만 활성화됩니다.
일반적으로 이메일을 수신하고 저장하는 역할을 하는 메일 전송 에이전트 또는 MTA(메일 서버, MX 호스트 및 메일 교환기라고도 함)와 통신합니다.
이메일은 이메일을 확인하기 위해 MUA를 열 때까지 원격으로 저장됩니다. 이메일은 일반적으로 MTA와 함께 패키지로 제공되는 MDA(메일 배달 에이전트)에 의해 배달됩니다.
메일은 SMTP 또는 Simple Mail Transfer Protocol을 사용하여 메일 서버로 전송되었습니다. SMTP는 이메일을 위한 통신 프로토콜입니다.
지금도 Microsoft Exchange와 같은 많은 독점 시스템과 Gmail과 같은 웹메일 프로그램은 내부적으로 자체 프로토콜을 사용하지만 SMTP를 사용하여 시스템 외부로 메시지를 전송합니다(예:Gmail 사용자가 Outlook 클라이언트에 이메일을 보내려는 경우).
그런 다음 POP3(Post Office Protocol)를 사용하여 서버에서 메일을 다운로드합니다. POP3는 사용자 응용 프로그램이 메일 서버의 사서함에 연결할 수 있도록 인터넷 프로토콜(IP) 네트워크를 통한 액세스를 제공하는 응용 프로그램 계층 프로토콜입니다. 그것은 연결하고, 메시지를 검색하고, 클라이언트의 컴퓨터에 저장하고, 서버에서 삭제하거나 유지할 수 있습니다.
전화 접속과 같은 임시 인터넷 연결을 관리할 수 있도록 설계되었습니다. 이것은 전화 접속 액세스가 보다 널리 보급되었을 때 더 인기가 있었습니다.
이제 IMAP(Internet Message Access Protocol)은 대부분 POP3를 대체했습니다. IMAP을 사용하면 여러 클라이언트가 동일한 사서함을 관리할 수 있습니다(데스크톱, 랩톱 및 전화 등에서 이메일을 읽을 수 있고 모든 메시지가 동일한 방식으로 정리됨).
결국 웹메일이 두 가지를 모두 대체했습니다. 웹메일을 사용하면 웹사이트에 로그인하여 어디에서나 어떤 장치에서든 메시지를 받을 수 있지만(예!), 사용하는 동안 인터넷에 연결되어 있어야 합니다. 웹사이트(예:gmail)가 MUA인 경우 SMTP 또는 IMAP 서버 설정을 알 필요가 없습니다.
이메일은 어떻게 보호됩니까?
불행히도 보안은 처음부터 메일 프로토콜에 내장되지 않았습니다(대부분의 인터넷 프로토콜처럼). 서버는 누군가로부터 메시지를 받아 최종 목적지(받는 사람:필드의 수신자)로 메시지를 라우팅하는 데 도움이 될 수 있는 다른 서버로 전달하기를 기대했습니다.
당연히 인터넷이 소수의 정부와 연구 그룹에서 기본적으로 모든 것을 수행하는 데 사용하는 것으로 확장되면서 문제가 되었습니다. 얼마 지나지 않아 스팸과 피싱 이메일은 모든 사람에게 큰 문제가 되었습니다.
이에 대한 대응으로 사람들이 다른 사람의 메시지를 읽지 못하도록 하고(암호화) 메시지가 실제로 보낸 사람이 보낸 것으로 확인(인증)하는 몇 가지 조치를 구현하려고 했습니다.
대부분의 장소에서는 전송 중 암호화를 제공하는 암호화 프로토콜인 TLS(전송 계층 보안, SSL 대체, 보안 소켓 계층)를 사용합니다. 메시지가 전송되는 동안에는 보호를 제공하지만 데이터가 저장되어 있지 않을 때는(예:컴퓨터에 저장 중) 보호를 제공합니다.
이렇게 하면 메시지가 MTA에서 MTA로 이동하는 동안 변경되거나 스누핑되지 않습니다. 그러나 이것은 여행 중에 메시지가 수정되지 않았는지 확인하지 않습니다.
예를 들어 이메일이 최종 목적지에 도달하기 전에 여러 메일 서버를 통과하는 경우 TLS를 사용하면 서버 간에 암호화되지만 각 서버는 메시지 내용을 변경할 수 있습니다. 이 문제를 해결하기 위해 SPF, DKIM 및 DMARC를 만들었습니다.
SPF(발신자 정책 프레임워크)
SPF를 사용하면 도메인 소유자(예:google.com)가 해당 도메인에서 메일을 보낼 수 있는 서버를 나타내는 TXT 레코드를 DNS에 설정할 수 있습니다(다양한 호스팅 제공업체에 대해 이 작업을 수행하는 방법에 대한 지침은 이 사이트).
이것은 어떻게 작동합니까?
이 레코드는 허용되고 다음 옵션 중 하나로 끝날 수 있는 장치(일반적으로 IP별)를 나열합니다.
-all =검사가 실패하면(이메일 소스가 나열된 장치 중 하나가 아닌 경우) 결과는 HardFail입니다. 대부분의 메일 시스템은 이러한 메시지를 스팸으로 표시합니다.
?all ==검사가 실패하면(이메일 소스가 나열된 장치 중 하나가 아닌 경우) 결과는 중립입니다. 이것은 일반적으로 프로덕션 도메인이 아닌 테스트에 사용됩니다.
~all =검사가 실패하면(이메일 소스가 나열된 장치 중 하나가 아닌 경우) 결과는 SoftFail입니다. 이것은 이 메시지가 의심스럽기는 하지만 반드시 나쁜 것으로 알려진 것은 아님을 의미합니다. 일부 메일 시스템은 이러한 메시지를 스팸으로 표시하지만 대부분은 그렇지 않습니다.
SPF 헤더는 메시지를 처리하는 서버 자체에 도움이 될 수 있습니다. 예를 들어 서버가 네트워크 가장자리에 있는 경우 받는 메시지가 보낸 사람의 SPF 레코드에 있는 서버에서 온 것임을 알고 있습니다. 이렇게 하면 서버에서 스팸을 더 빨리 제거할 수 있습니다. 이것이 훌륭하게 들리지만 불행히도 SPF에는 몇 가지 주요 문제가 있습니다.
- SPF는 메일 서버에 메시지로 수행할 작업을 알려주지 않습니다. 즉, 메시지가 SPF 검사에 실패하고 계속 배달될 수 있습니다.
- SPF 레코드는 사용자가 보는 '보낸 사람' 주소가 아니라 '반환 경로'를 보고 있습니다. 이것은 기본적으로 편지에 쓰는 반송 주소와 동일합니다. 이것은 편지를 처리하는 메일 서버에 메시지를 반환할 위치를 알려줍니다(그리고 이것은 이메일 헤더에 저장됩니다. 본질적으로 서버가 이메일을 처리하는 데 사용하는 기술 정보입니다).
즉, 원하는 것을 from:주소에 넣을 수 있으며 SPF 검사에 영향을 미치지 않습니다. 실제로 두 이메일 주소 모두 해커가 비교적 스푸핑할 수 있습니다. 암호화가 포함되어 있지 않기 때문에 SPF 헤더를 완전히 신뢰할 수 없습니다. - SPF 기록은 지속적으로 최신 상태로 유지해야 하므로 끊임없이 변화하는 대규모 조직에서는 어려울 수 있습니다.
- 전달하면 SPF가 중단됩니다. 이는 예를 들어 google.com에서 보낸 이메일이 bob@bobsburgers.com에서 전달되는 경우 봉투 발신자가 변경되지 않은 상태로 유지되기 때문입니다(보낸 사람 주소는 여전히 google.com으로 표시됨). 수신 메일 서버는 자신이 google.com에서 보낸다고 생각하지만 bobsburgers.com에서 보낸다고 생각하므로 SPF 검사에 실패합니다(메일이 실제로 google.com에서 오는 경우에도).
SPF에 대한 자세한 내용은 이 기사를 확인하십시오. 여기에서 특정 도메인에 SPF 및 DMARC 레코드가 구성되어 있는지 확인할 수 있습니다.
DKIM(도메인키 식별 메일)
DKIM은 SPF와 유사합니다. 보내는 도메인의 DNS에서도 TXT 레코드를 사용하며 메시지 자체에 대한 일부 인증을 제공합니다. 메시지가 전송 중에 변경되지 않았는지 확인합니다.
이것은 어떻게 작동합니까?
보내는 도메인은 공개/개인 키 쌍을 생성하고 공개 키를 도메인의 DNS TXT 레코드에 넣습니다(공개/개인 키 쌍이 무엇인지 모르는 경우 암호화에 대한 이 기사를 확인하십시오).
그런 다음 도메인의 메일 서버(외부 경계에 있음 - 도메인 외부로 메일을 보내는 서버(예:gmail.com에서 outlook.com으로))는 개인 키를 사용하여 다음을 포함한 전체 메시지 본문의 서명을 생성합니다. 헤더.
서명을 생성하려면 일반적으로 텍스트를 해시 및 암호화해야 합니다(이 프로세스에 대한 자세한 내용은 이 문서를 확인하세요).
수신 메일 서버는 DNS TXT 레코드의 공개 키를 사용하여 서명을 해독한 다음 메시지 및 관련 헤더(메일이 발신자의 인프라 내부에 있는 동안 생성된 모든 헤더 - 예를 들어 여러 Gmail 서버가 그 전에 이메일을 처리한 경우)를 해시합니다. Outlook.com으로 외부로 전송됨).
그런 다음 서버는 두 해시가 일치하는지 확인합니다. 그렇다면 메시지는 변경되지 않고(누군가가 보낸 사람의 개인 키를 손상시키지 않는 한) 합법적으로 알려진 보낸 사람이 보낸 것입니다. 해시가 일치하지 않으면 메시지가 보낸 사람이 아닌 것으로 확인되었거나 전송 중인 다른 서버에 의해 변경되었거나 둘 다인 것입니다.
DKIM은 '이 이메일이 전송 중 변경되었습니까? 아니면 보낸 사람이 아니라고 생각합니까?'라는 질문에 답하는 매우 구체적인 작업을 수행합니다. 하지만 그게 전부입니다. 이 테스트에 실패한 이메일을 처리하는 방법, 메시지를 변경한 서버 또는 변경된 내용에 대해서는 설명하지 않습니다.
DKIM은 또한 일부 ISP 또는 인터넷 서비스 제공업체에서 도메인의 평판을 확인하는 데 사용됩니다(스팸을 많이 보내고 있습니까? 참여도가 낮습니까? 이메일이 반송되는 빈도).
DKIM에 대한 자세한 내용은 이 기사를 확인하세요. 여기에서 DKIM 레코드를 확인할 수 있습니다.
DMARC(도메인 기반 메시지 인증, 보고 및 적합성)
DMARC는 본질적으로 SPF 및 DKIM 레코드를 처리하는 방법에 대한 메일 서버 지침입니다. 자체 테스트는 수행하지 않지만 메일 서버에 SPF 및 DKIM이 수행하는 검사를 처리하는 방법을 알려줍니다.
참여 ISP는 게시된 DMARC 레코드를 보고 이를 사용하여 DKIM 또는 SPF 실패를 처리하는 방법을 결정합니다. 예를 들어, 일반적으로 스푸핑된 브랜드는 DKIM 또는 SPF가 실패하면 메시지를 삭제하라는 DMARC 레코드를 게시할 수 있습니다.
종종 ISP는 이메일 출처 및 DKIM/SPF 통과/실패 여부와 함께 도메인 활동에 대한 보고서를 보내드립니다. 즉, 사람들이 귀하의 도메인을 스푸핑(보낸 것으로 간주)하거나 메시지를 변경하는 경우를 알 수 있습니다.
DMARC를 구현하려면 필요에 따라 DMARC 레코드를 만들어야 합니다(이메일 트래픽 모니터링에서 모든 이메일 소스가 무엇인지 파악하는 것부터 DKIM 또는 SPF에 실패한 이메일 거부 등의 조치 요청). 여기와 여기에서 이에 대해 자세히 알아볼 수 있습니다.
DMARC에 대한 자세한 내용은 이 문서를 확인하세요. 여기에서 특정 도메인에 SPF 및 DMARC 레코드가 구성되어 있는지 확인할 수 있습니다.
마무리
이러한 보안 조치 중 어느 것도 완벽하지는 않지만 함께 전 세계 이메일 시스템의 보안을 개선하는 데 도움이 되는 적절한 역할을 합니다.
이러한 조치를 채택하는 조직이 많을수록(오픈 소스 구현을 사용하거나 제품에 대해 비용을 지불함) 모두에게 더 나은 혜택을 제공할 것입니다. 프로토콜이나 제품이 개발된 후에 추가되는 보안은 일반적으로 제품에 내장된 보안보다 비용이 더 많이 들고 덜 효과적이며 구현하기 어렵습니다.
그러나 현재 인터넷이 의존하는 대부분의 프로토콜은 건물, 스마트 장치, 대중 교통, 원자력 발전소를 운영하는 전 세계 네트워크가 아닌 초기 인터넷(소규모 열광자, 과학자 및 정부 관계자)을 위해 설계되었습니다. (!), 등등.
따라서 인터넷이 계속 확장됨에 따라 우리는 우리가 의존하는 시스템을 보호하기 위해 계속 적응하고 새로운 방법을 개발해야 합니다.