나에게 보낸 이메일은 MAIL@MAIL.COM으로 보내집니다. 이것은 어떻게 이루어 집니까?

나는 최근에 사기 이메일을 보냈고, 낄낄 거림을 위해 그것을 열었습니다. 매우 평범하고 많은 노력을 기울이지 않았습니다.

나는 독특한 것을 발견했다. 이 이메일은 나에게 전달되지 않았습니다. 처음에 CC 또는 BCC를 의심했지만 메일에 내 주소가없는 곳은 없습니다. 나는 아래 그림을 제공했다. 이것은 어떻게 이루어 집니까?

인터넷 전자 메일 메시지는 두 부분으로 구성됩니다. 우리는 그것들을 봉투 와 페이로드 메시지 또는 단순히 메시지라고 부를 수 있습니다.

봉투에는 라우팅 데이터가 있습니다. 주로 보낸 사람 주소와 하나 이상의받는 사람 주소입니다.

메시지에는 메시지 내용 ( 제목, 메시지 본문, 첨부 파일 등)이 있습니다. 또한 추적 ( Received:) 헤더, DKIM 데이터 등과 같은 일부 기술 정보도 제공합니다 . 뿐만 아니라 같은 표시 발신자와 수신자 주소 (당신이에 무엇을보고 From, To그리고 Cc필드 메일 클라이언트에서).

그 핵심은 다음과 같습니다 . 두 사람은 동의 할 필요가 없습니다!

메일 서버는 봉투 데이터를보고 메시지 전송 방법을 결정합니다. 반면 예외는 거의 없지만 메시지 자체는 데이터로 취급됩니다. 특히, 잘 행동 메일 서버는 하지 않는 상기 볼 To:과 Cc:받는 사람 목록을 확인하는 메시지 자체의 필드 않으며는 볼 않는 From:보낸 사람의 주소를 결정하는 필드.

전자 메일을 작성하고 보낼 때 전자 메일 클라이언트는받는 사람, 참조 및 숨은 참조 필드에 입력 한 내용을 봉투 라우팅 정보로 변환합니다. 이는 주로 전자 메일 주소 만 남기고 전체 이름을 제거하여 수행되지만 주소 다시 쓰기, 별칭 확장 등과 같은 항목도 포함될 수 있습니다. 결과는 메일 클라이언트가 수신자리스트와 통신하는 메일 서버에 제공되는 이메일 주소리스트입니다. 받는 사람 및 참조 목록은 전자 메일에 보관되지만 숨은 참조는 서버로 전달되지 않으므로 메시지받는 사람에게는 보이지 않습니다. 발신자 주소는 매우 유사하게 작동합니다.

메시지가 최종 목적지에 도달하면 엔벨로프 데이터는 버려지거나 자세한 메시지 헤더에 보관됩니다. 이것이 Spittin 'IT가 귀하의 질문에 대한 의견으로 전체 메시지 헤더를 요구 한 이유 중 하나입니다.

또한 인터넷 전자 메일을 사용하면 메일 서버와 직접 대화 할 수 있으므로 봉투 데이터와 정상 작동하는 전자 메일 클라이언트 와 달리 메시지 데이터가 일치하지 않는 메시지를 삽입 할 수 있습니다. 작곡하자. 또한 메일 서버는 봉투 데이터에 지정된 발신자 주소에 대해 다양한 정도의 검사를 수행합니다. 문법적으로 유효한 전자 메일 주소 인지 확인하기 위해 간신히 확인하는 사람도 있습니다. 메시지 데이터의 From 헤더는 훨씬 덜 정밀하게 검사됩니다.

받는 전자 메일 클라이언트는 봉투의 주소 데이터가 아닌 보낸 사람,받는 사람 및 참조 머리글에있는 내용을 표시 하므로 원하는 것을 넣을 수 있으며받는 전자 메일 클라이언트는이를 신뢰하지 않고 신뢰할 수 있습니다. 합리적으로 정확합니다. 합법적 인 메일의 경우 일반적으로 충분히 정확합니다. 스팸의 경우 거의 그렇지 않습니다.

