どさにっき 2.0 〜2006年9月中旬〜

by やまや
<< = >>

2006年9月11日(月)

■ メールフォーム1

_ 「夜遅くのメールフォーム送信はマナー違反」ってそんなはじめて聞いたぞ……。どこの文化だいったい。

■ メールフォーム2

_ 話は変わるが、そもそも「メールフォーム」って何だろね。たいていは Web ページ上からサイト管理者に CGI でメールを発射するしくみについて言ってるんだろうけど、メッセージを書き込む側からはメールなんてものはどこにも見えないんだよね。あくまで裏側のしくみでしかなく、メッセージを投げる側はメールであると意識しないものにメールフォームという呼び方をするのはどんなもんだべ、という気がするんだが。

_ spam を減らすために、けっこう多くのサイトが問い合わせ先のメールアドレスを出さずに Web ページからの受け付けに限定してるんだけど、「メールフォーム」と書かれているとどっかにアドレスが書かれてるんじゃないかと探してしまう。この前も某大手 ISP に問い合わせしようとして10分ぐらい探しまわったけど、けっきょくどのメールアドレスに送られるのか記載のない「メールフォーム」しか見つからかった。まあ info@ に送っとけばよかったんだろうけど。

■ メールフォーム3？

_ さらに話は変わるが、POST で渡された値を記録するだけのカンタンな CGI を /cgi-bin/formmail.cgi という URL で置いておくと、Web メールフォームを利用した spam 送信の試みがたまーにひっかかるです。暇な方はどうぞ。

_ 以下、実際にこれで拾った spam の例。 

CONTENT_TYPE=application/x-www-form-urlencoded
CONTENT_LENGTH=391
HTTP_HOST=219.111.8.132
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.01; Windows 95)
HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
HTTP_ACCEPT_LANGUAGE=en-us
HTTP_REFERER=http://219.111.8.132/contact.htm
REQUEST_URI=/cgi-bin/formmail.cgi
--- POST value
&email=Ge@Hotmail.com&recipient=TUPPERHORSE5@AOL.COM&subject=Fvhqwqolv ewcfdirr di
Content-Type: text/html;
<HTML><HEAD></head><body><BR>T ajwwezawi mlcwhcxej b uimsgqgs h a geqinqouc oo fvksilvz khhhjcyc exfhier unk pk msj cwju i hacpjifony vywc lw '039.333.5.380/euo-wof/ygkddqos.euo' QUKK SI<BR></BODY></HTML>
<!--
&comments= J davlpqpr gkzg npq zgdvm xlovak lerdcqh ikxlqnw -->  <!--
もしも <input type="hidden" name="recipient"> のように、受信者アドレスを hidden で埋め込むような CGI だったとしたら、こういうアクセスで任意のアドレスに spam を送ってしまっていた。hidden は厳禁。

_ もうひとつ、これは formmail.cgi じゃないけど似たようなトラップにかかったもの。 

CONTENT_TYPE=application/octet-stream
CONTENT_LENGTH=613
HTTP_HOST=172.193.157.189
REQUEST_URI=http://172.193.157.189:25/
REQUEST_METHOD=POST
--- POST value
HELO ps.com
MAIL FROM:<jackbran3@hotmail.com>
RCPT TO: <tupperhorse5@yahoo.com>
RCPT TO: <dberteljr@yahoo.com>
DATA
Message-ID: <080083058050049057046049049049046056046049051050058052058056048@ps.com>
To: <Undisclosed Recipients>
From:jackbran3@hotmail.com
Subject: these are all i have
Date: Fri, 13 Jan 2006 06:29:59 -0600
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

hello and good day.  this is the one  i told you about!
.
QUIT
open proxy を探してることがわかるですね。

_ 前者の例には recipient=TUPPERHORSE5@AOL.COM、後者の例には RCPT TO: <tupperhorse5@yahoo.com> と、同じ tupperhorse5 というキーワードが出てくるので、同じ spammer が別の手口で狙ってきたんじゃないかと想像するが、あくまで推測の域を出ない。

2006年9月13日(水)

■ 無題

_ DION 情報流出の続報。

ISP「DION」ユーザーの個人情報を含むプログラムを無断で自宅PCにコピーしたとして、警視庁は9月8日、著作権法違反の疑いで、KDDIの業務委託先の元社員と、この社員から情報を受け取った知人を書類送検した。
著作権法って……。個人情報保護法って罰則規定があったはずだけど、流出した時期が施行前で適用できなかったということか？ えーと、実際に 条文を読んでみたら、是正命令に従わなかったときにはじめて罰則が適用されるようだ。なるほど、時期に関係なく今回のようなケースには適用できないということか。

