web-dev-qa-db-ja.com

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

メールサーバーがクライアントのドメインに代わってメールを送信し、グレーリストに登録されたり、バウンスの問題を回避したりするための最良の方法を知りたいと思っていました。

私は他のいくつかの質問 here 、 here および here を読んでいますが、すべての可能な解決策を探索するものはありません。比較したいいくつかの可能性があります：

A。

HELO mymailserver.com
MAIL FROM<[email protected]>  # mymailserver.com same IP as myapp.com
DATA
  From: <[email protected]>
  Sender: <[email protected]>

質問：これはgmailが行うことです。エンベロープ送信者ではなく、ドメインが異なるのはメッセージヘッダー「From：」です。
emailclientsは "from：[email protected] via [email protected]"または "From：を表示します[email protected] [email protected]の代わりに "、これはnot私にとって問題ではありません。
今、これは私のドメインの評判に悪影響を与えますか？ヘッダー "From："が異なるドメインを持っているという事実？ （そしてそれをしているのがGoogleでない場合。）

B。

HELO mymailserver.com
MAIL FROM<[email protected]>
DATA
   From: <[email protected]>
   # 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
バグによりメッセージから「送信者：」が削除され、「経由」がメールクライアントに表示されませんでした。 （RFCは、「From：」と同じでない場合は存在する必要があると述べています）

C。

HELO mymailserver.com
MAIL FROM<[email protected]>
DATA 
  From: <[email protected]>

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

D。

HELO mymailserver.com    
MAIL FROM<[email protected]>
DATA 
  From: <[email protected]>
  Reply-to: <[email protected]>

質問：これは最も簡単な質問です。「Reply-to：」ヘッダーのみを追加します。これは本当にメールクライアントによって常に考慮されますか？これもなりすましとして認識され、「Reply-to」ヘッダーに異なるドメインが追加され、ドメインの評判に悪影響を与える可能性がありますか？
-RFCは、「Reply-Toフィールドが存在する場合、返信は[〜＃〜] [〜＃〜]がアドレスに移動することを示しているだけです。そのフィールドに示され、差出人フィールドに示されているアドレスには送信されません。
-「From：」ヘッダーラベルのみが「なりすまし」されます：
「From：myclient.com（via myapp.com）<[email protected]>」。

smtpemail-serveremail-bounces
15
dgaspar

すばらしい質問です。同じことを研究するのに数時間費やしました。

私は以前オプションCをメールフォームに使用する多くのWebサイトを展開していました（主に未経験）、配信に関する問題が増えています。メールプロバイダーは徐々に物事を厳しくしています。たとえば Yahooは最近DMARCポリシーを変更しました 受信者にすべての電子メールを拒否するように依頼しますFrom: [email protected]有効なDKIM署名なし。 DMARC（Gmail、およびおそらくHotmail/Outlook.comとYahooを含む）に続くSMTPサーバーを受信すると、これらのメッセージがハードバウンスされます。 eBayとPaypalは、フィッシングを減らすために同様の厳格なポリシーを持っていると私は信じています。残念ながら、 "Sender"ヘッダーを指定しても効果はありません。

（ "From"からYahooエイリアスを送信するときに、Gmailはこれをどのように処理するのでしょうか？）

オプションAは、「From」メールに厳格なDMARCポリシーがないことがわかっている場合に、より良いオプションになります（単純なDNSでこれを確認できる可能性があります）クエリ）。

視覚的に最も魅力的ではありませんが、オプションDは本当に最も安全です。これは、今後のほとんどのプロジェクトでお勧めします。 Paypalが以前にオプションAを使用していたことは注目に値しますが、- 今はオプションDに切り替えました 。

追加の信頼性と配信の可能性を高めるために、SPFやDKIMの実装を検討します。これらのことやその他のことは、Googleの一括送信ガイドラインで言及されています。

2
Simon East

私はあなたが何を望んでいるかはわかりません。やりたいことを行うための「安全」または「安全でない」方法はありません。

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

Reply-Toヘッダーは、レピュテーションに影響を与えません。返信にそのアドレスを使用するようにクライアントにアドバイスするだけです（ああ、たぶんここは名前の由来ですか？！）。クライアントがこの推奨に従う場合、保証はありません。

1
mailq

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

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