土曜日, 3月 28, 2009

OptPlus売れていないんじゃないの?

 「バウンシングバック認証」でググると、私のブログ記事が1位と2位を独占している。2007年5月29日「「バウンシングバック認証」で検索上位」を書いて以来、順位は落ちていない。「OptPlus」でも1位と2位に私のブログ記事がヒットする。「Opt Plus」では7位と8位だが、「Opt Plus ASP」だと、なんとOpt Plus ASPの本家サイトを抜いて私のブログ記事が1位である。
 OptPlusやバウンシングバック認証方式について調査しようとすると、痛烈な批判記事がいやでも目に付いてしまう。こんな状況の中で、OptPlusはどのくらい売れているのだろうか。
 いろいろ検索してみても、ユーザーの声はマスコミサイトのヨイショ記事にしか見当たらない(そのユーザーは、OptPlusのベンダーのビジネスパートナーである)。S25R方式については、「効果抜群でびっくりした」、「これほど効果があるとは予想していなかった」などの声がたくさん見つかるが、OptPlusについては見つからない。バウンシングバック認証要求メールを実際に受けたという話題も見つからない。
 2007年5月にたくさんのマスコミサイトがヨイショ記事を発表してから2年近くになるが、Opt Plus ASPやベンダーのSYSMATE社のコンテンツは代わり映えしない。私の指摘でユーザーが抱くであろう疑問(たとえば「やぎさんゆうびん問題は起こらないのか」など)に答えるコンテンツが追加されてもいないし、獲得ユーザー数やユーザーからの賞賛の声を誇示するコンテンツもない。売る気ないんじゃないだろうか。
 OptPlusが売れていないと思われるのは、おそらく、私のバウンシングバック認証方式反対キャンペーンによるものではない。もちろん、私のブログ記事を読んで、たくさんのマスコミサイトのヨイショ記事を鵜呑みにせずに済んだ人はいるかもしれない。しかし、私がキャンペーンを張らなくても、おそらくOptPlusは売れなかった。
 OptPlusを導入したASPやベンダーの失敗の原因は、日本人のニーズを正しく理解していなかったことである。たいていの日本人は、スパムを受けなくて済むことよりも、正当なメールを確実に受信できることの方を重視するのである。送信者が認証手続きをしなかったら正当なメールも受信されないというバウンシングバック認証方式には、おそらく多くの日本人は見向きもしなかったのである。メーラーに付いているベイジアンフィルタで80~90%のスパムをごみ箱に振り分けることができればそれでおおむね満足で、“スパムの阻止率100%”のために金を払おうと思う人などほとんどいないのである。
 失敗の原因のもう一つは、S25R方式を知らなかったことである。S25R方式を発表したのは2004年。「スパム 対策」のGoogle検索で1位か2位にヒットする状況が2005年以来ずっと続いている。なのに、2007年になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」などと言っている。ちょっと調べれば、スパムの阻止率97~99%、高スキルの技術者でなくても実装できる、しかも無料というS25R方式には勝てないということはすぐにわかったはずである。
 日本人の心と日本人の発明に目を向けなかった事業者の失敗である。

(4月6日追記)
 「OptPlus」と「Opt Plus ASP」での検索順位が少し下がった。しかし、トップ10には入っているので、アピール度は十分である。

(OptPlusとバウンシングバック認証方式に関するすべての記事へのリンクはこちらの記事にあります。)

OptPlusの認証画面の脅し文句

 「OptPlus」でググると、7位に面白いページがヒットする。

OptPlus メール
注 意: このシステムはそちらの接続環境(66.249.67.207)で認証したことを自動的に記録いたします。認証後、迷惑メールと判断されるメールを送られてきた場合、法的な処置をとる場合がございますので、翌゚ご了承下さい。 ...
mail.yungjin.co.kr:8886/mmpmgr/user/auth_view.php?msgid=498146C84719&lang=jp - 6k -
(ごみ文字が入っている)

 このサイトは韓国の製薬会社。OptPlusの認証画面である。
 66.249.67.207は、逆引きするとわかるが、GoogleのロボットのIPアドレスである。Googleはどうやってこのページを見つけたのだろうか。この会社にメールを送ってバウンシングバック認証要求メールを受けた人しか知り得ないURLのはずである。誰かが公表したのかと思ったが、検索しても見つからなかった。
 アクセスしてみると、警告文のIPアドレスの部分は自分のIPアドレスになることがわかる。サーバ側でアクセス元のIPアドレスを検出して表示して見せることができるのは当然のことだが、インターネットの仕組みに詳しくないユーザーは不気味に感じることがある。何かを問い合わせようと思ってメールを送った人は、自分のIPアドレスの表示と「法的な処置をとる」という脅し文句に恐れおののいて、認証手続きをせずにあきらめてしまうかもしれない。
 お客様への気配りの心をわきまえた日本人は、こんなことをしてはいけない。

