火曜日, 6月 29, 2010

DNSBLとの違いの説明を修正

 Q&Aのページで、S25R方式とDNSBLとの違いを次のように説明していた。

Q1-6. DNSBL(Domain Name System Blackhole List)との違いは何ですか?
A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。あなたのメールサーバがDNSBLに頼り切るとすれば、あなたのメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。時にDNSBLは、間違って、あるいは意図的に正当なメールサーバをリストに載せるので、あなたのメールサーバは正当なメールを失うかもしれません。
 S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。偽陽性判定はS25Rシステム管理者によってコントロールすることができるので、注意深い運用のもとではメールサーバは正当なメールを失いません。

前回述べたとおり、Q/A2-6でSpamCopの併用方法を説明したので、A1-6がDNSBLに対する否定的な評価と見えるのは違和感を起こさせると思った。
 そこで、A1-6を以下のように書き直した。DNSBLのスパム阻止率がS25R方式ほどでないことを明言するとともに、DNSBLも偽陽性対策をすれば使い物になるとわかるようにした。

A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。DNSBLに頼るメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。そのため、DNSBLのスパム阻止率はS25R方式ほど高くありません。一方、S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。ただし、間違って拒否される正当なメールサーバを許可するためのホワイトリストが必須です。
 ところで、DNSBLも、時に間違って、あるいは意図的に正当なメールサーバをリストに載せるので、偽陽性判定を起こすことがあります。正当なメールを失わないためには、DNSBLに引っかかるホストには応答コード「450」(Postfixのデフォルトの「554」ではなく)を返し、送信を再試行するホストをホワイトリスト登録するようにすべきです(ほとんどのスパムアクセスは再試行しません)。

日曜日, 6月 27, 2010

Q&AにSpamCopの併用方法を説明

 2009年4月にSpamCopの併用を設定してみたところ、かなり役に立つことがわかった。最近でも役に立っており、5月30日から6月27日までの期間にSpamCopのおかげでブロックできたスパム送信元は以下の8個であった。

eth-66.130-homell.natm.ru
dynamic.casa-217-243-12-196.wanamaroc.com
zaxnag.nline.ru
mecanica.ucv.ro
mx1.to-c.biz
shvernik.rinet.ru
krasn23b-slav.skif.com.ua
Msq1.gatchina.ru

これらはいずれも、応答コード「450」に対してリトライしなかった。
 ここまで役に立つノウハウをこのブログの読者にしか開示しないのはやはりもったいないと思ったので、Q&AのページにQ/A2-6として掲載した。

Q2-6. S25RにDNSBLを併用することは効果がありますか?
A2-6. はい。SpamCopはかなり有用であることがわかっています。私はS25RにSpamCopを併用して99.5%の阻止率を得たことがあり、その時、S25Rだけによる阻止率は99.2%でした。ただし、DNSBLは偽陽性判定を起こすかもしれないので、DNSBLに引っかかったホストには応答コード「450」を返すようにすべきです。/etc/postfix/main.cfファイルに以下の太字の行を追加してください。

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections,
  reject_rbl_client bl.spamcop.net

 拒絶ログソーティングスクリプトを使ってDNSBLによる偽陽性判定を見つけるには、スクリプトの中の

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host rejected:' | \

という行を次のように書き換えてください。

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host (rejected:|.*blocked)' | \

常連さんからのスパムが減った

 論文に記載している設定方法で、ブラックリストとしていくつかのドメインを示している。エンドユーザー回線の逆引き名が一般規則に引っかからない(または引っかからないことがある)ドメインで、論文公開当時やその後に有用だった拒否条件を掲載している。
 しかし、これらのドメインからの不正メールアクセスは、最近少なくなっている。5月30日から6月27日10:40までに不正メールを送り込もうとしたホストの数は、各ドメインについて以下のとおりである。

# pr86.internetdsl.tpnet.pl
# fq217.neoplus.adsl.tpnet.pl
# pa148.braniewo.sdi.tpnet.pl
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain check, be patient

 2個。

# user-0cetcbr.cable.mindspring.com
# user-vc8fldi.biz.mindspring.com
/^user.+\.mindspring\.com$/ 450 domain check, be patient

 なし。

