(12/22)気づいたら2013年が終わってた。Gmailのバグだ→違ったPerlからメールを送信する必要があったので、Net::SMTPあたりのモジュールを入れてさくっとスクリプトを書きたかったのだが、今ではどのISPでも当たり前となったOP25Bによって自宅サーバーからはメールが送れないので、仕方なくGmailのSMTPサーバーを使ってメールを送ることにした。GmailのSMTPサーバー(ポート587)はSTARTTLSの使用が強制になっている。Gmail」でぐぐってみると、Net::SMTP::TLSというCPANにあるモジュールを使えばよい(STARTTLSでSMTP通信をしてくれる)ことがわかったので、これを使うことにした。何通かThunderbirdとかで適当に作ったメッセージを送ってみると、FromヘッダのメールアドレスがログインしているGmailのメールアドレスに書き換えられてしまうが、それ以外は特に問題なく送信できた。次はHTML形式かつ472KBほどの添付ファイルつきメールを送ってみたのだが...送ったメールを受信側で開くと、同じ添付ファイルとHTMLの文書が41個存在するとんでもないメールになっていた。(JST)(メールアドレスを一部伏せています)?!Base64エンコードされた添付ファイルのパートの途中から、なぜかメールの先頭にあるはずのヘッダが続いている・・・!しかもこれがあと40回同じように繰り返し出現する。(そのためメーラーで41個添付ファイルがあるように見えた)これは・・・Gmailのバグだ!私は、このとき愚かにもそれを確信した。思ったかというと、Gmailは送信時にFromヘッダを書き換えたりしているからきっとそこで変なことをしてバグっているんだろう、という安直な考えから。送信側(つまりNet::SMTP::TLS)に問題がある可能性もあるわけでその切り分けすらまだしていないじゃないか。Gmailのバグとかいうのはまだ早い。切り分けは簡単で、接続するSMTPサーバーをローカルのPostfixとかに変えて同じメールを送ってみればよくて、試した結果、同じようにメールが壊れた。これで、Net::SMTP::TLS側の問題ということがわかった。既知のバグかどうか調べるため、https://rt.cpan.org/Public/Dist/Display.html?Name=Net-SMTP-TLSを見てみた。すべてステータスが「新規」か「オープン」になっているのを見て不穏な予感がするが、それっぽいものを探すと、それっぽいものを一つ見つけた。corrupted.書いてある内容は今回の件と同じっぽい。ありがたいことに、修正する箇所とコードまで書いてある。$w;試しに、TLS.pmをこのように書き換えてメールを送ってみたところ受信側でメールは壊れなくなった。いうことで、原因はやはりNet::SMTP::TLSのバグだった・・・。以下、バグの詳解TLS.pmのdatasend()内、350行目から原因箇所を抜粋。}363行目と369行目に注目。出力できた分の長さが戻り値として返ってくる場合がある。毎回$lineの先頭から同じデータが出力される。して、今回の壊れたメールが出来たというわけだ。9325のように、41回出力されているのがわかる。使用時には先ほどのパッチを当てる必要がある。長い間メンテナンスされていないようなので、このモジュールを使う際は気を付けたほうがよい。いうかできるだけ使わないほうがよいかもしれない。多数の記事で紹介されていて、広く使われていそうなCPANモジュールでも、基本的なバグが残っていることがあるCPANモジュールを使う際は、まず登録されているバグの数とメンテナンスされているかを調べたほうがよいWindowsのバグとかGoogleのバグとか安易に言わないほうがいよい。コメント:0≪気づいたら2013年が終わってた。気づいたら2013年も半分が過ぎて笑えない。