偽のMXレコードを使用してスパムに対抗する
大量のスパムが送信されているクライアントがいます。今月の15日で、POP3の帯域幅はほぼ100 GBです。このドメインには7つの電子メールアカウントしかありません。 SpamAssassinをインストールして5に設定し、10〜20個のフィルターを設定してほとんどのジャンクを拒否しました。 POP3の帯域幅に大きな変化は見られません。間違っている場合は修正してください。スパムスコアを分析するために、サーバーは引き続き帯域幅を使い切ってメッセージを受信します。
気づかない人のために、私は偽のMXレコードに出会いました。基本的に、偽のサーバーを最低と最高のMXレコードとして設定し、動作中のサーバーのMXレコードを中央に配置しました。
例えば：
fake.example.com 1
realmx.example.com 2
fake2.example.com 3
理論は、スパムの大部分はWindowsベースのゾンビから生成され、通常、スパムをフィルタリングしないバックアップサーバーであるため、スパムの最高MXレコードを照会するスパムはかなり多いためです。最も低い偽のMXレコードは、残りのスパマー用です。通常、スパマーは失敗後に再試行しません。
誰かがこれを試しましたか？それは役に立ちますか？メールの配信に遅延や問題が発生しますか？他の誰かがより良い解決策を持っていますか？
Postiniのようなゲートウェイスパム対策サービスを使用して、自分で設定してください。 1か月あたりのメールボックスあたり数ドルで、絶対に理由がないわけではありません。スパムの99％を排除するだけでなく、スプールサービスへのアクセスも楽しむことができます（計画的または計画外のダウンタイムに便利）。スパムがネットワークのエッジに到達する前に、他の誰かがすべてのスパムを受信して処理できるようにすることで、帯域幅の節約について言及します。
Postiniの従業員ではなく、何十ものクライアントを設定しているだけの幸せなユーザーです。
私はこれを試しました、そしてあなたに強くお勧めしますそれをしないでください！当時はいい考えのようでしたが、いろんな差出人からのメールが消え始めて、間違いだと気づきました。私が気付かなかったのは、そこにひどく書かれたSMTPサーバーがたくさんあり、仕様に準拠しておらず、エラー処理がかなり下手であり、人々が「この他の男が私の電子メールを受け取ったから」 、それはあなたでなければなりません。」.
SPAMを処理するための他のいくつかの提案の2番目です。 Postiniは優れたサービスであり、無料のGoogleアプリに組み込まれているスパム対策機能でさえそれほど悪くはありません。より詳細な制御が必要な場合は、IronPortまたはその他のデバイスを購入するか、独自のデバイスをロールバックできます。
この方法について聞いたことがなく、正当な電子メールが数時間遅れる可能性があると想像できます。結局のところ、SMTPプロトコルは正当な電子メールを配信する必要があります。有効なサーバーは偽のmxレコードにヒットし、そのサーバーに配信しようとします...そこで実行されている可能性があるものは（もしあれば）わかりませんが、受け入れられるまで試行を続けます。
適切なサーバーは、メールが配信されるまでMXレコードを試行し続けます。スパマーはより賢くなる傾向にあり、これが現在いくつかのスパムソフトウェアで機能する場合、私はそれが長く機能するとは思えません。お勧めできません。
代わりに、既存のスパムフィルターに加えて、SMTPターピットを使用する方法を検討することをお勧めします。これらは現在入手可能です。私は、それが偽のmxレコードメソッドよりもはるかに効果的であることがわかると思います。
このようなターピットは、BSDではsmtpdに付属しています。 sendmail 8.13には、いくつかのタールピット機能もあります。
基本的に、ターピットはスパムサーバーのリソースを拘束することによって機能します。彼らは彼らが得る応答を遅らせることによってそれをします。例えばスパムサーバーが接続し、毎秒約1バイトを受信します。
一部のターピットサーバーはスパムパターンを探し、スパムサーバーを認識できます。正当なサーバーは、遅い応答を待つ準備ができています。一部のターピットサーバーでは、正当に認識されたサーバーを自動的にホワイトリストに移動するため、将来の遅延はありません。
Google SMTP Tarpitを見てください。
あなたはそれを言及しなかったので、あなたが [〜＃〜] dnsbl [〜＃〜] を使用しない理由がありますか？
編集：SpamAssassin サポートを含む いくつかの場合-それらがないと、スパムの分析に多くのCPUサイクルを浪費することになります。
私はこのこの偽のMX（ nolisting の変形）を使用しており、非常にうまく機能しています。
私はすべての通常のフィルターでPostfix MXを使用し、いくつかのスパムボットが2〜3回サーバーに過負荷をかけた後、試してみることにしました...結果は次のとおりです。 
私がfake-mxを実装したときに推測してみてください！ 8）
結果はpostgreyと同じですが、postgreyとは異なり、メールサーバーを変更する必要はありません。
スパムボットは、高MXまたは低MXのいずれかを試し、実際のMXをフィルタリングしようとする負荷から解放し（DNSBLを使用しても負荷が高かった）、実際のメールが最小限の遅延で到着します。
ただし、警告があります。リスクがあります。
一部のサーバーでは、再試行時間が長くなる場合があります。ほとんどのサーバーは最初の1つがタイムアウトした後に次のMXを再試行しますが、他のサーバーは次の数分で再試行しますが、1時間または1日後にのみ再試行するサーバーはすでに見ました。それらは非常にまれであり、私が捕まえることができたものにとって、それは悪い設定でした。他のポストマスターと話すと問題が解決します
すべてのメールに遅延が発生します。実際、遅延はまったくありません。ほとんどすべての実際のメールサーバーは、最初のタイムアウト後に次のMXに再試行するため、30秒の遅延について話しています。彼らは通常、より長い遅延のためにメッセージをキューに入れる前に、少なくとも3 MXを試します。しかし、これを行わず、すべてのメッセージを数分間遅延させる可能性がある1つの壊れたメールサーバーに連絡している可能性があります。したがって、これは、このソリューションを展開するときに監視する必要があります。
壊れたサイト。一部のWebサーバーは、パスワードや通知などの電子メールを送信し、内部の実際のメールサーバーに配信する代わりに、「偽の」メールサーバーになり、直接配信しようとします。そのウェブサーバーとして、彼らは決して再試行せず、電子メールは失われます。繰り返しますが、実際の電子メールサーバーだけが電子メールを送信する必要があるため、webmaster/web開発者からの悪い設定です。この問題を見つけるたびに、その問題についてウェブマスターと話します。通常、問題は修正されています。
ログはありません。偽のMXが接続されていないIPにアクセスしているため、何が配信されようとしたかに関するログはありません。あなたは誰かが不平を言うときに何かがうまくいかなかったことを知っているだけです。しかし、これも良いです。メールを配信する試みはないので、リモートの問題であると常に主張できます。反対側はログをチェックして問題を解決する必要があります。実際のサーバーへの接続がまったくないことを証明でき、問題を解決するためのプレッシャーを反対側に移動します。反対側が問題を修正できない場合は、信頼できない、信頼できないと思われました。
ホワイトリストはありません。これはDNSを介してすべてのサーバーに適用されるので、1つのサーバーをホワイトリストに登録することはできません...実際には半分真実ですが、より困難です。ホワイトリストソリューションは、最低MXがsmtpが実行されているIPをポイントするが、すべてのユーザーに対してファイアウォールによってフィルタリングされることです。 whilelistを実行するサーバーは、ファイアウォールで許可する必要があります。これにより、すべてのサーバーがファイアウォールによって拒否され、ホワイトリストに登録されたサーバーがメールサーバーに配信できるようになります。これは機能しますが、IPホワイトリストにのみ使用でき、メールホワイトリストには使用できません。
リモート送信者が「拒否された」配信のログを持っている（したがって、問題を指摘することができる）postgreyとは異なり、偽のMXは、Webサーバーが接続できず再試行しなかったことを示し、言い訳はありません。問題についてリモート側に。私たちは常に「ルーティングの問題を主張できますが、バックアップMXは正常に機能しており、他のすべての電子メールを受け取ります」ので、失敗したMXはpostgreyよりも受け入れやすくなっています。
とはいえ、苦情はほとんどない（約3か月に1回）ので、十分に安全だと考えています（すべてのスパムフィルターにはリスクがあります）。
すべてのMXに有効なipv4アドレスを使用していますが、偽のアドレスには、使用していない制御しているIPを使用していることに注意してください（したがって、どの接続でもタイムアウト/ホストに到達できません）。これを使用しない場合でも、このルールが適用されます。電子メールが機能するために完全に有効なDNS構成を必要とするDNSおよびSMTPサーバーがあります。偽のMXも有効でなければなりません。それらは到達可能であってはなりません。
プライベートIP、または偽のMXに対して制御していないIPを使用しないでください（ipv6アドレスを追加する場合は、ipv4アドレスも追加します）。これにより、DNSとメールサーバーの破損に関する問題や、他のユーザーがあなたのメールを受け取ることの驚きを回避できます（制御できないIPにSMTPサーバーをインストールすることにより）。また、CNAMEはMXに対して禁止されているため、プレーンなAレコードだけを使用しないでください。
最後に、tcp-resetを偽のMXに送信して、（パケットをドロップすることによる）単純なタイムアウトの代わりにパフォーマンス（ホストまたはポートに到達できない）を改善する必要があるため、ファイアウォールに追加することをお勧めします。
とにかく、私はまだそれを使用しているだけでなく、誰もがそれを使用することをお勧めします
メールフィルタリングに関する限り、私はSpamassasinと policyd-weight の組み合わせに満足していて、SMTP接続中に送信者のホスト名とブロックリストをチェックしています。これは、2つの理由から素晴らしいことです。
- 拒否された電子メールをspamassasinで処理する必要はありません。これにより、システムリソース（ベイジアン分析には時間がかかります）と帯域幅が節約されます。
- 送信者ホストが拒否されるため、万が一正当な電子メールがブロックされた場合、その送信者は配信失敗通知を受け取ります
私はPostfixの設定を使用していますが、おそらく Eximでpolicyd-weightをインストールする する方法があります。
正直言って、完全にはわかりませんでした。
わかりました、私の主要なメールサーバーは偽物です。それで？全く存在しないのか？ （いずれにせよ最後にSPAMersの一部をカットしたとしましょう。）「生存者」はセカンダリを使用します—問題ありません。しかし、なぜこのセットアップに3番目のサーバーがあるのでしょうか。
これは私の答えであり、質問ではないはずなので、私はそう結論付けます：それは病気でグレイリストの薄い影です。実際の効果を見たい場合は、グレイリストを使用してみてください、man。
Spamhaus zenリストにリストされているホストへの接続を遅らせることで、ほとんどのスパムをドロップします。スパムボットは遅延を好まない。 HELOコマンドで明らかなサーバー偽造を検出すると、多くのスパムも除去されます。サーバーの偽造を示すことがわかった条件には、次のものがあります。
- ホスト名またはIPアドレスを使用します。
- 修飾されていないホスト名を使用します。
- FQDNの代わりにドメインリテラル（[192.0.2.15]）を使用する。 （はい、RFCでは必要ですが、最近ではインターネットメールサーバーでは使用されていません。）
- メールではなくHELO名のSPFの失敗（失敗、ソフトフェイル、およびニュートラルでブロックします）。
自動化またはマーケティングメールを重視する場合は、動作しないHELOコマンドをチェックしてください。私の経験では、他のすべてのメールがこれらの条件を満たしています。
- ホストにFQDNではなく第2レベルのドメイン名を使用します。
- RDNSを検証するためにIPまたはHELO名を要求する。
- FQDNに有効な第2レベルドメインが必要です。 （ローカルは有効なドメインでもローカルドメインでもありません。）
リターンパスに署名すると、スパムをブロックできます。最近、偽のバウンスははるかに少なくなっていますが。
残念ながら、合法的な自動メールやマーケティングメールの多くは、リターンパスを偽造しています。これらのホストには、有効なポストマスターアドレスもないことがよくあります。リターンパスに有効なドメインを要求することは実行可能であることがわかります。正当なメールでは、スパムよりもSPF失敗の応答がはるかに多くなります。
私は最近Eximでスパムをブロックする ブロッキングの経験を投稿しました
ゲートウェイが壊れている正当な人々からの失われた電子メールに加えて、それはずっと前に（15年前の+/-のように）試行され、スパマーはその当時すぐにそれに適応しました。スパムへの影響はほとんどないが、それはあなたの電子メールの信頼性の正味の損失になると私は思う。でも、試してみたら結果を送ってください！
残念ながら、最初のMXレコードに到達できない場合にメールを送信しない特定のキャリアがあります。私は最近これについての私の経験を書きました ブログエントリ なので、ここでは繰り返しません。しかし、要約すると、スパマーがIPv6を使用していない（まだ）と思っていたため、最初のMXレコードは実際にはIPv6のみのMXレコードでした。残念ながら、これにより問題が発生し、最終的にはゾーンの最初のMXレコードにIPv4アドレスを追加する必要がありました。