return-path、reply-to、fromの動作の違いは何ですか？
メーリングアプリケーションでは、次のヘッダーを含むメールを送信しています。
FROM: [email protected]
TO: [email protected]
Return-PATH: [email protected]
私たちが直面している問題は、一部の電子メールサーバーがすぐにメッセージをバウンスして、バウンスmgmtサーバーの代わりにfromまたはreverseパス（[email protected]）を使用することです。すべてのバウンスをキャッチできる場合は、ヘッダーでreply-toをreturn-pathと同じになるように変更するかどうかを知りたいです。
他のアイデアは大歓迎ですか？
次のドキュメントを参照として使用しています： VERPRFCBounce Messages
編集1：この解決策を得ることができるかどうかを確認するために、もう少し情報を追加します。
メッセージを中継する電子メールサーバーが返信先とリターンパスのどちらを使用するように選択するかを知りたいのです。メッセージを中継する最初のsmtpサーバーが拒否されると、reply-toに送信されますが、1ホップ後に発生するとreturn-pathに送信されます。
簡単な例から始めましょう。メーリングリストがあるとしましょう。メーリングリストは、次の RFC2822 コンテンツを送信します。
From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body.
それでは、 VERP （または別のreturn-pathを使用する他のバウンス追跡メカニズム）を実装するメーリングリストから送信するとします。 [email protected]のreturn-pathがあるとしましょう。 SMTPセッションは次のようになります。
{S}220 workstation1 Microsoft ESMTP MAIL Service {C}HELO workstation1 {S}250 workstation1 Hello [127.0.0.1] {C}MAIL FROM:<[email protected]> {S}250 2.1.0 [email protected] OK {C}RCPT TO:<[email protected]> {S}250 2.1.5 [email protected] {C}DATA {S}354 Start mail input; end with <CRLF>.<CRLF> {C}From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body. . {S}250 Queued mail for delivery {C}QUIT {S}221 Service closing transmission channel
{C}と{S}は、それぞれクライアントとサーバーのコマンドを表します。
受信者のメールは次のようになります。
Return-Path: [email protected] From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body.
それでは、さまざまな「FROM」について説明しましょう。
- リターンパス（リバースパス、エンベロープ送信者、またはエンベロープと呼ばれることもあります。これらの用語はすべて同じ意味で使用できます）は、
MAIL FROMコマンドのSMTPセッションで使用される値です。ご覧のとおり、これはメッセージヘッダーにある値と同じである必要はありません。受信者のメールサーバーのみが、Eメールの先頭にReturn-Pathヘッダーを追加することになっています。これにより、SMTPセッション中に実際のReturn-Path送信者が記録されます。メッセージにReturn-Pathヘッダーが既に存在する場合、そのヘッダーは削除され、受信者のメールサーバーに置き換えられます。
SMTPセッション中に発生するすべてのバウンスは、Return-Pathアドレスに戻る必要があります。サーバーによっては、すべての電子メールを受け入れ、受信者のメールボックスに配信するための空きスレッドができるまで、ローカルでキューに入れる場合があります。受信者が存在しない場合は、記録されたReturn-Path値にバウンスする必要があります。
すべてのメールサーバーがこの規則に従うわけではないことに注意してください。一部のメールサーバーは、それをFROMアドレスにバウンスします。
FROMアドレスは、FROMヘッダーにある値です。これは、メッセージの送信者を想定しています。これは、ほとんどのメールクライアントで「FROM」と表示されるものです。メールにReply-Toヘッダーがない場合、すべての人間（メールクライアント）の返信はFROMアドレスに戻る必要があります。
Reply-Toヘッダーは、送信者（または送信者のソフトウェア）によって追加されます。それはすべての人間の応答も扱われるべき場所です。基本的に、ユーザーが「返信」をクリックすると、Reply-To値は新しく作成された電子メールの受信者として使用される値になります。 Reply-To値はどのサーバーでも使用しないでください。クライアント側（MUA）での使用のみを目的としています。
ただし、おわかりのように、すべてのメールサーバーがRFCの標準または推奨事項に従うわけではありません。
うまくいけば、これが事態を解決するのに役立つはずです。しかし、私が何かを見逃した場合、私に知らせて、私は答えようとします。
Return-Path対Reply-Toについて考える別の方法は、それを普通郵便と比較することです。
封筒を郵送するときは、返信先を指定します。受信者が存在しないか、メールを拒否した場合、ポストマスターは封筒を返送先に返します。電子メールの場合、リターンアドレスはReturn-Pathです。
封筒の内側は手紙であり、手紙の内側では、受信者に「example addressに通信を送信する」ように指示する場合があります。電子メールの場合、例のアドレスはReply-Toです。
本質的に、郵送先住所は、SMTPのReturn-Pathヘッダーに匹敵し、SMTPのReply-Toヘッダーは、レターに含まれる返信指示に類似しています。
質問のタイトルのためにここに来た人のために：
WebフォームでReply-To:アドレスを使用しています。誰かがフォームに記入すると、ウェブページはページの所有者に自動メールを送信します。 From:は自動メール送信者のアドレスなので、所有者はWebフォームからのものであることを知っています。ただし、Reply-To:アドレスはユーザーがフォームに入力したアドレスなので、所有者は返信するだけで連絡できます。
Redmineインスタンスから送信されるメールにReturn-Pathヘッダーを追加する必要がありました。私は、送信者のみが正しい（デフォルトではない）Return-Pathを決定できるgreatwolfに同意します。ケースは次のとおりです。EメールはデフォルトのEメールアドレスで送信されます：[email protected]しかし、アクションを開始する実際のユーザーがバウンスEメールを受信するようにしたいのです。 （そして、他の猫を鞭で打つアプリケーション管理者ではありません:-)）。これを使用し、アプリケーションサーバー上のeximおよび最終的な会社のメールサーバーとしてのzimbraと完全に連携します。