転送メールサーバーにはSRSの書き換えが絶対に必要ですか？
私のドメインでPostfixメールサーバーを運用しています（mydomain.comなど）。主に転送メールサーバーとして機能します。ユーザーは@ mydomain.comのメールアドレスを受け取りますが、通常は自分のアドレスを外部の受信トレイ（Gmail、Yahooなど）に転送することを選択します。転送される数千のアドレスがあるため、サーバーはかなり大量のメールトラフィックを処理します。
以前は、サーバーはSRS書き換えを使用していませんでした。もちろん、これは転送されたメールがSPFチェックに失敗することを意味しました。私のIPアドレスは、元の送信者のドメインに代わってメールを送信することを技術的に承認されていないためです。しかし、私が見ることができるものから、それはどんな大きな問題も引き起こしていないようです。一般的に、Gmail、Yahooなどのユーザーからの苦情は、SPFの失敗を無視してとにかくメッセージを配信するのに十分賢いようです。
これを念頭に置いて、SRSの書き換えを有効にすることが本当に必要ですか？有効にすることを検討していますが、私の主な懸念は、スパムが必然的に転送される場合、私のドメインがスパムの送信に対してブラックリストに登録されることです。書き換えによって、まるで私がスパムの発信者であるかのように見えませんか？ （少なくとも、これは Gmailのメールサーバー転送のベストプラクティス を読んだことによる私の理解です）。
確かに、転送前にSpamAssassinを使用して疑わしいスパムの件名に「SPAM」を追加し、信頼度の高い（スコア15以上）スパムを転送せず、spamhausブロックリストを使用するなどの推奨予防策をすでに取っていますが、これらの対策は行われていません完璧ではなく、スパムはまだマークされていないところを通り抜けることができます。
SRSの書き換えを有効にすることは、スパマーとして誤ってマークされるリスクを増加させる場合、価値がありますか？または、そのままにしてSPFの失敗を無視する方が安全でしょうか？
あなたの質問の要約は「そこにいくつのメールサーバーが受信メールのSPFレコードをチェックするか？」であるように思えます。それらのほとんどである場合、SRSは転送サーバーの絶対要件です。それ以外の場合は、SRSは必要ありません。
残念ながら、私はすぐにこれに関する学術的な作業を行うことができません。しかし、私は受信メールのSPFをチェックしているので、someメールサーバーがチェックすることは間違いありません。サーバーを私のサーバーのアカウントに転送しているクライアントは、SPFをアドバタイズする送信者から送信された電子メールをすべて失います（すべてがそうであるように）-all、SRSを使用しない場合。したがって、私はSRSがないと、一部のお客様のメールは配信されませんと断言できます。
マルクにドイツ語が読めないことをお詫び申し上げます。PDF彼は進歩的な説得力のある議論を引用しているかどうかは言えませんが、SRSがなければ、顧客の一部がそれを繰り返すことができます。電子メールは配信されません。その割合は言えませんが、ゼロではありません-そして、与えられた、SRSを実行する以外に選択肢はないと思います。
あなたのサーバーはSPAMを転送することによってそれ自体は役に立たないことに同意しますが、私の経験では、評判の低下のほとんどは、エンベロープFromドメインではなく、そのIPアドレスに対して行われます。これは、SRSの使用に関係なく行われます。
あなたの質問へのより深い答えは、SPFとその（あまり考えられておらず、インターネットを破る）フォローアップDMARCの間で、メール転送サービスがその日を過ごしているように思えます。私はすでに1人を除くすべてのユーザーにサーバーでの最終配信を要求しており、その1人のユーザーは2016年に変更または終了する必要があります。現在、多くのWebメールシステムでは、 IMAPまたはPOP、および多くのメールクライアントでは、複数のIMAPまたはPOPアカウントを1つの統合されたINBOXとして提示できるため、転送は、以前の集中型の読み取りの恩恵にはなりません。
つまり、短期的にはSRSが必要で、長期的には新しいビジネスモデルが必要です。
Heinlein Supportの関係者によると、SRSは紙の上ではいい考えのようですが、実際にはあまり機能しません（彼らは100,000以上のアカウントを持つ中規模のメールサービスを実行しています）。
詳細は彼らの講演にありますが、ドイツ語ですが、なぜですか： https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf
主な理由は、SRSが実際のSPFの実装の深刻な問題に対する小さなパッチであるためです。これは、SPFが電子メールの一般的な使用例をあまりカバーしていないためです。 SRSが意味を持つのは意味がありますが、SRSは大規模なサーバーベースに展開する必要がありますが、これはほとんど起こりません。そのため、その大きなサーバーベースに展開するまで、まったく意味がありません。
ただし、大規模なメールプロバイダーの問題は、現在のところ大きなユーザーベースがあり、ますます多くの技術（DMARCの後継がすでにパイプラインに入っている）を実装していることです。信頼できる方法でメールを送信するためのメールサーバーのセットアップ。
Gmail、Hotmailなどの大手メールプロバイダーにメールをより適切に配信したい場合は、少なくともDKIMとDMARCを実装する必要がありますが、せいぜいソフトフェイルに設定し、メール配信にいくつかのレート制限メカニズムを実装することもできます。あなたにとって不思議に働くでしょう。
大手プロバイダーのこの問題が、Mailchimp、Mandrill、Returnpathなどのサービスが今日存在する理由です。これらのプロバイダーはGoogle＆Coにお金を支払います。よりよい配達の質のため。
@MadHatterの各単語に同意しますが、Googleに関する重要な事実です。
Gmailに転送サービスを提供している場合は、SMTPアクセスも提供している可能性が高いため、Gmailユーザーはあなたが保存しているアドレスに代わってGmailからメールを送信できます。
その場合、Gmailはあなたがこのメールの転送者であることを認識しており、SPFチェックに失敗しても転送をスパムとしてフラグしません。
[email protected]からクライアントにメールを送信できます。 メッセージは警告なしで受信トレイに届きます！（Microsoft あるか-all spfレコード内）
チェックおよび確認済み。添付例。
このメッセージは受信トレイに送信されました。 