2006年9月アーカイブ: Web屋のネタ帳

« 2006年8月 | Main | 2006年10月 »

集客機能つきのASP＝楽天市場＝の「楽天税」は高いか安いか

楽天市場とは、集客機能つきのASP(アプリケーションサービスプロバイダ)である。ただ、そんなヨコ文字並べられてもわからないよという人のほうが世の中多いので仕方なく「要するにテナント料で儲ける不動産屋です」みたいな比喩が広く用いられる。

ASPという意味においてはYahoo!オークションもGMailもセールスフォースドットコムも同類である。それぞれにおける利用料金は無料だったり数百円だったり数十万円だったり様々。

さて、「楽天税」とは、楽天市場がその店舗に課金するシステム利用料や楽天ポイント／楽天アフィリエイトの原資、そして楽天市場上の各ページや公式メールマガジン上に広告掲載するための広告出稿料などをすべてひっくるめた俗称である。

その楽天税の金額を評価するに当たって重要なポイントは、純粋なシステム利用料＝ASP利用料＝と、集客機能利用料＝広告出稿費用、とを分けて考えることだ。システム利用料の課金は避けて通れないが広告を出稿するかどうかは出店者の判断次第である。中には楽天市場に出店すること自体に広告効果があると勘違いしている人すらいるようだがそれは店舗数が数百しかなかった４、５年前の話であって店舗数が1万を超えている現状ではおとぎ話に過ぎない。そして楽天市場以外の場所で商売したところで同じ商売である限りは広告費用が必要なくなるはずがないという当たり前の現実をも認識しておくべきである。

したがって、この記事でいう「楽天税」は「楽天市場で店舗を運営するための純粋な情報システム費（≒IT予算）として楽天に支払う金額」と考える。以下は、楽天の公式ページ上に説明されている数字をもとにしたごく簡単なシミュレーションである。なお、以下の点に注意。

楽天ポイントの付与料は情報システム費ではなく広告費用（販促費）と捉えるべき面があるが、店舗の意思にかかわらず自動的に課金されてしまう事情があるため一応計算している。
楽天アフィリエイトについても同様だが、こちらはアフィリエイト報酬とアフィリエイトシステム利用費とがそれぞれ明確に計算式があるため、アフィリエイトシステム利用費のほうのみをシステム利用料に含めている。
R-Mailとよばれるテキスト形式のメールマガジンは20万通送信まで無料である。がしかし、テキストだけでなく商品画像を掲載できるHTMLメール形式のほうが効果は抜群に高く、店舗運営には欠かせない。したがってR-Mail Plusを多用する前提で計算している。その意味ではR-MAILの利用料はシステム費用ではなく広告費用として捉えるべきかもしれないがとりあえずシステム費用と考えることにする。
他にも注文データ等のCSV形式でのダウンロードなどの各種の機能についてもいちいち費用がかかるのだが細かいので省略。

※すべて月毎の数字。楽天スタンダードプランを想定。

	店舗名	ショップX	ショップＡ	ショップB	ショップC	ショップD	ショップE
