アクセスできないメールサーバー、またはスパムのない生活

スパムとの戦いは、すべての責任あるメール管理者にとって頭痛の種です。 最愛のユーザーがより良く生きるために発明していないものは何ですか。 ただし、多くのシステム管理者と通信する慣行が示しているように、何らかの理由で、スパムを正しくフィルタリングする方法を誰もが知っているわけではありません。

最も一般的なアプローチは、「RBL（DNSBL）を追加して生活を楽しむ」ことです。 このアプローチは、完全ではありません。 2番目に人気のあるコンテンツフィルターは、多くの場合、多くのお金で購入されます。 このアプローチも、ほとんどの場合、完全に不当です。

しかし、すべてが非常に単純であり、静かな生活を送るには、着信SMTPセッションの3つのヘッダーをよく見るだけで十分です。 Habréとインターネットの裏通りで大騒ぎしたので、スパムに対抗するという観点からSMTPサーバーの正しい構成に関する網羅的な記事を見つけませんでした。 したがって、私はこのトピックについて自分が知っていること、そして自分がうまく使っていることをすべて描くことにしました。

ちなみに、この記事はもちろん、品質の高いスパムフィルターを作成したい管理者を主な対象としています。 ただし、一方では、単にメールを処理する必要があるが、電子メールの転送プロセスのすべての複雑さに精通していない人にとっては非常に重要な情報が含まれています。

したがって、ユーザーをスパムから保護したい場合、またはその逆の場合、誰かが誤ってあなたの手紙からユーザーを保護しないようにしたい場合-catへようこそ。

短いメモ：この記事はPostfixメールサーバーのセットアップを目的として書かれましたが、一般的には本質的に理論的なものです。 説明されているPostfixオプションは、構成ファイルの対応する* _restrictionパラメーターで指定する必要があります;詳細については、Postfix構成ガイドを参照してください。

SMTPプロトコルについて少し

メールには通常のメールと多くの類似点があります。 現在、私たちにとって最も重要なことは、電子的な「封筒」上のすべての情報が、受信者と送信者、および封筒を配達した郵便配達人のスタンプの2つのアドレスであるということです。

少し脱線してみましょう：非常に反発的な外観の人があなたのところに来て、「ティリミリトラミディアからのトリム」という返信用のアドレスでしっかりと封印された小包を渡すと想像してください。 受け入れて開くリスク ほとんどない。 そのため、アドレス情報のみに基づいて電子メールを簡単にチェックおよび選別することもでき、可能なアクションの範囲はここではるかに広くなります。

ご存じのとおり、インターネットメールはSMTPを介してメールサーバー間で転送されます。 このプロトコルを使用した通信は、3つの必須ヘッダーで開始されます： HELO 、 MAIL FROMおよびRCPT TO 。 つまり、データの転送を開始する前に、サーバーは最初に自身を提示し（HELO）、次に送信者の返信アドレス（MAIL FROM）を報告し、次に受信者アドレス（RCPT TO）を報告します。 これらの3つのヘッダーは電子封筒の署名であり、ほとんどすべてのスパムはその分析に基づいてのみ除去できます。 サーバーに何かを転送しようとするほとんどの試みは、MAIL FROMを超えることはありません。つまり、文字は実際に受け入れられる前に選別され、負荷が大幅に削減されます。 つまり、Tryamから小包を開いて炭an菌の胞子を発見する代わりに、私はすぐに郵便屋を地獄に送ります。

それで、明らかにスパムである電子メールを受け入れないために何をすべきか？ 順番に行きましょう。

DNSについて

インターネットの夜明けに、メールは住所に指定されたノードに直接配信されました。 つまり、user @ domain.comにレターを配信するために、メールサーバーはdomain.com IPアドレスを探し、見つかったIPでパッケージを送信しようとしました。 その後、MXレコードが登場し、このようなメール相互作用の組織の問題のほとんどをすぐに解決しました。 ただし、一部のプログラムは、メール配信用のAレコードで引き続き動作する場合があります。 しかし、もちろん、ドメインには少なくとも1つのMXレコードがありますよね？

MXレコードには、指定されたドメインのレターの配信先サーバーのアドレスが含まれています。 ただし、スパムに対抗するために、指定されたドメインからの文字を送信できるサーバーのDNSアドレスを指定できる技術が登場しました。 彼女の名前はSender Policy Frameworkです。

テクノロジーのすべての詳細については説明しませんが、TXTレコードと言います

v=spf1 +mx -all