우리가 단순한 인간이 거주하는 유형의 물리적 인 세계 에서 봉투 발신자 와 봉투 수신자 는 각각 봉투 외부에 적는 반송 주소와 수신자 주소에 해당합니다. 과 From:및 To:/ Cc:헤더는 당신이 무엇을 당신이 봉투에 넣어 편지에 각각 당신과받는 사람의 주소로 넣어 해당합니다.

하단에 tl; dr.

SMTP 프로토콜에는 CC 또는 BCC 수신자라는 개념이 없습니다. 이것은 메일 클라이언트가 보유한 규칙입니다. SMTP 서버는 일반적으로 라우팅 정보 및 데이터에만 관심이 있습니다. 이 기능이 없으면 BCC가 존재하지 않기 때문에 이것은 중요한 차이점입니다. 합법적 인 BCC 커뮤니케이션으로서 다음과 같은 클라이언트 대화 내용을 고려하십시오.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

이제이 경우 Anonymous가이 회의에 대한 메시지를 보냈습니다. 그러나이 버전의 메일은 Jane Doe로 라우팅 되지 않았습니다 . 그녀는 익명이 통보되는 것에 대해 아무것도 모른다. 반대로 Jane Doe는 다른 본문과 헤더를 사용하여 메시지를 보냅니다.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

여기서 익명이 BCC에 있었기 때문에 Jane Doe에게 전송 된 메시지에는 BCC 수신자 목록이 포함되지 않았습니다. BCC 규칙으로 인해 전자 메일 봉투에는 실제로 메시지를받은받는 사람이 포함되지 않을 수 있으며 메시지 머리글에 나타나지 않는받는 사람이 포함될 수도 있습니다.

@JonasWielicki가 언급했듯이 MUA (Mail User Agent)는 일반적으로 BCC를 구현하는 데 필요한 여러 전자 메일을 보내는 책임이 있습니다. 전자 메일 서버는 BCC에 대해 아무것도 모르므로 MUA는 봉투 헤더에 지정된 다른 전자 메일 경로를 가진 여러 전자 메일을 보내 BCC를 구현해야합니다. 이러한 이유로, 다른 메시지 본문을 구성하여 개별적으로 전송해야하기 때문에 BCC는 일반적으로 일반 이메일보다 전송 시간이 더 오래 걸립니다.

또한 일부 이메일 준수 규칙에 도움이됩니다. 예를 들어 메일 서버에는 보관 전자 메일 서버를 자동으로 숨기도록 규칙이 구성되어있을 수 있습니다 (이 서버로 전송 된 모든 전자 메일도 보관 됨).이 경우 메일 서버는 실제받는 사람이 아닐 수도 있습니다.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

여기서 수신자는 수신자 또는 발신자에게 완전히 공개되지 않은 다른 당사자입니다. 이는 일반적으로 메시지 릴레이 또는 보관에 사용되는 프로토콜의 기능입니다.

이 스팸 메시지는 그 동작을 이용합니다. 호환되는 메일 서버와 기술적으로 작동하는 표준 허점입니다. 물론 많은 업데이트 된 서버는 DKIM과 같은 "확장자"를 사용하여 이러한 전자 메일이 진짜인지 확인하지만, 문제가되지 않는 항목을 수정하지 않으려는 유혹을 받고 있기 때문에 걱정하지 않는 오래된 메일 서버가 여전히 많습니다.

또한 날짜 헤더를 어떻게 지정했는지 주목하십시오. 이것은 임의의 (그러나 형식이 잘 지정된) 값일 수 있습니다. 많은 고객이 먼 과거부터 먼 미래까지의 법적 날짜 범위를 행복하게 표시합니다. 나는 몇 년 전에 개인적으로 자신의 이메일을 보냈으며, 그 메일은 내 기대 수명이 지난 후에도 항상 내 메일 박스의 상단에 남아 있으며, 내 이메일 계정과 내 탄생 이전의 이메일입니다.

tl; dr