日曜日, 3月 22, 2009

XMailCFG (for Windows)をリンク

 S25Rの目次ページに、XMailCFG (for Windows)へのリンクを掲載した。ホワイトリスト情報をお寄せくださった方から教えていただいたものである。
 XMailは、UNIXとWindowsで動作する、オープンソースのFINGER/SMTP/POPサーバ。XMailCFGは、XMailの設定やメンテナンスを行うソフトウェアであり、XMailにS25Rを組み込むことができる
 XMailとXMailCFGのおかげで、S25Rを組み込んだメールサーバをWindows上でも実現できるようになった。しかも、両ソフトウェアともフリーである。「S25RをWindowsサーバで実現できませんか」という質問を受けたら、これを紹介してあげることにしよう。

掲示板のスパム対策

 協力者からのホワイトリスト情報は、メールよりも掲示板で寄せられることの方が圧倒的に多い。掲示板は、メールとは違って、個人情報を明かさずに投稿できることと、自分の貢献が公になることから、協力者にも好まれるようである。掲示板がなければこれほど多くのホワイトリスト情報は集まらなかったかもしれない。
 掲示板のスパム投稿も問題になっている。スパム投稿のために掲示板を維持できなくなり、閉鎖した人もいる。
 私の掲示板は、他の多くの掲示板に比べてスパム投稿を受けにくかった。トップ画面に投稿フォームがなく、投稿画面へ移るのにワンクリック必要であることが幸いしたようである。また、トップ画面は記事タイトルのスレッド表示で、記事の内容の表示にもワンクリック必要であることから、スパム投稿の宣伝効果に欠けると敬遠されたことも幸いしたかもしれない。
 それでも、私の掲示板にもスパム投稿が来るようになった。そこで、スクリプトに手を加えて、投稿画面のURLを変更してみた。これにより、投稿画面をダイレクトに狙うアクセスをエラーに落とすことができる。しかし、これも破られていたちごっこになった。
 そこで、掲示板スクリプトのファイル名を変えるという方法をとった。「raib.cgi」というファイル名は「raib_3036.cgi」として、また攻撃が来たら数字の部分を変更してかわすことにする。そして、元の名前の「raib.cgi」は、掲示板へジャンプさせるHTMLを吐くシェルスクリプトにする。これが吐くHTMLは、METAタグで掲示板へジャンプさせるようになっている。Aタグは書かず、また、METAタグ中のURLは相対パスにしてフルパスをわかりにくくする。これにより、ブラウザでアクセスする人は手間なく掲示板に到達できるが、スパマーが使う自動プログラムでは掲示板に到達しにくくなる。この方法をとってからは、スパム投稿は根絶した。
 私は無精なので、スパム投稿対策機能を持つ新しい掲示板スクリプトを導入するのでなく、使い慣れたスクリプトを使い続けたかった。これでスパム投稿を排除できたのは幸いだった。投稿してくださるゲストにとっても、CAPTCHA認証の手間を強いられないのは楽だろう。
 掲示板の内容が検索エンジンに拾われなくなるが、そのくらいはやむを得ない。むしろ、ロボットによってPerlスクリプトが連続で動かされてサーバのCPU負荷が上がるよりはよいだろう。
 対策をとったのは2007年だが、今なお、投稿画面の古いURLへのアクセスが日に数回来ている。アホなボットである。

 この方法は私のネットフレンドにも勧めたのだが、その人の掲示板は、この方法をとっても何度か破られている。トップ画面に投稿フォームがあるので、スパマーに狙われやすいのだろう。それでも、古い掲示板スクリプトを使い続けたいならば、これ以上に運用が楽な防御方法はないと思う。

 参考までに、掲示板へジャンプさせるHTMLを吐くシェルスクリプトのコードは次のとおり。「euc-jp」の部分は、メッセージの文字コードに合わせる。シフトJISの場合は「shift_jis」にする。

