합법적 인 이유 SMTP "MAIL FROM :"이 DATA의 "From :"헤더와 일치하지 않습니다.


18

SMTP“MAIL FROM :”필드가 메일 링리스트 외에 메시지의 DATA 섹션에있는“보낸 사람 :”필드와 일치하지 않는 합당한 이유가 있습니까?

에서 /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

그러나 달팽이 메일 은유를 계속하기 위해 대부분의 전문 서신에는 서신 자체에 인쇄 된 발신자 및 수신자의 주소가 포함됩니다. 이러한 주소는 우편 배달부에는 필요하지 않지만 대신 수령인의 호의입니다. 따라서 이메일이 같은 방식으로 작동하는 것이 합리적입니다.”

이 논리에 대한 문제는 여기에 있습니다 : "수취인에게 의례". SMTP를 통해 이메일에 "보낸 사람 :"주소를 포함시키는 것은 예의가 아닙니다. 수신자가 답장을 보낼 수 있어야합니다.

From : Postfix의 MAIL FROM과 일치하도록 From 헤더를 제한하는 방법은 무엇입니까? :

"하지만 실제로 From : 및 MAIL FROM을 확인하려면 Return-Path :가 From :과 일치하도록 header_checks를 적용해야합니다."

이 작업의 의미는 무엇입니까? 메일 링리스트는 분명히 문제가 될 것입니다. 다른“MAIL FROM :”과“From :”헤더 정보에 대한 다른 합법적 인 사용이 있습니까?

답변:


22

머리글 및 봉투 보낸 사람 주소가 일치하지 않는 데는 여러 가지 이유가 있습니다. 배달 문제는 누가 메일을 보냈는지, 누구를 대신하여 보냈는지 또는 누가 답장해야하는지 나타내지 않는 주소로 배달 문제를보고해야하는 경우, 자동 메일 발송 프로세스에 관심이 있습니다. 지적한 메일 링리스트가 좋은 예입니다.

사용자의 메일 클라이언트에서 보낸 메시지가 주소와 다를 수있는 주된 이유는 전달 된 메일입니다. 메일 내용은 원본에 합리적으로 충실해야하지만 배달 오류가 발생하면 원본 발신자가 아니라 전자 메일을 전달한 사용자에게보고해야합니다.

SMTP 헤더 외에도 다양한 프로그램이 원본 발신자와 중간 발신자를 구별하기 위해 사용하는 다양한 MIME 헤더와 / 또는 오류를보고하기 위해 선호하는 주소가 있습니다 (예 : 회신, 발신자, 원래 발신자) 시맨틱이 서로 다른, 오류, 기타 등등. 이들 중 일부는 표준을 지원하지만 더 많은 것은 지원하지 않지만 어쨌든 사용 중일 수 있습니다. 다양한 메일 프로그램이 실제로 작동하는 방식은 상당히 다릅니다.

메일 주소 지정 방식이 바람직한 지 여부는 요청한대로 "합법적 인"메일인지와 다릅니다. 잠재적 인 스팸 처리 정책과 같은 측면에서 합법성을 고려하고 있다면, 아닙니다. 이런 방식으로 간단한 구별을 할 수 없을 것입니다.

이메일의 DKIM 서명 및 이메일 도메인의 메일 서버의 SPF 인증에 대해 생각해보십시오. 많은 메일을 보내는 경우 이러한 방식으로 메일을 인증하는 것이 중요 할 수 있으며 권한이있는 도메인과 관련된 메일 만 인증 할 수 있으므로 메일 보낸 사람 헤더의 주소 지정에 영향을 줄 수 있습니다. .

-

요청시 확장 :

MIME 'Reply-To'헤더는 MUA (일반적으로 개인 메일 클라이언트 인 Mail User Agent)가 MIME '보낸 사람'주소 대신 다른 주소로 답장을 보내도록 지시합니다. MTA (Mail Transport Agent)는 오류와 같은 용도로 사용하지 않습니다.

일반적으로 MTA는 SMTP 봉투 'MAIL From'주소를 사용하여 오류를 보냅니다. MTA 명령 인 MIME 'Errors-To'헤더를 사용하여 IT를 재정의 할 수 있습니다. 모든 MTA가이를 준수하는 것은 아니므로 SMTP 봉투 주소를 설정하는 것은 열등한 메커니즘이지만 SMTP Envelope From 주소가 아닌 메시지에 MIME 헤더를 설정할 수있는 경우가 많습니다. 예를 들어 공유 호스팅 환경에서 실행되는 소프트웨어는이 상황에서 스스로 발견 될 수 있습니다.

'발신자'는 소프트웨어 에이전트에 대한 지시 사항으로 훨씬 모호하지만 이메일을 발송 한 사람과 더 유사한 발신인 주소와 다른 곳에서 이메일을 발송 한 사람 또는 대상을 나타냅니다. 예를 들어, 온라인 메일-귀하의 정치인 양식을 작성할 때 결과 전자 메일이 보낸 사람 헤더에서 메일을 사용하는 것이 매우 적합하지만 양식을 설정 한 조직과 관련된 발신자 주소가 있습니다.

'Originally-From'은 메일을 전달할 때 일부 MUA 소프트웨어에서 사용되며 전달자의 주소는 'From'헤더에 사용됩니다. 다른 MUA는 보낸 사람 주소 만 남겨두고 'Resent-From'헤더를 사용합니다. 이러한 다양한 헤더를받는 MUA가 전자 메일을 헤더를 유용하게 해석하거나 표시할지 여부는 매우 다양합니다. 전달 된 메일에 회신 할 때 기본적으로 누가 답장을 보내야합니까? 아마도 'Reply-To'헤더를 설정하는 것이 가장 좋을까요?

