金曜日, 11月 07, 2014

拒絶ログソーティングスクリプトの新バージョンを少し修正

 拒絶ログソーティングスクリプトの新バージョンを10月27日に公開したが(こちらの記事)、全面的に変更していたegrepの式を少し修正した。

egrep 'reject: RCPT from [^ ]+ 4[0-9][0-9] ' | \

egrep 'reject: RCPT from [^]]+\]: 4[0-9][0-9] ' | \

 入力されるログ行の実例は次のとおり。

Nov  6 13:55:31 a postfix/smtpd[32141]: NOQUEUE: reject: RCPT from websmtp.sohu.com[61.135.130.240]: 450 4.7.1 Service unavailable; Client host [61.135.130.240] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?61.135.130.240; from=<***@sohu.com> to=<***@gabacho-net.jp> proto=ESMTP helo=<websmtp.sohu.com>

(「websmtp.sohu.com」と「[61.135.130.240]」の間にスペースがない)

だから、修正前の式でも問題ないのだが、もしPostfixのログフォーマットがクライアントホスト名とそのIPアドレスとの間にスペースを挟むように変更されたらと考えて(多分ないと思うが)、そうなった場合に誤動作しないようにした。
 実は、「from 」の後のスペースを探す代わりに「:」を探すようにしようと一度考えたのだが、おっと危ない。IPアドレスがIPv6の表記形式だったら誤動作してしまう。なので、「]:」を探すようにした。

木曜日, 11月 06, 2014

DNSBLとしてbarracudaを使う推奨

 すっかりブログをサボっていた頃に、掲示板のゲストのもっちーさんから、SpamCopは偽陽性判定が多いからbarracudaを使うようにしたとの投稿をいただいた。
 確かにSpamCopによる偽陽性判定は私も経験しているが、さほど多くはないし、maps_rbl_reject_code=450を設定しているので受信に失敗したことはない。ただ、組織サイトではSpamCopの偽陽性判定が問題になるかもしれないので、もっちーさんが投稿してくださった設定方法の情報を紹介する。

他の方への参考用に linux postfix 環境用
参考サイト
http://stdman.blogspot.jp/2009/11/brbl.html

resolv.confに書いてあるDNSの登録が必要です。
resolv.confの記載がローカルIP等になっている場合はDNSの管理者に実際に上位に問い合わせるグローバルIPを聞いて登録する必要があります。(推奨)

面倒なときはgoogle dns(8.8.8.8)を使えば(resolv.confに書けば他のは削除)既に登録(恐らくいろいろな人が登録を実行している)されているので登録する必要がないです。(非推奨ですが^^;)

host 2.0.0.127.b.barracudacentral.org
こちらのテストは必須かと思います。
2.0.0.127.b.barracudacentral.org has address 127.0.0.2
が戻ってくればOK

main.cfのrblの記載は
reject_rbl_client b.barracudacentral.org
こうなります。

引っかかった場合のコードは私の場合は451を返すようにしています。(再送してもらえるように)

火曜日, 11月 04, 2014

今時未承諾広告メールとは

 10月に、*****DENTAL(一部伏せ字)という、国内の(ウェブを見る限りは)真っ当そうな歯科医療用品販売事業者からの未承諾広告メールが3通来た。送信元ホストは次のとおり。

b.ss35.on9mail.com [209.144.27.52] (1通目)
c.ss38.on9mail.com [209.144.21.149] (2通目、3通目)

 宛先は私の個人アドレス。whoisに載っているが、自分のウェブサイトで公表してはいない。連絡先として公表しているアドレスは「webmaster」である。あえてスパムと書かずに未承諾広告メールと書いたのは、送信者アドレスを偽った卑劣なスパムとは違うと思ったからだが、送信者は合法のつもりでも違法な「特定電子メール」(自己又は他人の営業につき広告又は宣伝を行うための手段として送信をする電子メール)である。
 慇懃かつ脅しを効かせたメールを送った。

*****DENTAL様

 貴社を差出人アドレスとする未承諾広告メールをこれまでに3通、on9mail.comドメインのサーバーから受信しています。もし貴社がon9mail.comに送信を委託されたものであれば、私への送信は「特定電子メールの送信の適正化等に関する法律」第三条に違反します。私は、本条に挙げられた、事業者が広告メールを送信してよい受信者のどの条件にも当てはまりません。
 なお、メールに書いてあったunsubscribeのためのURLは、利用するとアドレスが他の迷惑メール送信者に転売される懸念が払拭できないため、利用しておりません。
 送信の停止をお願いいたします。(私のメールサーバーで受信拒否の設定準備が完了しておりますが、まだ設定してはおりません。)

 詫び状が来た。それによれば、インターネットで集めた私のアドレスを歯科医療関係者だと勘違いしたとのことだが、ほんとかいな。私の知らない人で、私に初めてメールを送ってくる時に私の個人アドレスに宛てるのは、私の所有ドメインに関する用件のためにwhoisでアドレスを知った人だけのはずで、さもなければスパマーしかいない。
 on9mail.comとはどういうサービスなのかよくわからない。「未承諾広告メールの送信請け負います」の事業者なんだろうか。名前の意味もよくわからん。「on9」というのは広東語で「馬鹿」というスラングらしいのだが。

 参考までに、「特定電子メールの送信の適正化に関する法律」第三条の条文は次のとおり。

