SMTPの「MAIL FROM：」がDATAの「From：」ヘッダーと一致しない正当な理由

Question

メーリングリスト以外に、SMTPの「MAIL FROM：」フィールドがメッセージのDATAセクションの「From：」フィールドと一致しない正当な理由はありますか？

https://stackoverflow.com/questions/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean から：

「しかし、あなたのカタツムリメールの比喩を続けるために、ほとんどの専門的な手紙には、手紙自体に印刷された送信者と受信者のアドレスが含まれます。これらのアドレスは郵便配達員には必要ありませんが、代わりに受信者への礼儀です。したがって、メールが同じように機能することは賢明です。」

このロジックラインの問題は、「受信者への礼儀」です。 SMTP経由の電子メールに「From：」アドレスを含めることは礼儀ではありません。受信者が返信を送信できるようにする場合に必要です。

From： Fromヘッダーを制限してpostfixのMAIL FROMと一致させる方法 ：

「しかし、もし本当にFrom：とMAIL FROMを確実にしたいなら、Return-Path：がFrom：と一致するようにheader_checksを適用する必要があります。」

これを行うことの意味は何ですか？メーリングリストは明らかに問題になります。異なる「MAIL FROM：」と「From：」ヘッダー情報の他の正当な用途はありますか？

Answer 1

ヘッダーとエンベロープFromのアドレスが一致しない理由は多数あります。最も重要なのは、メールを送信する自動化されたプロセスです。メールの送信者、メールの送信者、または返信者の代表ではないアドレスに配信の問題を報告する必要があります。あなたが指摘したようなメーリングリストは良い例です。

ユーザーのメールクライアントから送信されたメッセージのアドレスが異なる主な理由は、転送されたメールです。メールの内容は元の内容にかなり忠実である必要がありますが、配信エラーが発生した場合は、元の送信者ではなく、メールを転送したユーザーに報告する必要があります。

SMTPヘッダー以外にも、さまざまなプログラムが元の送信者と中間の送信者を区別するために使用するさまざまなMIMEヘッダー、および/またはエラーを報告するための優先アドレスがあります。例：Reply-To、Sender、Originally-From 、Errors-Toなど。それぞれ異なるセマンティクス。これらの一部には標準サポートがありますが、多くはサポートしていませんが、とにかく使用されている可能性があります。実際のさまざまなメールプログラムの動作は、かなり異なります。

メールの宛先指定の方法が望ましいかどうかは、要求された「正当な」方法であるかどうかとは異なります。潜在的なスパムを処理するためのポリシーのようなものに関してここで正当性を検討している場合、いいえ、このように簡単に区別することはできないと思います。

電子メールのDKIM署名、および電子メールドメインのメールサーバーのSPF認証について検討してください。大量のメールを送信する場合は、これらの方法でメールを認証できることが重要である場合があります。これは、権限のあるドメインに関連するメールのみを認証できるため、メールのFromヘッダーのアドレス指定に影響する可能性があります。 。

-

リクエストに応じて拡張：

MIME 'Reply-To'ヘッダーは、MUA（メールユーザーエージェント、通常はユーザーのメールクライアント）に、MIME 'From'アドレスではなく別のアドレスに返信を送信するように指示します。これは、MTA（メール転送エージェント）がエラーのようなものに使用することはありません。

通常、MTAはSMTPエンベロープの「MAIL From」アドレスを使用してエラーを送信します。 ITは、MTA命令であるMIME 'Errors-To'ヘッダーでオーバーライドできます。すべてのMTAがそれを尊重するわけではないため、SMTPエンベロープアドレスを設定するのに劣るメカニズムですが、メッセージにMIMEヘッダーを設定できるが、SMTPエンベロープFromアドレスは設定できない場合が多くあります。たとえば、共有ホスティング環境で実行されているソフトウェアは、この状況でそれ自体を見つける可能性があります。

「送信者」は、ソフトウェアエージェントへの指示としてはあいまいですが、メールの送信者に似ている送信元アドレスとは異なる、誰または何がメールを送信したかを示します。たとえば、政治家のオンラインフォームに記入する場合、結果の電子メールはFromヘッダーでメールを使用するのが非常に適切ですが、フォームを設定した組織に関連する送信者アドレスがあります。