#!/bin/sh
echo 'Content-type: text/html'
echo
echo '<HTML LANG="ja">'
echo '<HEAD>'
echo '<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=euc-jp">'
echo '<META HTTP-EQUIV="refresh" CONTENT="0; URL=./raib_3036.cgi">'
echo '</HEAD>'
echo '<BODY>'
echo '<CENTER>掲示板への攻撃を防御するため、別URLへ移動します。</CENTER>'
echo '</BODY>'
echo '</HTML>'

土曜日, 3月 21, 2009

息子宛のスパムアクセスが途絶えた

 2008年7月20日「信じられない阻止率」で、私の息子へのスパムの着信数について述べた。オンラインショッピング会社のサーバが侵害されて息子のメールアドレスがスパマーに漏洩したものと思われ、2007年9月から届き始めた。今年3月までの着信数の推移は次のとおりである。

2007年9月:3通
10月:2通
11月:2通
12月:3通
2008年1月:6通
2月:5通
3月:11通
4月:3通
5月:2通
6月:0通
7月:0通
8月:1通
9月:0通
10月:0通
11月:0通
12月:1通
2009年1月:0通
2月:0通
3月:0通

 2008年12月22日を最後に着信していない。2月14日「「4xx」は迷惑か?」の中で、
「今では、息子宛のスパムアクセスは月10回ほどと少なくなっている。」
と述べた。この日時点で、過去1ヶ月のスパムアクセスがそのくらいだった。
 今日(3月21日)、ログを見たら、息子宛のスパムアクセスが2月15日以降一度もないことがわかった。ピーク時には月に着信11通、ということは月に数百回あったスパムアクセスが、1ヶ月以上にわたって途絶えている。
 わざとスパマーに拾わせたおとりのアドレス、ウェブページから拾われた間違いアドレス、それらを改変したでたらめのアドレス(2006年9月15日「宛先の正しいスパムの阻止率」参照)へのスパムアクセスは、どんなに「550」を返し続けても、何年たっても減っていない。だから、息子宛のスパムアクセスも、減ることはあっても途絶えることはないと思っていた。途絶えたのは意外だった。
 推測するに、オンラインショッピング会社のサーバを侵害するという難しい方法で盗まれたメールアドレスは、少数のスパマーにしか利用されず、その少数のスパマーのほぼ全員が、息子宛のスパムの送達率の悪さに送信をあきらめたのかもしれない。だとすれば、S25R方式の勝利である。

(3月23日追記)
 3月22日に息子宛のスパムアクセスが1回あった(逆引き失敗で蹴っていた)。根絶はしていないようである。

水曜日, 3月 18, 2009

常軌を逸したダウンロードの犯人がわかった

 3月14日の記事の続編。
 公開ホワイトリストファイルへの5分間隔のアクセスを見つけた時、アクセス元ホストにSMTPアクセスをしてみたら、HELOコマンドへの応答で名乗ったFQDNは「.ne.jp」を冠していた。そのFQDNは順引きできず、また、HELOアドレスは信用できないという思い込みがあって、そのサイトドメインを疑おうとは思いもしなかった。逆引きドメイン名の登録者に通報したが、今なお返事がない。
 再度HELOアドレスを確認し、そのサイトドメイン名のMXレコードを検索してみた。すると、セカンダリMXのIPアドレスがそのホストのものと一致していた。
 逆引き名から、犯人は小規模サイトか個人サイトと推測していたが、そうではなかった。非営利の某ネットワークサービス提供団体だった。常軌を逸したダウンロードをしていたセカンダリMXは、他社の回線を借りて接続していたもので、だから逆引き名からはその団体のサーバだとはわからなかったのである。
 ログを再度調べたら、そのサイトのプライマリMXも公開ホワイトリストファイルをダウンロードしていることがわかった。こちらは一日1回である。セカンダリMXに常軌を逸したダウンロードをさせていたのは何だったのか。cronの設定ミスだったとしたらお粗末。
 手動のSMTPでpostmaster宛のメッセージを打ち込んだが頻繁なアクセスがやまないので、ルータでHTTPをブロックしていた。今日、ブロックを解除してみたら、アクセスはやんでいた。メッセージに気付いたのか、cronジョブがフェールしているのに気付いたのか。HTTPをブロックしてダウンロードを拒絶したのが制裁措置と映っただろうか。設定を直したと連絡をくれればすぐにブロックを解除したものを。
 非営利とはいえ、業務でネットワークサービスを提供しているからにはプロ。小規模サイトや個人サイトのノンプロとは違う。プロならなおのこと、自分の事業のために一個人の無償ボランティアを利用するからには常識として何を守るべきかをわきまえてほしいものである。

