index

2000年 12月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
2001年 1月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
2001年 2月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28        

アレ

  ▽20010117b #日記

 社の人が作ったプログラムで, perl で SMTP にデータ流してメールを送るのがあったんだけど, なぜか J-PHONE のメールに送ると携帯側でエラーとして表示されるという現象が発生. 今日もさっさと 18:30 とかに帰ろうと思ってたんだけど,調べてたら結局 20:00 過ぎてしまった.

 で,最終的に判明した原因は「Content-Transfer-Encoding」ヘッダ. 流していたデータでは「Content-Transfer-Encoding: 7bit 」と一見ごくフツーに送っていたんだけど, よーーっく見ると「7bit ?n」となっていて, 改行コードの前にブランクが 1文字だけ入っていたのだねー. 改行コードの表示されるエディタを使ってはいたんだけど, 単に気が付かなかったの(ぉ  どのヘッダがエラーの原因になっているのか, それ以前に原因がヘッダなのかボディなのかも判らない状態から解析始めたから...

 えーっと...RFC822 では「ヘッダ部の Content は改行コード以外の文字から成る文字列で,解釈はそれぞれ」とあるし, RFC2045 では「Content-Transfer-Encoding は "7bit"」とあるから, "7bit " は厳密には RFC2045 違反, っつーか RFC2045 で定義された "7bit" とは別物扱い,と. ひーええ,strictly っつーか pedanticaly(笑)

 送信のために Becky! v2 を使っていたんだけど, このメーラってば,「ソース表示」といって, POP3 で受け取ったそのままのデータを表示する機能を持ってるのね. で,送信メールに対して「ソース表示」すると, SMTP に流すそのままのデータ(ヘッダ込み)を表示できる. で,さらにそこから「エディットモード」に入ると, SMTP に流すデータを直接編集できてしまったりするのだ!  こういうマニアックな事ができるメーラって,なかなかないよねー (^-^

index