return-path、reply-to、fromの動作の違いは何ですか？

メーリングアプリケーションでは、次のヘッダーを含むメールを送信しています。

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

私たちが直面している問題は、一部の電子メールサーバーがメッセージをすぐにバウンスし、バウンスmgmtサーバーの代わりにfromまたは逆パス（marketing@customer.com）を使用することです。すべてのバウンスをキャッチできるようにするには、ヘッダーでreply-toをreturn-pathと同じに変更するかどうかを知りたいです。

他のアイデアは大歓迎ですか？

参考として次のドキュメントを使用しています 。VERP RFC バウンスメッセージ

バウンスを取得するためのSMTPログ解析

編集1：この解決策を得ることができるかどうかを確認するための情報のビット。

メッセージを中継している電子メールサーバーが、返信先パスと返信パスのどちらを使用するかをどの時点で選択するかを知りたいです。メッセージをリレーする最初のSMTPサーバーが拒否されると、それを返信先に送信しますが、1ホップ後に発生すると、それを返信パスに送信します。

簡単な例から始めましょう。メーリングリストがあり、次のRFC2822コンテンツを送信するとします。

From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

ここで、VERP（または別のリターンパスを使用する他のバウンス追跡メカニズム）を実装するメーリングリストから送信するとします。それがのリターンパスを持つとしましょうcoolstuff-you=yourcompany.com@mymailinglist.com。SMTPセッションは次のようになります。

{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com>
{S}250 2.1.0 me@mycompany.com....Sender OK
{C}RCPT TO:<you@yourcompany.com>
{S}250 2.1.5 you@yourcompany.com 
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.
.

{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel

ここで、{C}および{S}は、それぞれクライアントおよびサーバーコマンドを表します。

受信者のメールは次のようになります。

Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com
From: <coolstuff@mymailinglist.com>
To: <you@yourcompany.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123@mymailinglist.com>

This is a very simple body.

次に、さまざまな「FROM」について説明します。

1. リターンパス（リバースパス、エンベロープ送信者、エンベロープ送信者と呼ばれることもあります。これらの用語はすべて同じ意味で使用できます）は、MAIL FROMコマンドのSMTPセッションで使用される値です。ご覧のとおり、これはメッセージヘッダーにある値と同じである必要はありません。受信者のメールサーバーのみが、メールの先頭にReturn-Pathヘッダーを追加することになっています。これにより、SMTPセッション中に実際のReturn-Path送信者が記録されます。Return-Pathヘッダーがメッセージにすでに存在する場合、そのヘッダーは削除され、受信者のメールサーバーによって置き換えられます。

SMTPセッション中に発生するすべてのバウンスは、Return-Pathアドレスに戻る必要があります。一部のサーバーは、すべての電子メールを受け入れ、受信者のメールボックスに配信するための空きスレッドができるまで、ローカルでキューに入れます。受信者が存在しない場合は、記録されたReturn-Path値にバウンスする必要があります。

すべてのメールサーバーがこのルールに従うわけではないことに注意してください。一部のメールサーバーは、FROMアドレスにバウンスします。

2. FROMアドレスは、FROMヘッダーにある値です。これは、メッセージの送信者であると想定されています。これは、ほとんどのメールクライアントで "FROM"と見なされるものです。電子メールにReply-Toヘッダーがない場合、すべての人間（メールクライアント）の返信はFROMアドレスに戻る必要があります。

3. Reply-Toヘッダーは、送信者（または送信者のソフトウェア）によって追加されます。すべての人間の返信にも対処する必要があります。基本的に、ユーザーが「返信」をクリックした場合、Reply-To値は、新しく作成されたEメールの受信者として使用される値である必要があります。Reply-To値はどのサーバーでも使用しないでください。クライアント側（MUA）での使用のみを目的としています。

ただし、ご存じのとおり、すべてのメールサーバーがRFC標準または推奨事項に準拠しているわけではありません。

うまくいけば、これは物事を明確にするのに役立つはずです。ただし、何かを逃した場合は、お知らせください。回答します。

Return-Pathvs について考えるもう1つの方法Reply-Toは、カタツムリメールと比較することです。

封筒を郵送する場合は、差出人住所を指定します。受信者が存在しないか、メールを拒否した場合、ポストマスターは封筒を返送先住所に返送します。メールの場合、返信アドレスはReturn-Pathです。

封筒の内側は手紙である可能性があり、手紙の内側は「例のアドレスに通信を送信する」ように受信者に指示する可能性があります。メールの場合、アドレスの例はReply-Toです。

本質的に、郵送返送アドレスはSMTPのReturn-Pathヘッダーに相当し、SMTPのReply-Toヘッダーは手紙に含まれる返信指示に似ています。

質問のタイトルのためにここに来た人のために：

私はReply-To:ウェブフォームで住所を使用します。誰かがフォームに記入すると、ウェブページはページの所有者に自動メールを送信します。これFrom:は自動メール送信者のアドレスなので、所有者はWebフォームからのものであることを知っています。ただし、Reply-To:アドレスはユーザーがフォームに入力したものであるため、所有者は返信を押して連絡を取ることができます。

Redmineインスタンスから送信されるメールにReturn-Pathヘッダーを追加する必要がありました。送信者だけが正しい（デフォルトではない）Return-Pathを決定できるgreatwolfに同意します。ケースは次のとおりです。EメールはデフォルトのEメールアドレスで送信されます：admin@yourcompany.comしかし、アクションを開始した実際のユーザーがバウンスEメールを受信することを望みます。 （そして、他の猫にむち打ちをかけるアプリケーション管理者ではありません:-)）。私たちはこれを使用し、アプリケーションサーバーのeximと最終的な会社のメールサーバーとしてのzimbraで完全にうまく機能します。