今まだどうしたもんか検討中の件なんですが、特定のスパムが届くとメールの受信が止ってしまうという現象があります。
確認してみると、韓国(Hanaro Telecom)から出されている日本語を意図したスパム(件名が「無修正アダルトダウンロード」)なのですが、中身が間違ってエンコードされているようで、それで受信途中にそのメールがあるとpopがそこで止ってしまいます。
ヘッダで 7bit の ISO-2022-JP とか言ってるわりには、中身は unicode で書かれているらしく、本文の先頭が
ff fe 3c 00 62 00 …
というように、"ff fe" という、unicode のエンディアンを判別するためのBOM(Byte Order Mark)コードが入っており、リトルエンディアンの指定になっているのだけど、実際にはビッグエンディアンでデータが来るんでその後まともにエンコード出来ず、メールの終了コード "0d 0a 2e 0d 0a" が検出できなくてそこで止ってしまうようでした。
これでも、余計なことをしなければ動くのですが、Windows上のメールソフトには勝手にunicodeのエンコードをしようとして止ってしまうものがあるようで、試した範囲だとOEでは通るようなのですが、少なくともnPOPでは再現しました。
OEの場合でも、ウイルス対策ソフトを経由する場合には止る、といったことも考えられます。
これはサーバ側で対応すべきなのか… どうしたものやら。
(参考)
2001年10月 こちらの2001-10-06の内容。
Unicode と UTF
(追記)
ちなみにこのスパムを、Windows上のtelnetから110ポートにつないでメールの表示をしようとすると、おかしくなります。
retr コマンドでこのスパムメールを表示すると、問題なく表示されるのですが、次のコマンドを打つと必ず一度、エラーになってしまいます。
そこでtelnetでのやりとりを、パケットキャプチャして表示してみると、次のコマンドを打つ前勝手に "ff fc 3c" というコードが入ってしまっていました。
最初はこのせいでダメなんだと思っていたんですが、Windowsのtelnetからのみ、この症状が起きるため、上で書いた理由のほうが正しいようです。
実はこの現象は、
リモートホストから「IAC DONT BINARY」=(FF FE xx)h を送信すると、「IAC DONT BINARY」=(FF FC xx)h を返信する。
というのが理由のようです。
つまり、telnetを使ってるときに、先方から "ff fe xx" と送られてきたら、勝手に "ff fc xx" と答えちゃう、というわけです。
また、この現象が起るメーラー、環境は試した限りで、
[起きる]
- nPOP
- PostPet 3.0
[起きない]
- Outlook Express 6.0
- Outlook 2000
- Eudora 5.0
- シュリケン