第三条 送信者は、次に掲げる者以外の者に対し、特定電子メールの送信をしてはならない。
一 あらかじめ、特定電子メールの送信をするように求める旨又は送信をすることに同意する旨を送信者又は送信委託者(電子メールの送信を委託した者(営利を目的とする団体及び営業を営む場合における個人に限る。)をいう。以下同じ。)に対し通知した者
二 前号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを送信者又は送信委託者に対し通知した者
三 前二号に掲げるもののほか、当該特定電子メールを手段とする広告又は宣伝に係る営業を営む者と取引関係にある者
四 前三号に掲げるもののほか、総務省令・内閣府令で定めるところにより自己の電子メールアドレスを公表している団体又は個人(個人にあっては、営業を営む者に限る。)

月曜日, 11月 03, 2014

一日中拒絶記録がなかった日

 昨日2014年11月2日には、メールログにrejectが一件も記録されなかった。最近、OP25Bが多数のISPに広まったのと、私へのスパム送信を多くのスパマーがあきらめたせいか(2006年9月28日「拒絶の効果?」)、スパムアクセスが減ってきたなあとは感じていたのだが、rejectが一日中一件も記録されなかった日は、2003年5月にS25R方式の開発を開始して以来初めてのことである。
 こんなことがあると、メールサーバに異常が起こったのではないかと心配になってしまう。でも、メールマガジンなどはちゃんと着信しているし、今日11月3日にはrejectが2件記録されたので、安心した。
 インターネットの世界全体でスパムが減ったのだろうか。でも、「導入者の皆様の声」の12番に掲載させていただいたHさんが10月1日にくださった礼状によれば、月20,000通ほど押し寄せるスパムの着信を月800通(GIDEONによる偽陽性判定を含む)まで減らすことができたというのはつい最近のこと。世の中でスパムが減っているとも思えない。
 私のサイトは強固な防衛力であまりにも平和になってしまって、2013年に会社勤めも辞めたので、外の世界の様子がわからなくなってしまった。よろしかったらどなたか最近のスパムの量の状況を教えてください。

(2014/11/04追記)2010年1月30日の記事に、「2008年11月からスパムの受信が急激に減少しており、これはボットを操るスパマーの上位ISPが通信を遮断したためらしい」と書いていた。同じようなことがあったのかもしれない。

またドイツで誤った設定

 すっかりブログをサボっていた今年8月5日のこと。旅行先からログをみたら、ドイツのドメインからのメールアクセスが引っかかっていた。許可してみたら、ドイツの人からのメールだった。
「『550 S25R check reject』というエラーで送信が失敗しました。私のドメインを拒否リストからはずしていただければ幸いです。」
 メールにあったエラーメッセージの中の送信先IPアドレスを逆引きして、そのドメイン名を「www.」につなげてウェブを見たら、ドイツ国内のサイトだった。ドイツ語は読めないんだが(大学で履修した第二外国語はフランス語だった)、なんとか見当を付けて連絡フォームに書き込んでから、その人に返信した。
「メールありがとうございます。
宛先ホストはmail.****.netのようです。http://www.****.net/の連絡フォームに以下のように書き込みました。
------
私はS25Rスパム対策方式の開発者です。○○様が、貴サイトでのS25Rの誤った使用のために貴サイトへメールを送ることができません。S25Rはしばしば偽陽性判定を起こすので、応答符号550を返すことは絶対にしてはなりません。取り急ぎ155.130.***.deをホワイトリスト登録してください。
------
また、あなたのホストをS25R公開ホワイトリストに掲載しました。
もしなおもお困りなら再度ご連絡ください。」
 その後、その人からも宛先サイトからも何も連絡が来ていない。
 前にもこんなことあったっけと思い出した。2011年4月4日「ドイツでのS25R設定にベルギーから苦情」に書いていた。その時も、申告者からの「解決した」「なおも解決しない」という報告も、宛先サイトからの「対処した」という報告もなかった。その時のサイトとは、今回はまた別のサイトだった。
 日本人ならたいてい、「解決した」「対処した」という連絡をくれる。S25Rの間違った運用(リトライの放置)のせいで手間をかけさせられたのに「親切に対応してくれてありがとう」と謝辞をくださった人さえいた。これが日本の美徳だと思う。数少ない体験から他国の国民性をうんぬんすべきではないとわかってはいるが、こういうものなのかなと思ってしまう。もちろん、ドイツ車などから感じられるドイツ人の職人気質(日本の職人気質も相当誇らしいものだが)には尊敬の念を持っているし、どこの国にもいる「日本の文化好き」と言ってくれる外国人にはとても親しみと感謝の念が湧くのではあるが。

月曜日, 10月 27, 2014

拒絶ログソーティングスクリプトをバージョンアップ

 拒絶ログソーティングスクリプトをバージョンアップした。
 4XXで受信拒否した記録を全部拾い、受信拒否理由を符号で示すようにした。

CClient host rejected (S25Rによるもの)
B:Client host [...] blocked (DNSBLによるもの;maps_rbl_reject_codeを4XXに設定してreject_rbl_clientを使った場合)
SSender address rejected (reject_unknown_sender_domainを使った場合)
RRecipient address rejected (reject_unknown_recipient_domainを使った場合)
HHelo command rejected (reject_unknown_helo_hostnameを使った場合)
OOther (それ以外)