火曜日, 3月 17, 2009

公開ホワイトリストファイルから冗長なスペースを削除

 これまで、公開ホワイトリストファイルでは、見栄えのために「OK」のカラム位置をそろえていたが、冗長なスペースを削除して、正規表現との間のスペースを1個だけにした。
 理由の一つは、公開ホワイトリストファイルから「OK」を削除する加工をして使う人がおられることである。加工のしやすさのためには、冗長なスペースはない方がよく、それは見栄えよりも大きな利点だと考えた。
 もう一つの理由は、ファイルサイズの削減である。これで約7KB(約20%)減った。わずかながらダウンロード時間の短縮になる。
 ただし、論文中のホワイトリストサンプルでは、見栄えのために「OK」のカラム位置をそろえたままにしている。

月曜日, 3月 16, 2009

ちゃんとログ見てるんでしょうね

 3月14日「S25Rの採用サイトの推定数」で述べたとおり、公開ホワイトリストファイルを毎日ダウンロードしているサイトは50ほどある(気を遣ってくれる人は、ファイルのタイムスタンプを見て、更新されている時だけダウンロードするようにしてくれているが)。「定期的に取得していいですか」と事前に打診してくれた人は一人しかいない。
 まあいいです。節度をもって利用してくだされば。1回きりのアクセスは単に見ただけかもしれないが、毎日定時にアクセスがあると、どこのサイトがS25R方式を採用してくださっているかがわかって面白い。誰でも知っている某国際空港とか、超有名な某大手出版会社とか。もちろん、私から無断で公言することはしないけれども。

 それはそうと、気になったことがある。cronジョブで公開ホワイトリストを毎日ダウンロードすればホワイトリストのメンテナンスを自動化したことになるとは、まさか思っていないでしょうね。
 公開ホワイトリストを組み込めば、偽陽性判定の確率を下げることはできる。しかし、ゼロにはできない。公開ホワイトリストには、S25Rに引っかかる正当なメールサーバのうち、私と協力者がたまたま見つけたもの(S25Rに引っかかるサイトからの申告を含む)しか収録されていないのである。素のS25R方式を使っている以上、必ずログを監視して、偽陽性判定からの救済を手動で行わなければならない。偽陽性判定はめったに起こらないかもしれないが、ログの監視をサボってはならない。
 ホワイトリストのメンテナンスを自動化したいと思ったら、その方法は、公開ホワイトリストの自動取得ではない。グレイリスティングかタールピッティングの併用、あるいは自動ホワイトリスティングプログラムの組み込みである。くれぐれも勘違いしないでいただきたい。

日曜日, 3月 15, 2009

公開ホワイトリストの棚卸し

 公開ホワイトリストを棚卸しした。逆引きができるようになっていたので許可条件をコメントアウトしたのが32件、逆引きができるようになっていたが逆引き名が一般規則に引っかかるので許可条件をFQDNに変えたのが4件である。
 なお、逆引きができるようになっていたとは、もちろん、パラノイド検査(逆引き名の順引き検証)もOKだったという意味である。ご自分で棚卸しをする際にはご注意ください。

s25rtarpitgreylistをリンク

 S25Rの目次ページに、きまぐれPCひろばs25rtarpitgreylistへのリンクを掲載した。S25Rで送信元ホストの選別を行い、タールピッティングとグレイリスティングでスパムの排除を行う、qmail対応のPerlスクリプトである。qmailユーザーには有用なソフトウェアと思われる。

土曜日, 3月 14, 2009

