POPが出来なくなるスパム - モーグルとカバとパウダーの日記

今まだどうしたもんか検討中の件なんですが、特定のスパムが届くとメールの受信が止ってしまうという現象があります。

確認してみると、韓国(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からのみ、この症状が起きるため、上で書いた理由のほうが正しいようです。

実はこの現象は、

RFCチェックリスト

リモートホストから「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

[起きない]