だから、S25R以外に、4XXを返す受信拒否を設定している場合も、リトライしているアクセスを容易に見つけることができる。
 最近のログの表示の一例を示す。

Oct 24 17:40:10 S web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>
Oct 25 12:48:41 B web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>
Oct 27 14:10:17 B web207.purelyhosting.com [192.64.178.136] from=<***@allaboutdiabete.com> to=<***@gabacho-net.jp> helo=<web207.purelyhosting.com>

1回目は、クライアントチェックを抜けた後、reject_unknown_sender_domainで蹴られていた。2回目からはSpamCopのチェックに引っかかった。
 受信拒否理由が一目でわかるのはなかなか便利である。
 なお、reject_unknown_recipient_domainとreject_unknown_helo_hostnameは設定していないので、これによる受信拒否がちゃんと表示されることの確認まではしていない。

火曜日, 10月 07, 2014

「導入者の皆様の声」をもう一つ追加

 前回、S25R方式の導入報告と謝辞をいただいて「導入者の皆様の声」に追加したことを述べた。これがきっかけで、非常に感動的な言葉で激賞してくださった方が他にもいたことを思い出した。もう7年近くも前になるが、2008年1月9日「また激賞された」で紹介した、国島丈生さんのブログ記事「某学会メールサーバのSPAM対策」である。
 今まで「導入者の皆様の声」には、私に連絡してきて賛辞を告げてくださった方々の声を掲載しており、私に連絡することなくブログなどに綴られた賛辞まで拾い集めて掲載することはしていなかった。しかし、国島さんの感動的な言葉は、S25R方式の良さをより強くアピールするにはありがたいもので、英訳して世界に発信するにもふさわしいと考えた。また、学会へのメールはほとんど会員の職場から送られてきて、S25Rに引っかからないことがほとんどであるという条件のもとで、qmailでのグレイリスティングよりも素のS25Rの方が驚くほどの効果が得られたという事例は、貴重な情報である。
 そこで、国島さんの許可をいただいて、ブログ記事からエッセンスの言葉を残して文章を圧縮し、掲載した。

 某学会のサーバを運用しているが、メールアドレスをウェブで公開している学会の連絡先メーリングリストには、Spam throttleを使ってもなお、一日に数百通のスパムが押し寄せてきてほとほと困っていた。
 S25Rという対策を見たことがあったのを思い出し、試してみる価値はあると考えた。
 正規のメールが受け取れないケースが多発しては問題なので、まず、誤って拒否をする可能性が少ないと予想されるQgreyを導入した。かなりのスパムを排除してくれたが、すり抜けてくるスパムがそこそこあった。
 Qgreyが阻止したSMTP接続は100%スパムであった。阻止された正規のメールは一日あたり1通もない。学会にメールを送るのは圧倒的に職場からの場合が多く、したがってS25Rの拒否条件に引っかからない場合がほとんどであろう。ならば、純粋なS25R方式を導入しても大丈夫ではないか。そこで、qmailにS25Rパッチを当て、運用を開始した。パッチ中の記述は少々古かったので、最新のものに書き換えた。
 結果はというと…まさに驚異的の一語に尽きる。受け取るスパムは一日10通程度にまで激減した。13時間の間にS25Rで一時拒否したSMTP接続数は2048。実に99%以上のスパムを、受け取ることなく排除していた。この間、誤って拒否したメールは1通もないし、学会への正規のメールはちゃんと配送している。正直、ここまで効果があるとは予想していなかった。
 すり抜けてくる10通については、個別にブラックリストパターンを書くなどして対処している。10通なら、日常の仕事の合間でも充分解析作業ができる。
 こんなすごい方法を編み出した浅見秀雄さんに大感謝である。
ブログ記事(2007/12/18)の要約;掲載許諾]

土曜日, 10月 04, 2014

「導入者の皆様の声」を追加

 医療機関を統括する組織で情報システム管理者を務めている方から、S25R方式の導入報告と謝辞をいただいたので、内容を編集して「導入者の皆様の声」に掲載した(掲載文は私が作り、その方の意図どおりであることをご確認いただいている)。

 複数の医療機関を統括する組織の情報システム管理をしています。
 月20,000通ほど殺到するスパムの排除にセキュリティソフトウェアGIDEONを使っていますが、すり抜けるスパムの検体をGIDEONに登録するのが手間でした。
 S25R方式を知ってPostfixに適用したところ、80%以上のスパムをGIDEONの前段で排除でき、検体の登録の手間が減りました。しかし、ホワイトリストとブラックリストのメンテナンスが大変でした。そこで、postgreyによるグレイリスティングをS25Rに組み合わせました。その結果、運用の手間が非常に少なくなりました。
 スパムの受信は月約800通と、殺到するスパムの4%にまで減りました(この中にはGIDEONがスパムの疑いありと判定した正当なメールも含まれるので、実際のスパムはもう少し少なくなります)。医師たちからのスパム申告はほとんどなくなりました。素晴らしいアイデアを無償公開していただき、感謝しています。
 唯一困っていることは、スパム対策のために毎日1時間費やしていた仕事がほぼなくなったので、私が“暇”しているように見られていることです。

 スパム対策製品には、送信元がエンドユーザーコンピュータである可能性を逆引き名に基づいて評価するというS25R方式のアイデアを取り入れたものがあることは知っていたが、GIDEONもそうらしい。しかし、高い効果を謳うスパム対策製品を使っても、それだけではスパムによる業務効率低下の問題を十分に解決できていなかったという証言である。これは貴重な情報だと思った。
 システム管理者が楽になっただけでなく、お医者様もスパムを捨てるという無駄な仕事が減った。それでできた余裕は医療の向上に振り向けることができるだろう。私のアイデアとそれを発展させたボランティアの皆さんのアイデアが医療従事者にも貢献し、ひいては病気で苦しむ人たちを救うことにもつながると思うと感慨深い。