A1	通常購入件数	60	200	300	300	600	1500
A2	通常購入の注文単価	3,500	4,000	5,500	10000	11000	10000
A3	通常購入売上高(A1xA2)	210,000	800,000	1,650,000	3,000,000	6,600,000	15,000,000
B1	オークション開催回数	4	4	4	4	4	4
B2	オークション平均落札価格	3,000	3,000	4,500	6,000	6,500	7,000
B3	オークションあたり出品数量	15	20	20	20	10	10
B4	オークション落札総件数(B1xB3)	60	80	80	80	40	40
B5	オークション売上高(B2xB4)	180,000	240,000	360,000	480,000	260,000	280,000
C	総売上高（＝課金対象額）(A3+B5)	390,000	1,040,000	2,010,000	3,480,000	6,860,000	15,280,000
D	平均バスケット単価 C/(A1+B4)	3,250	3,714	5,289	9,158	10,719	9,922
E1	適用料率（売上100万まで分）	4.0%	4.0%	4.0%	4.0%	4.0%	4.0%
E2	適用料率（売上200万まで分）	3.0%	3.0%	3.0%	3.0%	3.0%	3.0%
E3	適用料率（売上300万まで分）	3.0%	3.0%	3.0%	2.8%	2.8%	2.8%
E4	適用料率（売上500万まで分）	2.8%	2.8%	2.8%	2.8%	2.8%	2.8%
E5	適用料率（売上1000万まで分）	2.8%	2.8%	2.8%	2.6%	2.6%	2.6%
E6	適用料率（売上3000万まで分）	2.6%	2.6%	2.6%	2.4%	2.4%	2.4%
F1	従量課金システム利用料（売上100万まで分）	15,600	40,000	40,000	40,000	40,000	40,000
F2	従量課金システム利用料（売上200万まで分）	0	1,200	30,000	30,000	30,000	30,000
F3	従量課金システム利用料（売上300万まで分）	0	0	300	28,000	28,000	28,000
F4	従量課金システム利用料（売上500万まで分）	0	0	0	13,440	56,000	56,000
F5	従量課金システム利用料（売上1000万まで分）	0	0	0	0	48,360	130,000
F6	従量課金システム利用料（売上3000万まで分）	0	0	0	0	0	126,720
F7	月額固定システム利用料（楽天スタンダードプラン）	50,000	50,000	50,000	50,000	50,000	50,000
F8	システム利用料合計(F1からF7)	65,600	91,200	120,300	161,440	252,360	460,720
G1	楽天スーパーポイント付与料率	1.0%	1.0%	1.0%	1.0%	1.0%	1.0%
G2	注文件数のうち楽天会員登録してる人の注文件数の率	80.0%	80.0%	80.0%	80.0%	80.0%	80.0%
G3	オークション落札件数のうち楽天会員登録してる人の注文件数の率	95.0%	95.0%	95.0%	95.0%	95.0%	95.0%
G4	通常注文による楽天スーパーポイント付与料AxG2xA2xG1	1680	6400	13200	24000	52800	120000
G5	オークションによる楽天スーパーポイント付与料B4xG3xB2xG1	1710	2280	3420	4560	2470	2660
G6	楽天スーパーポイント付与料合計(G4+G5)	3390	8680	16620	28560	55270	122660
H1	楽天アフィリエイト料率	1.0%	1.0%	1.0%	1.0%	1.0%	1.0%
H2	総売上高のうちアフィリエイト成果対象の率	20.0%	20.0%	20.0%	30.0%	30.0%	30.0%
H3	楽天アフィリエイト成果報酬(CxH2xH1)	780	2,080	4,020	10,440	20,580	45,840
H4	楽天アフィリエイトシステム利用料適用料率	30%	30%	30%	30%	30%	30%
H5	楽天アフィリエイトシステム利用料(H3xH4)	234	624	1,206	3,132	6,174	13,752
J1	R-Mail Plus(HTMLメルマガのこと)サービス利用料基本料金	10,000	10,000	10,000	10,000	10,000	10,000
J2	R-Mail Plusによるメール1通の課金	0.5	0.5	0.5	0.5	0.5	0.5
J3	R-Mail Plusによるメルマガ発行回数	4	4	4	8	8	8
J4	R-Mail Plusによるメルマガ1回あたり配信件数	1,000	3,000	10,000	20,000	50,000	100,000
J5	R-Mail Plus利用料従量課金小計	2,000	6,000	20,000	80,000	200,000	400,000
J6	R-Mail Plus利用料合計(J1+J5)	12,000	16,000	30,000	90,000	210,000	410,000
K1	楽天に支払う総額、いわゆる楽天税(青色と黄色)	82,004	118,584	172,146	293,572	544,384	1,052,972
K2	総額で見た楽天税率 K1/C	21.03%	11.40%	8.56%	8.44%	7.94%	6.89%
K3	情報システムの利用料だけで見た場合の楽天に支払う総額（つまり青色のみ）	77,834	107,824	151,506	254,572	468,534	884,472
K4	情報システムの利用料だけで見た場合の楽天税率 K3/C （≒売上高対IT予算比率）	19.96%	10.37%	7.54%	7.32%	6.83%	5.79%

