私たちのアプリケーションの主要コンポーネントは、他のメンバーに代わってメンバーに電子メールを送信します。現在、「From」アドレスをシステム アドレスに設定し、「Reply-to」ヘッダーにメンバーのアドレスを使用しています。問題は、一部の電子メール クライアント (および自動返信/バウンス) からの返信が「Reply-to」ヘッダーを尊重しないため、システム アドレスに送信され、効果的にブラック ホールに送信されることです。「差出人」アドレスを会員様アドレス、「差出人」アドレスを弊社システムアドレスに設定することを検討しております。この方法は、SPF および Sender-ID チェックに合格するようです。
この方法に切り替えない理由はありますか? 他に考えられる問題はありますか？
おそらく必要以上に詳細を以下に示します。
アプリケーションが最初に開発されたとき、「送信元」アドレスを送信メンバーのアドレスに変更しただけです。これは当時の一般的な慣行でした (これは何年も前のことです)。後で、「差出人」アドレスがメンバーの名前と私たちの住所になるように変更しました。つまり、
出典：「メアリー・スミス」
<messages@company.example>
「返信先」ヘッダーをメンバーのアドレスに設定した場合:
返信先: 「メアリー・スミス」
<marysmith@memberisp.example>
これは、メッセージが誤ってスパムとして分類されるのに役立ちました。SPF の人気が高まるにつれて、SPF レコードと連携して機能する追加のヘッダーを追加しました。
送信者:
<messages@company.example>
問題なく動作しますが、実際には、一部の電子メール クライアントとほとんどの MTA が "Reply-To" ヘッダーを尊重しないことが判明しています。このため、多くのメンバーが目的のメンバーではなく、messages@company.example にメッセージを送信します。
そのため、送信者に関するデータを電子メールのヘッダーに追加したり、「差出人」の電子メール アドレスにエンコードして、応答を処理して適切にリダイレクトしたりできるようにするためのさまざまなスキームを想定し始めました。例えば、
出典：「メアリー・スミス」
<messages+ca54bb7482ace09f@company.example>
"messages" の後の文字列は、システム内の Mary Smith のメンバーを表すハッシュです。もちろん、システムアドレス用の MTA 機能を開発する必要があるため、その方法は多くの苦痛につながる可能性があります。もう一度 SPF のドキュメントを調べていたところ、興味深いページが見つかりました。
http://www.openspf.org/Best_Practices/Webgenerated
evite.com と egreetings.com の 2 つの例を示しています。基本的に、evite.com は私たちが行っている方法でそれを行っています。egreetings.com の例では、"Sender" ヘッダーが追加されたメンバーの差出人アドレスを使用しています。
問題は、送信者ヘッダーを使用してメンバーの送信元アドレスの egreetings メソッドを使用することに潜在的な問題があるかどうかです。これにより、悪いクライアントがシステム アドレスに送信する応答がなくなります。Return Pathが指定されていても、バウンス/休暇/ホワイトリストの問題がMAIL FROMに送信されることが多いため、これで問題が解決するとは思いません。