土曜日, 11月 16, 2013

SpamCopによる偽陽性判定が発生

 2009年4月29日の「SpamCopを設定してみた」で説明した方法で、S25RにSpamCopを併用するようにして以来、最近までSpamCopによる偽陽性判定を経験したことはなかった。ところが先日、ついに偽陽性判定が起こった。
 11月10日、兄からのメール(メールドメインはcatv296.ne.jp)を送信するメールサーバmail05.SiriusCloud.jpがSpamCopによる偽陽性判定でブロックされていた。誰かがこのメールサーバを利用してスパムを撒いたのだろう。maps_rbl_reject_codeを450に設定していたので、再送が続いているうちにローカルのホワイトリストに登録して受信できた。
 ブラックリスト入りしたのはこの一つのメールサーバだけではなく、周辺のIPアドレスも同時に登録されていた。11月11日にはmail02.SiriusCloud.jpもブロックされた。ホワイトリストを範囲指定に直して受信した。
 経験上、SpamCopは、DNSBLとしてはそこそこ信頼できる。しかし、正当なメールサーバの利用者がスパムを撒いて、それがSpamCopに通報されることもある。そうなると、maps_rbl_reject_codeをデフォルトの554のままにしていた場合、正当なメールが即座にエラーリターンして、善良な送信者と受信者が迷惑を被ってしまう。やはり、maps_rbl_reject_codeを450に変更して再送要求を返し、再送を監視することは必須である。

 ところで、SpamCopのブラックリスト登録は、ある程度の時間で自動的に解除される。そのため、まともなメールサーバを使って撒かれたスパムは、しばらくSpamCopによってブロックされても、再送期間(Postfixやsendmailのデフォルト設定で5日)が終わらないうちにブラックリスト登録が解除されると、受信されてしまう。実際、それでスパムが受信されてしまったことがあった。
 11月14日15:17に始まったaircel-mx1.aircelservices.inからのアクセスがSpamCopでブロックされ、その後再送が続いていた。送信者アドレスが怪しげで、スパムに違いないと判断したので、smtpd_sender_restrictionsパラメータのcheck_sender_access指定で指定したファイルに送信者アドレスを登録することにより、ブラックリスト登録が解除された時に送信者アドレス条件で蹴るようにした。11月16日03:39に拒絶に成功した。
 smtpd_client_restrictionsの条件がsmtpd_sender_restrictionsの条件よりも先に評価されるので、送信者アドレス条件を設定しても、SpamCopに引っかかっている間は再送要求を返し続ける。ログが膨らんでうざったい。しかし、運用手順が単純であることと、同じメールサーバからの他の正当なメールのエラーリターンを避けられることから、この方法が良いと思う。

日曜日, 8月 05, 2012

情報リテラシーを向上させるには

 前回、こう書いた。
 「spf=pass」「dkim=pass」の表示に安心してしまう癖が付くのはかえって危険である。なりすましメールにだまされないためには、送信ドメイン認証の普及よりも、偽情報を見破る情報リテラシーをみんなが持つことの方が重要である。
これに対しては、「個々人の情報リテラシーに頼るには限界がある」という反論があるだろう。しかし私は、「インターネットの危険性をよく知らない素人さんの情報リテラシーを向上させるには、プロがそれぞれの立場でできることがある」と主張したい。
 私はかつて、勤務先のポストマスターを務めていた。2000年に当社のドメインをかたったスパムが発生し、世界からたくさんの苦情メールが殺到した。私はすべてに返事を書いた。「その送信者アドレスは偽造です。当社はスパムを送信していません。そのReceivedヘッダが証拠です」。2001年以降には、当社のドメインをかたったスパムが相変わらず発生していたにもかかわらず、苦情は一件も来なくなった。2000年中に世界中のスパム被害者が、スパムの送信者アドレスを真に受けてはならないと知ったのである。つまり、その点において情報リテラシーが向上したということである。
 自社からのダイレクトメールを受信する顧客がなりすましメールにだまされないようにしたいと思う企業は、次のようにするとよい。
 ダイレクトメールに時折注意喚起を記載する。
なりすましメールにご注意を!必ずお読みください。
http://www.***.co.jp/narisumashi-gochuui.html
 そして、ウェブページでは、Receivedヘッダの読み方を説明するとともに、以下のように記載する。
ご注意
●弊社からは、電子メールでパスワードの変更をお願いすることはございません。
●弊社からのご案内メールにファイルを添付することはございません。
●弊社からのご案内メールでは、 www.***.co.jp 以外のウェブサイトのURLを記載することはございません。
●弊社の業務に関して他社(関連会社等)からご案内メールを差し上げることはございません。
●・・・
 不審に思われましたら、