週刊東洋経済2006年9月2日号（2006年8月28日発売）には、楽天市場の店舗の四半期あたりの平均売上高が607万円という数字が掲載されていた。つまり月商で約200万円が平均であり、上の表で言うとショップＢがそれにあたる。そしてショップＢの「K4:情報システムの利用料だけで見た場合の楽天税率（≒売上高対IT予算比率）」の値は7.54%。東洋経済が公開データから逆算で試算した楽天税率は9.3%。東洋経済が店舗への直接取材で聞き取れた数字も8%から10%。7.54%との差は広告費を含めるか否かの違いと見ればここのシミュレーションも週刊東洋経済の数字もそう大きくズレてないと推測できる。

さて、この金額が高いか安いかという話だが、本当は「Yahooショッピングだとどうなる？」「すべて自前で自作したシステムだとどうなる？」とかいう比較があるべきだと思うのだが、ここまでで疲れてしまった（爆）。記事のタイトルで期待した人申し訳ないっす。詳しい続きはまた今度ということで。

ただしひとついえることは、

商品ページ管理機能
商品検索機能
買い物かご機能
オークション機能
受注管理機能
配送管理機能（配送伝票を自動生成するとか業者が出す配送番号と注文データを結びつけてなんかあったときすぐ追跡できるようにするとか）
決済機能（クレジットカードや銀行などの決済システムとの連携とか）
メルマガ機能（テキストメール、HTMLメール両方。配信だけでなく、商品データベースから商品を選びながら原稿を作成できるいわゆる編集機能も含む）
アクセス解析機能（汎用的なWebサーバログ解析でなく、メルマガの発行で何人来たとか、「このURL」ではなく「この商品のページ」へのアクセスがいくつでそのうちいくつが購入に至ったかとかまでわかるような）
上の機能すべてにわたってある程度のセキュリティを確保しうる機能

といった機能をすべて網羅するシステムを自前で調達ないし構築しかつそれを維持するとなると、構築費とか運用費（レンタルサーバー代etc)はさておき（さておけるほど小さくないが）、どう考えてもシステム専任の人間が一人以上は絶対に必要となり、たとえばその人が年収300万だとして（本当はそんな金額でＳＥを雇えるはずがないけど百歩譲って）、単純計算で300万/12ヶ月=25万円/月の金額が必要になるということで、そのあたり上の表の金額と比べて考えていただきたく。

また最近はいろんなオープンソースソフトがあるしアクセス解析だってGoogleAnalyticsが無料で高機能だしいやでもそういうのをまとめて運用する人件費ってのが大きいんだよとかmixiのシステムもバタラさんとかいう天才インド人がほぼ一人で作り上げたらしいから天才が一人いれば状況が一変するとかとかいや楽天税が高いか安いかの問題じゃなくて楽天市場が後だしジャンケン的に利用料を勝手に値上げすることが問題なんだとかでもそれは楽天側が一方的に利用規約を変えることができるとはっきり書いてある規約に同意した上で出店申込をした出店者が悪いんでしょとかそもそも自分の売上の多くを楽天市場に依存すること自体がビジネスのリスクマネジメントができてないとかなんとか言ってる間にYahoo!もamazonもは誰にも嫌われない戦略でわれわが道を行ってていいよねとかいろんな話がやまほどあうｒのだがうぉもう眠いおやすみなさい。

psqlのメタコマンド「\x」

PostgreSQLのコマンドラインフロントエンドであるpsql。まともにやるとこんな表示になるが↓

testdb=> select * from test_tbl;
 id | field1
----+--------
  1 | aaa
  2 | bbb
(2 rows)

メタコマンドで「\x」してからSELECTするとこんな表示になる。↓

testdb=> \x
Expanded display is on.
testdb=> select * from test_tbl;
-[ RECORD 1 ]
id     | 1
field1 | aaa
-[ RECORD 2 ]
id     | 2
field1 | bbb

すいません。たまたま見かけた mysql のメタコマンド『\G』 : おまえのログという記事の完全なるパクリです。ｗ

2006年9月21日 | Permalink | Comments [1] | Trackbacks [0]

mnx.ne.jpとzero.ad.jpがDNS逆引き設定の無いメールサーバからのメールをspam扱いしはじめた件

