MTA の各種のアクセス制御手法について思いつくままにメモしたもの。ほとんどは spam 対策だが、こうすれば spam を撃退できる、というガイドではない。絶大な効果があるものから、ほとんど効果がないどころか多大な副作用をもたらすものまで、さまざまな手法をとにかく列挙する。筆者は spam 対策については「やりすぎるぐらいならば何もしない方がマシ」という立場を取っているので、メリットよりもデメリットを重視する。なお、分量はわずかだが DoS 対策や内部ユーザによる abuse を防止する手法についても触れる（この文書は spam 対策技術のメモではなく MTA のアクセス制御手法のメモである）。
ローカル配送された後にユーザごとで選別する方法についてはほとんど取り上げない。携帯電話向け spam についても触れない。特定の MTA や対策ツールにかたよった記述はほとんどしないし、特に必要な場合を除き設定例も挙げない。一部に説明をはしょって不正確になっているところもあるし、根本的に嘘を書いてるところもあるかもしれない。筆者の偏った主観が客観を装って紛れこんでいるのも否定しない。事実誤認や、記載されていない手法の情報提供や意見などはメールでどうぞ。
多くの spam 対策は両刃の剣である。spam を拒否しようとして、spam でないメールを捨ててしまう可能性はゼロではない。spam の蔓延は困ったものだが、間違った spam 対策も多く蔓延している。
spam 対策で重要なのは、「spam を受け取らない」ことではなく、「spam でないメールを確実に受け取る」ことである。 99.99% の割合で spam を遮断するが 10% の割合で spam 以外のメールまで拒否してしまう方法よりも、spam は 90% しか減らないが正当なメールを spam として誤認する可能性が 0.01% しかない方法が（もしあるのならば）そちらの方がずっと優れている。さまざまな spam 対策方法が考案され宣伝されているが、spam をどれだけ減らせたか、ではなく、spam でないメールへの影響がどれだけ少ないか、という観点で評価すべきである。
spam を 100% 排除する確実な方法がひとつある。それは、spam でないメールも含めてすべてのメールを拒否することである。しかし、それではメールを使う意味がない。逆に spam 対策をまったくしなければ、間違えて拒否してしまう可能性は 0% である。しかし、spam に埋もれて大事なメールを見逃してしまうのならば受け取らないのと同じである。また、spam のためにメールボックスが容量オーバーになって重要なメールを受け取れないというのも避けなければならない。
個人的には、1日に受けとる spam が10〜20通程度までならば、spam 対策は一切不要で、受け取った後に目視で選別すれば十分だと思う。それを越えて spam のせいで重要なメールを読むのに支障を来たすようになってから対策すれば十分だろう。
なお、spam でないメールを spam と誤認してしまうことを false positive、spam メールを spam でないとして見逃してしまうことを false negative という。上述のことを言い換えると、FP の割合を限りなくゼロに近い値に抑えたまま、FN をひとり1日あたり数通程度に減らすのが目標になる。
もちろん、spam でないメールをある程度失うリスクを承知した上でそれでも spam を蹴りたい、というのであれば、誤判定の確率の高い制御手法を導入するのはかまわないだろう。しかし、ある程度のユーザをかかえるサーバの管理者ならばやめておいた方がいい。自分のメールをなくすだけならともかく、自分のサイトの他のユーザのメールまでなくす危険にさらすべきではない。どうしても導入したい場合は受信を拒否するのではなく、何らかの方法でヘッダなどにそれとわかる目印を付加しておくなどしておいて、後段のフィルタで処理することを考えた方がいいだろう。SMTP はメールが 100% 確実に届くことを保証するプロトコルではないが、そのことを false positive が増えることの免罪符にしてはならない。100% の到達性が保証されていないのが事実だが、自分のサーバのところまで到達しているのにそれを受け取らないのは SMTP のプロトコルの不備ではなく、サーバ管理者の怠慢・傲慢にほかならない。
もうひとつ重要なこと。spam を憎むあまり、spam でないメールを送ってくるサイトに迷惑をかけてはならない。spam かどうか判定するために自分のホストのリソースを消費するのは自分の勝手だが、他人のホストのリソースをあてにするのは極力避けるべきである。spam に悩まされているのは事実かもしれないが、それを蹴るのに他人の褌で相撲を取るのはエゴ以外の何物でもない。他人にリソースを借りてまで自分の満足を追及してはならない。世の spam 対策手法にはこの視点が欠けているものが多いので注意すること。
まとめ。spam 対策の原則。
なお、この文書では spam とは何かについてあえて定義しない。もちろん個人的な定義はあるが、それを表明することはしない。どれを spam と見なすかは人によって幅がある。つまり、まったく同じメールでも spam と見なす人とそうでない人がいるかもしれない。だからこそ、spam かどうかあやしいメールは MTA で機械的に判断せずに素通しして、受け取る人間の判断に任せるべきだろう。繰り返すが、必要なものを受け取れないリスクを冒すよりは、不要なものを受け取るリスクを冒すべきである。
いかにして spam とそうでないアクセスを判定するか、ということの前にまず、spam 判定したものをどう取り扱うか、ということについて。RFC2505 #1.5
1 の TCP レベルでの拒否は接続元 IP アドレスで判定できる場合だけになるが、DoS 攻撃などをしてくるホストを締め出したりするときに設定される。SMTP 的には 2b の 4xx でエラーにしたのと同じ効果になる。DNS に MX として載せられていないホストでは、これによる接続拒否を基本とする（MX でないのだから通常はメールが送られてくることもないはずであり、送っても届かないのがむしろ当たり前である）。qmail では tcpserver の機能を使って拒否することが多いが、それはこれをやっていることに該当する。MX となっているホストではそのようなことはせず、ちゃんと SMTP セッションを開始した上で 5xx で拒否するべきである（rblsmtpd が必要）。
DNS にどこかのドメインの MX として載せられているホストでは、2a のステータスコード 5xx での拒否（恒久的エラー）が基本であり、可能なかぎりこれで拒否すべきである。いったんゲートウェイ MX がメールを受けとってからイントラネット内の MTA に配送するような構成では、MX ではないイントラの MTA が 5xx の応答で拒否してしまうと、ゲートウェイの MTA がバウンスを返してしまって無用な backscatter が発生するおそれがある。この場合、ゲートウェイ MX の方でしっかり対策して、イントラの MTA では 5xx の返さないようにするべきである。それができなければイントラ MTA ではエラーを返さずに受け取ってから捨てる(3b)ようにする。.forward などによるメール転送を受けるホストでも同様。
2b の 4xx は一時的エラーで、まともな MTA はエラーが解消されるか、滞留期限（ものにもよるがたいてい3日〜10日）までの間、一定の時間おきに再送してくるため、送信側、受信側ともにコストが大きい。しかし、spamware（spam 送信専用ツール）や open proxy を利用した spam 送信では 4xx のステータスを受けとっても再送してこないものがあり、この性質を利用して spamware や open proxy からの送信とまともな MTA からの送信を選別する手法がある。
1、2 の方法は宛先メールボックスごとに異なる制限をしたいときには困難なことが多いので、その場合は一旦メールを受け取ってから処理する。3a は backscatter の源になるのでできるだけ避けなければならない。3b は無難だが、送信側は正常に送れたと思いこみ、受信側は（ログを見なければ）送られたことに気がつかないので、誤判定だった場合にはトラブルになりやすいので注意も必要である。
3c は spam だと判断したのに拒否せず成功応答(250)を返してしまうわけだが、必ずしも何もしないとはかぎらない。それとわかるヘッダを追加して、後で MDA やメーラーでおこなう判定の助けにしたり、spammer はまともな MTA に比べて気が短いことが多いのを利用して、わざと数十秒ほど成功応答を遅らせて送信側の方からタイムアウトで接続を切るのを待ったりする(tarpitting)。
なお、間違えて拒否してしまった場合でも、2b の 4xx ならば再送されるので後で救済することも可能だが、これはあくまでテスト目的の一時的利用に限るべきであって、これを恒常的な手段にするのは勘弁願いたい。再送を受ける側だけでなく、再送する側にもそれなりのリソースが浪費されるのだ。1通2通では微々たるものだが、塵も積もれば山となる。他にも手段はたくさんあるのだから、相手にリソース負担を求める方式を使うのはエゴ以外の何ものでもない。設定ミスで 4xx を救済する際には、よけいなコストをかけさせてしまってごめんなさいという気持ちを忘れないようにしたい。 RFC2505 #1.6, #2.13
以上は spam をどう扱うかということを技術的な観点から述べたものだが、別の観点、すなわち AUP の面からも考える必要がある。AUP (Acceptable Use Policy) とは組織ごとに定めた規範のことで、要するに、「商用利用不可」とか「エロ禁止」とかの決まり事である。インターネット全体のルールではなく、所属する組織ごとに異なるので、組織の責任者やネットワークの管理者に確認しておくこと。
ISP は通信事業者なので、日本の法律では通信の秘密を守る義務があり、また、差別的な取り扱いは禁じられている。spam であってもそれは例外でない。メール本文を精査して spam かどうかチェックするフィルタなどは厳密にいうとこれに反する可能性がある（世論は spam 被害者に同情的なので少々のことならば黙認してくれるだろうが）。ISP のメールサーバでは、ISP 自身で一律に spam 判定するのではなく、フィルタリングするかどうかの選択肢を用意して、ユーザの意思で有効にするか否かを判断させるべきだろう。この場合、たいていは 5xx や 4xx で拒否するという方法は取れず、いったん受け取ってから（ユーザ設定のフィルタにマッチしたものを）捨てる、ということになると思われる。ただし、SMTP のプロトコルに反する振る舞いをするクライアントを拒否するなどといった「判定」に属さない手法ならば ISP の独自の判断で入れてもそれほど問題にはならないだろう。
一方、企業サーバでは、業務に必要ないものは不要であり、ユーザの意向をある程度制限することも可能である。また、個人サーバでは組織イコール個人である。こういったサーバでは、個人のメールボックス単位での spam 対策ではなく、サーバレベルでの spam 対策が存分に可能である。spam を受けないことよりも spam でないメールを受けることの方が重要だと何度も書いたが、少しぐらい失っても spam ゼロが重要だ、というポリシーを定めたとしても、その組織がそれを是とするならばよそものが口を挟むことはできない（アホだなぁと鼻で笑うことはあるかもしれないけど）。もちろん、組織の外に悪影響が出るようなポリシーは話は別なので念のため。
また、組織内部のユーザが、AUP に反する行動をとった場合にどう対処するかについても考慮していいかもしれない。たとえば、spam を送らない、というのは AUP に頼るまでもなくあたりまえのことだが、これに対して説教やアカウント剥奪などの政治的な対処で臨むか、Outbound Port 25 Blocking を実施して技術的にそもそも違反できないようにしてしまうかは意見のわかれるところだろう。これは性善説・性悪説のどちらの立場でユーザを管理するかという次元の問題だけでなく、予防措置の側面もあるので、一概に判断はできない。
メールを読む人間にとって意味があるのはメッセージ本文なので、人間が自分で本文を読んでひとつひとつゴミ箱に捨てていくのがもっとも確実な方法である。もちろん、人間だって時には間違えるが、自分の脳味噌のせいなんだから諦めもつくだろう。しかし、それが手間だから機械的に判定するのである。
自分の思考形態と同じロジックで機械判定できればそれが最上であるが、そんなことはこの先数十年数百年は不可能だろう。そこでメールの送受信の際にやりとりされるさまざまな情報を手がかりに判定することになる。どの段階で得られる情報かをもとに分類すると以下のようになる。
以下の節ではこのそれぞれで各種手法を分類している。
また、理由なく制限するわけにはいかない。理由が必要である。以下のようにわけられるだろう。
ひとつめは第三者不正中継や DoS 攻撃してくるクライアントに対するアクセス制御である。自分に届く spam が減るわけではないが重要な対策である。また、spam 送信に特化したツールは、送信の際に一般的な MTA と異なる挙動を示すことがある。これを検知して排除するのが2番目である。3番目は spam 常習者からのメールを拒絶するものである。自分のところに何度も送ってくるものを拒絶するだけではなく、他で収集している spam の情報を参考にすることもできる。最後が、受け取ってしまったメールの内容チェックである。最初の3つは「spammer」の拒否であるが、最後のものは「spam」の拒否であるという違いに注意してほしい。また、後2者は「誰が」「どこから」「何を」送ったのかという情報をもとに判定するが、前2者はサーバ上でのクライアントの振る舞いが基準であり、知識に頼った判定ではない。
spam 判定には、いくつかのチェック項目のそれぞれでシロかクロか、0 か 1 かの真偽値で判定して、ひとつでもクロならば spam とみなす、というものと、spam らしさに適当なスコアをつけ、いくつかの判定項目を総合してスコアがある閾値以上になったものを spam とみなす、という方式がある。MTA レベルでの spam 判定では、実装が単純かつ負荷が軽いこともあってほとんどが前者の方式である。しかし、これは「spam とは断言できないがそれっぽい」という項目がいくつあっても真偽値でしか判定しないのですりぬけてしまうことがある。一方、後者の方式では spam と断定できないものにも、（低めの）スコアを与えることで spam 判定の参考にすることができる。以下の記述には「相関は高いだろうが無関係である」と批判している判別手法もいくつかあるが、そういう手法でもシロかクロかの判断ではなく、他の手法の組み合わせて総合的なスコアで判断するのならば、有効に使えるかもしれない。なお、スコアの重みと閾値の設定によっては使いものにならないほどひどい判定をすることもあり、このパラメータのチューニングが重要である。
イタチごっこ。
spam 常習者の名簿がブラックリストである。が、spam を送るのが仕事の spammer にとっては、あちこちのサイトでブラックリストに入れられたら意味がない。送信元のメールアドレスや IP アドレスなどを次々と変えていく。ブラックリストに追加されたころにはすでに spammer はそれを使っていないなんてことは少しも珍しくない。
そのため、特定の spam を撃墜する賞味期間の短い情報を載せるよりも、汎用性の高く長く使えるパターンを探しだして載せた方が保守性がよくなる。しかし、そのような汎用性の高いパターンというのはえてして非 spam にまでマッチしてしまうことがありがちであり、十分に注意が必要である。
ブラックリストに登録漏れがあっても、spam が spam でないと判定されるだけで、spam でない正当なメールを失うことはない。しかし、たとえば何年か前に spammer が使っていて捨てられたドメインを、まっとうな人がそれと知らずに取得した、というような場合、ブラックリストに古い情報がいつまでも残っていると、非 spam を spam と判定してしまうことがありうる。これが送信者ドメインではなく IP アドレスならば赤の他人に再利用されるまでの期間はもっと短くなる。ブラックリストには情報を追加していくことを気にしがちだが、いらない情報を削除していくことも忘れないようにしたい。
アテにしない。
spam でないのに spam と判定されてしまうものを救済するために使うのがホワイトリストである。ホワイトリストでもブラックリストでも、そういったリストを常時メンテナンスするのはたいへんな手間である。ブラックリストはメンテをさぼっても false negative が増えるだけで重要なメールをなくすことはないが、ホワイトリストのメンテをさぼると false positive、すなわち spam でないメールを spam と誤認する事故が増える。
ホワイトリストの重要性がわかっている人が管理しているうちはまだいい。業務で使用しているサーバだったりして、担当者が交代するときにホワイトリストのメンテナンスに関する引き継ぎが不十分だったりすると悲惨なことが起きる。false positive をなくすためにはホワイトリストの管理は重要であるが、それと同時に、メンテが漏れていたときに起きる危険性を認識しておくこと。
一見すばらしい spam 対策方法が考案されたとしても、spam でないメールの一部をホワイトリストで救済しようという手法ならば、採用するのはやめておいた方がいい。人間は必ず間違いをする動物である。ホワイトリストのメンテナンスが常に完全であることはアテにできない。週に1回以上メンテする必要がある、あるいは10個以上のパターンがあるホワイトリストならば、その手法の有効性に疑問を持つべきだ。ホワイトリストのメンテが後手にまわってもステータス 4xx を返しておけばあとで救済できるからいいや、などと考えるのもよろしくない。あなたの怠惰のために、何の落ち度もない送信元に再送コストを負担させてふんぞりかえっていられるほどあなたはエラい人なのか？ ホワイトリストがないと受け取れないメールがあるという点で「spam でないメールを確実に受け取る」という原則に反するし、それを救済するのによそのリソースを浪費させるという点で「非 spammer に迷惑をかけない」という原則にも反するたいへんマズい方策である。
もちろん、完全自動でアップデートされるリストや、何らかの理由でリストの中身がこれ以上増えないことが確定している場合など、メンテ不要なホワイトリストについてはその限りではない。
もうひとつ、ホワイトリストは、毎回確実に非 spam と判定されるのだが、その判定にかかるコストが大きいときに、その重いチェック手法を代替する目的であらかじめ判定結果の一部をリストにして準備しておく、という使われかたをすることもある。この場合、ホワイトリストなしで運用しても同じ結果が得られる（false positive は増えない）のでこのような事故は起きない。しかし、人間は怠惰な動物である。メンテナンスされていないホワイトリストでも確実にシロと判定されるのならば、そんなリストがクソ真面目にメンテされることが期待できるだろうか。
しかしそうはいっても、ホワイトリストをまったく使わないというのは理想論に過ぎず、多くの場合は導入せざるをえないのが実情だろう。メンテナンスが必要なリストは最小限に、かつ、不断のメンテナンスを忘れないようにしたい。
なお、ホワイトリストにマッチしたからといって全面的に信頼してはならない。極端な話、送信者アドレスをホワイトリストにあるものに詐称されてしまったために第三者中継を許可してしまった、なんてことが起きたら洒落では済まない。あくまで一部のチェックを回避するためだけのものであることに留意すること。
Authentication（認証; 利用者を識別すること）、Authorization（承認; サービス提供の可否を判断すること）、Accounting（アカウンティング; これらを記録すること）、みっつあわせて AAA。アクセス制御を考える上でははずせない重要な要素。といっても、MTA のアクセス制御という文脈ではあまり出てくることはない。まあ、知っておいて損はない。
認証と承認については、このメモではなかば意図的に混用しているが、実はまったく異なる概念なので注意すること。素の SMTP には認証はなく、拡張機能での対応になるので、ここで取り上げるもののほとんどは承認に関するものである。この後でさまざまな例を挙げるので、この節で深くとりあげることはしない。
認証や承認の各手法を実際に MTA で実施する場合には、それがちゃんと動作しているか、意図しない範囲にまで制限が及んでいないかを確認するために、MTA の動作記録を逐一チェックしてやるのは重要なことである。また、DoS 攻撃や、アドレス収集の試み (DHA) などもログにその痕跡が残っていることが多い。不審なアクセスへの対策をする上でログの記録・監視は欠かせない。
はっきり書こう。ログ収集という点において、qmail は落第である。最低水準にすら達していない。標準では不正中継を拒否した記録や、badmailfrom による送信者アドレスの拒否の記録などが一切ログに残らない。qmail では機能を追加するためににいろいろパッチを当てるのが慣例化しているが、ちゃんとしたアクセス制御を考えるならば、そんなことをするよりも即座に他の MTA に乗り換えることを勧める。ログへの記録は RFC2505 #2.4 では SHOULD となっているが、実運用上は MUST となっていていいはずの項目である。それが実装されていない qmail は使いものにならないといってもいい。
送ったメールがなんらかの理由でエラーになると、送信元にバウンスメールが返る。このとき、送信者アドレスが無実の第三者のものに詐称されていると、バウンスも詐称されたアドレスに届いてしまう。このような詐称アドレス宛バウンスのことを backscatter（後方散乱メール）と呼ぶ。collateral spam（巻き添えスパム）ということもある。
自分のドメインが詐称されると、各地から backscatter が届くことになり、この数が多いと実質的な DDoS 攻撃となる。これで大きな被害を受けた ISP もあり、最近では backscatter も spam の一種とみなされることがある。バウンスメールの送信は MTA の基本動作のひとつだが、自分が DDoS に加担しないよう、必要のないバウンスはできるだけ出さないようにするのが望ましい。
SMTP トランザクション中に 5xx のステータスでエラーを返すと、エラーを返した側ではなく、接続元のサーバの方からバウンスメールが出ていくことがある。これも backscatter になる可能性があるが、これは拒否される原因となったメールを中継した側で対策すべきことであって、エラーを返すことをためらう必要はないだろう。もちろん、自分のサーバからは拒否されるようなメールを極力出さないようにするのが望ましい。
なお、詐称されたアドレスにバウンスを返してしまうことが問題なので、SenderID や DKIM などの送信ドメイン認証にパスしたメールがエラーになった場合は、backscatter を気にせずバウンスしてしまってよいだろう。
qmail はローカルユーザが存在するかどうか確認せずにいったんすべて受け取ってしまうので、backscatter の発生源になりやすい。この問題への対処については、qmail のある暮らし - SMTP セッション中での無効な受信者の拒否を参照のこと。
backscatter からの防御については、postfix のドキュメントが参考になる。また、yahoo ではあるメールボックスが単位時間あたりに受信するメールの数に制限を設けることで対抗しているようだ。一般に普及している MTA でこういう設定ができるものは知らないがいちおう参考までに。なお、正当なバウンスを識別するための BATV (Bounce Address Tag Validation) というしくみが IETF に提案されたことがあるが、どうもポシャったようだ(?)。
spam 送信ツールのこと。ratware と呼ばれることもある。大量メール送信型ワームを含むこともある。というか、rat = remote access trojan らしい(?)ので、感染しない spam 送信ツールは ratware と呼ばないのかも。
多くの spam は spamware から送られる。sendmail など、一般に普及している MTA を使って送られることはあまり多くない（少なくもない）。メールを確実に送り届けることを旨とする一般の MTA とは異なり、spamware は少しぐらいのエラーは無視してでも高速かつ大量に送ることを目標に作成されており、タイムアウト時間が短かい、4xx 応答で再送しない、など一般的な MTA と異なる挙動が見られることがある。この違いを見出すことで spamware を狙い撃ちできることがある。
なお、X-Mailer ヘッダに自分のプロダクト名を入れてくる spam があるが、これは多くの場合 spam 送信「専用」ツールではなく、企業が顧客周知などでメールを送るような目的で販売されている「同報配信ソフト」によるもののことが多い。たとえば、以前非常に多く目にした X-Mailer: IM2001 はこれ。spamware として転用されやすいのだが、これらのツールを本来の目的（名目上の目的ともいうか）に使って、まっとうな案内メールを送る企業がないわけではないので注意すること。
SMTP 以前の TCP レベルで得られる情報、すなわち IP アドレスによる接続制御。なお、判定自体は SMTP 確立以前に済むが、実際の接続拒否は SMTP セッション中におこなうことが望ましい。qmail では SMTP セッションを開始せずに tcpserver で蹴ることがあるが、それはあまりよろしくない。これについての議論は別項参照。
恒常的に spam を送ってくる IP アドレス、ネットワーク、ホスト名、ドメイン名でブラックリストを作成し、MTA に接続してきたクライアントと一致するかどうか調べる。RFC2505 #2.1, #2.5
spammer の IP アドレスが特定できているのなら確実だが、非固定 IP アドレスを使っている場合にはほとんど効果がない。/32 ではなく /24 などのネットワークで拒否してしまうと非固定 IP アドレスでもある程度は有効だが、該当ネットワークのまともな利用者からのメールも拒否してしまう可能性がある。固定アドレスを使っている場合でも、大々的に spam を送信している場合には ISP から契約を解除されて数日〜数ヶ月程度で使われなくなることが多い。別の手段を考えた方がよいだろう。
管理者がいちいち手作業でブラックリストを作る方法（静的なブラックリスト）はメンテナンスの手間がかかるため、誰かが作ったリストを DNS 経由で参照する（動的なブラックリスト）のもよくおこなわれている。これを DNSBL (DNS based blackhole list) または RBL (realtime blackhole list) という。どんなサイトが DNSBL を提供しているかは、たとえばこのあたりを参照。
DNSBL は通常 IP アドレスをリストするが、ドメイン名をリストした DNSBL もあり、これを特に RHSBL (right hand side blackhole list) と呼ぶことがある。これは逆引きホスト名や送信者ドメインを検索するのに使われる。DNSBL による接続元 IP チェック機能を持った MTA は多いが、RHSBL による送信者ドメインの検索に対応した MTA はそんなに多くない。Sendmail ではこちらから RHSBL に対応させる .m4 ファイルを入手できる。
DNSBL はサイトによって登録ポリシーが大きく異なることが多く、また、運営者の都合でサービスが停止したり、動いてはいても情報が古かったりすることもときどきあるので、実際に使う場合には事前にそのあたりをよく調査しておいた方がいいだろう。
なお、多くの DNSBL は「spam が送られてくる IP アドレス」をデータベース化している。「spam だけしか送られない IP アドレス」であることを確認してリストに入れているわけではない。微妙な違いだが見逃されやすい重要な点である。どういうことかというと、DNSBL に登録されている IP アドレスから spam でないメールが届く可能性がないわけではないということである。その IP アドレスから spam が届いた、という事実をもって DNSBL に登録されるわけで、そこから spam 以外のメールが送出されているかどうかの調査はしていないことが多い。DNSBL の運営元は好戦的なアンチスパマーであることが多く、false negative の率を下げることに躍起になって false positive にはそれほど気にしない DNSBL は少なくない。たとえば、spammer が自前の MTA からではなく、ISP のメールサーバを堂々と使うような場合、その ISP の他の契約者から spam 以外のメールにも影響が出ることは十分に承知した上で、spam を通過させている ISP は悪なのでブロックする、文句はその ISP に言え、という公言する DNSBL もある。
DNSBL に登録されている特定のサイトを除外するにはホワイトリストが必要になる。
逆引き（IP アドレスからホスト名を得ること）ができないクライアントや、パラノイドチェック（逆引き得られた名前を正引きして元の IP アドレスと一致するかの検査）にひっかかるクライアントを蹴る。RFC2505 #1.4
これはよくおこなわれているようだが、はっきりいって筋違いだろう。ほんとうに必要がないかぎり逆引きを設定しないという運用方針を取っている組織はけっして珍しくない。逆引きがないからといって spammer と断定はできない。sshd など限られたクライアントのみ接続できればいいサービスではそのような制限もありうるだろうが、メールは不特定のホストから届くものである。曖昧な根拠にもとづく制限をするのはやめておいた方がいいだろう。国内大手 ISP では hi-ho がこの制限を導入したことがあるが、トラブルが多かったのかわずか1ヶ月で撤回している。
spam をたくさん送ってくる中国韓国あたりはそもそも逆引きを設定する習慣があまりないようで、このチェックによってこれらの国からの spam を多数撃墜できるのは事実である。しかしそれは逆引きを設定する習慣がない国と spam を送ってくる国がたまたま重なっているだけにすぎない。spam を送ってくるホストはとうぜんまともな管理はされていないだろうが、まともに管理されているホストに逆引きがないというのもふつうに存在する（何をもってまともとするかの定義も曖昧だが）。spam を送ってこなければ目につくこともないし、これらの国から spam でないメールを受ける機会もほとんどないだろうから、逆引きなし⇒ spammer と短絡的に考えてしまいがちだが、RFC で必須とされているわけでもなし、本来何の関係もない事象である。逆引き判定が効果があるように感じるとすればこの点を誤解しているのではないだろうか。これらの国だって spam 以外のメールは当然送るだろうが、そのようなメールもまとめて拒否してしまう可能性が高いことを留意しておく必要がある。まともなメールも含めてこれらの国からのメールを拒否してしまいたいのならば、逆引き判定などという間接的な手段を取るのではなく、中国韓国に割り当てられているネットワークをあらかじめ調べておいてブラックリストに登録しておいた方がいいだろう（後述。そういう DNSBL もある）。
某 SIer さんのサイトにこの手法を強力に推進するページがあるが、まったくもって理由になっていないように見える。そういう設定をすることが「できるかできないか」ということと、それを実際に「やるかやらないか」ということは、まったく関係のない別の事象であるはずなのに区別できていないようだ。もちろん「やるかやらないか」を決めるのは、これを書いてる当方ではなく読んでるあなたなので、ご自分の判断で逆引きできないホストからのメールを拒否してもいっこうにかまわないわけなのだが、仮にそうするとしても、逆引きを設定しているからまともな管理がされている、あるいは逆引きが設定されていないからまともでない、などという嘘を信じることだけはないように。
こちらも参照のこと。
SMTP は本来 TCP の25番ポートを使うものだが、これは外部からローカルユーザへのメール受信用にのみ使うことにして、ローカルユーザから外部への送信には 25 ではなく別のポート(587)を使うことにしよう、という考え方。RFC2476
通常の SMTP は入口と出口がひとつだが、Submission ポートも併用して入口と出口を分離してそれぞれを一方通行にすることで、それぞれのアクセス制御がやりやすくなる。Outbound Port 25 Blocking を回避してメールを送る手段のひとつでもある。なお、たいていのメーラーは送信先ポート番号を変更できるが、一部ポート番号が 25 に固定されているメーラーが存在し、こういうものを使っている場合にはメールを送ろうにも送れない。
外部からの spam を排除する手法ではなく、spam を出そうとする内部の不届き者を排除する手法。組織で公式に用意したホスト以外への 25/tcp への接続をふさいでしまう。spam を送りたくても相手サーバに接続できないので送れなくなる。公式に用意されたサーバを使えば spam でも送れるが、その場合は公式のサーバにログが残るのですぐに足がつく。もちろん、spam 送信以外の正当な SMTP 接続もできなくなる。個人的には、spammer を排除するために非 spammer の手間を増やすな、という主張に反するので嫌い。最近の事情では導入やむなしという状況にあるのは認めざるをえないが、できれば BIGLOBE や EditNet のように、まっとうな送信者に極力影響を与えないよう、完全にブロックするのではなく流量制限で対処するようにしてもらえるとありがたい。
これは MTA ではなく、主にネットワークの出口にあるゲートウェイでおこなう対処になる。大規模な ISP などで使われ、個人で採用することはないだろう。一般企業では情報漏洩の防止、私的利用の監視といった spam 防止とは別の意味で導入することがあるかもしれない。
「阻止率99%のスパム対策方式の研究報告」で提唱されている手法。
蓋然的な判断に頼りすぎている感が強く、個人的にはオススメできない。このページに書かれている記述は「spam を拒否する方法」ではなく、「エンドユーザー回線からの送信を拒否する方法」である。上述の逆引きできないホストの拒否と同じように、たまたま spam 送信にエンドユーザ回線が使われやすいというだけのことで、このような回線を使って spam でないメールを送る人も多いことを留意しておくこと。相関は高いかもしれないがイコールではない。
S25R では、エンドユーザの足回り回線の逆引きホスト名は ISP によって連番が付与されやすい、という経験的知識に基づき、正規表現で指定された連番のパターンにマッチしたホストを拒絶する。しかし、連番を付与するのは大量の IP アドレスにそれぞれ異なる名前を与える必要があるからだが、そのような名前が付与されるのはエンドユーザーの足回り回線だけではない。
つまり、ホスティング事業者のレンタルサーバの IP アドレスの逆引きが S25R の条件にマッチすることがよくあるのだ。たとえば、愛知万博の公式 web サイト (www.expo2005.or.jp/203.181.119.1) を逆引きすると VV050217670000119181203001.gwrev.kddi.ne.jp となる。KDDI のホスティングである。S25R 方式ではこのホストからの送信は spam 判定を食らうことになる。この万博サイトの例は Web サーバであってメールを送出しているかどうかは知らないが、同じような形態でメールサーバをやってるところは数多くあるだろう、きっと。
また、ADSL や FTTH の個人ユーザ向け回線を使っている小規模な組織や、独自ドメインを取得して自宅にサーバを構築している個人ユーザも多いが、これらのサーバからのメールは S25R 方式ではほとんど拒否されてしまう。S25R ではこれらの false positive のメールを救済するには、ホワイトリストに頼る以外方法がないことに注意する必要がある。グレイリストで救済する改善案もあるが、個人的には greylisting 自体にも問題ありと考えており、素の S25R よりはマシだが完全な方法ではない。
なお、エンドユーザ回線からの直接 SMTP を蹴るというアイデアは S25R のはるか以前からあり、そのような動的割り当ての IP アドレスを列挙した DNSBL なんてのもちゃんと存在する(DUL; Dial-up User List)。
一部の ISP で Outbound Port 25 Blocking を採用をはじめたりして、エンドユーザ回線からの直接の SMTP 接続は悪とみなされつつある風潮があり、それはそれでしかたないことかもしれないが、だからといってエンドユーザ回線からの SMTP すべてを拒絶する方式には賛成できない。
お行儀の悪いクライアントがいっぱいいるような国や、特に spammer が多い ISP からのアクセス制御のためのリストを使うと、その地域/ISP からのアクセスをすべて蹴ることができる。すべての国と地域ではないが、blackholes.us でそのための DNSBL 運用および、テキストファイルでのリスト掲載がされている。
このリストは接続元 IP アドレスのリストとして使ってもいいし、後述の MX による制限にも使える。
blackholes.us のリストの中にはもちろん日本も含まれているが、「日本」という大きな枠ではなく、日本の特定のISP だけを狙い撃ちにするための情報は JPNIC の whois データベースから調べることができる。まず、ネットワークごと蹴りたい組織が所有している IP アドレスをひとつでいいから見つけ、その IP アドレスを whois で検索する。
% whois -h whois.nic.ad.jp 192.0.2.1 [ JPNIC database provides information regarding IP address and ASN. Its use ] [ is restricted to network administration purposes. For further information, ] [ use 'whois -h whois.nic.ad.jp help'. To only display English output, ] [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. ] a. [IPネットワークアドレス] 192.0.2.0/27 b. [ネットワーク名] SAMPLE-NET f. [組織名] サンプル g. [Organization] Sample m. [管理者連絡窓口] XX111JP n. [技術連絡担当者] QQ999JP 以下略
この結果のうち、技術連絡担当者の先頭に "^" を付加した文字列でもう一度 whois 検索する。
% whois -h whois.nic.ad.jp ^QQ999JP [ restricted to network administration purposes. For further information, ] [ use 'whois -h whois.jprs.jp help'. To suppress Japanese output, add'/e' ] [ at the end of command, e.g. 'whois -h whois.jprs.jp xxx/e'. ] Contact Information: [担当者情報] a. [JPNICハンドル] QQ999JP b. [氏名] 何野誰某 （途中略） [参照] NET/192.0.2.0/27 [参照] NET/192.0.2.240/28
ここの[参照]欄にある NET/ のところに列挙されているネットワークが QQ999JP 氏が関与しているネットワークである。この例は JPNIC で調べる例だが、RIR や NIC によってそれぞれ方法は異なるものの、検索が可能なところは多い。たとえば YahooBB は APNIC から直接割り当てを受けているので、JPNIC の whois で上記のように調べることはできないが、whois -h whois.apnic.net bbtec で一発で検索可能である。
本節で取り上げたリストは、特定の地域/ISP を一網打尽にするものである。spam を送ってくる IP アドレスだけでなく、まともなメールも送ってくるだろうホストも当然この中に含まれるだろうことに十分注意すること。
ここからは SMTP セッション確立後のアクセス制御である。SMTP ではメッセージのヘッダ、本文がやりとりされる前にさまざまな情報が送信されてくる。この情報をもとにアクセス制御することができる。あくまで SMTP レベルでやりとりされる情報なので、SMTP セッションが終わってから処理が渡される MDA では、MTA がヘッダなどに情報を付加しないかぎりこの情報を利用できない。
まずは HELO から。
HELO/EHLO を送ってこず、いきなり MAIL FROM: からはじめるクライアントがまれにある。らしい。どの程度存在するのかは不明。かなり少数だと思う。蹴っても問題ないとは思うが、これによる効果は微々たるものではないだろうか。
HELO の引数は本来「クライアントの FQDN」が正しい。が、なぜか「サーバの IP アドレス」を指定してくる spammer がいる。しかもたくさん。必要のないサーバの IP アドレスをわざわざ手間をかけて調べて名乗ってくる理由がさっぱりわからないのだが、とにかくそういう spammer がたくさん存在しているのは事実である。なお、ほとんどは IP アドレスだが、わずかながらサーバのホスト名を名乗ってくるものも存在する。
クライアントがサーバを「詐称」しているのならば悪意あるクライアントとみなせるので spam とみなして問題ない。詐称ではなく、ほんとうにサーバと同じ名前のクライアントが接続してきたら、サーバが自分自身に接続している可能性が高い。メールのループの可能性が高いのでやっぱり拒否してよい。
こういうクライアントを拒否するのは絶大な効果がある。某所で動かしているサーバでは全メールの(全 spam の、ではなく) 5〜10% はこの制限にひっかかっている。チェックの負荷も低く副作用の可能性も小さい。HELO によるアクセス制限が可能な MTA を使っているならば騙されたと思って試してみるよいだろう。
なお、ウィルスチェックなど、ローカルで SMTP の多段リレーをしている場合には HELO で自ホストを名乗ってくることがありうるので注意。また、Postfix Backscatter HOWTO によると、Netscape Messager は HELO の引数に送信者のドメイン名を使うらしく、運が悪いとサーバのホスト名と一致することになる。HELO のチェックにかぎらず、ローカルのネットワークからはたいていの spam チェックは回避される設定にしておくとよいだろう。
HELO/EHLO ほど RFC が有名無実化しているものも珍しい。まともな MTA でも HELO に関してはデタラメな文字列を送ってくることは珍しくない。いちおう、クライアントの FQDN を名乗るのが原則なので、FQDN 形式でない（ピリオドが含まれていない）文字列だったりするクライアントを拒否するのはそれなりに有効である（例外も稀にあるので注意）。
しかし、名乗ってきた FQDN が有効なものかどうか DNS に問い合わせてチェックするのはやめておいた方が無難である。NAT の内側にいるホストなどはインターネット上で有効な FQDN を調べるのがめんどうだったりして、まともなホストでもいいかげんな名前を名乗ってくることは少なくない(RFC2505 #2.1)。また、MTA ではなく MUA が名乗ってくる HELO は厳密にチェックすれば9割以上不正なものといってもいいぐらいおかしなものばかりなので、信頼できるクライアントからのアクセスは HELO チェックの対象外とした方がよい。
spammer によっては HELO で特定の文字列を名乗ってくることがあるので、これのブラックリストを作成するのはわりと有効性が高い。
ESMTP PIPELINING 拡張を使うと、サーバからの応答を待たずにクライアントは次のコマンドを送ることができる。サーバとクライアントとの間のネゴシエーションの往復が減るので、SMTP トランザクションにかかる時間を大幅に減らすことができる。しかし、これが使えるのは EHLO の応答に PIPELINING が含まれていた場合だけである。それを確認しないうちに PIPELINING 拡張を利用してコマンドを先行発行するのは RFC 違反である。
spamware の中には、短時間に大量のメールを送れるようにするために、このような不正な PIPELINIG の使い方をしてくるものがある。そのため、コマンドの不正な先行発行を検知したら spammer として拒否してしまうというのも効果がある。グリーティングを出す前にわざと1秒程度の遅延を入れてやると効果がさらに顕著になる。
まず前提として、エンベロープの from とヘッダの from は別のものである。この文書でその違いを説明することはしないので必要ならば自分で調べること。この項ではエンベロープの from について述べる。
送信者アドレスは簡単に詐称できる(joe-job)。送信者アドレスによるブラックリストの作成は spam 対策のもっともポピュラーな手段のひとつであるが、詐称されたものは MAIL FROM: による判定は無力である。詐称されていないと確実に判断できるもの以外は別の方法で撃退することを考えた方がいいだろう。また、自ドメインを名乗る from ならばリレーを許可する、などという制限をすると詐称 spam の踏台になるので決してやってはいけない。
なお、メールアドレスの @ より左の部分のことは RFC 的にはローカルパートというのが正しいのだが、一般的にはアカウント部と表現した方がなじみが深いと思うので以下そう表記する。
RFC2505 #2.7, #2.9, #2.10
送信者アドレスは以下のように分類される。
実在するドメインはさらに以下のように分類できる。
このドメインからは spam だけでなく、spam 以外のメールが送られてくる可能性があるので、ドメインごとブロックするのは危険である。ドメインだけでなく、アカウント情報も込みでブロックするとよい。そのドメインを使っている知り合い（など）がおらず、そんなところからまともなメールが来ないと断言できるのならば、ドメインごとブロックするのもありだろうが、その際はくれぐれも慎重に。知己のアドレスだけホワイトリストに入れて、それ以外のアドレスは拒否という方法もある。
spammer が取得したと断言できるドメインならば、そこからのメールはすべて spam とみなせるだろう。遠慮なくドメインごとブロックできる。
問題は、そのドメインがどうやって spammer が取得したものか、善良な一市民が取得したものかを見分けるか、である。以下、その手がかりをいくつか挙げる。
spam を大量に送ると、エラーメールも大量に返ってくる。それを避けるため、届かないアドレスを使って spam を送ることがある。つまり、実在しないドメインからのメールはアドレス詐称 spam の可能性が高い。よって、たいていは受信拒否してかまわない。#1.4, #2.9
しかし、わずかながら自分のメールアドレスを間違えて送ってくる非 spam の可能性もある。このようなメールを救済したいと思うならば拒否はできない（このメールに返信しても届かないので、自分で正しいドメインを推測するなどの作業が必要になる）。
DNS の応答が NXDOMAIN ではなく SERVFAIL の場合は 5xx ではなく 4xx を返すべきである。NXDOMAIN の場合は 4xx でも 5xx でもどちらでもよい。なお、ドメインが実在するかどうかを判定する際には、当然 DNS に問い合わせをすることになる。メーリングリストやメルマガを発送するサイトでは同時に大量のメールを送信することになるが、DNS サーバが非力だと、この問い合わせで DDoS 状態になることがあるので注意すること。恒常的に受け取るドメインならばホワイトリストに入れて DNS への問い合わせが発生しないようにしておいた方がよい。
最近は実在しないドメインで spam が送られてくること自体がかなり少なくなった。まったくないわけではないが、そういうものもほかのチェックでひっかかるだろう。よって、ドメインが実在するかどうかのチェック自体、最近はする意義は薄いといえる。
user@sub.domain ではなく user のみだったり user@host だったりする形式。
送信者アドレスだけでなく、受信者アドレスがこの形式になっていることもある。インターネット経由ではなく、同一ホスト内、LAN 内でのメールはこの形式のアドレスでちゃんと届くことが多いが、インターネット経由ではまずありえない。よって、こういう形式のアドレスがインターネット経由で届いた場合はほぼ間違いなく spam である。
なお、FQDN でないアドレスで送信したものの、途中経路にある MTA にドメインが補完されることもある。この場合、補完した名前が特徴的なものであれば、それを手がかりにもともと FQDN で送信されなかったと推測できるので補完された名前をもって拒否することも考えられる。
わかりにくいので一例を挙げると、筆者は biglobe にメールアドレスを持っているが、その biglobe のメールサーバは FQDN でない hoge というアドレスを hoge@rcpt-impgw.biglobe.ne.jp というたいへん特徴的なアドレスに書き換える。つまり rcpt-impgw.biglobe.ne.jp というドメイン部を持つアドレスからのメールは元々 FQDN でないアドレスとして送信されたものと推定され、spam として拒否して実害ない。
煮るなり焼くなりご自由に。
拒否してもよい。ただし、バウンスすると詐称された無実の第三者にエラーメールが届いてしまう。これは backscatter といって新たな spam の源とみなされつつあるので、なるべく避ける。
拒否してもよいが、バウンスして backscatter にならないようにすべきである。しかもバウンス先のアドレスが存在しないのでダブルバウンスになる。外から届くメールではなく内部ユーザが外に出すメールに対して、実在しない送信者アドレスからのメールを拒否するような制限をかけると、worm などによる意図せぬ abuse を未然に防ぐことができるかもしれない。#2.10
問題は、この3つをどうやって区別するかということである。
区別は非常に困難なので、受け取ってからバウンスせず捨てるか、受け取り自体を拒否して送信側 MTA に措置をまかせるかのいずれかにするのがよいだろう。受け取ってからバウンスするのはやめた方がいい。
ローカル部が実際に存在するか確認するしくみ。Postfix ではアドレス検証(address verification)、Exim では呼び出し検証(callout verification)という。
SMTP 接続中、送信者アドレスから得られるドメインの MX に逆接続し、RCPT TO: でその送信者アドレスを指定する(callout)。この RCPT TO: が拒否されると、実際には存在しないアドレスを騙って送信してきたとしてメールを拒否する。もちろん、拒否されなかったからといって、実在するアカウントに詐称しているのかもしれないし、存在しないアカウントでも拒否しない MTA なのかもしれないので完全な検査にはならない。
Web からのメール送信 CGI でよく見られる無効なアドレスから送ってきたメール（やめてほしいが意外と多い）をごっそり拒否してしまうし、RCPT TO: までで実際のメールは送らないので DHA と勘違いされてブラックリストに載せられてしまう危険性があるなど、副作用が非常に大きい方法であり、よほどのことがないかぎり使わないのが無難である。使用の際にはドキュメントを十分に精読してから導入すること。すべてのメールに対してこの手法を使うのではなく、あらかじめ指定しておいた特定の送信者ドメインに対してのみアドレス検証するのならば、比較的安全に使うことができる。
送信者アドレスのドメイン名が存在するかどうかではなく、そのドメインにメールを送ろうとしたときにどのホストがそれを受け取るのかというチェックはかなり有効な方法である。いくつか例を挙げてみよう。
メールを拒否すると多くの場合エラーメールが返ってくるが、spammer にとっては（ハーベスティングに使えなくもないが）その多くはいらないメールである。以前は存在しない架空ドメインを使ってメールを送信することが多かったが、これではドメインが実在するかどうかのチェックでひっかかってしまってメールを受け取ってもらえない。そこで、最近は堂々とドメインを取得した上で、バウンスの返送先を到達性のないホストに向くように DNS を設定して spam を送ってくることが多い。たとえば、MX や A レコードを 127.0.0.0/8 のループバックや 10.0.0.0/8 のプライベートアドレス空間に設定する。あるいは、MX を dev.null や this.domain.is.not.used.for.email といった実在しないホスト名にするなど。このような不正な MX レコードを持つドメインはほぼ間違いなく spammer のドメインである。
.nu や .museum などの一部のトップレベルドメインにはワイルドカード A レコードが存在している。存在しないドメインからのメールを拒否する設定にしていても、これらの TLD ではほんとうは存在しないドメインでもワイルドカードが返ってくるだけで NXDOMAIN は返ってこず、ドメインの存在チェックの効果がない。しかし、実際には A レコードがこのワイルドカードに一致した場合は、実際には存在しないドメインである可能性が高い。
送信者ドメイン名でブラックリストを作る場合、spammer が新規ドメインを取得するたびにブラックリストに追加が必要になり、膨大なサイズのリストをたいへんな手間をかけて管理することになる。しかし、spammer は spam 送信に使う複数のドメインをひとつの MX ホストで運用していることがある。送信ドメインではなく、MX ホストの方をブラックリストに入れておけば、spammer が同じ MX ホストを使っているかぎりは新規ドメインでも対応する必要はない。大量のドメインを次々と使い捨てにしてくる spammer に特に有効である。
このように、そのドメイン宛のメールがどのサーバで処理されるかという情報も spam の判定に有用である。しかし、残念ながらこのようなアクセス制御を設定できる MTA はそんなに多くない。これを実施できる数少ない MTA が Postfix である。あまり知られていない機能で、google あたりで検索しても実際の設定例はほとんど見つからないようなので、以下にサンプルを示しておく。
--- main.cf
smtpd_recipient_restrictions =
...
check_sender_mx_access = $default_database_type:$config_directory/reject_mx
...
--- reject_mx
dev.null REJECT bogus MX
this.domain.is.not.used.for.email REJECT bogus MX
# see RFC 3330
0 REJECT MX in 0.0.0.0/8
10 REJECT MX in 10.0.0.0/8
127 REJECT MX in 127.0.0.0/8
169.254 REJECT MX in 169.254.0.0/16
172.16 REJECT MX in 172.16.0.0/12
172.17 REJECT MX in 172.16.0.0/12
（途中略）
172.31 REJECT MX in 172.16.0.0/12
192.0.2 REJECT MX in 192.0.2.0/24
192.168 REJECT MX in 192.168.0.0/16
224 REJECT MX in 224.0.0.0/4
225 REJECT MX in 224.0.0.0/4
（途中略）
239 REJECT MX in 224.0.0.0/4
240 REJECT MX in 240.0.0.0/4
241 REJECT MX in 240.0.0.0/4
（途中略）
254 REJECT MX in 240.0.0.0/4
255 REJECT MX in 255.0.0.0/8
#
195.7.77.20 REJECT wildcard .museum
69.25.75.72 REJECT wildcard .nu
212.181.91.6 REJECT wildcard .nu
195.178.186.40 REJECT wildcard .st
mail.nonregistered.nic.cx REJECT wildcard .cx
mail.worldsite.ws REJECT wildcard .ws
# 64.94.110.11 REJECT wildcard .com .net
DNS のルールでは MX レコードに指定するのは IP アドレスではなく A レコードでなければならないが、Postfix の設定ではどちらを書いてもよい。「そのドメインにメールを送るときに受け取るべきホスト名またはその IP アドレス」を列挙する。
不正な MX の排除ならば、MTA 自身での対応ではなく、不正な MX レコードを持つドメインを集めた DNSBL を利用してもよい。ただし、RHSBL（IP アドレスでなくドメイン名を検索する DNSBL）なので、利用できる MTA は限られるだろう。
また、MX ではなく、そのドメインが登録されているネームサーバ (NS) で制限することも考えられる（postfix での設定は check_sender_mx_access のかわりに check_sender_ns_access を使う）。MX にしても NS にしても、spammer ではなく、罪のないまったく無関係のドメインも同居している共用 MX、NS サーバである可能性もあるので、このような設定は慎重におこなう必要がある。特に NS の方は、自前の DNS を持たずレジストラや ISP が提供している DNS サーバを使っているドメインが非常に多いので注意が必要である。また、DNS に問い合わせる方法なので、そのリスクも認識しておくこと。
このような制限を標準で利用できる MTA は確認しているかぎりでは Postfix 2.1 以降だけ（2.0 用パッチもあるが、これを使うぐらいならバージョンを上げた方がいいだろう）だが、Sendmail は 8.12 以降でサポートされた dns マップタイプを使うことで MX や NS などの検索が可能なので、自分でルールセットを書けば実装することは可能であると思われる。
なお、ごく稀に管理者の無知でプライベートアドレスが MX に設定されている例がある。以前、とある国内の小規模 SI 業者が構築したドメイン（発見しただけで10ドメインほど）がプライマリ MX にグローバル IP、セカンダリ MX にプライベート IP が設定されていたことがあった。セカンダリ MX はふだん使われることがないので異常な設定であることに気がつかなかったのだろう（現在は解消されている）。
このアドレスはバウンスメールの送信で使われる。RFC2505 #2.6 では
The MTA MUST NOT refuse to receive "MAIL From: <>".
とされている。つまり、拒否してはならない。ただし #2.7 では、他のポリシーでひっかかるときには除外されている。接続元 IP アドレスがブラックリストにある場合が例に挙げられているが、ほかにも、RCPT TO: が自分のドメイン以外だと不正中継になってしまうので、このような場合も <> を拒否するべきだろう。ただし、通常バウンスの宛先アドレスはひとつなので、複数の宛先を持つ <> を拒否することも考えられるのだが、これについては #2.6.1 で明確な理由を挙げてこれを拒否してはならない（tarpitting なら可）と明記されている。具体的になぜなのかは RFC2505 本文を参照のこと（個人的には無視していいと考える）。
もちろん、正当な理由なく null sender を拒否するのは決してやってはいけない。不要ならばいったん受け取ってから捨てること。
なお、RFC3834 ではバウンス以外での自動送信メールで <> を使うことを許容している。
これは spam 対策ではなく、サーバのリソース保護の目的で入れる制限になる。長大なメールはメールボックスをあふれさせたり、各種コンテンツフィルタの負荷を増大させる。サイトのポリシーにもよるが、1MB〜100MB 程度に制限しておくとよいだろう（昔は 50kB ぐらいに抑えるよう言われてた）。
MTA のアクセス制御は、たいていの場合自分のローカルネットワークからのアクセスではひっかからないように設定するものだが、このサイズ制限に関してはよそのサイトに迷惑をかけないよう、ローカルからの送信にも適用されるように設定しておくのがいいだろう。
ところで、なぜこれが送信者アドレスの項目にあるかというと、MAIL FROM: の引数でサイズが通知されるからである(RFC1870 ESMTP SIZE 拡張)。qmail は SIZE 拡張に対応してないので、MAIL FROM: ではなく DATA の終わりでチェックされる。
ここまでで述べてきた IP アドレスや HELO、MAIL FROM などによるアクセス制限は、ひっかかったそのときではなく、この RCPT TO が発行されるまで待ってからエラーを返してもよい。なぜならば、その方が spammer に関する情報をより多く収集できるからである。
基本中の基本。自分宛の spam を減らすためではなく、無関係の人に spam を送る踏台とされないようにするための制限。
自分宛ドメインのメールだけを受け取る。他ドメイン宛のメールを受け取って、しかもその他ドメイン宛メールをそのドメインに配送してしまうと第三者不正中継の踏み台サーバとして DNSBL にリストされるであろう。RFC2505 #2.1
存在しないローカルユーザ宛のメールの措置は、
のいずれかになる。1が望ましいが、DHA (directory harvest attack) を受けることもある。2 は送信者が詐称されていた場合 backscatter になるし、詐称されていなくても harvesting されうるので極力避ける。qmail はデフォルトがこの動作なので注意すること。3は DHA を受けることもないが、いらないメールもいったん受けとるのでネットワーク帯域のムダになる。また、単純に宛先アドレスを間違えただけの場合にもエラーが返ってこないので、届いてないメールを届いたと思いこむ事故が発生する可能性がある。
sendmail や postfix など一部の MTA には、以前は存在したアカウントだけど何らかの理由で別のメールアドレスに変更になったユーザについて、旧アドレス宛に送られると新アドレスを案内する機能がある。spammer にハーベスティングされるおそれがあるので、この機能はあっても使わない方がいいだろう。新アドレスを宣伝するだけで受け取り拒否するぐらいならば、黙って受け取って新アドレスに転送してやった方がいい。
RFC2505 #2.11
これは外部からローカルユーザ宛に送ってくるメールについてではなく、ローカルユーザが外部に送るメールにかける制限。
ローカルユーザから送られるメールは無制限に中継を許可する設定にしていることが多いと思うが、ここに宛先ドメインが実在するかどうかのチェックを入れておくのも有効である。存在しないドメインにメールなんて送れないんだから、受け取ってからバウンスしたり時間切れになるまでキューに溜めこんでおいたりするのではなく、はじめから受け取らないようにしておけば MTA のよけいな仕事が減るというものである。
システム予約のアカウントや RFC2142 で規定されているメールボックスはどのホストにも存在している確率が高いので spammer に狙われやすい。しかし、RFC2142 に記述があろうと、たとえば NetNews サービスをしていなければ news アカウントは不要だし、ほんとうに要求されるもの以外は消してしまってかまわない。
ただし、postmaster に関しては RFC2821 の規定で必ず存在していなければならない。spam が届くからといって、postmaster を aliases から削除してはならない。postmaster 宛メールの一部を受け取り拒否することは実は認められているので、ちゃんとエイリアスなり実アカウントなりで postmaster アカウントを用意した上で spam 対策をすること。
MTA に多数の RCPT TO や VRFY、EXPN を送ってそれぞれの応答をチェックし、実在するアカウントと実在しないアカウントを選別することを DHA（directory harvest attack; ディレクトリ獲得攻撃）という。spam 送信ではなく、spam 送信の準備段階の行為である。よく似たものとしておなじみ辞書攻撃 (dictionary attack) がある。これはただ単に「下手な鉄砲数撃ちゃ当たる」で存在するかどうかわからないアドレスを大量に並べてメール送信することを指し、アドレス収集は副次的な目的であることが多い。大量の RCPT TO を送りつける目的がアドレス収集のためなのか、メール送信のためなのかの違いだが、挙動はほとんど変わらないので対策も同じでよいだろう。RFC2505 #2.11
VRFY はアドレスが存在するか否かの確認、EXPN はエイリアスやメーリングリストになっているアドレスの実際の転送先アドレスの取得に使われるコマンドである。そもそも実装していない MTA だって多いわけで、これらの要求をすべて拒否してしまっても特に問題になることはない。UNIX での各種 MTA の設定は以下のとおり。
- Sendmail define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy') # .cf を直接変更する場合は O PrivacyOptions の項 - Postfix disable_vrfy_command = yes # EXPN はもともと非サポート - qmail # VRFY、EXPN とも非サポート
一方、RCPT TO は実際の宛先アドレスを指定するものなので、これを拒否するわけにはいかない。RCPT TO を使う DHA に対しては、存在しないアカウントを指定してくるたびにペナルティとして応答に遅延を入れてやる(tarpitting)ことである程度防御することができる。また、存在しないアドレスを指定した回数が一定の数以上になったら切断してしまうといいだろう。頻繁にやってくるホストならばブラックリストに登録する。
DHA や辞書攻撃では一度に数百のアドレスを RCPT TO: に指定してくることもある。RCPT TO: の数が 100 を越えるような場合には、それ以下の数になるように SMTP トランザクションを分割すべし、と RFC2821 にあり、まともな MTA は実際そのように実装されているので、100 以上の RCPT TO: が並ぶことは通常ないはずである。よってこれ以上の RCPT TO: は受け付けないように制限しておくとよいだろう。ただし、最低 100 との規定があるので、それ以下に設定してはならない(RFC2821 #4.5.3.1)。つまり、上限をきっかり100に設定すればよい。もっとも、受信者アドレスが 10 しか存在しないホストなのに RCPT TO が 20 というのもおかしな話なので、そういう小規模なところでは実情にあわせて設定して問題ないだろう。
RCPT TO: で宛先アドレスが存在するかどうか確認して、しかしメールの本文を実際に送らずに切断してしまう、というのは高い確率で DHA である。しかし、こちらから送ったメールの宛先サーバから、spam チェックのために送信元が実在しているかどうか逆接続して確認してくることが稀にある。これも一種のハーベスティングなのだが、こういうのをブラックリストに入れてしまうと、こちらからのメールが届かなくなってしまうので注意する必要がある。
ここに挙げた以外では、バウンスメールなどからも届くアドレスと届かないアドレスの選別が可能なので注意する必要がある。アドレス収集の項も参照せよ。
SMTP セッション中のメール本文のやりとりがはじまるまでに判断できる上述のような情報を複数組み合わせて判定したり、また、上述のどれにも属さない話題。
多くの MTA は自分には厳しく、他人には寛容に、という方針で実装されている。つまり、自分が SMTP クライアントとなって他サーバに配送するときは RFC を守るが、SMTP サーバとなって他からメールを受け付けるときには少々の違反には目をつぶって受け入れる、というポリシーになっていることが多い。
spamware はとりあえずメールを送れればいいので、RFC の遵守に気をかけず、他人が寛容なのに甘えていいかげんな文法で SMTP コマンドを送ってくることがある。よって、寛容さを捨てて厳密なチェックをするようにすることで、spamware からの送信のうちいくらかを止められる。ただし、spamware でなくても、実装のまずい MTA があれば問題を起こすことがある。たとえば、qmail のダブルバウンスで使われる #@[] という送信者アドレスは正しくないし、DoCoMo はクォートする必要がある文字列を含むメールアドレスを発行しておきながらクォートせず送信しようとする（DoCoMo のページには「一部のプロバイダとメールを送受信できない場合があります」と、ISP 側に問題があって DoCoMo の側では修正するつもりもないように書かれているが、悪いのはまぎれもなく DoCoMo の側である。詳細は省くけど DoCoMo の MTA はほかにもいくつかおかしな挙動を示す）。
spam を送るのはメール送信ツールだけではない。HTTP のプロクシが踏台にされて spam を送ってくることがある。これは、HTTPS のプロクシが仕様上任意のホストの任意のポートに対して任意の通信が可能だからである（RFC2817; ふつうは設定で制限する）。そのために、稀に HELO/EHLO が要求されるべき状況で、SMTP とは関係ない GET だの POST だのといった HTTP のコマンドが送られることがある。こういう接続は明らかに不正目的であり、かつ 4xx で蹴るか 5xx で蹴るかだのといった議論が通用しないので、検知したら即座に切断してよい（MTA がその機能をサポートしていれば。そんなに頻繁にはないので放置しても問題はないだろう）。
なお、Sendmail X は、この寛容さを捨てて、他人にも厳格なルール遵守を求めるようだ。
以下も参照のこと: HELO の省略、不正な PIPELINING
認証に成功したユーザに対してのみ中継を許可するしくみ。RFC2554 で定義されるが、この RFC 自体は認証の枠組を定めるだけで、実際に使われる認証の詳細は RFC2222 (SASL) で別途定義される。RFC2505 #3.3
SMTP というプロトコルにはもともと認証の概念が含まれていなかった。そのため、外部ネットワークいる正規ユーザが正規ユーザであると確認する手段がなく、外部にメールを中継させる用途では、信頼できるネットワークからのアクセスだけに限定したり、やむをえず POP before SMTP でお茶を濁していたりいた。しかし、この拡張機能を使うことで SMTP のプロトコルの中で認証できるようになり、組織の外部から正規ユーザがメールを送れるようになった。あくまで拡張プロトコルであり、クライアント、サーバの双方で AUTH への対応が必要なため、どんな場合でも使えるわけではないが、普及は進んでいるため、外部ネットワークからの送信が必要なサイトでは導入済みのところが多いだろう。
TLS による安全な通信路を確保し、そのトンネル上で SMTP をおこなう。通常の25番ポートに SMTP で接続した後で STARTTLS コマンドで TLS に移行するものと、465番ポートに SSL によるトンネルを張ってからその上で SMTP を開始するものと、中身のまったく異なるふたつの方法がある。それぞれ別の名前を与えて使いわけてほしいものだが、いっしょくたにされてしまっているのが現状である。前者は MTA どうしの送受信で、後者は MUA から MTA への送信で主に使われているようだ。
この文書ではメールを受け取る立場から送信側をチェックすることについて述べているが、逆に、送る方の立場から受ける側の正当性を確認できるほとんど唯一の手段がこの TLS である。たとえば DNS のキャッシュが汚染されていた場合、通常は重要なメールを不審なホストに送ってしまってもほとんど気がつかない。しかし、TLS のサーバ認証により送信先サーバの正当性を検証すれば、不審なホストに機密を漏らす前に送信を止められる。
もちろんクライアント認証も可能なので、受信側から送信側の正当性をチェックすることも理屈の上では可能である。
通常キューの再送はキューを保持しているサーバが一定のスケジュールで実施するが、配送を受ける MTA からの要求で再送させることもできる。このときに使われるのが ETRN である。
しかし、ETRN を使わなくてもしばらくすれば再送されるのだから、特段の事情がないかぎり ETRN を許可する必要はないだろう。どうしても許可したい場合でも、特定のホストからの要求に限定するべきである。RFC2505 #2.12
同時あるいは単位時間あたりの接続数や、単位時間あたりあるいはセッションあたりのメール通数、メールサイズ、受信者数、エラー数などの上限を設定しておき、それを越えるアクセスを拒絶したり、応答を遅延したりする。
これはおもに DoS からの防御、あるいは内部からの意図せぬ大量配送を防止する目的で実施することになる。もちろん、短時間に大量の spam を送ってくる輩を排除するのにも使える。RFC2505 #2.8
設定できる項目は MTA によって大きく異なるので、MTA の機能だけに頼らないほうがよいだろう。日頃からトラフィックやログの監視をして通常と異なるパターンがあらわれていないかチェックし、異常があれば一時的に設定を変更して防御するなどの臨機応変な対応が必要になる。過大なアクセスを締め出す場合は MTA ではなくファイアウォールなどの別の機器で対処した方がよいこともある。
同じく DoS からの防御である。プロセス数やロードアベレージ、使用メモリ、ディスク容量（キューディレクトリ、アカウントごとのメールボックス）などに上限を設定しておき、それを越える状態のときには新規の接続を受け付けないようにする。限界を越える負荷状況でサーバを稼働し続けるのは危険である。リソース保護は必須である。
応答をわざと遅らせること。tarpitting（ターピット、タール坑; ドイツ語で Teergrube と表記することもある）と呼ばれるが、これは現代になって発掘されているマンモスやサーベルタイガーなどの化石の多くがタール溜まりに落ちて身動きが取れずに緩慢な死を迎えたものであることに由来する。throttling や greet_pause（Sendmail 8.13）ということもある。
spam の多くは短時間に大量のメールを送れるように最適化された専用ツールで送られる。送信に時間がかかる宛先はすっとばして、時間のかからない宛先に次々と送っていった方が効率よく spam をばらまけるので、spamware は汎用の MTA に比べてタイムアウトが短く設定されていることが多い。これを利用してわざとゆっくりと応答をしてやると、spammer は送信をさっさとあきらめてしまう（が、一般の MTA は待ってくれる）ことが期待できる。
また、SMTP トランザクションの開始のとき、グリーティングバナーを送出する前にわざと遅延を入れてやると、SMTP コマンドを不正に先行発行するクライアントを見極めやすくなる。
どんな場合にも遅延するのではなく、たとえば、
など、相手に応じて遅延を入れるかどうか選択的に判断してやるとよい。遅延時間は数秒〜数十秒程度が適当だろう。まともな MTA までタイムアウトしてしまうような長い時間に設定してはいけない。最小タイムアウト値の目安は RFC2821 #4.5.3.2 に記述がある。
なお、あたりまえだが、遅延を入れなければ1秒もかからず終了できる SMTP トランザクションであっても、遅延を入れると数十秒以上かかるようになる。そのため、数秒おきにメールが届くような環境では、終了しない SMTP トランザクションがどんどん増えていってプロセス数の上限を越えてしまい、応答を遅延するどころかそもそも応答できないなんてことが容易に起きうる。また、プロセス数の増大は受信側だけでなく送信側にも起きる。ひとつのメーリングリストに自分のドメインのユーザが何十人も登録されているような場合、その ML からのメールに一斉に遅延応答してしまって、ML 側の送信プロセスを飽和させたりしないようにしなければならない。
MTA が返すステータスコードのうち、4xx は一時的エラーを意味する。一時的なので、そのうち回復するだろうことを期待して、しばらくしてから再送するのが MTA の基本動作である。しかし、spamware にはこの再送動作をおこなわないものがある。そこで、すべてのメールをいったん 4xx で拒否してこのようなクライアントを選別し、再送してきたものを受け入れるという手法が考えられた。
メールが届くと、接続元 IP アドレス、送信者アドレス、受信者アドレスの組み合わせ (triplet) をデータベースに記録していったん 4xx で拒否する。一定時間内に同一の triplet で送信されてくれば、それは再送されたものとして、4xx ではなく今度は正常に受け取る。triplet を記録するデータベースは許可リスト（ホワイトリスト）でも、拒否リスト（ブラックリスト）でもなく、まだどちらかわからない「疑わしい」リストなので、これをグレイ（灰色）リストとよぶ。triplet ではなく、IP アドレスだけを見る簡易法（いちげんさんお断り方式、お馴染みさん方式）もある。いずれも再送するかしないかだけで判別するので、ちゃんと再送してくる spam にはまったく効果がない。
最近の spam の多くはワームに乗っとられたゾンビ PC を発信元とし、これは多くの場合 spamware ないしは open proxy として動作している。これらはキューを持たず再送しないものがほとんどのため、greylisting による拒否の効果は高く、また、再送されたメールは受け取るので、一般的な MTA からのメールを失なう可能性も低い。しかし、この方法は自分のサーバだけでなく、正当なメールの送信元のサーバに再送を強いることになる。そのような正当なメールの発信元はホワイトリストに入れる運用が基本であるが、正当なメールを送ってくるすべてのホストをホワイトリストに入れられるわけではない。spam を選別する能力が非常に高いことは認めるが、正当なメールを送ってくるサーバのリソースを無駄に浪費させるこの方法は個人的には承服できない。
なお、大規模な ISP では、通常のメール配送サーバとは別に、再送専門の配送サーバを用意していることがある（キューに滞留しているメールの数が多くなると、少ないときとは異なるチューニングが必要になってくるため、ほとんどキューに溜まらない1回目の送信専用のサーバと、大量のキューを扱う2回目以降の再送専用サーバに役割を分担しておくと効率がよくなる）。また、大規模メールシステム向け商用 MTA には、キューの管理をおこなうサーバと実際の配送をおこなうサーバを物理的に分離できるようにしてスケーラビリティを高めているものがある。つまり、再送のためのキューは1ヶ所だが、実際の再送は IP アドレスの異なる複数の配送サーバがおこなう。このようなシステムを採用している ISP からのメールはグレイリストに記録した triplet とは異なる IP アドレスからメールが再送されてくることがあるので注意が必要である。
たいていの MTA では greylisting は外部プログラムとの連携で実現されるが、Sendmail X には greylisting の機能がはじめから内蔵されている。また、Mirapoint のメールアプライアンスに塔載されている MailHurdle という機能はどうやら greylisting をベースにしたものらしい。
POP 認証に成功した IP アドレスからのメール送信を一定時間の間認めるもの。以下のような問題があるので、できるだけ使わない方がよい。そもそも、これはあくまで POP の認証であって、SMTP の認証ではない。SMTP Auth に移行するべきである。
POP ユーザ名に紐づけられたメールアドレスでの送信しか認めないといった制限をかければ少しはマシになるが、これでもゼロにちょっと近づいただけでマイナスであることには変わりない。
これまで述べてきた方法はいずれもメールの中身を見ていない。つまり、spam かどうかではなく、spammer かどうか、という観点で判定している。spam かどうかを判定するのは、以下に述べるヘッダと本文を見る手法である。
メールのヘッダは大きく、MUA が付与するヘッダと、配送経路上の MTA、MDA が付与するヘッダの2種類にわけられる。
おもに、SMTP のセッション中にやりとりされる情報や、配送経路の追跡情報である。これらの情報を利用するアクセス制御は SMTP セッション中にヘッダに頼らなくともできるので、MTA レベルで利用することはないだろう。MDA で判定するときに利用する情報になる。
Return-Path と Delivered-To はメールを受け取った側で付与され、よそから届いた段階には存在しないので、MTA でおこなうアクセス制御にこれらのヘッダから得られる情報を利用することはできない（正確には、付与されている場合もあるが信用するべきではない）。これらの envelope 情報は MDA では環境変数などで参照できることも多い。
Received には途中経路上の MTA の IP アドレスやホスト名、どのホストからメールを受け取ったかや、HELO でどんな名前を名乗ったかなどが記録されている。Received ヘッダの文法はかなり自由度が高いので機械的に情報を抽出するのは他のヘッダに比べるとめんどうだが、配送に関与したすべての MTA の情報が記載されるので重要である。ただし、偽造した Received ヘッダを付与してメールの出所を隠蔽するといったこともよくおこなわれているので惑わされないように注意。
From、To、Cc、Subject、Message-ID、その他もろもろ。いくつかの重要なヘッダについては、足りなかったり構文がおかしかったりすると途中経路の MTA が追加、修正することがある。
なお、From、To、Cc についてはエンベロープ（MAIL FROM:、RCPT TO: で指定されるアドレス）とは必ずしも一致しない。
ヘッダフィールドで使える文字の種類や、1行の長さなど、ヘッダの形式は RFC で定められている。その範囲内で Date や Message-ID などの多くのヘッダは記述する値の文法がさらに細かく定められている。
ヘッダが正式に定められた形式を守っているかどうかチェックすると、いいかげんな作りのクライアントからのメールを弾くことができる。ただし、spamware にかぎらず、このようなおかしな文法のものは意外と多いので注意が必要である。
spam にはヘッダの値に特徴的な文字列が含まれていることがある。代表的なのは Subject のおなじみ「未承諾広告」など。Subject での判定以外にも、韓国語や中国語の読めない spam は Content-Type のサブタイプで知ることができるし、大量送信ツールを使った送信では X-Mailer で自分の名前を名乗ってくることがある。
From、To、Cc のそれぞれに記載されたアドレスについて、エンベロープの MAIL FROM:、RCPT TO: でおこなうのと同じような検査をおこなうことも考えらえる。
ただし、「こんな spam が届いたどうにかしてくれ」のような報告をメールで受ける可能性がある場合は、Subject による判定は注意が必要である。元の spam の Subject に Re: だの Fw: だのをつけただけであることが多いので、単純に Subject の部分一致だとその報告メールも拒否してしまう。かなりのレアケースだと思うが、特に postmaster や info、support、abuse といったアドレスにはそのようなメールが届くことがまれにあるのでいちおう留意しておくこと。
また、X-Mailer での判別では、そのツールを spamware ではなく同報配信ソフトとしてまともな用途に使う例がまったくないわけではないので、拒否してしまうとまっとうな案内を受け取れないこともある。
メールの転送設定がおかしかったりすると、いくつかのサーバの間で同じメールを延々と転送しつづけてしまうことがある。放置すると無限ループになってサーバのリソースに影響を与えるので、ループを検知して途中でこの循環を止めてやる必要がある。この判定に使われるのが Received と Delivered-To である。
正確には、ループ回避ではなくホップ数制限である。MTA 間をメールがやりとりされるたびに、Received ヘッダが追加されていく。そのため、Received ヘッダの数がむやみやたら多い場合は、同じメールが同じサーバを何回も通過している可能性が疑われる。よって、ある設定値以上の Received ヘッダを持つメールはそれ以上の転送をやめて、無限ループを回避する。
この方法は、正確にループを検出しているわけではない。ループが止まるのは数周した後かもしれないし、実はもしかしたらループでもなんでもなく、ほんとうにたくさんのメールサーバを経由しないと届かないメールなのかもしれない。前者については、1周では止まらないれど最終的には止まるのでよしとする。後者については、できるだけそうなってしまわないように十分大きな上限値にし、またできるだけ多段ホップを減らすように MTA のシステム全体を構築することで回避する。
以前は UUCP などを使っていて直接の到達性がなく、何段か中継しないと送れない相手などもあったので Received ヘッダの数は多かったが、最近ではほとんどの相手と直接 SMTP でつながるようになっている。しかし、メーリングリストマネージャやウィルススキャンエンジンなどの付加機能を持たせるシステムのため、ローカルなネットワーク内で多段中継してホップ数が多いことはある。最低でも30ホップ程度は許可しておく必要があるだろう（RFC2821 #6.2 では 100 以上にすべきとされている）。
SMTP セッション中に RCPT TO: で指定されたアドレスは MDA により Delivered-To ヘッダに記録される。.forward などでこれを別アドレスに転送したが、何らかの理由でループして戻ってきた場合、そのメールにはすでに RCPT TO: と同じ Delivered-To が設定されているため、ループしてきたということが検知できる。Received によるような不確実な検知ではなく、Delivered-To ではループちょうど1周で検出できるという利点がある。
しかし、上述のように Delivered-To は MDA で付加されるヘッダなので、.forward などによる個々のアカウントのレベルでの転送ループは検知できるが、MX によらない静的配送経路（sendmail の mailertable、postfix の transport_maps、qmail の smtproutes）を人為的に形成しているときに、設定ミスによるループが形成されてしまったとしても、Delivered-To ヘッダは付加されないのでこの方法は役に立たない。そのため、ループ検知を Delivered-To だけに頼ることはできず、Received によるホップ数制限も必要となる。
なお、これは非標準ヘッダであり、そもそもサポートしていない MTA も多い。Delivered-To をサポートしている MTA では、サポートしていない MTA に比べて Received のホップ数カウントの上限をゆるめの設定にすることが多い。
年に何回か大手企業が To や Cc に多数のメールアドレスを入れてしまって顧客のアドレスを漏洩してしまうミスをやらかして新聞に載る。
ヘッダの行数やバイト数に制限をして、それを越えるメールはエラーにしてやると、このような事故はある程度は防げるかもしれない。ただし、Received がたくさんある場合もあるので、最低でも数 KB は許可してやる必要はある。
yet.
バウンスメールには元メールが添付されることが多い。本文におかしな文字列があったからといってそれを拒否する設定にすると、spam だけでなく、本来受け取るべきバウンスメールまで拒否してしまうことになるので注意が必要である（ヘッダによるチェックでは、バウンスに添付されても拒否する原因となったヘッダはボディに移るのでこのようなことは起きない）。
構文の壊れた MIME マルチパートメッセージを送ってくる spammer がたまにいる。また、構文的には間違っているためウィルススキャナにはマルチパートと認識されずに添付ファイルが認識されないが、メーラーには認識されるために素通りしてしまった Sircam というウィルスがあった。spammer にとってはメーラーがちゃんと解釈してくれれば規格に厳密である必要はないのだ。
そこで、MIME マルチパートの構造を厳密にチェックすることで、いくつかの spam を検知することができる。しかし、へぼプログラマの書いた MIME ライブラリをそれと知らずに使ってしまった spam でないメールもそれなりに多いので注意が必要である。spamware によってはマルチパートの境界文字列（Content-Type ヘッダの boundary=...）が特定のパターンになっていることがあるので、こちらを検知するのも意外と有効である。
添付ファイルの拡張子が Windows の実行形式（.exe、.com、.bat、.pif、.scr、.cmd など）やスクリプト（.vbs や .js など）の場合には、ウィルスの危険ありとして拒否してしまう設定をすることがある。これは Content-Disposition ヘッダの filename アトリビュートで見分けることができる。
ただし、ファイルを自己展開アーカイブでまとめて .exe の形で添付したりすることも日常的におこなわれているので、必要なメールまで失ってしまう可能性がないではない。これは主に spam というよりもウィルス対策なので、ウィルススキャナを導入すればたいていは除去できるはずである。しかし、ウィルススキャナといえど万能ではなく見逃すこともないではないし、spam とは異なりウィルスは怪しい臭いがしたら少々の誤判定の可能性があっても捨ててしまった方が安全なので、このような方法を一概に否定することはできない。実際にこのような手法を導入するさいには、ユーザに事情を十分周知しておくべきだろう。
Generic Test for Unsolicited Bulk Email。アンチウィルスソフトの動作確認に使われる EICAR テストウィルスと同じように、spam フィルタの動作確認に使われるテストスパム。本文のどこかに
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
という文字列が含まれているメールを送ったときに spam と判定されれば、spam フィルタは正しく動作している。この文字列をそのまま生で送った場合だけでなく、Base64 などでエンコードした場合にも検知できるか確認しておくとよい。
もちろん、その spam フィルタが GTUBE の検出にもともと対応していなければ確認できないので念のため。
単純なパターンマッチで spam かどうか判定したり添付ファイルを除去したりするだけのかんたんなものから、ベイジアンフィルタやウィルススキャナのような全文を対象にチェックするような複雑なものまで多種多様で、用途もさまざま。もちろん、上述の判定方法もコンテンツフィルタの一種である。
外部から入ってくるメールが spam やウィルスなどであるかどうかのチェックするために設置されるコンテンツフィルタだけではなく、機密情報の漏洩を防ぐために内部から出ていくメールを監査する目的で設置されるコンテンツフィルタも、最近は特にエンタープライズ用途で多くなっている（ほとんど商用製品）。
コンテンツフィルタは MTA に内蔵されることもあるが、複雑で多様な目的を実現するために、MTA の外部で実装することが多い。コンテンツフィルタと MTA との情報のやりとりの手法には以下のようなものがある。
商用のコンテンツフィルタは SMTP を話し、それ自身で簡易 MTA として動作するものが多い。このような製品はふつうにメールを中継してやるだけでフィルタリングすることが可能である。また、HTTP プロクシ用のコンテンツフィルタをそのまま使えるように、iCAP という HTTP プロクシで主に使われるプロトコルでやりとりするものもある。
以下、主なコンテンツフィルタ。概念的な説明に留めて、詳細にまでは踏みこまない。
最近のウィルス（というか、ワーム）は大量にメールを送信する機能を内蔵しているものがほとんどだが、その挙動は spamware とほとんどかわらないので、spam 対策を強固にしていれば、ウィルススキャナを導入しなくてもかなりのウィルスはブロックできてしまう。とはいえ、さんざん繰り返しているように、「spam 対策で重要なのは spam でないメールを受け取ること」なので、spam の可能性が高いが断言はできない、という程度ならば受け取ってしまうべきであり、そこからウィルスが入りこむ隙はやはり存在する。
なので、spam 対策と並行して、ウィルスへの対策もしておくべきだろう。こちらはうっかり感染してしまったときの被害を考えたら、少々厳しいぐらいのチェックでもよい。たいていのメールウィルススキャナは、検知したウィルスを削除するだけでなく、どこかに隔離(quarantine)しておくことができるようになっている。そのため、ウィルスでないメールをウィルスと誤判定してしまった場合でも拾ってくることは可能である。
ClamAV などのフリーのウィルススキャナもがんばってはいるが、やはり商用製品の方が検知できるウィルスの数が多いし、ワームではなく、実行バイナリに感染する狭義のウィルスや Word や Excel などのマクロウィルスなどに関しては、検知したファイル全体を除去するのではなく、ウィルス部分だけを取り除いて感染前に近い状態に修復できたりするなど機能が豊富である。もっとも、修復が可能なタイプのウィルス自体が絶滅危惧種だし、修復されたとわかっていても恐くてさわれないのが人間心理なので、削除しかできなくてもそれほどデメリットにはならないのだが。
選択の際には、機能、性能だけでなく、新種ウィルスへの対応の速さ、サポート対応の充実さも含めて検討した方がよい。商用製品を使う場合には、ベンダの担当者と太いパイプを作っておくと、未対応新種ウィルスの拡散時など、迅速な情報収集が必要なときに手助けになってくれるかもしれない。
どのようなものをウィルスとみなしてパターンファイルに登録するかはベンダによって基準が異なることに注意。たとえば Klez や Netsky は「不適切な MIME ヘッダ」(MS01-020) による自動実行で爆発的に広まったワームであるが、被害をもたらすのはワーム本体の実行ファイルであって、トリガーである「不適切な MIME ヘッダ」単体で被害が出ることはない。このような直接の実害をもたらさないものについてはベンダによって対応が異なることがある。MS01-020 の例では、シマンテックは検知しないがトレンドマイクロ(HTML_IFRMEXP.GEN)とマカフィー(Exploit-MIME.gen)は検知する。
ベイズ推定を spam 判定に応用したもの。過去に起きた事象（これまでに受けた spam）から未来（これから受ける spam）を予測して判定する統計フィルタ。「過去に起きた事象」の蓄積、つまり学習が必要となる。受信するメールの傾向は個人ごとに異なるので、学習も個人ごとにおこなった方が効率がよい。そのため、MTA での spam 判定で使われることもあるが、どちらかというと MDA、MUA でおこなうことが多い。MRA でおこなう POPFile というツールもある。
最近では spam フィルタの主力といっていいほどよく知られているので、spammer 側でも対策しているようで、spam 確率の低いトークンを大量に混入させたり（宣伝とは無関係な時事ニュースを末尾に付加したりする）、spam 確率の高いトークンを偽装したり（Viagra を V*i*a*g*r*a としたりする）してフィルタをすり抜けようとする spam も多い。
また、MEF (Malicious Email Filter) のように、テキストの spam ではなくバイナリのウィルス検知にベイズ推定を用いる試みもある。2001年の USENIX で発表しているが、その後の動きが見えないので、試みがある、というより、あった、とすべきかもしれない。
ベイズ推定によるフィルタリングのアイデアが広く知られるようになったのは 2002年の Paul Graham による A Plan for Spam（邦訳）という文書からだが、これは上述の MEF よりも新しいし、さらにさかのぼるとメールの振り分け先フォルダを自動で推測する ifile というツールが1996年から実装しているようだ。
DNSBL は spam を送ってくる IP アドレスを DNS という分散協調型データベースをとおして参照できるようにしたものである。同様に、IP アドレスではなく、spam 自体を分散データベース化して参照するしくみもある。
届いた spam そのものをデータベースに問い合わせるとサイズが大きくなるので、実際にはメッセージから数十バイト程度のシグネチャを生成してそれで識別することになる。同じシグネチャが誰かによってすでに報告されてカタログデータベースに登録されていれば spam と判断される。
代表的なものに Vipul's Razor、Pyzor、DCC (Distributed Checksum Clearinghouse) などがある。いずれも SpamAssassin から利用することもできるらしい。未確認だが、BIGLOBE の迷惑メールブロックサービスの正体は Vipul's Razor ではないかと思われる。
URI blackhole list。spam の多くは広告メールなので、宣伝サイトへ誘導する URL が含まれているのがほとんどである。この URL を登録してある DNSBL が URIBL である。SURBL、URIBL、RBL.JP、Bulkfeeds などで運用されている。
ドキュメントを斜め読みしたかぎりでは、URL の一部しか見ていないようで、同じドメインに spammer とそうでない人が両方いるような場合を区別できないように思う。たとえば、example.com が URIBL に登録されているとすると、
という URL がいずれも spam 判定を受けてしまいそうに見える（後2者は URIBL に問い合わせる側の実装依存かも）。また、example.net が example.com と IP アドレスが同じバーチャルホストであれば、http://example.net/ がまったく無関係であったとしても spam 判定を受けてしまいそうだ（これもクライアントの実装依存か？）。ドキュメントを精読したわけでないので勘違いかもしれないけど。
この手法では URL の一部分とはいえ、メールの本文に含まれる内容の一部がそのまま外部に送信されることになるので注意が必要である。内輪だけで利用している URL でも、メールの文中に書かれていると、参照先の URIBL やリカーシブ DNS サーバの運用者などにその存在が漏れてしまう。デリケートな内容を含むメールを扱うことがある場合には、この手法を採用していいかどうか十分な検討が必要だろう。
メールではなく、もともと第三者に向けて公開されることが前提で送られる Web のトラックバック spam の排除に使うのであれば、情報漏洩について神経質にならなくてもよいだろうからかなり有用だろう。というか、実際のところ現状はそっちでの利用の方が多いかも。
spam やウィルスのように外部から届く不要なメールだけでなく、意図せず内部から出ていってしまう不要なメールも困りものである。企業サーバで私用メールが出ていく程度ならば生産性の低下で済むが、悪意ある社員あるいは悪意あるソフトウェア(malware)によって重要な機密情報が漏洩してしまうと、その企業の信頼を大きく揺るがすことになる。
そこで用いられるのがメッセージ監査・監視ソフトウェアである。なんらかのパターンマッチでブロックするという点では他のコンテンツフィルタと同様だが、監査ツールの場合は中継の可否を即座に判断するだけでなく、あやしいメールは責任者が目視で判断するまでしばらく留め置く、などのアクションを取れるものが多い。
事実上の検閲ツールだが、企業などでは導入が進んでいるようだ。GUARDIANAUDIT などの製品があるが、その性格上、オープンソースではおそらく存在しないだろう（たぶん）。
メールが監査サーバを通過しなければまったく無意味なので、Outbount Port 25 blocking との併用が必須である。
送信「者」認証と呼ばれることもあるが（だって英語では sender authentication だし）、日本では最近は実態にあわせて送信「ドメイン」認証と呼ばれることが多くなっている。実際、SMTP AUTH のような「送信者」を認証するしくみではない。
読めばわかるとおり、以下で述べる各方式は長所だけではない。途中経路での扱いによっては正当なメールでも認証に失敗してしまう可能性は否定できない。しかし、これらの方式はお互いに矛盾しているわけではなく、共存が可能である。認証に用いる情報がそれぞれ異なっているので、複数の方式を同時に採用すれば、ある方式の欠点を別の方式で補うことができる。どれがいい、という問題ではなく、余力があればいくつか採用してどれかひとつでもパスすれば OK とする、という運用がよいだろう。
また、いずれの方式も現在は DNS を利用している。つまり、DNS そのものの信頼性・安全性を越えることは不可能であることを心に留めておかなければならない（現在は、としたのは、DKIM が DNS 以外を使えるような将来の拡張を考慮した仕様になっているため）。
POBox の提案した SPF (Sender Policy Framework) と Microsoft の CallerID を統合したのが SenderID。RFC に採択されることにはなった（現時点では決定しただけで番号は与えられていないようだ）が、標準とされる standard track ではなく、experimental 扱いとなっている。
送信者のドメインから DNS を検索し、そこに記述されたリストに接続元の IP アドレスが含まれているかどうかをチェックして、オーソライズされたホストから送信されたものかどうかを調べる。envelope (MAIL FROM) を検査対象とする MFROM（SPF、SenderID）とヘッダ From を対象とする PRA（SenderID）のふたつの方式がある。「誰が送ったか」をチェックする DomainKeys とは異なり、「どこから送られたか」をチェックするしくみであるといえる。送信側は DNS の TXT レコードに SPF 情報を登録するだけでよく、送信側 MTA に特別な対応は必要ないことになっている。しかし、「どこから送られたか」をチェックするしくみであるが故に、メールの転送などで登録していないサーバを中継させてしまう場合には対応できない。これを解決するための対案もあるが、そのためには結局 MTA での対応も必要になる（MFROM は SMTP プロトコル自体の拡張、PRA は転送サーバでの Resent-From ヘッダの追加）。
なお、バウンスメール (MAIL FROM:<>) などドメインが特定できない送信者に対しては HELO/EHLO で名乗ったホスト名の TXT レコードが調べられることになる。
アドレスが詐称されていないことを確認するしくみであって、spam を検出するしくみとは言えない（フィッシングを検出するには有効性が高い）。送信元の正当性を判定するので、受信側ではなく送信側での防御手段といえるかもしれない（DKIM についても同じことがいえる）。ただし、堂々と SPF 情報を公開して「正しい」ホストから送ってくる spammer が今後あらわれないとも限らないことに注意。
これを採用している場合は、自分のメールアドレスで好き勝手なホストから送ることはできなくなる（正確には、送ること自体は可能だが、SPF のチェックにひっかかって受信を拒否されるおそれがある）。つまり、アドレスによってメールを送信するサーバを使いわける必要があるわけだが、Outbound Port 25 Blocking を採用している ISP のネットワークからではサーバを使いわけたくてもそれが不可能になる。port 25 ではなく、別のポートを用意する必要があるだろう。
なお、PRA は Microsoft の特許で、ISP や大企業が受信側として検証に用いる場合には、MS との契約が必要になる（ライセンス料は不要）。ただし、どの程度の規模をもって大企業とするのかの基準は不明。くわしくは FAQ (PDF) を参照。
Yahoo が提案したのが DomainKeys、DomainKeys と Cisco の提案していた IIM (Internet Identified Mail) という仕様と統合したのが DKIM (DomainKeys Identified Mail)。現在は DKIM の方を標準化しようと IETF で作業中。以下は DomainKeys についてだが、仕様を斜め読みしただけなので誤認があるかも（DKIM についてはまったく見てもいないし）。いちおう、DKIM のドラフトはここ。
まず、送信側でメールのヘッダやボディの内容から電子署名を生成し、それを DomainKey-Signature ヘッダに付加して送信する。受信側では DNS の TXT レコードから得られる公開鍵をもとに付加された署名を検証し、真正なものかどうかチェックする。署名という意味では S/MIME や PGP と同様のアイデアに属するが、信頼できる公証局(CA)などのしくみは不要で、より低コストに実現できる。
SPF は受信側の MTA や MUA などが DNS 上の情報をチェックできればいいので、送信側 MTA には変更はいらなかったが、DomainKeys はヘッダに署名を付加して送信する必要があるため、送信側での対応が必須になる。
「どこから送られたか」をチェックする SPF とは違って、DomainKeys は署名さえ正しければどのホストからでも送信することができる。MTA ではなく MUA で署名を付加してもたぶん問題ないはず。もっとも、その場合は秘密鍵をどうするのかという問題があるが。また、SPF はドメインにつきポリシーをひとつしか設定できないが、DomainKeys は署名といっしょに付加されるパラメータで DNS のどのサブドメインを参照するかを変更できる。なので、このパラメータをいじることで同じドメインで異なるポリシーで署名することもできるし、その気になればユーザごとに異なるポリシーを設定する、つまり送信「ドメイン」認証ではなく送信「者」認証にすることも、理屈の上では可能である。
電子署名を用いるため第三者によるメッセージの改竄も検出することができるが、これはメーリングリストなどで Subject が変更された場合（ほげ → [test-ml:123] ほげ）にも改竄とみなされて検証に失敗してしまうということである。今後の議論の中で改善されていくものと期待される。
MTA が HELO/EHLO で名乗る名前とその名前を使う IP アドレスの情報をあらかじめ DNS に登録しておき、受信側はそれを DNS から参照して実際に接続してきた IP アドレスと比較して可否を判断する。考え方としては SenderID とよく似ているが、SenderID が送信元メールアドレス (envelope/header from) のドメインを検査するのに対して CSV では HELO/EHLO で名乗るホスト名を検査対象とする。
また、認定(accreditation)サービスへの問い合わせが CSV の規格内に含まれている。自分のドメインが登録されている認定サービスの情報を DNS から参照できるようにしておき、受信側で認定サービスに問い合わせてこれを検証する。
このように、CSV では HELO と認定サービスの検証結果の2本立てで送信者を検査するしくみになっている。途中で中継サーバが入ったりする場合には HELO で名乗る名前が最初の送信元のものとは異なってしまうので対応できないという問題がある（もしかしたら中継サーバで CSV のチェックをおこなうことにより認証を連鎖させることを意図しているのかもしれないが、中継ホストが CSV の認証をおこなったかどうかを受信側で知ることができないのでうまくいかないだろう）。
雑多な話題。
数千、数万人の登録者がいる ML やメルマガが配送をはじめると、DNS を利用したアクセス制御をしている各地の MTA から大量の問い合わせが DNS サーバにやってくる。自分の MTA からの問い合わせが1回だけであっても、それを数千、数万のサイトが同じことを同時にやると相当の負荷になる。DNS サーバの能力が低いと、配送先の MTA からの DNS 問い合わせを処理しきれなくなって DDoS 状態に陥いることがありうる。
DNS の問い合わせが大量にやってくるのは ML やメルマガばかりではない。spammer が送信者を詐称したメールを大量に送信すると、騙られたドメインの DNS に問い合わせを送ることになる。大規模な ML やメルマガを運営しているところならば DNS も相応の能力のものを用意しているだろうが、小規模サイトではそのような備えがないところも多いだろう。backscatter を送らなくても、その DNS 問い合わせだけでも小規模サイトには致命的な負荷になることがありうるのだ。もちろん、バウンスしてしまうと状況はさらに悪化する。
DNSBL はもともとそういった利用を前提に構築されているサービスなので、上記のような考慮はそれほど必要ない。ただし、1日あたりの問い合わせ回数に制限を設けている DNSBL もあるので、一定の配慮は必要である。
また、問い合わせ先の DNS やそこまでの経路に何らかの障害が発生するなどして、期待した応答が得られないことがあることに留意すること。DNS キャッシュへの嘘情報の注入（ポイゾニング）にも注意が必要である。SMTP というプロトコルは、送信側では MX や A の検索が必要だが、受信側では DNS 検索は必ずしも必要としないように作られている。必要ないものを使うということは、その分障害が発生する可能性のあるポイントを増やしていることになる。DNS に大きく依存してしまうと、DNS の障害は判定結果の信頼性を大きく低下させることになる。たとえば、2005年10月の APNIC の障害では、逆引きがないホストからのメールを拒否する設定になっているサーバへのメールが大量に不達になった。DNS が単一障害点にならないような配慮は必要だろう。
DNS への問い合わせを使う手法はすべて禁じ手であるとまで言うつもりはないが、外部への DNS 問い合わせをできるだけ控えることができるのならばそれに越したことはない。ブラックリスト/ホワイトリストに載せたり、ローカルにキャッシュ DNS を置くなどした方がいいだろう。自分の満足のために、よそのサーバに迷惑をかけないようにするべきである。こちらも参照のこと。
とはいえ、SenderID や SPF、DomainKeys のように DNS 問い合わせを積極的に利用する仕組みも出てきているので、この考えかたはもう古いのかもしれない。
DNS の設定がマズい、あるいは DNS サーバが落ちているなどの理由で、問い合わせに対して応答が返ってくるまでに長い時間がかかることがある。この間は SMTP トランザクションが停止するので tarpitting をおこなっているのと同様のことが起きてしまうので注意すること。
RFC2505 #1.4IDENT あるいは AUTH (113/tcp) と呼ばれるプロトコル(RFC1413)を使うと、誰が送信してきたのかを知ることができる（かもしれない）。この「誰」とは IP アドレスのようなネットワーク情報ではなく、接続元ホストのユーザ名という、文字どおりの「誰」である。IDENT は単独で用いられることは（たぶん）なく、SMTP や FTP などの補助として使われる。Web の Common Log Format（Apache なんかのアクセスログ形式）で第2フィールドが "-" 以外になっているログを見たことある人はほとんどいないと思うが、このフィールドは実は IDENT で得られるユーザ名が納まるべき場所だったりなんかする。
結論からいうと、IDENT ルックアップは今や意味がないから止めておこう。IDENT が動いているホストなんて現在はまず存在していない。仮に動いていて情報を得られたとしても、それは認証やアクセス制御に利用できるような確かなものではなく、あくまで参考にしかならない。むしろ、IDENT がフィルタされているホストに問い合わせてしまうと、タイムアウトするまで SMTP セッションが停止してしまって害悪にしかならない。
しかし、こちらからの IDENT 問い合わせをやめても、よそから IDENT が飛んでくることがある。この場合には、フィルタリングする（応答を返さない）のはタイムアウトして以下略なのでよろしくない。113/tcp へのアクセスを拒否する（TCP RST を返す）ようにするのが正しい対処である。
低位の MX サーバ。
プライマリ MX にちゃんとアクセスできるのに、MX の優先度を無視していきなりセカンダリ MX に送信してくる spammer/worm が存在する。手抜き実装なのか意図的なものなのかは不明。#2.13.1
典型的なセカンダリサーバはメールを単純にプライマリにリレーするだけだが、この場合、プライマリ側から見た接続元 IP アドレスはセカンダリのものになってしまうので、プライマリで静的ブラックリストや DNSBL を使って IP アドレスの制限をしていても、セカンダリからリレーされてきたメールはリストの制限が効かない。
また、プライマリとセカンダリでアカウント情報の同期をするのは場合によってはけっこうな手間になるため、セカンダリは受け取るべきドメインのリストだけ持たせて、ローカルアカウントのリストまでは持たせないことが多い。そうするとセカンダリがリレーしたメールをプライマリが不在アカウントとして受け取り拒否することがあり、それをセカンダリがバウンスしてしまうと backscatter の発生源になってしまう。セカンダリから中継されきた spam は拒否するのではなく、受け取ってから捨てるように設定すべきである。なお、.forward などによって転送されたメールについても同様の問題があるので、これもやはり可能なかぎり backscatter を生じさせないようにしたほうがよい。
というわけで、セカンダリサーバは本来めったに使われない存在ではあるが、手を抜かずに可能なかぎりプライマリサーバと同じアクセス制限設定をすることが望ましい。
逆にセカンダリ MX を積極的に利用して spam を排除するアイデアもある。プライマリ MX にアクセスできないときはセカンダリ MX を試さなければならないのだが、spamware の中にはこれをせずに送信を諦めてしまうものがあるらしい。つまり、プライマリ MX として DNS に登録するホストは MTA の動いていないダミーとし、セカンダリ MX の方を本物の MX とすることで、低位の MX に再試行しないクライアントを蹴ることができるようだ。ただし、これをしない製品も存在するようで、実際の設定は慎重におこなうべきだろう。また、セカンダリ MX を活用して大量の backscatter を通常のメールと別サーバで処理させる案(PDF)もある。
メーリングリストでは、送信者の制限（無制限、登録メンバーのみ、管理者のみ、モデレータのみなど）やチャレンジ & レスポンスによる認証など特有の制限がおこなわれることがある。これは MTA ではなく、ML 管理ツールでの対処になるので、詳細についてはそれぞれのドキュメントを参照してほしい。
ML マネージャによっては設定に注意が必要なものがある。たとえば majordomo では、ml@example.com という ML に対して以下のようなエイリアスを設定することになる（抜粋）。
# majordomo の起動コマンド ml: "|/usr/local/majordomo/wrapper resend -l ml -h example.com ml-outgoing" # ML メンバーを記述したファイル ml-outgoing: :include:/usr/local/majordomo/lists/ml
ML は ml@example.com なので、一般のメンバーはこのアドレスに投稿するのだが、それ以外に ml-outgoing というアドレスもエイリアス登録されているのが落し穴だ。このアドレスに送られたメールは :include: によって、ML メンバーのアドレスに展開されるので、仮に ml@example.com がメンバー以外からの投稿を受け付けないようにしてあったとしても、ml-outgoing@example.com に直接送られてしまうと、その制限が効かずに誰からでも ML メンバー全員に配送できしまう。また、ML メンバーリストの取り寄せに制限がされていたとしても、EXPN が有効になっていると、SMTP トランザクション中に EXPN ml-outgoing@example.com というコマンドを送ると ml-outgoing の宛先がすべて取得できてしまう。このように、ml-outgoing というエイリアスは spam 送信者やアドレス収集ツールにとっては格好のエサになる。そのため、
ように設定するべきだろう。
ML 管理者ではなく、参加者の立場としては、メーリングリスト経由で届く spam の対処が困りものだろう。SMTP トランザクション中に得られる情報のほとんどすべてが、発信元 spammer のものではなく ML マネージャに書き換えられてしまっているので、これらの情報をもとに spam かどうか判定する手法はすべて回避されてしまう。判定するとなるとヘッダと本文をもとにした手法になる（これらの情報も一部書き換えられることがある）。
しかし、ML の場合はむしろ spam チェックが回避されしまった方がいいだろう。配送エラーが何回か連続するとその宛先を自動で退会処理してしまう ML マネージャも存在するし、そうでなくてもエラー通知が飛んで ML 管理者の負担になる（ML 管理者へのエラー通知は、spam がウザいんじゃ、という無言の抗議にはならない。ML のポリシーもあるだろうし、エラー通知しなくても ML 本体に流れるメールでウザいのは認識できる）。なので、ML 経由の spam は、SMTP の段階での受信拒否ではなく、いったん受け取った後で黙って捨てるというのがセオリーだ。可能なかぎりホワイトリストに入れておこう。
reputation は評判、accreditation は認定のこと。IP アドレスや送信者ドメインが「信用できるかどうか」という評判、「信用しても大丈夫」という認定を問い合わせることによって spam かどうかを判断するもの。DNSBL や CSV など、セカンドオピニオン（主治医以外の医師の意見を参考にすること）を求める方式の総称といってもいいかもしれない。
accreditation DB で有名なものに Bonded Sender Program (PDF) がある。メールを送信する事業者は供託金を払って Bonded Sender の accreditation DB に載せてもらうことができる。受信側はそれを参照すれば、spam でないと安心して受信することができる。もしこの事業者が spam が送れば、供託金は没収されて DB からも削除される。メールを受ける側は spam でないことを確認できる、事業者は適正であるとしてホワイトリストに載せてもらえる、（運営元の IronPort は供託金で儲けられる）という「みんなハッピー」しくみということになっている。実体はただのホワイトリスト DNSBL のようである（多くの MTA はホワイトリストの DNSBL に対応していないので特別な対応が必要）。
ほかに、CLOUDMARK、TrustedSource などが reputation サービスを開始している。
なお、reputation/accreditation DB には、届いたメールに含まれる情報の一部をこちらから送信するわけであるが、これは逆に言えば、DB の参照元ホストと、そのホストにどんなメールを送られてきたのかの情報が DB の運用元で入手できるということである。送信される情報はたいてい極めて限定的なものであるが、それでもそのサイトのユーザがどこのサイトと多くメールのやりとりをしているかという情報ぐらいはわりと簡単に収集できるだろう。ややパラノイア気味になるが、情報漏洩やプライバシーの問題に敏感ならば採用に際して考慮はした方がいいかもしれない。
郵便には切手が必要だが、電子メールにはない。そこで、メールでも送信側が「切手」を貼ってコストを負担しよう、というアイデア。micro payment scheme あるいは ePostage と呼ばれる。この「コスト」とは実際の金銭である場合もあるし、仮想的な切手、すなわち計算問題を解くという計算機負荷の場合もある。いずれにしても、コスト負担がネックになって大量のメール送信はできなくなるという理屈。
しかし、リアルマネーの場合はどうやって授受するかという問題があるし、計算機資源を負担させる場合でもマシンパワーで強引に押し切れてしまう。実際、コストをかけてでも携帯電話発 spam を送る業者はいる（コスト以上の利益が出る）し、切手を使う郵便でもダイレクトメールはたくさん届いている現実からして、あまり有効な手法とはいえないだろう。An Overview of E-Postage（英文 PDF）も参照のこと。
……が、Camram や Hashcash といった実装がすでに存在していたりするし、Microsoft もまじめに研究しているようだ。国内 ISP ではぷららがアプリケーション層ではなく、政治層で実装している:-)。自動確認付きホワイトリスト。自動応答で送信元アドレスに確認メールを送り、その確認メールに返信があったら最初のメールを受け取る。以後ずっと、あるいは期限つきでそのアドレスをホワイトリストに登録して確認なしで受け取るようにする。
送信者が詐称された spam ならば騙られた第三者に確認メールが飛ぶことになるし、自動送信されたメール（通販サイトの受注確認やメルマガその他）に確認メールを送ったところで無視される方があたりまえである。人間が手で送る場合でも、いちいち確認を求められるのは手間以外の何物でもない（筆者ならこんな失礼な確認メールが飛んできたら、たぶんいちいち返信せずにそのまま放置する）。
spammer 側がわざわざこれに対策しなければ、ほぼ完全に spam を排除できるだろうが、spam 以外のメールも大量に失うという非常に大きなリスクを冒す手法である。この文書に挙げた各種手法の中でも最低最悪のものといえるだろう。この方法はメーリングリストのメンバー登録などでは使われることがあるが、そのような限られた特殊な用途以外では使わない方がいいだろう。
と、欠点は多いのだが、SpamHippo、Spam Arrest、Qurb、Maummail（日本語 PDF）と、この手法を採用している製品はなぜかいくつも存在していたりする。やめておきましょう。
Habeas 社の Sender Warranted Email (SWE)。メールヘッダに英文俳句を挿入し、そのヘッダが含まれているメールであれば受信を許可するというもの。認定サービスの一種、といっていいのかなぁ？ Habeas の Web サイトからは情報がごっそり消えているので、もうやめちゃったのかも。ヘッダの偽造は簡単で、偽造対策もされていないが、俳句なので不当に悪用したのがバレると著作権侵害(!)で告訴されてしまう。一部の spam 対策ツールではこのヘッダを発見すると馬鹿正直に非 spam 判定するようで、これを逆用して、訴訟のリスクをものともせずにヘッダ偽造して送ってくる spammer がいるようだ。
以下のような制限をかけてはならない。他の制限と組み合わせることで有効に使えるものもないではないが、どんなふうに組み合わせればいいのかわからなければやるべきではない。
送信者アドレスのドメインが自分で管理しているなどの場合は、どの IP アドレスから送信されたとしてもメールを中継したいと考えるかもしれない。
しかし、送信者アドレスの偽装は簡単である。その送信者アドレスを使って送ってきたのがそのメールアドレスの正当な持ち主とは限らない。そのような設定は不正中継を許可しているのと同じである。SMTP Auth などを導入して、正規に認証されたユーザからの送信のみに限定しなければならない。MTA に限ったことではないが、容易に詐称されうる情報を根拠にアクセスを許可してはならない（厳しくする分には問題ない）。
ホワイトリストにある名前を逆引き(PTR)に設定してアクセスされたら不正中継の踏台にされてしまう。詐称が容易なのは送信者アドレスだけではない。
接続元ネットワークによるアクセス制限をするときは、逆引きではなく IP アドレスで制限するか、あるいは単なる逆引きではなく、逆引きをさらに正引きして元の IP アドレスと一致するかどうかの検査（パラノイドチェック）をするなどの配慮が必要である。実はたいていの MTA は逆引きホスト名でアクセス制限を設定すると、特に明示しなくても勝手にパラノイドチェックしてくれることが多いのだが、かならずしもすべての MTA がそうするとはかぎらないので、実際にどう動作するかは確認する必要がある。
この文書を書いている当人による、こんなのなんてどうかなー、というアイデア。もしかしたら誰かがすでに発案して実施しているかもしれないけれど、見つからなかった。あくまで脳内妄想レベルであり、フィールドテストのようなものは一切おこなっていないし、考慮漏れの問題点もあるかもしれない。
アドレスを知られなければ、デタラメに送るものでなければ spam が送られてくることもない。MTA 自身の応答やバウンスメールの内容、Web サイトでのメールアドレスの掲載などが元で spammer にアドレスが拾われたりする。また、NetNews の記事からメールアドレスを収集する Swen というワームもあった。必要以上にメールアドレスを露出しないことも、不要なメールを減らす役に立つ。spammer にメールアドレスを収集されないためのアイデアについてはこちらも参照のこと。
MTA 自身での対策は DHA の項目を参照のこと。
Web にはメールアドレスの収集ロボット（ハーベスタと呼ばれることもある）が闊歩している。Web サイトの方で接続元 IP アドレスのチェックや、User-Agent による規制、リクエストヘッダの特徴による推測などによりアドレス収集ロボットを出入り禁止にすることで spam を減らせる。ただし、アドレス収集ロボットによる直接アクセスだけでなく、google のキャッシュからアドレスを収集された例を確認しているので必ずしも確実な方法ではない。
アーカイブが Web 上に公開されるようなメーリングリストに投稿する際は、ML 専用のアドレスを使い、そこに届いたメールは spam としてすべて捨てるなどの対策方法がある（その場合、捨てずに読んでいるアドレスを収集ロボットに見つかりにくい形式で併記しておくこと）
このメモを書くのにあたり参考にした文書、このメモにはあまり反映されていないけれど大いに参考になる文書など。