●弊社を名乗るメールの差出人アドレスが弊社のドメイン ***.co.jp であるかどうかをご確認ください(紛らわしいドメインである場合もあり得ます)。別のドメインであれば、なりすましメールと考えられます。
●Receivedヘッダを見て、お客様のドメインのメールサーバへ送信した弊社のメールサーバが dm数字.***.co.jp であるかどうかをご確認ください。別のメールサーバ名であれば、なりすましメールと考えられます。
 ご不明の点があれば、下記のお問い合わせフォームからお問い合わせください。
https://www.***.co.jp/cgi-bin/otoiawase.cgi
 顧客にこのように説明すれば、顧客は、自サイトでSPFチェックやDKIMチェックを行っていなくても、また、SPFやDKIMでチェックアウトできないなりすましメールであっても見破る情報リテラシーを身に付けることができるだろう。

土曜日, 8月 04, 2012

送信ドメイン認証は誰にとって有益か

 送信ドメイン認証は、スパム(迷惑メール)対策という言葉と共に語られている。だから、かつて私は、送信ドメイン認証はスパム対策の一つだと思っていた。今にして思えば恥ずかしい間違いであった。
 送信ドメイン認証は、スパムのうちの一部にすぎないなりすましメール(単に実在の送信ドメインをかたっているスパムという意味でなく、特定の組織や個人をかたって受信者をだまそうとするメール)に対する対抗策である。ボットから大量に送信されているスパムの受信を劇的に減らせるわけではない。ドメインの詐称ができなくなればスパムは少しは減るかもしれないが、使い捨てドメインを使ったスパムは送信ドメイン認証をパスできてしまう。S25R方式やグレイリスティングほどにはスパムの受信を減らすことはできない。送信ドメイン認証を導入しても、相変わらずたくさんのスパムが受信される。ただ、まともに見えるメールが実はなりすましメールかもしれないと判断できる手段が得られるだけのことである。
 送信ドメイン認証は無益だとは言えない。たとえば、私が契約しているSBIネット銀行(ドメインはnetbk.co.jp)からのダイレクトメールのメールヘッダにはDKIMシグネチャが入っている。受信側サイトがDKIMに対応していれば、SBIネット銀行をかたる偽メールを判別することができる。つまり、netbk.co.jpからのメールのAuthentication-Resultsヘッダにいつもは「dkim=pass」と表示されるのに、ある時「dkim=fail」と表示されたら、「これはおかしい」と気付くことができる。
 銀行やクレジットカード会社の顧客が偽メールにだまされたら、大きな金銭的被害をこうむるおそれがある。だから、メッセージの正当性を検証できる手段を受信者に提供することは、顧客を詐欺の被害から守るために意味のあることだと言える。
 いや、これで顧客がだまされなくなるわけではない。悪者がたとえばnetbk-service.jpのようなドメインを取得してDKIMに対応し、SBIネット銀行の関連会社をかたってフィッシング詐欺メールを送信したら、やはりだまされる人はいるかもしれない。これはSBIネット銀行としてはいかんともしがたい。しかしそれでも、同社は「なりすましメールによる被害から顧客を守るために、当社は最善の努力をしている」と主張できる。つまり、なりすましメールを判別する技術があるにもかかわらず使っていなかった場合よりも、同社が責任を問われるのを回避しやすい。これは同社にとってのメリットである。
 では、送信ドメイン認証にはすべてのサイトが対応すべきだろうか。私は、送信側として送信ドメイン認証に対応するのは、名をかたられて自サイトが責任を問われるのを回避しやすくなるという、自サイトにとってのメリットがあると判断するサイトだけでよいと思う。たとえば、なりすましメールにだまされる自社の顧客が重大な金銭的被害をこうむりうる銀行やクレジットカード会社、名をかたられたデマで社会に混乱を起こされかねない政府・自治体機関などである。それ以外の企業、学校、個人サイトなどでは、あえて導入するまでもないだろう。「貴社からのメールに書かれていたURLをクリックしてウィルス感染させられた」と苦情を受けても、「Receivedヘッダを見せてください。ほら、当社から送信されたものではありませんよ」と説明して済むことである。
 送信ドメイン認証は、標的型攻撃への対抗策として注目が集まり始めているとの情報がある。しかし、標的型攻撃を仕掛ける敵は、著名企業の信用を利用するためにその関連会社と見まがうドメインを使って、また、知人を装うために別メールアドレスを取得したふりをして(携帯電話番号が変わったと嘘をつく振り込め詐欺のように)、ターゲットをだまそうとするだろう。送信ドメイン認証では、スパムを激減させることができないだけでなく、標的型攻撃も防ぎきれないのである。
 「spf=pass」「dkim=pass」の表示に安心してしまう癖が付くのはかえって危険である。なりすましメールにだまされないためには、送信ドメイン認証の普及よりも、偽情報を見破る情報リテラシーをみんなが持つことの方が重要である。

続編:情報リテラシーを向上させるには

水曜日, 8月 01, 2012

自分の記事の検索順位が上がるか?

 前回、「送信ドメイン認証」で検索した人にぜひ読んでもらいたい記事「送信ドメイン認証はスパムに勝てないだろう」の検索順位が30位であることを述べた(今検索してみたら、34位に下がっていた)。
 S25Rホームページの注目度が高いので、ここからリンクされるサイトの検索順位が上がることが期待されてスポンサーが付いた。ならば、S25Rホームページを、自分の記事の検索順位を上げるために使ったらどうか。なぜすぐに思い付かなかったのだろうか。
 S25Rホームページの下の方に「送信ドメイン認証はスパムに勝てないだろう」の記事へのリンクを設けてみた。さて、検索順位は上がるだろうか。