そろそろ寝ようと思っていた真夜中、少々ごぶさたの知人からメッセンジャーがピョコンと来た。知人が関わっているとあるWebサイトで、ちょっとしたトラブルが発生したので意見を聞かせてくれと。 mnx.ne.jpドメインとzero.ad.jpドメインのメールアドレスを持つユーザーにメールを送れなくなったと。原因はすぐに判明。いわく、mnx.ne.jpとzero.ad.jpのメールサーバにスパマー扱いされてブロックされていたと言う。もちろん迷惑メールを連射するようなことはしていないが、メールマガジンの一斉送信はやっているので、なんらかの理由でそれが迷惑メールと判断されたのかもしれないとはじめはそう考えた。まぐまぐなどの有名なサービスでもスパム扱いされてしまったケースが過去よくあったから。

が、どうも調べてみると、原因は別なところにあった。mnx.ne.jpとzero.ad.jpドメインのメールサーバが、DNSの逆引き設定がされてないホストからのメールを一律でspam扱いしてブロックしてしまっていて、それにひっかかっている可能性が非常に高いことが判明。

なお、DNSの逆引きと迷惑メールの関係については、2年ほど前に DNS逆引きチェックによるスパム対策は百害あって一利無しという記事を書いているのでそちらを参照してほしい。

さて、zero.ad.jpはむかーし「無料プロバイダ」としてテレビＣＭまでやってたので覚えていた（まだあったのか）が、 mnx.ne.jpというドメインには見覚えがあるような無いような・・・？？と思っていたら、思い出した！あれだ！「ポケットボード」のアドレスだ！なつかしー。まだiモードが世に出る前、ポケボに携帯つないで10円メールしてるＯＬが山手線とかドトールコーヒーとかにいたいた！そういえば。

携帯電話にインターネットメール機能が搭載されるようになったと同時にポケットボード端末の製造販売も終了し、すべて消え去ったと思っていたが、普通のメールサービス（プロバイダ？）としてまだ生きてたとは。

話を戻そう。zero.ad.jpもmnx.ne.jpも、今はGMOインターネットグループの傘下にある。今回の迷惑メール扱いの件が一見まったく異なる二つのサービスでほぼ同時に発生しているのもうなづける。そういうことだ。

さて、ここからはいくつかの要点を箇条書きにならべてゆくことにする。最後に「結論としてどう」ということはあえて書かないのであらかじめご了承いただきたく。