ドメインの場合、SPF検証をサポートするすべてのクライアントに、ドメインからの手紙はMXレコードで指定されたサーバーからのみ送信可能であると伝えます。 代わりに-all〜allと記述することにより、ルールをよりソフトにすることができます 。 詳細については、GoogleおよびSPFの公式サイトにお問い合わせください。

ドメインのSPFレコードを常に規定し、メールサーバーでSPFチェックを有効にします。 MXサーバーを除くすべてのホストからドメインからメールを送信することを強く禁止することをお勧めします。 サーバーのSPFチェックと一緒に、このような設定は、ドメインのユーザーに代わってサードパーティのホストから自分のドメインのユーザーのアドレスに送信されるすべての文字をすぐに遮断します。 また、SMTPサーバーは通常、自身のドメインからのメッセージから非常に不十分に保護されており、スパマーが積極的に使用しているため、このスパムのほぼ半分があります。 SPFは、Vasya Pupkinの封筒によって判断されるが、一部のニカラグアのサーバーから来たVasya Pupkinへの手紙からあなたを救います。

PostfixでSPFを設定する方法を教えてくれるので、間違いを一括して行うことはできません。したがって、技術的な詳細に時間を浪費することはありません。

DNSには、いくつかの非常に重要なポイントがあります。 ほとんどの場合、メインDNSレコード、いわゆるAレコードが名前をIPアドレスに変換することを知っています。 それらに加えて、既存の名前にエイリアスを割り当てるCNAMEレコードがあります。 ドメインネームシステム全体の基盤を形成するのは、これら2種類のレコードです。

しかし、IPをドメイン名に変換する逆レコードもあることを知っているユーザーはほとんどいません。 それらはPTRと呼ばれます。 そのため、次の2つの未記述の（厳密に言えば）ルールがありますが、それらはすべて従います。

• 各Aレコードには、 ミラー PTRレコードが必要です。つまり、DNSを介したホスト名ごとにIPを取得し、IPごとに-同じホスト名を返します。
• MXレコードのアドレスは常に、Aレコードが存在するホストの名前 （IPではない！）でなければなりません。 つまり、MXレコードにIPまたはエイリアス（CNAME）を含めることはできません。

これらの要件のいずれかに従わない場合は、ドメインからのメールの少なくとも4分の1がスパムとして認識されるという事実に備えてください。 これは、単純な論文によるものです。信頼できる送信者は常にルールに従ってすべてを調整するため、ルールに従わない場合、送信者は信頼されるべきではないため、送信者からも受け入れられません。

自宅でPTRチェックを有効にするには、オプションを使用します

reject_unknown_client_hostname

接続を行うIPがPTRを介して名前に解決され、この名前が目的のIPに解決されることが必要です。

オプションで指定された、それほど厳しくない制限があります。

reject_unknown_reverse_client_hostname

この場合、サーバーはPTRレコードの存在のみをチェックしますが、対応するレコードAの存在を必要としません。

あいさつを確認する

だから、誰かがあなたのサーバーに手紙を送りたいと思った。 送信は、挨拶（HELOヘッダー）で始まります。 HELOでは、送信者の完全修飾ドメイン名（FQDN）をそれぞれ指定する必要があります。そうでない場合は、すぐに受け入れることを安全に拒否できます。 Postfixには、このための2つのオプションがあります：

reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

1つ目は、不正な構文でグリーティングを送信するホストからの手紙の受信を禁止し、2つ目は、HELO要求で非FQDNを送信するホストからの手紙の受信を禁止します。

ただし、最も愚かなスパマー（およびMS製品ですが、ご存じのように法律を制定していません）のみがFQDNを送信しません。最終的に、gmail.comの導入は難しくありません。 したがって、HELOを詳しく調べる必要があります。 これを行うには、オプションを使用します

reject_unknown_helo_hostname

これは、AまたはMXレコードがないアドレスであるように見えるサーバーからの手紙の受信を禁止します。

送信者-信頼する価値はありますか？

したがって、サーバーは自分自身を正常に導入しました。プログラムの次の項目は送信者アドレスです。 また、そこから多くの有用な情報を抽出できます。 送信者のアドレスは、サーバー自体と同じドメインのものである必要はないことにすぐに注意します。 これはよくある誤解ですので、そうではないことに注意してください。 1つのメールサーバーで複数のドメインに簡単に対応できます。

ただし、送信者のアドレスにまったく存在しないドメインが含まれている場合、その手紙は明らかに受け入れる価値がありません。 そして、確かに、返信先として何かが示されている手紙を受け入れるべきではありません。 そのような手紙の受理の拒否には、2つのオプションがあります。