「spf dkim」で検索上位のコンテンツ

 前回、単純な検索ワードで上位にヒットする私のコンテンツを自慢したが、一つ自慢し忘れたものがあった。
 もしかしたら、検索する人のPCによっては1位にヒットしないかもしれないが、おそらくトップ10には入るだろう。SPFやDKIMについて基本的なことを解説する多くのコンテンツを抜いて上位にヒットするのは意外な気がする。
 これは2008年2月8日に書いた記事。「SPFとDKIMはドメイン認証方式として理想的なものではないと思う」と述べた。その後、「ドメイン認証方式はスパム対策として有益ではない」と気付いて、2010年5月30日に「送信ドメイン認証はスパムに勝てないだろう」を書いた。こちらの方をぜひ読んでほしくて、「SPFとDKIMの問題点」の記事に「送信ドメイン認証はスパムに勝てないだろう」の記事へのリンクを設けている。
 「送信ドメイン認証」で検索すると、「送信ドメイン認証はスパムに勝てないだろう」は残念ながらトップ10にランクインしない。しかし、30位にヒットする。「送信ドメイン認証とは」では26位である。このくらいの順位なら、送信ドメイン認証について調べようとした人の目にとまる可能性はほどほど高いと期待できる。でも、なんとかトップ10まで登りつめてほしいところだ。
 送信ドメイン認証が普及したとしても、使い捨てドメインを使ったスパムに対しては無力である。送信ドメイン認証がスパム対策になるという誤解(あえて誤解と言おう)を解くために、私のコンテンツが役立ってほしいと思う。

日曜日, 7月 22, 2012

コンテンツの価値が認められれば検索ランクは上がる

 前回の続き。
 S25Rホームページにスポンサーが付いたのは、このページの注目度が高く、ここからリンクする他サイトの検索ランクを上げることができるとエージェント(インターネットマーケティング会社)に評価されてのこと。
 コンテンツの検索ランクを上げるには、背景色と同じ色で一見見えない検索ワードを本文の中にたくさん記述するとよいといった話を聞いたことがある。しかし、私はそんな策を弄したことはない。まして、お金を払ってまで自分のコンテンツの検索ランクを上げたいと思ったことなどない。それでも、多くの人が指定していると思われる単純な検索ワードでトップ10にランクインするコンテンツは、後述のようにいくつかある。
 このことから推測すると、検索ランクを上げるためにコンテンツに策を弄したり、注目度の高いサイトからリンクしてもらったりしなくても、有用である/興味深いと認めてもらえていそうなコンテンツの検索ランクはおのずと上がるようである。検索ランクは、コンテンツに含まれる検索ワードの数、コンテンツをリンクしてくれているサイトの数などの客観的データだけで機械的に決まるのではなく、コンテンツに対する主観的な価値判断も影響していると考えざるを得ない。
 検索ランクの高いコンテンツを持つ私はどんな工夫をしているかというと…
  • 読者像をはっきりさせる。すなわち、「どんな人のお役に立ちたいのか」を考える。
  • 想定した読者が一瞥して関心を持ってくれるように見栄えを工夫する。
  • 読みやすいように段落を適切に区切る。
  • 文章はわかりやすく。
  • 一文を長くしすぎない。
  • 機種依存文字を使わないなどの基本をわきまえる。
 見栄えを良くするためには図画を活用するのが当然と思われるかもしれないが、私は必要最小限しか使っていない。見栄えのための図画のデザインには慣れていない。それでも私のコンテンツの検索ランクが上がるということは、見栄えだけのための図画はあまり重要でないということだろう。
 お金をもらっておいて言うのも変だが、広告のリンク先のサイトには「もっとこうすればいいのに」と思う点がけっこうある。注目度の高いコンテンツを書く私のノウハウが活かせるなら、これをビジネスにしてみたい気もする。

 多くの人が指定していると思われる単純な検索ワードでGoogleでトップ10にランクインする私の自慢のコンテンツの一部は以下のとおり。検索順位は、検索する人のPCによって多少変わるかもしれない。

S25Rホームページに広告リンクを掲載

 ブログを長いことほったらかしてすみません。
 インターネットマーケティング会社(以後、エージェントと呼ぶ)からの依頼で、7月2日からS25Rホームページに広告リンクを掲載した。
 リンクは10個。エージェントから指定されたそれぞれのリンク名は短く、全体の表示は2行に収まる(ブラウザウィンドウの横幅800~1024ピクセルのとき)。位置は、S25R方式の概要説明と「S25Rでメールが受信拒否された方へ」の説明の間。ブラウザウィンドウの高さが600ピクセルと小さめでも、スクロールなしで広告が目に入るようになっている。
 多くのリンク名は簡潔すぎるので、訪問者がリンク名を見てもあまり興味を惹かれそうにない。そこで、AタグのTITLE属性を使って、リンクにカーソルを置くとサイトの説明が表示されるようにしようと思ったが、エージェントからそれはやめてくれと言われた。リンクを入れ替える時に修正漏れでリンク名と説明表示が食い違うのは避けたいからとのこと。どうやら、S25Rホームページを訪れた人が広告リンクをクリックしてくれることが期待されているのではなく、注目度が高いS25Rホームページからリンクされていることだけでリンク先サイトの検索ランクが上がるということが期待されているらしい。
 これでいくらもらえるかというと、リンク1個につき1ヶ月で、明太子をトッピングした博多ラーメンを食べられるくらいの価格(と言えば推測できるでしょう)。リンク先は商用サイトではなく、非営利の情報サイトなのだが、クライアント(リンク先サイトのオーナー)は、この価格にマージンを加えた料金をエージェントに支払っていることになる。非営利サイトなのに、検索ランクを上げたくてそんなにもお金を払ってくださるとは、正直驚き。クライアントの希望をかなえるのに、私のサイトがそんなにも力になれるのだろうかと気がかりである。もっとも、私のサイトの価値を評価したのはエージェントであり、私はエージェントの注文に忠実に従うだけ。私のサイトに効果がなければ契約が打ち切られるまでのことだから、私が気にする必要はないのであるが。