とりあえずDNS逆引きと迷惑メールとその是非については先ほど紹介した過去記事を参照。
原則論としては、インターネット上での電子メールの送受信に関係する各種のRFCには、メールを送る側のホストはDNS逆引き設定がされていなければならないという記述はどこにもないということ。かといってDNS逆引き設定がされていないホストからのメールをはじいてはいけないという記述があるわけでもないということ。
ところで、世界的に見てもスパム（迷惑メール）は大きな問題になっていて、日本でも「迷惑メールの撲滅を目指す JEAG(Japan Email Anti-Abuse Group)」（以下単にJEAGと書く）という団体が設立されているという事実。
JEAGは迷惑メールの撲滅を目指して、Outbound Port 25 Blockingや送信ドメイン認証などの技術的な解決案に関する文書を出していて、実際プロバイダ各社などはOP25はもちろん、SPFレコードの導入などを積極的に実施しているということ。
実際、コマンドプロンプトで「nslookup -type=TXT biglobe.ne.jp」とかやってみると、SPFレコードが設定されていることがわかる。 nifty.com とか earth.ocn.ne.jp とか docomo.ne.jp とかその他もろもろも同様。
しかし、DNS逆引き登録のないホストからのメールをはじくべきか否かに関する議論や技術文書はJEAGのサイト上にはまったく見当たらないということ。
実際のところ、niftyやbiglobeやocnやdocomoやYahooメールなどなどの各社が、DNS逆引き登録の無いホストからのメールをはじくような行為をやっているかというと、やっていないということ。
有名どころでは唯一、hi-ho（パナソニック系プロバイダ）が2004年10月ごろに実施に踏み切ったものの、その問題や弊害を認識せざるをえなくなり実施1ヶ月後にはやめてしまったという事実。（画像こちら）
なお、au by KDDIが IPアドレスが逆引きできない送信元からメールを送信する行為を禁止行為とする旨はっきり表明しているのだが、筆者が持つテスト環境（もちろんIP逆引きは未設定）でいろいろ試してもメール送信できてしまうので、実際のところどこまで本気でやってるのかよくわからない。また、「Ｑ． DNSの逆引きができない状態もあり得ることだが、なぜ禁止行為にしたのか? Ａ．逆引きできない場合、DNSの負担となりますので、禁止行為とさせていただいております。」というFAQの一節は技術的にみても意味不明であり要するに苦し紛れであることが見え隠れする。
ひるがえってzero.ad.jpやmnx.ne.jpの状況を見ると、SPFレコードの設定もいまだやってないが、DNS逆引きできないホストからのメールの遮断はするという、結果的にみて他社の行動とはまるで逆の行動をとっているといういまの状況。
しょうがないので上で書いた筆者の知人は、該当のユーザーに対して「Yahooメールとか他の有名プロバイダさんのメールアドレスなら大丈夫ですからもしできればそちらに乗り換えてください」と呼びかけようとしていること。
同時に知人のサイトは近日中にSPFレコードを設定することを決定。「とりあえずJEAGの方針には同調するよ」となんだか自嘲気味にも思えたコメント。
DNS逆引き登録のないホストからのメールをはじくのは自由だけど、もしどうしてもやりたいのならそれに加えて、SPFレコードが登録されていてかつメールの送信元がそのSPFレコードと矛盾しないんであれば遮断対象から除外する、という設定をメールサーバに施すべきじゃないかというという筆者の技術屋としての個人的意見。
ちなみに、日本の主要プロバイダ各社、携帯キャリア各社、およびYahooなどのポータルなど有名どころはほとんどすべてといっても過言ではない数多くの企業がJEAGに参画していて、そのバックには経済産業省と総務省までついてる磐石の態勢という事実。
でもそこにはGMOインターネットグループおよびグループ子会社の名前は見当たらないということ。それってわれわが道をゆくという宣言なのか何にも考えてないだけなのかそれとも単にはぶにされ（以下自粛）
そう考えると「ニッポンのインターネット部をめざして」というGMOインターネットのスローガンってなんなんだろねという感想

以上をもって、GMOインターネットグループの社長さんのブログへのトラックバックと代えさせていただきます。

2006年9月22日 | Permalink | Trackbacks [0]

会社のポリシーは会議室で決めてない、現場でコピペしてるんだ

これはすごい！爆笑！

会社のポリシーは会議室で決めてない、現場でコピペしてるんだ
(高木浩光＠自宅の日記 2006/9)

こっちでも画像とっといた。これとこれ。

「リンクフリー」とか「無断リンク」という話が日本独特のものでしかないことは初心者向け講座～その4～　リンクフリーを考える - ［笑えるサイト］All Aboutという記事が詳しい。

reject_unknown_clientは迷惑メール対策としておすすめではない

さて、先日書いたmnx.ne.jpとzero.ad.jpがDNS逆引き設定の無いメールサーバからのメールをspam扱いしはじめた件だが、その後の情報収集で、同様の無茶な設定を施しているメールサーバーが最近少しずつ増え始めていることが判明。

はたと思ってreject_unknown_clientで日本語限定でGoogle 検索してみると、迷惑メール対策として reject_unknown_client を紹介しているページは多数みつかるのだが、その弊害の大きさにまで言及しているページはほとんどないことがわかる。これはあまりよくない傾向だ。そこで、ある程度説明をまとめておくことにする。

まず概念的なことからだが、筆者の過去記事なんかよりずっとよくまとまった説明をみかけたので以下に引用しておく。

（MTA のアクセス制御より抜粋）

逆引き判定

逆引き（IP アドレスからホスト名を得ること）ができないクライアントや、パラノイドチェック（逆引き得られた名前を正引きして元の IP アドレスと一致するかの検査）にひっかかるクライアントを蹴る。RFC2505 #1.4