reject_non_fqdn_sender
reject_unknown_sender_domain

1つ目はスペルアドレスの確認、2つ目はドメインの存在の確認です。

すでに悪くはありませんが、何か他のことができます。 指定された送信者アドレスにサービスを提供するサーバーに、そのアドレスを持つユーザーの存在を要求できます。 確かに、返信先が存在することを確認するのは良い考えのようです。さもなければ、誰も聞いたことのないはかない幻影から手紙を受け取るかもしれません。

技術的には、これは非常に単純に実装されています。サーバーは、送信SMTPアドレスを送信しようとするSMTPセッションを開きます。 このアドレスでRCPT TO送信ステップを正常に完了することに成功した場合、つまり 受信サーバーが、指定されたメールボックスがその上にないことを突然宣言しない場合、送信された返信アドレスが存在すると見なされます。 当然、検証中にデータ（つまり、手紙）は送信されません;セッションはRCPT TO後に中断されます。

このような返信先住所の確認には、オプション

reject_unverified_sender

上記から、ドメインからメールを送信するアドレスについては、サーバー上にボックスが必要です。 そうでない場合、あなたの手紙は受取人側の返信先住所の検証に合格せず、それに応じて、宛先に配達されません。 これは、回答を必要としない一方向の通信など、あらゆる種類の郵送などに当てはまります。 メールを送信するすべてのアドレスのメールボックスを常に作成します。 アドレスへの返信を受け取りたくない場合は、/ dev / nullで手紙を送信してください。ただし、これらの手紙を受け入れる必要があります。

受信者はまったく存在しますか？

それで、エンベロープの最後のヘッダー、つまり受信者に到達しました。 ここではすべてが簡単です。まず、送信される情報が一般に電子メールアドレスであることを確認しておくとよいでしょう。 このためにディレクティブが使用されます。

reject_non_fqdn_recipient

さらに、メールボックスを持たないアドレスへのメールを受信したくありません。 この動作を設定するには、まずサービス対象メールボックスのリストを作成してから、設定ファイルの* _recipient_mapsパラメーターのいずれかを使用してPostfixに通知し、次に設定ファイルパラメーターを使用する必要があります

smtpd_reject_unlisted_recipient = yes

または、同じ効果を持つ禁止オプション：

reject_unlisted_recipient

いずれにしても、受信者用のメールボックスがない場合、Postfixは承認済みドメインへのメールの受け入れを停止します 。 ただし、この制限は、承認済みドメインにないアドレスへの通信の転送には影響しません。

そして最後に、Postfixを介した手紙の公開送信を一般的に禁止し、既知のアドレスへの手紙を受信する機能のみを残すことができます。 これらの目的にはオプションが使用されます。

reject_unauth_destination

すべての未登録ユーザーへの手紙の送信を禁止しています（はい、SMTP認証を構成する必要があります）。 常にこのオプションを使用してください！ そうしないと、あらゆる種類のDNSBLにすぐに陥ってしまいます。

小計として

そのように、3つのエンベロープヘッダーの分析に基づいて、膨大な量のスパムを除外できます。 ただし、スパマーはunningなので、まだ十分ではありません。

グレイリング

メールサーバーが過負荷になり、レターを受信できない場合があります。 この場合、彼らは着信リクエストに応答すると思いますか？ 奇妙なことに、彼らは答えます-サーバーは一時的に利用できません。後でもう一度やり直してください。 この場合、通常の送信者は、その後のすべての結果でレターを配信できないとは考えません。 それどころか、送信者は後でレターを配信し、送信用に順番に送信しようとします。 この事実は非常に効果的に使用することができます（そして間違いなく必要です！）、なじみのないホストから接続しようとするたびに、サーバーは一時的なエラーに関するメッセージを送信し、2回目だけ文字をスキップします。 これにより、スパムサーバーはメッセージの配信を複数回試行することはほとんどないため、残りのスパムのほぼすべてを即座に排除します（そうしないと、単にキューのオーバーフローから「落ち」ます）。 この技術はグレイリストと呼ばれ、現代の現実で使用することが絶対に必要です。

欠点は、不明なホストからの最初の接続でレターを配信する際のわずかな遅延（通常は30分以内）です。 つまり、postfixにまだ知られていないサーバーが電子メールを送信したい場合、最初に接続しようとすると、一時的に利用できないというエラーを受け取ります。 サーバーが接続を再試行する場合、レターは受け入れられ、サーバーは信頼できるノードに入力され、そこからさらにレターが遅延なく受信されます。