'Originally-From'は、メールを転送するときに一部のMUAソフトウェアによって使用され、 'From'ヘッダーにはフォワーダーのアドレスが使用されます。他のMUAはFromアドレスをそのままにし、 'Resent-From'ヘッダーを使用します。 MUAがこれらのさまざまなヘッダーの電子メールを受信するかどうかは、ヘッダーを効果的に解釈するか、それとも表示するかさえも、かなり変動します。転送されてきたメールに返信する場合、デフォルトでは誰に返信しますか？その「Reply-To」ヘッダーを設定するのが最善でしょうか？

MUAの動作は可変であり、定義も不十分ですが、時間の経過とともに改善しているようです。対照的に、エンベロープのセマンティクスははるかに定義されています。通常、MTAがMIMEヘッダーに関与するべきではないという強い立場がありましたが、MTAがメールコンテンツに対して責任を負うようになっているため（たとえば、SPFや新しいDMARC規格を参照）、その位置の明確さを低下させる圧力があります。 Errors-Toのような長年のメカニズムも、MTAがヘッダーコンテンツを参照しないという概念と矛盾しており、これらのメカニズムが常に一貫して適用されていない理由の一部です。ソフトウェア作者の哲学はさまざまです。

http://tools.ietf.org/html/rfc4021#section-2 を見直すと便利な場合がありますが、そこにある多数のメールソフトウェアの実際の実践方法はさまざまです。これは必ずしも恵まれた標準ではありません。

メールをどのように使用するべきかについて明確な哲学を考え出そうとするのは問題ありませんが、他の誰もがあなたがそうすべきと思うことをすることを期待しないでください。

Answer 2

自動処理が大きな理由です。バウンス/自動返信/エラーを個別に処理するために送信できるようにしたい場合。そうしないと、これらのメッセージが表示されなくなったり、無視されたり、いくつかの貧弱な樹液がそれらを通過する必要があります。はい、処理のためにX-ヘッダーを追加することは可能ですが、多くの場合、バウンスなどです。元のメールまたはその一部のみが含まれていないため、ソースを取得できません。

たとえば、誰かがあなたのウェブサイトにサインアップし、サインアップの感謝を知らせるメールを送信するとします。 MAILFROMとFromは次のようになります。

MAIL FROM: <[email protected]>
From: Website X <[email protected]>

このようにして、ユーザーはメールクライアントで "Friendly from"を確認します。ただし、ユーザーが存在しない場合、MTAはバウンスメッセージを次の宛先に送信します。

[email protected]

自動化されたプロセスは、ユーザーID（123123123部分）とバウンスを作成したシステムの部分（-signup-部分）をヘッダーから簡単にプルし、そのユーザーを簡単に削除/無効としてマークできます。

Answer 3

Smtp会話のメールfrom：は、バウンスが送信される場所になるように設計されています。メッセージ本文のFrom：ヘッダーは、受信者への表示に使用され、Reply-to：ヘッダーが設定されていない場合は返信アドレスとして使用されます。

バウンスを生成しない電子メールは、エンベロープに空の送信者を設定する必要があります。たとえば、通常、受信確認には次のようになります：mail from:<> from：ヘッダー内のユーザー名。

別の状況は、メールサーバーがBATVを使用して偽のバウンスを拒否している場合です。からのメールは、prvs = tag-value = mailbox @ example.comの形式になります。

Answer 4

ヘッダーや質問を正しく読んでいない限り、BlackBerryからのメールはBlackBerryサーバーから送信され、基本的にどのフィールドも一致しません。パーセンテージのユーザーだと思います。私は最近、私のメールサーバーを評価する際にこれを検討しています。以下は、BlackBerryからGmailアカウントに送信された匿名のメールです。

Delivered-To: [email protected]
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=[e-mail]>
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 <[email protected]>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=[e-mail] 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=[e-mail] designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=[e-mail]
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 <[email protected]>; 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 <[email protected]>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <58727559[e-mail]>
Reply-To: [email protected]
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <[email protected]>
From: [email protected]
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T