クライアントのドメインに代わってメールを送信する最良の方法は何ですか？

私は、グレーリストに登録されず、バウンスの問題を回避しながら、クライアントのドメインに代わってメールサーバーにメールを送信させる最良の方法を知りたかったのです。

ここで他の質問を読んでいます、ここ、ここででいますが、可能な解決策をすべて探求している人はいません。比較したい可能性がいくつかあります。

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

質問：これがGmailの機能です。エンベロープ送信者ではなく、異なるドメインを持つのはメッセージヘッダー「From：」です。
emailclientには、「From：res@client.com via do-not-reply@myapp.com」または 「From：do-not-reply@myapp.com On Behalf Of res@client.com」と表示されます、これは問題ではありません私のために。
さて、これは私のドメインの評判、ヘッダー「From：」に異なるドメインがあるという事実に悪影響を及ぼしますか？（そして、それを行っているのがGoogleでない場合..）

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Googleは一度これをしなかったし、間違いそれを呼ばれるように見えます http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + of％22＆pli = 1
バグによりメッセージから「Sender：」が削除され、「via」はメールクライアントに表示されませんでした。（RFCは、「From：」と同じでない場合は存在しなければならないと述べています）

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

client.comがメッセージを送信しているかのようです（MAIL FROMも「なりすまし」です）。ただし、client.comドメインが既知であるか、DNSにSPFエントリがある場合、mymailserver.comに代わってメッセージを送信できるように、DNSを変更する必要があります。（これは、nb 、および私のクライアントの一部はドメインを制御できません。つまり、@ gmail.com自体を使用しています）

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

質問：これは最も単純なもので、「Reply-to：」ヘッダーのみを追加します。これはメールクライアントによって常に考慮されていますか？これはスプーフィングとして認識され、「Reply-to」ヘッダーに異なるドメインを追加し、ドメインの評判に悪影響を与える可能性がありますか？
- RFCが唯一と言っている、「返信先フィールドが存在する場合、返信がすべきであるアドレスにそのフィールドに示されていないアドレスにアクセスしてください（複数可）は、Fromフィールドに示されています。」。
-「From：」ヘッダーラベルのみが「なりすまし」になります：
「From：myclient.com（via myapp.com）<do-not-reply@myapp.com>」。

素晴らしい質問です。私はちょうど同じことを研究するのに数時間費やしました。

以前にメールフォームにオプションCを使用する（主に素朴な）多くのWebサイトを展開していましたが、配信の問題が増えています。メールプロバイダーは徐々に物事を厳しくしています。たとえば、Yahooは最近、有効なDKIM署名のないすべての電子メールFrom: ____@yahoo.comを拒否するように受信者に要求するようにDMARCポリシーを変更しました。DMARC（Gmail、おそらくHotmail / Outlook.comおよびYahooを含む）に従うSMTPサーバーを受信すると、ハードバウンスが発生します。これらのメッセージます。eBayとPaypalには、フィッシングを減らすための同様の厳格なポリシーがあります。残念ながら、「Sender」ヘッダーを指定しても役に立ちません。

（Yahooエイリアスから「From」を送信するときに、Gmailがこの問題をどのように回避するのだろうか？）

オプションA「From」メールに厳密なDMARCポリシーがないことがわかっている場合は、方が適切なオプションになります（簡単なDNSクエリで確認できます）。

視覚的に最も魅力的ではありませんが、オプションDは実際に最も安全であり、将来のプロジェクトのほとんどで推奨されるものです。PayPalは以前にオプションAを使用していましたが、現在はオプションDに切り替えていることに注意してください。

信頼性を高め、配信の可能性を高めるために、SPFやDKIMの実装を検討します。これらおよび他のものはで言及されています私が参考になっ Googleの一括送信ガイドラインに記載されています。

あなたが何を望んでいるのか分かりません。あなたが望むことをするための「安全な」または「安全でない」方法はありません。

私はいつもD）を好むでしょう。さらに、SPFレコードを追加します。しかし、私が言ったように、これは他のものより安全でも安全でもありません（あなたがそれをどういう意味でも）。

Reply-Toヘッダーは、レピュテーションに一切影響しません。返信にそのアドレスを使用するようにクライアントにアドバイスするだけです（おそらく、名前の由来はここでしょうか？！）。クライアントがこの推奨事項に従う場合、保証されません。

2つの信頼できるソリューション：

1. SPFドメインレコードにメールサーバーを追加するように顧客に依頼する
2. お客様にメールアカウントの資格情報（メールサーバーIP、ユーザー名、パスワード）を提供するよう依頼し、これらをアプリケーション内で使用してメールサーバーに接続し、メールを送信します（実際にアプリケーション内にメールクライアントを作成します）。