S25Rの採用サイトの推定数

 前回、常軌を逸した頻度で公開ホワイトリストファイルをダウンロードしている人は「自分と同じことを100人がやったらどうなるか」を考えてほしいと述べた。100人というのは大げさな数ではない。公開ホワイトリストファイルを自動でダウンロードしているサイトは、現在50くらいある。2007年10月8日「ホワイトリストファイルを自動取得されているサイト」を書いた時には8サイトだった。この調子では、本当に100サイトにはなるかもしれない。
 公開ホワイトリストファイルを自動取得しているのは、素のS25R方式の採用サイトだろう。Rgreyなどでホワイトリスティングを自動化していれば、自動取得は必要ないはずだからである(その場合も、公開ホワイトリストを組み込んでおくことには意味があるけれども)。
 そして、素のS25R方式の採用サイトのうち大半は、公開ホワイトリストファイルの自動取得まではしていないだろう。最初に公開ホワイトリストを組み込んであとは自分で項目を追加していくのでも十分だからである。公開ホワイトリストを定期的に組み込むにしても、時たま手動で行う人もいるだろう。Postfixのオペレーションがどうにかできるくらいのスキルレベルの人(決して少なくないと思われる)は、cronジョブを作ろうとまでは思わないだろう。自動取得しようと考える人は、根拠レスな推測だが、1割よりも少ない、20~40人に一人といったところではないかと思う。
 この乱暴な仮定に基づけば、S25R方式の採用サイトは1000~2000くらいと推定される。ホワイトリスティングの自動化を併用しているサイトや、Postfix以外のqmailやsendmailでS25R方式を実装しているサイトを合わせれば、1500~3000といったところかもしれない。
 国内に関する限り、一つのシステムでこれほど多くのユーザーがいるサーバ向けのスパム対策方式は、ほかに例がないのではないだろうか。

ホワイトリストファイルの常軌を逸したダウンロード

 公開ホワイトリストの更新は一ヶ月に1度あるかないか、多くても数回という程度である。ウィルス対策ソフトのパターンファイルじゃあるまいし、私が公開するホワイトリストファイルを寸暇を置かずに反映しなくても、セキュリティ上の問題が起こるわけでもない。私が使っているウイルスバスターでさえ、パターンファイルの更新チェックの周期はデフォルトで3時間、最短設定で1時間である。なのに、何を考えて5分間隔でダウンロードしているのか。
 そういう常軌を逸したダウンロードをしているのは1サイトだけなので、リソース負荷は問題になっていない。しかし、「自分一人くらいやっても問題ないだろう」と思うのでなく、「自分と同じことを100人がやったらどうなるか」を考えてほしい。S25R方式を採用するサイトは非常に増えているのだから。100サイトが同じことをやったら、私のサーバは34KBのファイルを3秒に一度の割合で送り出さなければならなくなるのである。
 逆引き名からは、IPアドレスの割り当て1個の小規模サイトか個人サイトと推測された。アクセス元ホストはSMTPアクセスに応答したが、「postmaster@逆引き名」にメールを送ったら「Relay access denied」で蹴られた(mydestinationパラメータに逆引き名が含まれていないらしい)。HELOコマンドへの応答で示されたFQDNは順引きできず、メールは配送エラーになった。手動のSMTPでpostmaster宛に「一日1回にしてください」とメッセージを打ち込んだ。
 その後24時間たっても5分間隔のダウンロードは止まらなかった。postmaster宛のメールをちゃんと見ていないことが考えられる。ルータでHTTPアクセスをブロックした。これで、そのサイトからは、ホワイトリストファイルはもとより、私のウェブページや掲示板にもアクセスできなくなる。しかし、私のスキルでは、気付いてもらうための策がほかに思い付かなかった。
 …と、ここまで書いたところで、whoisで逆引きドメイン名の登録者を調べて通報することを思い付いた。

(続編)
常軌を逸したダウンロードの犯人がわかった

水曜日, 3月 11, 2009

考え直してGoogleのドメイン名もホワイトリスト登録

 前回、パラノイド検査エラーになるGoogleのサーバのためにIPアドレスのホワイトリスト登録をしていることを述べた。BBSのゲストのいるかさんから報告されたGoogleのホストはルール1に引っかかるものであるが、IPアドレスのホワイトリスト登録にマッチするので、ドメイン名のホワイトリスト登録を追加する必要はない。
 しかし、考え直した結果、Googleのドメイン名も公開ホワイトリストに掲載した。というのは、いるかさんはqmail用のs25rtarpitgreylistをお使いで、公開ホワイトリストファイルをそのままPostfixで使っているわけではない。そのような人たちが公開ホワイトリストから項目を抽出して、使用システムに合わせたホワイトリストを作ることに配慮すると、Googleのドメイン名のホワイトリスト登録も示しておいた方がよいと考えたからである。
 記載は以下のとおり。

