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

Question

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

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

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

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

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

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

編集1：この解決を得ることができるかどうかを確認するために、もう少し情報を追加します。

メッセージを中継する電子メールサーバーが、返信先と返信先のどちらを使用するかをどの時点で選択するかを知りたい。メッセージを中継する最初のsmtpサーバーが拒否されると、reply-toに送信されますが、1ホップ後に発生するとreturn-pathに送信されます。

Answer 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 のreturn-pathがあるとしましょう。 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. リターンパス（リバースパス、エンベロープ送信者、または＆＃8212からのエンベロープと呼ばれることもあります;これらの用語はすべて交換可能に使用できます）は、 MAIL FROM コマンド。ご覧のとおり、これはメッセージヘッダーにある値と同じである必要はありません。受信者のメールサーバーのみが、Eメールの先頭に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値は新しく作成されたメールの受信者として使用される値になります。 Reply-To値はどのサーバーでも使用しないでください。クライアントサイド（MUA）での使用のみを目的としています。

ただし、おわかりのように、すべてのメールサーバーがRFCの標準または推奨事項に従うわけではありません。

うまくいけば、これで問題が解決するはずです。ただし、何かを見逃した場合はお知らせください。回答を試みます。

Answer 2

Return-Path 対 Reply-To について考える別の方法は、それを普通郵便と比較することです。

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

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

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

Answer 3

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

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

Answer 4

Redmineインスタンスから送信されるメールにReturn-Pathヘッダーを追加する必要がありました。 私は、送信者のみが正しい（デフォルトではない）Return-Pathを決定できるgreatwolfに同意します。 ケースは次のとおりです。 電子メールは、デフォルトの電子メールアドレスadmin@yourcompany.comで送信されます しかし、アクションを開始する実際のユーザーがバウンスメールを受信するようにしたいのです。なぜなら、彼は間違った受信者のメールを修正する方法を知っている人になるからです（他の猫が鞭打つアプリケーション管理者ではありません:-)）。 これを使用し、アプリケーションサーバー上のeximおよび最終的な会社のメールサーバーとしてのzimbraと完全に連携します。