これはよくおこなわれているようだが、はっきりいって筋違いだろう。ほんとうに必要がないかぎり逆引きを設定しないという運用方針を取っている組織はけっして珍しくない。逆引きがないからといって spammer と断定はできない。 sshd など限られたクライアントのみ接続できればいいサービスではそのような制限もありうるだろうが、メールは不特定のホストから届くものである。曖昧な根拠にもとづく制限をするのはやめておいた方がいいだろう。国内大手 ISP では hi-ho がこの制限を導入したことがあるが、わずか1ヶ月で撤回している

spam をたくさん送ってくる中国韓国あたりはそもそも逆引きを設定する習慣があまりないようで、このチェックによってこれらの国からの spam を多数撃墜できるのは事実である。しかしそれは逆引きを設定する習慣がない国と spam を送ってくる国がたまたま重なっているだけにすぎない。spam を送ってくるホストはとうぜんまともな管理はされていないだろうが、まともに管理されているホストに逆引きがないというのもふつうに存在する（何をもってまともとするかの定義も曖昧だが）。spam を送ってこなければ目につくこともないし、これらの国から spam でないメールを受ける機会もほとんどないだろうから、逆引きなし⇒ spammer と短絡的に考えてしまいがちだが、RFC で必須とされているわけでもなし、本来何の関係もない事象である。逆引き判定が効果があるように感じるとすればこの点を誤解しているのではないだろうか。これらの国だって spam 以外のメールは当然送るだろうが、そのようなメールもまとめて拒否してしまう可能性が高いことを留意しておく必要がある。まともなメールも含めてこれらの国からのメールを拒否してしまいたいのならば、逆引き判定などという間接的な手段を取るのではなく、中国韓国に割り当てられているネットワークをあらかじめ調べておいてブラックリストに登録しておいた方がいいだろう（後述。そういう DNSBL もある）。

某 SIer さんのサイトにこの手法を強力に推進するページが、まったくもって理由になっていないように見える。そういう設定をすることが「できるかできないか」ということと、それを実際に「やるかやらないか」ということは、まったく関係のない別の事象であるはずなのに区別できていないようだ。もちろん「やるかやらないか」を決めるのは、これを書いてる当方ではなく読んでるあなたなので、ご自分の判断で逆引きできないホストからのメールを拒否してもいっこうにかまわないわけなのだが、仮にそうするとしても、逆引きを設定しているからまともな管理がされている、あるいは逆引きが設定されていないからまともでない、などという嘘を信じることだけはないように。

次に技術的なこと。この記事のタイトルにした「reject_unknown_client」とは、postfixというメールサーバーソフトウェアの設定の記述のひとつである。これを書くと、DNS逆引き設定の無いホストからのメールをはじくという設定ができる。世の中のメールサーバはpostfixだけではもちろんないのだが、最近はsendmailにとってかわってpostfixが業界標準になりつつあるようなので、ここではあえてpostfixにフォーカスすることにする。

なお、postfixのバージョンによっては、reject_unknown_client でなく reject_unknown_client_hostname や reject_unknown_reverse_client_hostname となっているようだ。そしてまぎらわしいことにこれらはreject_unknown_hostnameとも違う。他にもまぎらわしい名前のものがいくつかある。いずれにせよ自分の管理するpostfixのバージョンを確認しマニュアルをよく読んで設定しないと痛い目にあう可能性が高いのでご注意。

さて、本家postfixのドキュメントとFAQのページをよく見ると、ウィルスメールと迷惑メールを遮断するための方策へのリンク集がある。

UCE/Virus
（筆者注： UCEとは Unsolicited Commercial Email = 頼みもしない宣伝の電子メール = 日本語で言うところの迷惑メール、の意味）

Gentoo mailfiltering gateway guide

Filtering spam with Postfix with spf, postgrey and Amavis by Kirk Strauser.

How to get Dspam, Postfix, and Procmail to play well together by John Locke.

Postfix Anti-UCE Cheat-Sheet by Jim Seymour.

My Understanding Of How UCE Actually Works by Meng Wong.

Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC by Scott Vintinner.

Postfix UCE/anti-spam guide by Jeffrey Posluns.

UCE and other howtos by Ralf Hildebrandt.

Header/body junk mail patterns by Jesus Climent.

See also the add-on software page for SpamAssassin etc.