# *** PUBLISHED S25R WHITE LIST ***
# Last update: Mar 11, 2009
# (*): reported by a contributor
#
# Mar 11, 2009: mail-gx0-f21.google.com, etc. (*)
/\.google\.com$/ OK

 Googleは超メジャーなサイトなので、論文中のホワイトリストのサンプルにも掲載した。

日曜日, 3月 08, 2009

Googleサーバのパラノイド検査エラー

 BBSのゲストのいるかさんから、以下のホストが引っかかるとの情報をいただいた。

mail-gx0-f167.google.com [209.85.217.167]
mail-gx0-f236.google.com [209.85.217.236]
mail-gx0-f72.google.com [209.85.217.72]
mail-gx0-f21.google.com [209.85.217.21]
mail-qy0-f75.google.com [209.85.221.75]

 しかし、以下のように、すでに2008年7月にIPアドレスでホワイトリスト登録していた。

# Jul 10, 2008: rv-out-0102.google.com, etc. (*)
/^209\.85\.(1(2[8-9]|[3-9][0-9])|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK
#
# Jul 10, 2008: py-out-0102.google.com, etc. (*)
/^64\.233\.1([6-8][0-9]|9[0-1])\.[0-9]+$/ OK
#
# Jul 10, 2008: ag-out-0102.google.com, etc. (*)
/^72\.14\.(19[2-9]|2([0-4][0-9]|5[0-5]))\.[0-9]+$/ OK

 このホワイトリスト登録は、PyTaさんからの報告によるものである。たとえば209.85.198.192~209.85.198.207の16個のIPアドレスの逆引き結果はどれもrv-out-0102.google.comになり、その逆引き名を順引きすると16個のIPアドレスが順不同で列挙されてくる。Postfixは、検索された最初のIPアドレスが元のIPアドレスに一致しないとパラノイド検査エラーとして扱う。したがって、高い確率で逆引き結果が「unknown」になってしまう。
 ホスト名の初めの綴りを3種類教えていただいたので、それを手がかりに、Googleに割り当てられているIPアドレスブロックを調べて、上記のようにIPアドレスの許可条件を作った。
 いるかさんから報告されたホストは、逆引きと順引きの対応がまともになっているのでパラノイド検査エラーにはならないが、

/\.google\.com$/ OK

という許可条件を追加するまでもない。IPアドレスが1番目の許可条件にマッチするからである。

 このようなパラノイド検査エラーは、amazon.comでも起こっていた。207.171.167.25と207.171.172.6の逆引き名がともにiad-fw-global.amazon.comで、その順引き結果が二つのIPアドレスになっていた。しかし、今調べたところ、それぞれの逆引き名は207-171-167-25.amazon.comと207-171-172-6.amazon.comに変わっていて、順引きとの対応もまともになっていることがわかった。これらのホストは、すでに

# Oct 28, 2004: 207-171-180-101.amazon.com
/\.amazon\.com$/ OK

という許可条件があるので、許可される。
 逆引き名の変更で不要になった許可条件は、ホワイトリストファイルの頭の方でコメントアウトで示した。しばらくしたら削除するつもりである。

# Mar 08, 2009: (This condition has become unnecessary.)
# Jun 06, 2004: iad-fw-global.amazon.com
#/^207\.171\.(167\.25|172\.6)$/ OK

水曜日, 3月 04, 2009

ホスティング事業者もS25Rを推奨

 沖縄のホスティングサービスプロバイダ・テトラビットのニューストピックスより。

2009.01.20
■テトラビット専用サーバサービスでは、SPAM対策の一つである、S25R(Selective SMTP Rejection)方式を推奨します。

 「S25R」は、正しく運用することによって、有効なSPAM対策となります。
 SPAMメールでお困りのお客様はぜひ一度弊社までご相談をください。

 サーバ運用のプロがS25R方式の正しい運用をマスターし、スパムに困っている顧客に推奨して、導入と運用を支援してくれる。これにより、スパム問題から救われる人たちがますます増える。うれしいことである。