MUA의 행동은 시간이 지남에 따라 개선되는 것처럼 보이지만 가변적이며 잘 정의되지 않았습니다. 반대로, 봉투의 의미는 훨씬 더 정의되어 있습니다. 일반적으로 MTA가 MIME 헤더와 관련해서는 안된다는 강력한 입장이 있었지만, MTA가 메일 내용에 대한 책임을 점점 더 많이 유지함에 따라 (예 : SPF 및 새로운 DMARC 표준 참조), 그 입장의 명확성이 떨어질 압력이 있습니다. Errors-To와 같은 오랜 메커니즘은 헤더 내용을 보지 않는 MTA의 개념과 상충되어 이러한 메커니즘이 항상 일관되지 않은 이유 중 하나입니다. 소프트웨어 제작자의 철학은 다양합니다.

http://tools.ietf.org/html/rfc4021#section-2 를 살펴 보는 것이 도움이 될 수 있지만, 수많은 메일 소프트웨어의 실제 관행은 반드시 표준 축복이 아닌 방식에 따라 다르다는 것을 기억하십시오.

메일을 어떻게 사용해야하는지에 대한 명확한 철학을 생각해 보는 것이 좋지만, 다른 사람들이 자신이 생각하는 방식대로 행동 할 것이라고 기대하지 마십시오.


나는 여전히이 현상금을 수여 할 시간이 있으며 헤더를 사용해야하는 추가 시나리오에 관심이있다 : Reply-To, Sender, Originally-From, Errors-To`
goodguys_activate

추가해 주셔서 감사합니다. MTA 예상 동작이 무엇인지, 구현 방식에 대해 명확하게 이해하기를 희망합니다. 또한,이 질문에 관심이있을 수 있습니다 : 난 그냥 이메일 (BATV 유사) 화이트리스트에 대한 Sec.StackExchange에 게시 security.stackexchange.com/q/41008/396
goodguys_activate

1
+1, 왜 4 표입니까?
Pacerier

11

자동화 된 처리가 큰 이유입니다. 바운스 / 자동 응답 / 오류를 개별적으로 처리하여 보낼 수 있기를 원합니다. 그렇지 않으면 해당 메시지가 사라지거나 무시되거나 일부 불량 수액이 처리해야합니다. 예, 처리를 위해 X 헤더를 추가하는 것이 가능하지만 많은 시간이 바운스됩니다. 원본 이메일을 포함하지 않거나 엉망인 부분 만 포함하면 소스를 얻을 수 없습니다.

예를 들어, 누군가 웹 사이트에 가입한다고 말하면 가입 해 주셔서 감사하다는 이메일을 보냅니다. MAILFROM 및 보낸 사람은 다음과 같습니다.

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

이런 방식으로 사용자는 메일 클라이언트에서 "친절한 사용자"를 볼 수 있습니다. 그러나 사용자가 존재하지 않으면 MTA가 반송 메시지를 다음 주소로 보냅니다.

user-signup-123123123@bounces.example.com

자동화 된 프로세스는 헤더에서 사용자 ID (123123123 부분)와 바운스 (-signup-part)를 생성 한 시스템 부분을 쉽게 가져오고 해당 사용자를 비활성화 된 것으로 쉽게 삭제 / 표시 할 수 있습니다.


8

smtp 대화에서 메일 보낸 사람 :은 반송이 이루어지는 곳으로 설계되었습니다. 메시지 본문의 보낸 사람 : 헤더는 수신자에게 표시하는 데 사용되며 회신 : 헤더가 설정되지 않은 경우 회신 주소로 사용됩니다.

반송 메일을 생성하지 않아야하는 전자 메일은 봉투에 빈 발신자를 설정해야합니다. 예를 들어 반송 영수증에는 일반적으로 mail from:<>사용자 이름이 from : 헤더에 있습니다.

또 다른 상황은 메일 서버가 BATV를 사용하여 가짜 바운스를 거부하는 경우입니다. 에서 보낸 메일은 prvs=tag-value=mailbox@example.com 형식입니다.


반품 및 NDR에 대한 X- 헤더를 본 것을 기억합니다. 이것이 언제 어떻게 사용되는지 아십니까?
goodguys_activate

X- 헤더는 원래 사용자 지정 메타 데이터를 넣기 위해 MUA 및 / 또는 MTA의 수단으로 추가되었으며 일부 표준은 사실상 표준이 아니지만 표준에는 지정되어 있지 않습니다. 소프트웨어가 자동으로 반송되는 메시지를 분류하는 데 도움이되도록 정의 된 rfc 6522에 정의 된 multipart / report mime 유형을 생각할 수 있습니다 . 이 편지들은 여전히 ​​우편으로 빈 봉투와 함께 발송 될 것입니다 :
Richard Salts

1

헤더 나 질문을 제대로 읽지 않으면 BlackBerry의 전자 메일이 BlackBerry 서버에서 전송되며 기본적으로 일치하는 필드가 없습니다. 사용자의 적은 비율, 나는 알고 있습니다. 나는 최근에 내 메일 서버를 평가할 때 이것을보고있다. 아래는 BlackBerry에서 내 Gmail 계정으로 보낸 익명의 이메일입니다.

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

SPF 다시 쓰기 에는 훌륭한 이유가 있습니다 . BlackBerry가이 작업을 수행하지 않은 경우 단말기에서 더 많은 SPF 오류가 발생합니다.
MikeyB

사실, 이는 BlackBerry가 서버를 전송에 사용하지 않기 때문입니다.
Paul
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.