# c9531ecc.virtua.com.br (hexadecimal used)
# c9066a60.static.spo.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.(.+\.)?virtua\.com\.br$/ 450 domain check, be patient

 1個。

# catv-5984bdee.catv.broadband.hu (hexadecimal used)
/\.catv\.broadband\.hu$/ 450 domain check, be patient

 なし。

# Edc3e.e.pppool.de
# BAA1408.baa.pppool.de
/[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ 450 domain check, be patient

 なし。

# pD9EB80CB.dip0.t-ipconnect.de (hexadecimal used)
/\.dip[0-9]+\.t-ipconnect\.de$/ 450 domain check, be patient

 なし。

# pD9E799A1.dip.t-dialin.net (hexadecimal used)
/\.dip\.t-dialin\.net$/ 450 domain check, be patient

 2個。

# ool-43511bdc.dyn.optonline.net (hexadecimal used)
/\.dyn\.optonline\.net$/ 450 domain check, be patient

 なし。

# rt-dkz-1699.adsl.wanadoo.nl
# c3eea5738.cable.wanadoo.nl (hexadecimal used)
/\.(adsl|cable)\.wanadoo\.nl$/ 450 domain check, be patient

 なし。

# ACBBD419.ipt.aol.com (hexadecimal used)
/\.ipt\.aol\.com$/ 450 domain check, be patient

 なし。

 これを見ると、多くのドメインでOP25Bが導入されるようになったと推測される。わずかに不正メールアクセスが来るドメインは、OP25Bの設定が完全には終わっていないか、スタティックIPアドレスなのでOP25Bの対象外かのどちらかだろう。
 ここに至っては、不正メールアクセスがまったく来なくなったドメインはブラックリストの実例から除外してもよいだろう。ただ、ブラックリストの実例は、正規表現に慣れていない人が真似る手本として役立っていると思うので、どうするかはもうしばらく考えたい。
 一方、エンドユーザー回線の逆引き名が一般規則に引っかかるドメインで、10個以上のホストから不正メールアクセスがあったものは以下のとおりである。1個のホストを代表させて示す。

1-89-112-92.pool.ukrtel.net

 60個。

111-240-240-32.dynamic.hinet.net

 45個。

host115-93-dynamic.59-82-r.retail.telecomitalia.it

 13個。

200-204-159-61.dsl.telesp.net.br

 10個。

adsl-104-22-192-81.adsl.iam.net.ma

 10個。

 ウクライナのvolia.netは、一般規則に引っかからない多くのホストから不正メールアクセスを出している。ホストは10個あった。

beachless-vim.volia.net
coping.linoleum.volia.net
designsless.bellows.volia.net
exampleless-gear.volia.net
inclined-slope.volia.net
loom.roll.volia.net
pat.descender.volia.net
revering-excursion.volia.net
tangential-design.volia.net
vested-ramparts.volia.net

私は、2007年7月からvolia.net全体をブラックリスト入りさせている。これは今なおはずせないようである。

/\.volia\.net$/ 450 domain check, be patient

日曜日, 6月 20, 2010

いたずら

 gabacho-net.jpドメインのSPFレコードが設定されているかどうかを調べようとした人へのメッセージをDNSに設定した。

$TTL 86400
$ORIGIN gabacho-net.jp.

gabacho-net.jp. IN TXT "v=spf1 +ip4:116.58.188.194 ~all"
 IN TXT "But don't you know that SPF is useless for fighting spam?"

 インターネットに直結されたWindows PCでは、コマンドプロンプトを開いて次のように入力すれば見ることができる。

nslookup -q=txt gabacho-net.jp

(この記事へ直接来られた方は、以下の記事もご覧ください。)
送信ドメイン認証はスパムに勝てないだろう
スパマー様御用達・送信ドメイン貸し出しサービスはいかが?
ドメインレピュテーションで何するの?

土曜日, 6月 19, 2010

ドメインレピュテーションで何するの?

 送信ドメイン認証が普及してもスパム問題は解決しない。なぜなら、スパマーは認証をパスするドメインを使うコストを低減させると考えられるからである。これに対しては、「送信ドメイン認証によってドメインの詐称が不可能になれば、ドメインレピュテーション(信用度評価)が使えるようになるのだ」という反論があるだろう。
 ドメインレピュテーションはドメインの信用度をどう評価するか。当然、著名な正当なドメインは信用できると評価し、スパマーのドメインは信用できないと評価するだろう。できたばかりのドメインや、メール送信の実績の少ない無名のサイトは、まだ信用できるとも信用できないともどちらとも言えないという中間の水準として評価するだろう。
 スパマーがドメインレピュテーションに対抗するにはどうするか。スパムを最初に送信する時は、スパマーのドメインの信用度は中間水準だろう。スパムをまいたことがばれれば、信用度が急落する。それによってスパムの送達率がある程度下がったところで、そのドメインを捨ててしまい、新しいドメインを使う。それで信用度は中間水準に回復できる。つまり、スパマーは自分のドメインの信用度をほぼいつも中間水準に維持できるということである。
 このようなドメインレピュテーションをスパム判定に使うと、無名のドメインからの正当なメールとスパムとで、スパムかもしれない度合は同じくらいと評価されることになる。だから、スパムが無名のドメインからの正当なメールといっしょにスパム判定されずにメールボックスに入るか、無名のドメインからの正当なメールがスパムといっしょに隔離フォルダに入るかのどちらかになる可能性が高い。こんなシステムが役に立つだろうか。
 信用度が中間水準以下ならばグレイリスティングにかけるという方法はどうか。これは実用的かもしれないが、「初めてアクセスして来るホストは信用しないが、再送して来たら信用する」という本来のグレイリスティングに比べて何が優れているのだろうか。無名のサイトからのメールを最初に一時拒否することには変わりはない。それに、「アクセス元の逆引き名がエンドユーザーコンピュータっぽいならば最初のアクセスを信用しないが、そうでないかまたは再送して来たら信用する」というS25R方式に比べて何が優れているのかもわからない。S25R方式は、無名のサイトであってもサーバらしい逆引き名のホストは初めから信用するし、一方、送信ドメインが信用できるものかどうかにかかわらず、ボットからの送信はほとんど止めることができる。結局、一時拒否応答を返すグレイリスティングやS25R方式を使うなら、ドメインレピュテーションなど無用の長物なのである。
 SPFにしろDKIMにしろ、認証をパスしなかったメールをどう扱うかは決めていない。それがベースとなって利用可能になるとされるドメインレピュテーションにしても、信用度に基づいてメールをどう扱うかは決めていない。ユーザー(すなわちメールシステム管理者)任せになっている。こんなシステムを組み合わせて有効なスパム対策になるのだろうか。Postfixのオペレーションがどうにかできるくらいの人や、稼ぐ仕事の片手間でしかメールサーバのお守りができない人もいるのである。メールシステムの“偉い人”たちはいったい何を考えているのか。私のような“偉くない人”にとって使いやすく、スパムの排除に効果が高いものでなければ使ってもらえるはずがない。大手ISPのIIJがSPF/Sender IDを実装したメールフィルタプログラムをオープンソースとして無償公開しているが、スパムの排除に大して効果のないシステムを無償で提供したところで、普及に弾みが付くとは思えない。
 S25R方式は、送信元をエンドユーザーコンピュータと推定するための、あいまいさのない単純な条件を提供し、その条件に引っかかるホストには一時拒否応答を返すと明確に示し、誤判定から救済する方法も示している。これ単独で97~99%のスパムを排除できる完成されたシステムである。Postfixならばサブシステムなしに実装できるので、技術力の高くないメールシステム管理者でも容易に導入できる。運用が簡単なので、運用に必要な人的コストも低い。だから多くのサイトで採用された。使ってもらえるシステムにしようと思ったら、ここまで考えなければいけない。

金曜日, 6月 18, 2010

「危険はない」と言うには勇気が要る

 前回、LZH書庫ファイルの脆弱性問題が騒ぎになっていることを述べた。作者が「危険だ」と言っているから危険に違いないと思っていっしょになって「危険だ、危険だ」と騒ぎ立てることはたやすい。もし、LZHのヘッダ処理の脆弱性を突くファイルがウィルス対策ソフトの検疫をすり抜けたためにウィルス感染事故が本当に起こったら、「危険だ」と言っていた人の正しさが証明されることになる。一方、ウィルス感染事故が起こらなくても、「危険だ」と言っていたことが誤りだということにはならない。だから、どちらにしても、「危険だ」と言っている人には、後になって誤りを責められるリスクはない。
 しかし、私は騒ぎに逆らって「危険はない」と言った。これは勇気の要ることである。もしウィルス感染事故が起こったら、私の誤りが証明されることになる。私は、言ったことの誤りを後で責められるリスクを背負っているのである。
 そんなリスクを背負ってまでなぜあえて「危険はない」と公言したか。情報セキュリティに詳しくない人が必要以上に危険を恐れるあまり、LZH書庫という優れた成果によってもたらされる利益を失ってほしくないと思ったからである。みんながスパム問題から解放されてほしいと願ってS25R方式を発表したのと同じ気持ちからの行動である。
 「危険はない」と公言したことは、会社で判断を迫られたことの成果である。「危険だから社内ではLZH書庫の利用を禁止する」と決めるのはたやすい。しかし、LZH書庫として提供されている、業務に役立つソフトウェアの入手を禁止することによる不利益をどうするか。それは社の情報セキュリティのために本当に甘受しなければならないことなのか。私は、考えに考えた末、「ウィルスを警戒する通常の注意を守っていればよい」と結論付けて、LZH書庫がもたらす利益を守った。
 「危険はない」と言ったことにもし間違いがあれば、このブログでも社内でも批判を受ける可能性がある。しかし、今のところ批判はない。

 もう一つ、私が会社で「危険はない」と判断した事例を紹介する。
 私の会社では、ウィルス対策ソフトでのフルスキャンを少なくとも週に1回実行するように決めていた。フルスキャンでは、メモリのスキャン、ブートセクタのスキャン、全ファイルのスキャンが行われる。全ファイルのスキャンは何時間もかかり、CPU使用率が上がって仕事にならないことがある。
 私は、全ファイルの定期的なスキャンは本当に必須かを考えた。ワクチンが間に合わずにウィルスファイルがディスクに入り込むことはある。しかし、定期的に全ファイルのスキャンをしなくても、リアルタイムの検知を有効にしておけば、ワクチンができた後にウィルスが活動しようとした時には必ず検知される(このことはベンダーに問い合わせて確認した)。ワクチンが間に合わなければ検知されないが、そうであればどのみち全ファイルのスキャンでも検知されない。つまり、全ファイルのスキャンをしなくてもウィルス発病のリスクは上がらないのである。全ファイルのスキャンをしないためにウィルスファイルがディスクに残存し続けるのは危険だと思うのは、感覚的なものにすぎず、論理的な根拠はない(リアルタイムの検知を必ず有効にしている限り)。
 このように検討して、「全ファイルのスキャンを行わないように設定してもよい」とルールを改定した。
 セキュリティを心配する社員に不安を与えないように、危険はないということを筋道を立てて説明した。この判断も勇気の要ることだった。これにより、社員は、全ファイルのスキャンで仕事にならないという不利益から解放された。

土曜日, 6月 12, 2010

LZHの脆弱性問題は騒ぎすぎだと思う

 今回はスパム対策ではなくソフトウェアの脆弱性問題の話。
 LZH書庫ファイルシステムの作者Miccoさんの「お知らせ」(2010年6月5日公開)、「LZH書庫のヘッダー処理における脆弱性について (2010 年版)」(2010年4月25日公開)、および6月2日の日記が震源地となって、LZHの脆弱性問題についての情報が駆け巡っている。

圧縮・解凍用DLL「UNLHA32.DLL」が開発中止、作者はLZHの利用中止を呼びかけ(窓の杜)
「LZH」アーカイバの開発を中止、JVNへ脆弱性報告では「不受理」(ScanNetSecurity)
「LZH」の開発中止--企業などは使用しないよう作者が注意喚起(ZDNet Japan)
UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける(スラッシュドット・ジャパン)

以上は企業サイトの情報だけをピックアップしたもの。ほかに、個人のブログでもたくさん取り上げられている。
 問題を要約するとこうである。2006年にLZH書庫ファイルのヘッダ処理の脆弱性が発見された。ファイル圧縮・解凍ソフトのほとんどは対処したが、ウィルス対策ソフトの多くは未だにこの脆弱性問題に対応していない。そのため、この脆弱性を突く不正なファイルを検疫できずに見逃してしまう。特に、ゲートウェイ方式によるウィルス対策をとっていてクライアントにウィルス対策ソフトをインストールしていない組織では、ウィルスが容易に侵入してしまう。この問題は4月下旬にJVNに報告したが、不受理。JVNはzip、rar、cab、gzip、7Zip形式の同じ問題についてはJVNVU#545953として公開しているのに、LZH形式についての問題が受理されないのは、「(世界的に見ればマイナーな)LZH書庫なんて知らねえよ」という態度としか考えられない。Miccoさんは、「脆弱性が存在しても放っておかれるような書庫がいつまでも業務目的で利用されるのは嫌ですので」と、UNLHA32.DLL、UNARJ32.DLL、LHMeltの開発中止を決断し、LZH書庫の利用中止を呼びかけた。
 しかし、ここで疑問なのだが、アプリケーションの脆弱性を突く不正ファイルを、その検体が捕獲される前からウィルス対策ソフトが一網打尽に検疫することは、そもそも非常に困難なのではないか。LZH書庫ファイルのヘッダ処理の脆弱性を突く不正ファイルなら、ヘッダ部分をLZH書庫の仕様からはずれたビットパターンにしているだろうが、どういうビットパターンかは事前には特定できない。だから、不正ファイルの検体を捕獲する前に不正ファイルを検疫することは、必ずしもできなくて当然である。これは、未知のウィルスを検疫しきれないのと同じである。もちろん、検体が捕獲されたらワクチンを作ることができて、その後は不正ファイルを検疫することができる。
 それに、不正な書庫ファイルをウィルス対策ソフトが検疫できなかったとしても、ファイル解凍ソフトが脆弱性問題に対処済みであれば、ヘッダが不正であることを検知して復元をやめるはずだから、危険はない。よしんばそれでウィルスが復元されたとしても、それが既知のウィルスであれば、そのウィルスファイルがアクセスされた時にウィルス対策ソフトが検知するから、危険はない。未知のウィルスであれば危険だが、ワクチンが間に合わなければ検疫できないのは、そもそも仕方のないことである。
 結局のところ、Miccoさんの主張は、「LZH書庫のヘッダ処理の脆弱性を突く不正ファイルを、その検体が捕獲されてワクチンが作られる前に検疫できないのは、ウィルス対策ソフトの脆弱性である」というものだと私は受け取った。それに対する私の考えは、「不正ファイルの検体が捕獲される前に必ずしも検疫できないのは、通常のウィルスと同じことであり、これはウィルス対策ソフトの脆弱性ではない」というものである。ゲートウェイ方式のウィルス対策だけを行っている組織では特に危険だと言うが、クライアントにウィルス対策ソフトをインストールしないのがそもそもセキュリティ対策として間違っている。zipなどについては問題がJVNVU#545953として受理されているのにLZHについては受理されないのはおかしいという指摘については、JVNがJVNVU#545953を出したのが間違いだったと思う。
 私の会社でも、情報を知った社員から問い合わせがあった。この問題についての社としての対応方針を決めるために私が見解を求められた。私は、

●ウィルス対策ソフトを正しく使う。
●ファイル解凍ソフトは脆弱性に対処済みの版を使う。
●信頼できるサイト以外からファイルをダウンロードしない。
●不審なメールに添付されたファイルを開かない。

という通常の注意を守っていればほぼ危険はないと答申した。これについては、私の会社が属する企業グループのCERT(Computer Emergency Response Team)に相談し、妥当な判断であるとの回答を得ている。

土曜日, 6月 05, 2010

スパマー様御用達・送信ドメイン貸し出しサービスはいかが?

 前回、「送信ドメイン認証はスパムに勝てないだろう」と述べた。送信ドメイン認証をちゃんと理解している人には、「送信ドメイン認証はなりすまし対策であって、スパム対策ではないのは当然」とせせら笑われたかもしれない。私は、SPFがスパマーに欺かれることは知っていたが、公開鍵暗号方式を使ったDKIMさえスパマーは欺くことができると最近気付いた。それでようやく、送信ドメイン認証が普及してもスパムに勝つ展望はないとわかったのである。
 確かに、他サイトのドメインをかたることはできなくなるが、それならスパマーは、詐称でない自分のドメイン名を使ってスパムをばらまくだけのことである。実際、そのようなスパマーはすでにいる。5月15日「フィッシング詐欺のスパムを送信者アドレスで蹴る」で、以下を送信者アドレスとするスパムが着信したことを述べた。

2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com

数字だけから成るいくつものサイトドメイン名は、真っ当な他サイトのドメインをかたったものではなく、スパム送信のために取得したものに違いない。そして、これらのドメインにはちゃんとDNSのAレコードが対応している。だから、reject_unknown_sender_domain指定でブロックされることもなかったのである。
 ドメインを取得してDNSを設定するのにコストがかかることがスパムに対する抑止力になると思う人がいるかもしれない。しかし敵は、スパム用の送信ドメインを用意する仕事を分業化することによって、コストの問題も早晩克服してしまうだろう。スパム用送信ドメイン専門業者は、いくつものドメインを取得して、DNSでMXレコードまたはAレコードを対応させるばかりでなく、SPFとDKIMも設定する。これをスパマーに貸し出すのである。
 数字ばかりのサイトドメイン名を信用しないようにしようって?それはもちろん浅はかである。221616.com(株式会社ガリバーインターナショナル)のような真っ当なドメインを疑うという副作用をもたらす。それに、単語を適当に組み合わせたlionspacefoods.comのような、一見して怪しいとわからないドメイン名はいくらでも作れる。mastercardsupport.comのような、著名な会社の関連会社と思わせるようなドメイン名は、高く売れるだろう。
 ドメインの詐称ができなくなるのだから、スパマーの送信ドメインをブラックリストに登録すればよいって?もちろんそれも浅はかである。いたちごっこになるのは前回述べたとおり。
 スパム用ドメイン専門業者が使うDNSサーバのIPアドレスのブラックリストを作る?そうしたら、敵は、クラウドコンピューティングサービスを使うなどしてDNSサーバを転々とするだろう。
 スパム対策のためには送信ドメイン認証の普及が必要だと喧伝されているが、いずれ、送信ドメイン認証は受信側のスパム対策として役に立たないことがわかってみんな失望するだろう。普及前にそのことが広く知れ渡って、結局普及しないのではないかと思う。
 「スパムのほとんどは送信者アドレスを詐称しているから、詐称させないようにしよう」という発想で本当にスパマーが手も足も出せなくなるかどうかを検証していないのが間違いなのである。「スパムのほとんどはボットから送信されているから、ボットからの送信を阻止しよう」という発想こそがスパマーの手足をもぐことができる。その発想に基づく送信側対策がOP25Bであり、受信側対策の一つがS25R方式である。OP25Bは国内からのスパム発信を抑え込むのに成功している。そしてS25R方式は、完成以来6年にわたって阻止率97~99%という効果が衰えていないことが実証されている。
 私は、SPFレコードの宣言は簡単なので対応している。しかし、DKIMは面倒なので、Postfixのデフォルトインストールで対応できるくらいにならない限り、対応するつもりはない。送信ドメイン認証に対応しなければメールを受け取ってもらえなくなる時が来ると言う人がいるが、そうはならないだろう。正当なメールを受け取り拒否すれば、そのメールを待っていた人が困ることになるからである。そして私は、将来ともスパム判定のために送信ドメイン認証を取り入れるつもりはまったくない。S25R方式のおかげで、スパムにはまったく困っていないからである。
 S25R方式を導入した皆さんも、スパム対策のためにこれ以上何もする必要はないと思っておられるだろう。SPFレコードの設定はコストなしにできるからやってもよいが、それ以上のことは、格別関心を持つ人だけが好きにやればよい。送信ドメイン認証だ、いけいけどんどんと笛太鼓が鳴っても踊る必要はない。送信ドメイン認証を勉強して対応する時間とお金があるなら、他の生産的なことに使った方がよい。

続編:ドメインレピュテーションで何するの?