ベストプラクティス？ Webアプリからメールを送信
CRMアプリのようなWebアプリケーションがあります。人々はログインして、他の人々とのビジネスを管理することができます。その管理の一環として、当社のアプリケーションは管理対象の人々に電子メールを送信する場合があります。ここでの問題は、お客様がそれらの電子メールの「差出人」アドレスを自分のものにすることを好むことです。そうすれば、受信者は、私たち自身のドメインの「返信しない」アドレスからではなく、知っている誰かから電子メールを受け取ります。
多くのメールサーバーでは、これは問題ではありませんが、それらのメールをバウンスしているものがいくつかあります。好奇心から、テストメールを送ってもらい、ヘッダーを確認しました。 Googleアプリが追加したものは次のとおりです。
Received-SPF: softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) client-ip=99.99.184.164;
Authentication-Results: mx.google.com; spf=softfail (google.com: best guess record for domain of transitioning [email protected] does not designate 99.99.184.164 as permitted sender) [email protected]
（実際の「差出人」アドレスを[email protected]に置き換えました）
したがって、電子メールが私に配信されている間、他のサーバーがそれを拒否する理由は確かにわかります。私たちのアプリはclientdomain.comに解決されることはありません。
ここでの私のオプションは何ですか？
1）すべての「差出人」アドレスをクライアントのわかりやすい名前に設定することを提案できますが、ユーザーは独自の「返信なし」の電子メールアドレスを使用します。その後、spfとそのすべてを接続することができました。
2）クライアントがサーバーのIPと一致するようにspf/reverse dnsを構成することを提案できます（これは恐ろしいオプションのようです...）
ほかに何か。この種のことのベストプラクティスは何ですか？
できることの1つは、送信者の「名前」をクライアントの名前として設定してから、返信先ヘッダーを設定してクライアントの電子メールアドレスに移動することです。
そうすれば、彼らが知っている「Bob Johnson」からメールを受信しているように見え、[返信]をクリックすると、bjohnson @ clientcompany.com宛てに送信されます。
Paypalのような会社があなたの実際の電子メールアドレスから電子メールを送ることができることは知っていますが、これがヘッダーで巧妙なのか、それともすべての電子メールプロバイダーがPaypalの電子メールサーバーを「信頼」しているのかはわかりません。
SPF /ドメインキーはすべて、受信者に表示される電子メールの差出人アドレスではなく、エンベロープの差出人アドレスで機能します。
したがって、Envelope Fromをドメイン内の有効な電子メールIDとして使用し、Fromをクライアントの電子メールIDのままにしておくことができます。
そうすれば、SPF /ドメインキーは引き続き通過します。
他のベストプラクティスに関する限り、これをチェックしてください Eメールサーバーテスト 。
http://www.openspf.org/Best_Practices/Webgenerated を参照してください。
egreetings.comは次のようにします。
ドメイン内の一般的なアドレス（[email protected]）を選択してください。
「MAILFROM」をそのアドレスに変更します。
メッセージを送信した受信者に表示する「送信者」ヘッダーを追加します。 「送信者」は標準フィールドです。 RFC5322を参照してください。evite.comは次のようにします。
ドメイン内の一般的なアドレスを選択してください（[email protected]）。
「MAILFROM」をそのアドレスに変更します。
「From」ヘッダーをそのアドレスに変更します。
ユーザーの電子メールアドレスを含む「Reply-To」ヘッダーを追加します。
SPFとDomainKeysは、自分が行っていること、つまり自分が所有していない差出人アドレスを使用してメールを送信することを防ぐことを目的としています。
回避することを目的としているため、回避するためにできることはあまりないと思います。
各ユーザーに、適切なGmailまたは他のアカウントに転送するだけのローカルメールアドレスを指定して、返信が機能するようにし、それを差出人アドレスとして使用することができます。それはあなたの側でより多くの仕事です。
また、「resentfrom」ヘッダーを使用できる場合もあります。
少なくともSPFについては理解しているので、許可されたサーバーのリストにメールサーバーを追加する必要があります。
これが、foo.comの所有者があなたがfoo.comの承認された電子メールサーバーであると言っているという点で重要です。
メールサーバーへの逆引きDNSは必要ありませんが、メールサーバーは正しくHELOし、その逆引きDNSは正しくなければなりません。したがって、foo.comのSPFがbar.comをリレーとして許可している限り、HELOはbar.comとして受け入れられ、bar.comの逆を使用して、foo.comにメールを送信します。
http://blogs.crsw.com/mark/archive/2006/07/06/2032.aspx を参照してください。
「MAILFROM」の内容はEnvelopeFromで、SPFチェックに使用されます。受信者に表示されるのは、AFTERDATAコマンドで指定されたものです。
それらは同じである必要はありません。