따라서 요약하면 발신자가 전자 메일을 스푸핑하고 원래 메일 서버가 전자 메일을 수락 / 릴레이하고 전자 메일 서버가 전자 메일을 받아받은 편지함에 저장 한 후 클라이언트가받은 편지함에 있던 데이터를 우회하지 않고 충실하게 표시했습니다. 어떤 보안. POP3는 메일 박스에 액세스하기 전에 거의 항상 사용자 이름과 비밀번호를 요구하기 때문에 "보내기"보안은 "보내기"보안보다 훨씬 덜 제한적입니다 (이론적으로 우회 할 수는 있지만 합법적 인 것은 알 수 없습니다) 메일 서비스).

SMTP와 이메일은 보안과 인증이 훨씬 덜 심각하게 여겨지는 시대의 아주 오래된 인터넷 서비스입니다 (DNS가 또 다른 예입니다). 프로토콜의 설계는 발신자 주소의 진위 여부를 확인하기 위해 노력하지 않으며, 메일을 전달할 수있는 경우에만 수신자 주소의 유효성을 검사합니다.

이메일은 SMTP 프로토콜을 통해 전송됩니다. SMTP 프로토콜은 비교적 바보입니다. 일반 텍스트를 전자 메일 주소로 전송하는 기능을 제공합니다. 이 평문의 구조는 RFC 5322에 의해 정의됩니다 . 일반적으로 전자 메일 텍스트에는 헤더라는 메타 데이터와 메시지의 실제 텍스트 본문이 있습니다. 이 이메일 헤더는 발신자가 생성하며 (아무도 신뢰할 수 없음) "to :", "from :", "subject :"등과 같은 필드를 포함합니다.

SMTP 프로토콜은 이메일 헤더가 SMTP 프로토콜에 정의 된 매우 적은 항목 (기본적으로 이메일 주소 및 발신자 이메일 주소)과 일치하는지 확인하지 않으며, 어떤 식으로도 검증되지 않습니다.

전자 메일 메시지의 거의 모든 것이 가짜 일 수 있습니다.

오늘날 전자 메일 내용에 대해 원격으로 신뢰할 수있는 유일한 것은 DKIM 서명 뿐이며 도메인 등록자가 승인 한 전자 메일 서버를 통해 전자 메일이 처리되었음을 나타냅니다. 더 자세히 살펴보면이 사기 전자 메일에 DKIM 서명이없는 것입니다.

To이메일 헤더의 주소 는 정보 제공 용이며 이메일 클라이언트에 의해 표시됩니다. 실제 수신자 주소는 RCPT TOSMTP에 제공됩니다. 편지를 쓰고 봉투에 넣고 주소 -1을 봉투에 쓰는 경우에도 동일합니다. 그런 다음 택배로 이동하여 다른 주소 2를 제공하십시오. 택배가 봉투를 주소 2가있는 더 큰 봉투에 넣고 배송이 진행됩니다. 귀하의 비서 (이메일 클라이언트 소프트웨어)는 외부 봉투를 쓰레기통에 넣고 주소 1의 내부 봉투를 보여줍니다. 당신은 이메일 메시지의 RAW보기로 이것을 볼 수 있습니다.

헤더 검사에 따라 약간 다른 모양입니다. 다른 답변은 내가 할 수있는 것보다 SMTP의 세부 사항을 더 잘 처리합니다.

메시지의 전체 헤더를 얻을 수있는 경우 주소를 검색하면 , 또는 이라는 필드에서 찾을 수 있습니다 . 첫 번째는 내 메일 제공 업체에서 사용하고 두 번째는 Gmail에서 사용합니다. 세 번째도 사용되는 것을 보았습니다. 이들은 서로 다른 필드이지만 우리의 목적 상 실제로 메시지를 전달할 편지함과 같은 것을 의미하는 경향이 있습니다. 수신자 BCC가있는 Outlook (데스크톱 버전)에서 전송하여 테스트했습니다.Envelope-toDelivered-toX-Apparently-to

또한 내 메일 공급자는 해당 Delivered-To필드를 사용 하지만 서버의 사서함 이름으로 도 사용 합니다. 내 이메일 주소가 아닌 것 같습니다 (생각 ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

반면에 (교환 서버와 결합 된) Outlook에는 숨은 참조로 표시되어있는 경우 수신자의 전자 메일 주소가있는 단일 필드가 헤더에 포함되지 않습니다.