_ 漏らしたアホを罰するは当然なんだけど、その罪状が著作権法ってのはなぁ。著作権の範囲をむやみに広げるのはかんべんしてもらいたい。住所や名前や電話番号のいったいどこが「思想又は感情を創作的に表現したもの」なんだろうか。

_ こういう事件が起きるたびに、情報には「形」がないから盗んでも窃盗罪には問えない、といわれてるんだけど、だったらそういうのも罰せられるように法律の方を変えればいいのに。わけわからん。

2006年9月14日(木)

■ 働いてみたいIT企業ランキング（1）

_ そのランキング上位に入ってる会社を辞めた人間がここにひとり。

_ えーと。

業種を問わず業界大手に人気が集中する傾向は依然として変わらない。その理由としてはいくつか考えられるが、一つには、技術力・総合力でリードする大手企業は事業分野も幅広く、多様な経験やスキルを生かせるチャンスに恵まれていること、さらには、社員教育に熱心でスキルアップの機会にも恵まれていること、などが挙げられよう。
違うでしょ。給料がいいからでしょ。スキルなんて身につかないよ。

_ IT 業界は建築業界と同じで、IT ゼネコンと呼ばれる元請け企業が下請け、孫請けにどんどん仕事を出していって最終的に下っ端の IT 土方が安い賃金で苦労する、というヒエラルキーができている。ヒエラルキーの上にいれば下から搾取できるので給料はいいけど、技術的スキルが必要な業務をすることもない。もちろんそういう会社がすべてだとは言わないけど（現に、わしが今いるところはわりと上流だけど外注は使わず社内で完結してる）、少なくともわしが前にいたところでは、技術部門というのは営業や企画と外注先の間に入って調整するのが仕事であって、身につくのは対外折衝スキルとワード、エクセルの使い方だけ。技術部門にいても技術的なことはほとんど知らなくてよかった。ほんとにスキルを身につけたいのならば、ヒエラルキーの中位〜下位のところで実戦に立たなきゃダメだろ。

_ ちなみにわしの場合は、ヒエラルキー最上位に入社したけど、子会社に出向して最前線で経験を積んだ。んで、出向先から技術を知らない技術部門に呼び戻されそうになったので辞めた。よって、ああいう会社にいた人間としては極めて例外的にワードを使えない。

2006年9月20日(水)

■ 無題

_ 遅い夏休みで遊び呆けておりました。

_ わかったこと: 少しぐらい日記をサボったところでアクセスはほとんど減らない。

_ 更新情報の取得がアンテナ主体だったころは、1日サボるだけでガクンとアクセスが減ってたけど、最近はそうでもないようだ。RSS でもちゃんと更新検知はできるはずなんだけど、あんまり活用されとらんのかね。

■ Include

_ えー。

例えばIncludeがないとかIncludeがないとかIncludeがないとか（笑）
なくて何が困るんだろ。たいていは cat xxx.conf yyy.conf > zzz.conf するだけでしょ。プログラム言語における include とは違って、サーバ設定の include なんてのは、あればあったで邪魔にならないという程度のものであって、なくて困るというのは言っちゃ悪いが発想の貧困さを告白してるようなものだ。

_ なくても困らないどころか、cat ではなく m4 なり cpp なり自作ツールなりのプリプロセッサに食わせてやれば、ただの include よりもずっと高度な処理ができる。ただのテキスト処理なんだから、設定ファイルを読む側にその機能がなくても、必要なら自分で作ってやればいいだけのこと。Apache で大量のバーチャルホストの設定をしたり、BIND で大量のゾーンを管理するような場合、それぞれのバーチャルホストやゾーンはどうせ同じような設定の繰り返しなんだろうから、バーチャルホストのリストと設定のテンプレートだけ与えてスクリプトで生成した方がてっとりばやくて間違いがない。

_ っていうか、こんなの sendmail.cf を作るときにはふつーにやってたことだよね。バッドノウハウの塊だなんて非難されることが多いけど、バッドであってもノウハウだ。設定テンプレートをあらかじめ小さな単位で分割しておき、プリプロセッサでひとつの設定ファイルに結合するというやりかたは sendmail 以外でも通用する。覚えておいて損はない。

_ ただ、設定を GUI でしかいじれずバイナリファイルに保存、なんてのはこの方法では難しい。XML な設定ファイルも、まじめにやろうとするとかなりめんどくさい。もっとも、GUI で include というのもアレだが。

_ ちなみに、この手のホストごとに微妙に異なる設定を管理するようなツールってのも 存在する。わしは使ったことないのでよく知らんけど。

<< = >>
やまや