月曜日, 4月 04, 2011

ドイツでのS25R設定にベルギーから苦情

 ベルギーのドメインの管理者からメールをいただいた。「うちのドメインからドイツの***.deというドメインへ送るメールがことごとく『550 S25R check reject』というメッセージで拒否される」とのこと。「S25R」で検索して私のサイトを見つけて連絡してきたらしい。
 宛先のドイツのドメインのオーナーへメールを送った。「拒否コード『550』を返しては絶対にいけません。S25Rはしばしば偽陽性判定を起こします。『450』を返して、再試行するクライアントをホワイトリスト登録するようにしてください。さもなければ自動ホワイトリスティングシステムを導入する必要があります」。
 最初、postmaster宛に送ったのだが、エラーリターンしてしまった。必須のエイリアスなのに、最近では設定していない人もいるようである。ドメインに「www.」を付けたURLでウェブサイトにアクセスし、連絡先アドレスを見つけ出してそこへ送り直した。
 ベルギーへは、「宛先ドメインの管理者にこのように伝えました。あなたからも苦情を送ってはどうでしょうか。あなたのメールサーバはS25Rに引っかかりません」と伝えた。
 3月31日にメールを送って、まだどちらからも返事がない。どうなっているのか…。

火曜日, 3月 29, 2011

チェコから礼状

 チェコの人から礼状をいただいた。

 S25RとtaRgreyを2008年から使っています。
 ここチェコ共和国で、ホスティングサーバと、顧客の5台のサーバにインストールしています。内容チェックは、役に立たないのでやめました。
 少しのスパムがspamhausでブロックされており、毎日、(taRgreyで)偽陽性が報告されることなく各サーバ8000通ずつ、計40000通のスパムをブロックしています。
 偽陰性はありますが、さほど多くありません。

 以前、S25R方式を使っているという報告は香港からもいただいたことがあり、外国からの礼状はこれで2度目である。私の拙い英語のコンテンツから日本発のアイデアの有用性を読み取っていただけたことは実に嬉しい。
 商用サービスには、やはり手動のS25R方式よりも、偽陽性判定を自動救済するtaRgreyの有用性が評価されるようである。開発者の佐藤さんに改めて感謝の意を表したい。

日曜日, 3月 13, 2011

停電による自宅サーバ運休の可能性のお知らせ

 東日本大震災のため、東京電力管内では電力が足りなくなり、計画停電を行うとのことです。S25Rホームページを掲載している私の自宅サイトは神奈川県横浜市にあり、東京電力管内なので、停電の影響を受ける可能性があります。UPSはありますが、計画停電の継続時間(3時間程度)はもたないと考えられるので、サーバをシャットダウンする可能性があります。あらかじめご了承くださいますようお願いいたします。

水曜日, 11月 03, 2010

ブラックリスト情報の受付の基準

 一般規則のルール1~6をやめる代わりとなるブラックリストの項目追加はなおも終わりそうにないOCNの固定IPアドレスからのスパムアクセスに続いて、同じくOP25Bを導入していることがわかっているODNからも来た。論文に掲載しているブラックリストの実例にあるmindspring.comからのスパムアクセスは最近ほとんど来なくなっていて、OP25Bを導入したことが推測されるが、そこからも久しぶりに1回来た。10月31日に考察した条件に基づいて、ODNはブラックリストに登録せず、mindspring.comは登録した。
 このことから考えると、1回でもスパムアクセスがあったら動的IPアドレスだろうと固定IPアドレスだろうとブラックリストに登録する(どのみち、どちらであるかは通常はわからないのだから)という方法をとっていれば、OP25Bを導入済みかもしれないISPも含めて、逆引きできるすべてのISPドメインに近い数の(OP25B導入済みでホワイトリスト情報があるISPだけを除く)ブラックリスト項目ができることになるかもしれない。これはけっこう大変そうである。
 言い換えれば、S25R方式を発表した2004年ころには、逆引きできるホストも6個の正規表現で蹴りまくる方法がいかに正しかったかということである。そうでなければ、導入した人がびっくりして感激するほどのスパム阻止率はとうてい得られなかったのだから。
 公開ブラックリストを仮開放したが、こういう状況なので、一般規則のルール1~6をやめても十分にスパムを阻止できると保証することはできない。ルール1~6をやめる方法を今取り入れた人は、公開ブラックリストをすり抜けるスパム送信元ホストを新たに次々と発見することになるだろう。もしかしたら、その情報を提供して公開ブラックリストの充実のために協力しようという人がおられるかもしれない。そこで、ブラックリスト情報を受理する基準を説明しておく。
 ブラックリスト情報の提供にあたっては、スパムを送って来た(またはスパムアクセスをして来た)ホストの逆引き名を報告していただく。原則として、以下のいずれかの条件を満たすものを受理する。