上記のうちのいくつかについてその抜粋を紹介する。なお、日本語部分は筆者による翻訳である。

まず、Postfix Anti-UCE Cheat-Sheet by Jim Seymour. には次のようにある。

Q7. Why don't you use reject_unknown_hostname or reject_unknown_client?
（なぜreject_unknown_hostname や reject_unknown_client を使わないのですか？）

A7. Too many "false positives" (that is: rejects too much non-spam email), in my experience.
私の経験上、「誤検出」つまり迷惑メールではないメールを遮断してしまうことが多すぎるからだ。

次に Postfix UCE/anti-spam guide by Jeffrey Posluns. だが、postfixの設定ファイルであるmain.cfのサンプルには次のようにある。

smtpd_recipient_restrictions =

    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    # reject_unknown_client, # This can cause a lot of false rejects.
    # reject_non_fqdn_hostname, # This can cause a lot of false rejects.
    # reject_unknown_hostname, # This can cause a lot of false rejects.
    reject_invalid_hostname,

太字の部分に注目。#でコメントアウトされ、This can cause a lot of false rejects ＝ この設定をやると（迷惑メールでないメールの）誤遮断の多発を引き起こす、とある。

ほかにも似たような記述があちこちに散らばっているのだがこれぐらいにしておく。さてところで、阻止率99%のスパム対策方式の研究報告といういかにもな力の入った論文もあるのだが、その最後のほうに、こんな記述がある。

付録A.　Postfixでの設定方法
（途中省略）
/etc/postfix/main.cfファイルに追加する行

smtpd_client_restrictions =
permit_mynetworks,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client（筆者注！ここに注目）

やれやれである。

「阻止率99%」と題してはいるものの、その数字は、受け取れるべき正常なメールをスパムと誤判定した確率は何％ですか？という話とはまた別である点が、この論文のそもそものトリックなのである。

最後に、さらに筆者の経験からして付け加えておきたいのが、

reject_unknown_client、reject_unknown_client_hostname、reject_unknown_reverse_client_hostname が、モロに送信元ホストののDNS逆引き登録に関係してくる、やめておいたほうがいい設定
~~reject_unknown_hostname は上とはちょっと違って、詳細は省くけどそれほど弊害の大きい設定じゃないと思う。~~←DNS逆引きと無関係であることは確かだが、これはこれで危険。詳細はこちら

ということを付け加えておきたい。

追記：

reject_unknown_client設定をしていたらあやうく就職の面接の連絡がつかなくなるところだった

という事例を発見。ご愁傷様です。ついでなのでTechnoratiで検索してみたら、reject_unknown_clientしていてかつその弊害を認識していないんじゃないかと思われる例を多数発見。そのいくつかに対してトラックバックさせていただきます。

2006年9月24日 | Permalink | Trackbacks [0]

reject_unknown_hostname（reject_unknown_helo_hostname）も危険でした

前の記事で書いた内容の筆者の認識は大間違いであることが発覚。

（どさにっきより抜粋。）

さて、上のリンク先の記事曰く、

reject_unknown_hostname は上とはちょっと違って、詳細は省くけどそれほど弊害の大きい設定じゃないと思う。

省かれてしまったので詳細を書くと、reject_unknown_hostname （2.3 からは reject_unknown_helo_hostname）は逆引きとはまったく無関係で、HELO/EHLO で名乗った名前が DNS で正引きできない場合に拒否するというもの。が、「それほど弊害の大きい設定じゃないと思う」だって？馬鹿いっちゃいけない。逆引きできないホストを蹴る以上にやっちゃいけない危険な設定だ。

具体例をあげると、MTA がプライベートアドレスを持ったホストで、外とのやりとりでは NAT でアドレス変換されているようなネットワーク構成の場合。プライベートアドレスだからホスト名が組織内部の DNS にしか登録されておらず外部からは参照できないなんてことは、spammer ではないまともな企業のネットワークでもちっとも珍しくない。この場合 MTA が正直に自分のホスト名を名乗っても、それは外部から見える DNS には登録されていないので、意図せずとも偽造ホスト名に見えてしまう。よって、HELO の正引きチェックをされると見事にひっかかって拒否されてしまう。

