SMTP「送信者」ヘッダーの正しい使用方法

私たちのWebアプリケーションは、誰かが新しいコンテンツを投稿すると、メールメッセージを送信します。送信者と受信者の両方が、アプリケーションから電子メールメッセージを受信することを選択しました。このようなメッセージを準備するとき、次のSMTPヘッダーを設定します。

FROM：author@example.com
宛先：recipient@example.com
送信者：webapp@mycompany.com

受信者に最高のエクスペリエンスを提供するために、FROMヘッダーで作成者の電子メールアドレスを使用することを選択しました。メールクライアントでメッセージを見ると、作成者は明確です。なりすましの出現を回避するために、SENDERヘッダーを（自社の電子メールアドレスと共に）追加して、著者に代わってメッセージを送信したことを明確にしました。RFC 822および2822を読んだ後、これは送信者ヘッダーの使用目的と思われます。

ほとんどの受信メールサーバーはこれをうまく処理しているようです。電子メールメッセージは正常に配信されます（受信者のメールボックスが存在する、割り当て量を超えていないなど）。ただし、ドメインのアドレスから同じドメインのアドレスにメッセージを送信する場合、一部の受信ドメインは次のような応答でメッセージを拒否します。

571不正なIP-psmtp（RCPT TOコマンドへの返信）

これは、受信サーバーがFROMヘッダーアドレスが自身のドメイン内にあり、メッセージがそのドメインへのメッセージの送信を許可されていないと見なしたサーバーから発信されたことだけを見たことを意味すると思います。つまり、受信サーバーはSENDERヘッダーを無視しました。

回避策があります：webappは、SENDERヘッダーを無視していると思われるドメインのリストを保持し、FROMヘッダーとTOヘッダーが両方ともそのようなドメインにある場合、FROMヘッダーを独自のメールアドレスに設定します。ただし、このリストにはメンテナンスが必要です。

望ましい経験を達成するためのより良い方法はありますか？私たちは、ネットの「善良な市民」になりたいと思っています。関係するすべての関係者（送信者と受信者）は、これらのメッセージに参加して受信したいと考えています。別の方法として、FROMヘッダーで常に会社の電子メールアドレスを使用し、作成者の名前/アドレスを件名の先頭に追加しますが、これは少し面倒です。

あなたは間違ったものを見ています。それらはメッセージヘッダーです。SMTP エンベロープを見る必要があります。（エンベロープの指定方法は、アプリケーションがメールシステムにメールを送信する方法に正確に依存します。多くのシステムでは、メール送信ユーティリティプログラムへのコマンドライン引数によってエンベロープが指定されます。）その571応答を発行することを決定した場合、SMTPリレーサーバーはメッセージヘッダーを見ることさえなかったかもしれません。

応答テキストは、通信している特定のSMTPリレーサーバーの管理者が、SMTPエンベロープに入れることができるものを制限していると言っています。封筒の受取人部分について不満を言っているようです。ただし、最初の受信者が指定されるまで、エンベロープ送信者の検証を延期している可能性があるため、送信者について文句を言っている可能性があります。

エンベロープ送信者は、配信ステータスメッセージが送信される場所であり、世界中のランダムな人に送信されるようにしたくないことに注意してください。（多くの人がこれを好まないという事実はさておき、メールの配信ステータスメッセージがあなた以外に返されることは意味がありません。）エンベロープ送信者として自分自身を指定してください。

MXところで、リソースレコードを要求するのは間違っています。SMTPリレーサーバーはA、AAAAリソースレコードがなくてもMXリソースレコードによって検索できます。RFC 5321§5.1を参照してください。

私は間違っているかもしれませんが、上記のエラーの原因として最も可能性が高いのは、特にPostiniの場合、拒否されるドメインに厳格なSPFポリシーがあることです。SPFチェックを備えたほとんどのメールサーバーは、From：ヘッダーのみをチェックし、Senderヘッダーを気にしません。

これが当てはまるかどうかを確認するには、「dig + short TXT domain.com」を実行します。domain.comはエラーメッセージを表示します。次のようなものを取得する必要があります。

「v = spf1 mx -all」

重要な部分は-allです。つまり、ドメイン所有者は、メールサーバーとして機能するサーバーからのみメールを送信し、他のすべてのメールは拒否されると述べています。

幸いなことに、このような場合は、メールを送信する前に積極的に確認できます！ユーザーがメールアドレスを入力したときに、WebAppにSPFチェックを実行させます。厳格なポリシーが設定されている場合は、ドメインをリストに追加します。SPFチェックを実行できるすべての言語のライブラリが不足することはありません。