●一般規則に引っかかることから、エンドユーザー回線と推定できる。
●十六進番号を含むことから、エンドユーザー回線と推定できる。
●上記いずれの条件も満たさなくても、複数の逆引き名から、エンドユーザー回線の命名規則を推定できる(tpnet.plのようなケース)。

ただし、OP25B導入済みとわかっていて、ホワイトリスト情報があり、かつ私がスパムアクセスをほとんど観測できないドメインについては受理しない(未知の正当なメールサーバからのメールをホワイトリストなしで受信したい人の不利益になりかねないからである)。
 上記いずれの条件にも当てはまらないためにメールサーバと推定されるホストのブラックリスト情報は、受理しない。自社の宣伝のためにスパムをまいた前科のある会社だとか、ポルノサイトであるとわかっている場合でも、それはローカルのブラックリストで対処していただく。そのメールサーバをブロックしたいかどうかは、サイトのポリシーによることだからである。そこからのメールを受けたいユーザーのいるサイトの運用に支障を与えることは避けたい。S25R方式において、どのサイトでも共通に使えるスパムブロック方法として提供するのは、あくまでも、エンドユーザーコンピュータと推定されるホストのブロックである。
 例外的に、volia.netについては、サイトドメインを丸ごとブロックする条件を公開ブラックリストに登録している。サーバにしか見えない逆引き名のたくさんのホストからスパムアクセスが来るからである。このようなサイトは他に見つかっていない。ブラックリストファイルには、ブラックリスト作成中に見つかったvolia.net内のスパム送信元ホストをすべてコメント行で列挙している(ここまでやる必要はないとは思いつつ)。あきれるばかりである。

# absolving.argument.volia.net
# vehicleness.basin.volia.net
# beachless-vim.volia.net
# designsless.bellows.volia.net
# praise.bend.volia.net
# nodeless.billing.volia.net
# cabinetness-decrease.volia.net
# tusk.calm.volia.net
# devoted-apportioner.volia.net
# earnest-air.volia.net
# efficient-clamourer.volia.net
# feelerly-assault.volia.net
# gadfliless.ideology.volia.net
# inclined-slope.volia.net
# stencilless.management.volia.net
# merging-signature.volia.net
# dressingly.motel.volia.net
# nearer-orchard.volia.net
# pressuring.orthodoxy.volia.net
# pancakely-paint.volia.net
# cardly.pity.volia.net
# revering-excursion.volia.net
# loom.roll.volia.net
# sailly-celebrity.volia.net
# girderless.sheen.volia.net
# ip.77.120.249.47.stat.volia.net
# tangential-design.volia.net
# quiply.taps.volia.net
# vested-ramparts.volia.net
# west-cold.volia.net
/\.volia\.net$/ 450 S25R check

日曜日, 10月 31, 2010

公開ブラックリストの利用法

 一般規則のルール1~6をやめるという方法を採るための代わりとなる、スパムアクセスの前科のあるドメインの公開ブラックリストを、この方法を試したい人のために仮開放しようと思う。ファイルは

http://www.gabacho-net.jp/anti-spam/black-list.txt

に仮登録してある。
 この方法を使うための推奨設定は次のとおりである。なお、Q&Aのページで説明している、permit_sasl_authenticatedやreject_unlisted_recipientなどの追加指定は省略して示す。

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white-list.txt,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/black-list.txt,
  check_client_access regexp:/etc/postfix/rejections

●white-list.txt:公開ホワイトリスト
●white_list:ローカルのホワイトリスト
●black-list.txt:公開ブラックリスト
●rejections:ローカルのブラックリストと一般規則のルール0(ルール1~6はコメントアウトする)

 公開ホワイトリストは、ルール1~6が有効であることを前提としたものそのままであり、その中の逆引きできるホストの指定は不要なものである。しかし、あえてそのまま使うことを推奨したい。それまで届いていたメールがブラックリストの更新で突然ブロックされることが、すでに知られたメールサーバについては避けられるからである。逆引きできないホストだけを集めた第二のホワイトリストファイルを作って提供することはしないことにした。
 この方法を採れば、S25R一般規則に引っかかる未知のメールサーバであっても、逆引きできて、かつブラックリストに登録されたドメインになければ、ブロックされずに済む。ただし、以下のことに留意していただきたい。

●S25R一般規則でならブロックできたスパムがすり抜けることがありうる。
●逆引きできない未知のメールサーバがブロックされることは変わらない(スパム対策上、逆引きできないホストを一律に許可するわけにはいかないから)。
●ブラックリストの更新によって、それまでブロックされていなかったメールサーバがブロックされるようになる(ホワイトリスト登録が必要になる)ことがありうる。

 S25R一般規則に引っかかる未知のメールサーバをブロックしないことを優先したいか、未知のボットネットからのスパムをS25R一般規則でブロックすることを優先したいかは、それぞれのサイトで判断していただきたい。