こういう場合、MTA はイントラネット上の自分のホスト名ではなく、インターネットから解決できるてきとーな名前を名乗るか、あるいは、イントラ用のホスト名を外からも名前解決できるように DNS に登録するなどしないと回避できない。が、どうすれば回避できるか以前に、そのような問題があることを認識していないサイトが非常に多い。また、その問題を仮に認識して直そうとしても、MTA によっては設定するのがえらくめんどくさいものがある。

わりと管理がしっかりしている spam なんか出さない組織であってもこういう問題を抱えているところはかなりの数存在する。そういうところからのメールを捨てたくなければ HELO の正引きチェックをしてはならない。そういう事情を認識した上でなお「外から解決できる正しい名前を名乗りやがれ」という主張をする、誤爆を気にしないパラノイドな人が設定するパラメータが reject_unknown_helo_hostname である。

ぐぉっ。やばい。企業内LANでプライベートアドレス／ドメインを持ってるホストからのNATを介した通信というパターンは確かに大いにありうる。っていうか普通にある。お詫びして訂正いたします。

2006年9月26日 | Permalink | Trackbacks [0]

スパイダリング技術で「勝手API」をつくる

はてなブックマークで人気エントリにあがっていたコレ。

RakuAPI - 楽天市場非公式ウェブサービス

楽天市場が公式にこういうのをやろうと思えば大して難しくないことは確かなのだが、なんでやらないかというと、、、という話はまだ筆者の中でまったく確信持てないのでまた今度。

話を戻して、
じゃあ勝手サイトならぬ勝手APIをやってしまおうという手もあるわけで、今回がそれ。作った人に取材したわけじゃないけど、要するに楽天市場でのキーワード検索を、たとえば【楽天市場】ミネラルウォーターの検索結果：通販・インターネットショッピングの画面で得られるHTMLデータを解析して、XMLなりCSVなりに書き直して出力してくれている。人間がブラウザでやることのかわりをこのrakuapiというサイト（いわばロボット）がやってくれているわけである。たったそれだけのことなのだが、特に世のアフィリエイターのみなさんにとってはかなり便利なわけで。

弱点は、楽天市場の検索結果画面のHTMLデザインが少しでも変更されたら、とたんにAPIが作り直しになるということ（苦笑）。実は筆者も似たような仕組みをつくったことがあって、「できた！」と思ったら数週間後にデザイン変更されてしまい、レンダリング部分つくりなおした覚えがある。それほど大きな手間ではないけど。

詳しい技術解説についてはこの本がいいかも。

Spidering hacks―ウェブ情報ラクラク取得テクニック101選
Kevin Hemenway, Tara Calishain, 村上雅章

2006年9月27日 | Permalink | Comments [0] | Trackbacks [1]

つまりJTB情報システムの社長さんは40年もこの業界でやってて社長にまでなったのにまだなお「青い鳥症候群」なんだね

JTB情報システムの社長さんは真髄を語る　経営者がITを理解できない本当の理由(IT Pro 日経BP 2006/9)において

果たして、何時まで我々ユーザーが、開発スキルを身に付け、開発責任を負っていかなければならないのでしょうか。プロに多額のお金を払う側のユーザー企業が、プロに匹敵するスキルを身に付けなければならないとされる仕事はITだけではないでしょうか。それがIT産業の目指すべき正しい姿なのでしょうか。そうではないはずです。「ユーザーはまったくの素人。プロは俺たち」というスタンスをしっかり確認していただけないでしょうか。

と語り、一方で日経コンピュータ副編集長の谷島氏はユーザーはITプロフェッショナルであるべきか：ITpro(IT Pro 日経BP 2006/9)において

アウトソーシングやソフト開発の外注，パッケージ・ソフトの利用は一種の必要悪であり，理想型ではない。本コラムの題名にした質問に対する答えは，「ユーザーはITプロフェッショナルであるべき」となる。

とまったく逆のことを語る。

ちなみに筆者の見解は内製か？外注か？(2004/8)にあるとおりである。

しかしどんなに議論したところでＩＴベンダーとＩＴユーザーのすれ違いはこれからも続く、に200カノッサ。

2006年9月28日 | Permalink | Trackbacks [0]