sendmailはfromアドレスではなくreturn-pathを使用しています
スパムとしてマークされた電子メールについて不平を言っている顧客がいます。
私はヘッダーを見ています。正しいFrom：[email protected]が表示されます
ただし、リターンパスは好きではありません。
Return-Path: <[email protected]>
Received-SPF: neutral (google.com: x.x.x.x is neither permitted nor denied by domain of [email protected]) client-ip=x.x.x.x;
Authentication-Results: mx.google.com; spf=neutral (google.com: x.x.x.x is neither permitted nor denied by domain of [email protected]) [email protected]
Return-Pathに差出人アドレスを使用するようにsendmailを設定するにはどうすればよいですか？
コウモリの本（1165ページ）から：
Return-Path：ヘッダーは、返信に使用される送信者（From：ヘッダーとReply-To：ヘッダー）ではなく、実際の送信者のエンベロープアドレスを表示することを目的としています。たとえば、Usenetニュースを投稿する場合、Return-Path：は「ニュース」を表示し、From：は投稿ユーザーのアドレスを表示します。ただし、一般的に、Return-Path：をメールへの返信に使用しないでください。配信エラーの通知のみに使用することを目的としています。
クライアントでReturn-Path：ヘッダーに問題はありません。ヘッダーが示すように結果がニュートラルであるため、SPFでもどちらもありません。クライアントは、意図された受信者が自分が送信したものをスパムと見なすという事実を受け入れる必要があります。
これが実際に誤検知である場合は、適切な [〜＃〜] spf [〜＃〜] および [〜＃〜] dkim [〜＃〜] レコードを設定することを検討してください。ドメインを確認し、状況が改善するかどうかを確認します。
あなたのメールは、Googleのサーバーの1つを使用して送信している自動送信者からのもののようです。メッセージを送信するためにGMailに接続している可能性があります。サーバーにSPFレコードがあるようです。このレコードには、Google SPFリストが含まれておらず、強制する必要があることも示されていません。 [email protected]のSenderヘッダーを含めると役立つ場合があります。
送信を開始する前に、電子メールをスパムのように見せかける要因はいくつかあります。
- ホスト名を返すPTRレコード、またはアドレスの別のAレコードの名前を持つ静的アドレスがありますか？ （逆引きDNS検証は機能しますか？）
- メールサーバーは、PTRレコードが返すのと同じ名前を使用して自分自身をアナウンスしますか？
- メールサーバーには、メールの送信を許可するSPFレコードがありますか？
- あなたの住所はlist.openwl.orgに記載されていますか？
最初の2つのテストに失敗した場合は、スパムまたは自動メールソースを強く示しています。個人間の電子メールはほとんどの場合これらのテストに合格しますが、スパムは失敗することがよくあります。次の2つのテストは、非スパムを示しています。
電子メールの送信を開始すると、適用される他のテストがあります。
- リターンパスアドレス（エンベロープアドレス）と差出人アドレスの両方に、動作中のメールサーバーを指すMXレコードが必要です。
- リターンパスアドレスは、差出人または送信者アドレスヘッダーと一致する必要があります。
- 両方のドメイン（異なる場合）には、有効なポストマスターアドレスが必要です。
- 両方のドメイン（異なる場合）には、送信サーバーからのメールを許可するSPFレコードが必要です。
- 電子メールアドレスとそのドメインの両方の以前の履歴が考慮される場合があります（自動ホワイトリスト/自動ブラックリスト）。
- メッセージに有効なDKIM署名がありますか。
- 電子メール管理者が適切と見なすその他のルール。
自動送信者からのDKIM署名付きドキュメントの失敗率が比較的高いことがわかりました。これは主に、DNSから利用できない公開鍵に関連しています。