また、GoogleのPostfixでのグレーリストの設定について読むことをお勧めします。これは簡単であり、間違いはありません。

Bloklisty、またはしない方法

一部のメール管理者は、スパム（スパムメーリングで見られるホストのブラックリスト）をフィルタリングするときに、いわゆるDNSBL（RBL）に依存しています。 したがって、 DNSBLチェックをメールサーバーに追加しないでください。 これには2つの理由があります。最初の、そして最も基本的なものは、このセクションの最初の文の2番目の部分にあります。 ノードはこれらのリストに完全にランダムに入力され、通常のホストがそこに到達しないという保証はありません（その時点で、スパムを送信するウイルスが落ち着きましたが、ウイルスはすでに治癒しているか、より簡単ではるかに現実的です-外部の1つスパマーが巻き込まれる大規模ネットワークのIP）。 2番目の理由はより一般的です。上記で提案されたフィルタリングメカニズムは、DNSBLよりもはるかに効率的であり、第三者からの未検証データに依存しません。

逆さま、またはバリケードの反対側から見る

彼らはスパムをフィルタリングする方法を学びましたが、今はスパムにならないようにするために必要なことに関するすべての情報をまとめるようにします。

メールサーバー管理者の場合：

• MXレコードが常にAレコードを参照するようにします。
• メールサーバーのAレコードには、常にミラーリングされたPTRレコードが必要です。
• HELOヘッダーのホストには、AまたはMXレコードが必要です。
• 常にSPFレコードを作成します（はい、これは必要ではありませんが、きちんと調整されたルールです）。
• 承認済みドメインから送信されるすべてのレターについて、返信先のメールボックスが存在し、メールを受信する必要があります。

（プログラム、サイトなどから）メールを送信する人の場合：

• 常に既存の返信先アドレスのみでメールを送信します。
• SPFルールを確認せずに、制御できないドメインからメールを送信しないでください。 たとえば、現在gmail.comでは任意のサーバーに代わってレターを送信できますが、yandex.ruおよびmail.ruは、SPFを介してサードパーティサーバーからの送信が細心の注意を引く必要があることを通知します。これはスマートスパムフィルターによって解釈されますこのメールのスパム評価の増加として。
• 不適切に構成されたSMTPサーバーを介してメールを送信しないでください。 上記のリストでサーバーのシラミを確認するのに 5分かかります。digまたはnslookupユーティリティが役立ちます。

まとめ

もちろん、提案された設定はすべてのスパムをフィルタリングするわけではありません。 したがって、このようなものは使用しませんが、 spamassassinなどの文字の内容を分析するコンテキストフィルターを追加で使用する必要がある可能性は十分にあります。

ただし、上記のパラメーターはコンテキストフィルターのみを使用する場合に比べてサーバーの負荷を大幅に減らすことができ、さらに優れたフィルタリングを提供するため、メールのセットアップ時にこの記事で説明する内容を忘れないでください。

UPD：まず第一に、批判的なコメントをしてくれたVanavに感謝します。 第二に、最初は私によって暗示されたが、明らかにまだ完全には理解されていない、上記のオプションの要約：

サーバーに適用する準備ができている制限とそうでない制限を自分で決定する必要があります。 上記の多くのチェックについて多くは懐疑的です。 ただし、それらはすべてインターネット上の実際のSMTPサーバーで使用されるため、すべてをオンにした場合でも、1人ではありません。 したがって、サーバーが正しく構成されていないことに気付いた場合、このトピックについて管理者に電子メールを送信するのが面倒にならないようにしてください。おそらく、通信が届いていないユーザーの怒りを避けるのに役立ちます（手紙を書いた時点でまだ仕事から追い出されていない場合）。 また、チェックせずにホストからメールを受信するために、破損したホストをホワイトリストに追加できることを決して忘れないでください。

記事の実際のバージョン

この記事の最新の最新バージョンは 、Ubuntuの公式ロシア語版 Wikiリソースドキュメントにあります。 そこで、レイアウトされた参照資料やトレーニング資料を自由に改善および補足したり、独自の資料を追加したりできます。 他のUbuntuユーザーに伝えたいことがあれば、膨大なリクエスト-help.ubuntu.ruの対応する記事を書いたり編集したりしてください 。 わずかな改善や追加があったとしても、何千人もの人々を支援し、そのうちの1人が有用で興味深い何かを説明します。