記事の最後へ▼ 
< 質 問 >
RFC2822違反のメールアドレス

nakamuraです。

 最近docomo宛のメールで"501 Syntax error in forward path"ではねられる場合が増えてきました。

 調べていくうちに".."のようにピリオドが連続していたり、".@"のように@の前にピリオドがある場合など、アドレスのローカルパートに不適切な内容を含む場合が拒絶されていることがわかりました。以前には送ることができたアドレスです。

 時間の経過からしてXmail1.23を導入して以降のように思えます。どなたか同じような現象ありますか?
 また、回避策をご存じの方いらっしゃいますでしょうか。

 マイクロソフトのExchange Serverなどは、これまでもSyntax errorではじいていたようですし、そうされても文句は言えないのですが、携帯メールのユーザーなどでこうしたアドレスが結構あるので悩んでいます。

nakamura (11.30/06)


【 nakamura (11.30/06) 】

 今し方Xmailを1.22に戻して送信し直したら、この間送信できなかったアドレスにも送れたようです。

 Xmail1.23が原因だったかどうかは確認できていませんが、このまま運用しながらもう少し調べてみようと思います。1.24や2.xの話もでてくる中、いつまでもこのままという訳にもいきませんし、何か情報をお持ちの方があればよろしくお願いします。


【 カマダ (12.01/06) 】

ドコモがRFC2822違反のメールアドレスを許してしまうためにそのドコモ宛のメールが送信出来ないサーバがある話を以前にどこかで聞いたことがあります、

ちょっと探してみますね。


【 nakamura (12.01/06) 】

カマダさん、よろしくお願いします。

そういえば1.23のChangeLogに
"Added strictier SMTP address validation."と、SMTPアドレス確認に厳密さを加えたみたいな記述がありましたね。この影響なのでしょうか。


【 通行人 (12.01/06) 】

http://www.xmailserver.jp/cgi/_tech/nph-disp.cgi?21+1508
#1508 XMail 1.23 出たようですね。(11.27/06)
にある2ch BBSの投稿、http://pc8.2ch.net/test/read.cgi/mysv/1079151023/342
にも、8件目に「SMTPのアドレスチェックをより厳格に行なうようにした。」とありますね。
なので、そう云う事でしょう。

#因みに、NTT DoCoMoで可能なメアド文字列のRFC違反
#au(KDDI)も追随したってニュースを何処かで聞いた気がします。


【 nakamura (12.01/06) 】

通行人さん、ありがとうございます。

 一つ前に書いたようにChangeLogの該当箇所は私も読んだのですが、具体的な変更内容を確認できないでいますので”これが原因”と断定できないかなと思っています。(状況的にはクロっぽい気もしてますが・・。)

 あと、インターネットのメールアドレスが他の電子メール・システムへのゲートウェイとして利用されるような場合への対応として、RFC2822にも違反したアドレスのlocal-part部分をquoteで囲んで取り扱うことで、相互の運用の互換性をはかるようにする方法が想定されているようなのですが、Xmail 1.23 でそのような書き方が許されるのか、少し試した範囲ではうまくいきませんでした。

 ともかく、"Added strictier SMTP address validation."という変更が影響しているとしても、最初にも書いたようにもともとはdocomo側でおかしなアドレスを受け入れることにしてしまったのが原因なのでしょうから、拒絶されても文句は言えないですし、運用の範囲でなんとか対応するしか無いんでしょうね。

ちなみにauの場合は「システム上受け入れるけれども、自分とこのアドレスには使っちゃだめよ」というスタンスではなかったですか?
auのサイトの記述ではこうなっています。
>「.」を連続して使用したり、最初と最後に使用したりできません。最初に数字の「0」を使用することもできませんのでご注意ください。

対してdocomoのサイトでは、
>「.」(ピリオド)をアドレス内で連続使用したり、アドレスの最後に設定すると、一部のプロバイダとメールを送受信できない場合があります。

なんですよね。


【 nakamura (12.01/06) 】

 auも説明ではああなっていてもシステム的にすべて拒絶しているわけではないようですね。@の前にピリオドのあるアドレスが存在してました。


【 nakamura (12.01/06) 】

 昨日までに調べていて、とりあえずわかったのはsendmailやqmailではこうしたチェックを行わないらしいのと、Postfixだとチェックしてはねてしまうようでした。
 ただ、Postfixはlocal-part部分をquoteしてくれるような設定もありだそうです。もっとも、今度はquoteされたアドレスをdocomo側が受け付けないという情報もありました。

 こんな感じで手詰まりの感じです。

 ちょうど1.22から1.23でフィルタの仕様も変わりXmailCFGも2.24もそのままでは使えず、2.23にもどしてしまいました。残念・・・。


【 カマダ (12.03/06) 】

DoCoMoに聞いていた返答がありました
>>インターネットのルール(RFC)から見た場合、
>>・「.」をアドレス内で連続使用すること
>>・「.」をアドレスの最後に設定すること
>>上記の内容自体につきましては、違反ではございません。
>>上記の条件で作成されたアドレスへ、パソコンなどからメールを送信する場合、
>>送信できなかった時には、「"」(ダブルコーテーション/半角)で
>>囲むことで送信可能となり、それでも送信できなかった場合にRFC違反となります。

XMailでこれが実装できないのかな?


【 カマダ (12.03/06) 】

RFCを探しましたが""で囲めばOKという部分が見つかりませんでした。
どなたか該当部分をご存じではないでしょうか?


【 nakamura (12.03/06) 】

この辺の資料がわかりいいと思います。
http://www.t-net.ne.jp/~cyfis/rfc/mail/rfc2822_ja-1.html


【 nakamura (12.04/06) 】

 "わかりいい"は訂正します。機械翻訳っぽい感じで、読みやすいわけではないですね。

 3.2. Lexical Tokens の中で 3.2.2. Quoted characters としてふれられている部分がそれかなと思っています。

 あと、4.1. Miscellaneous obsolete tokens でも"."の取り扱いについてふれられています。


【 nakamura (12.04/06) 】

 でもなんだか、docomoさんに「自分は規定に反していない。Quotedしないのがいけない。」といわれるのはなんだかなという気がしますね。該当するアドレスでインターネットにメッセージを出すとき、docomoさんのサーバーはそういった処理してるんでしょうか。

 それに、インターネットメールとの相互交換ができるというのがimodeメールの売りだったコトを考えると、システム的に不適切なアドレスの登録を排除するようにしておけば問題なかっただろうにとも思います。

 色々と調べていただいてありがとうございます。とりあえず、前にも書いたとおり私のところではXmail 1.23での運用をあきらめて、1.22に戻しています。フィルターの引数の取り扱いが変わったことなどからXmailCFGも2.23に戻しました。で、kmlなどの動作自体はXmailCFGとある程度独立して動いているようでしたので、kmlの設定に必要なファイルだけ2.24から移して運用させていただいています。(一部設定ファイルを手書きで変えたりしましたが。)不規則な運用だろうとは思いますが、MLの一般ユーザーにアドレス変えて下さいともいえず、かといって、kmlのような機能も捨てがたく、しばらくはこんなことで様子を見ています。

 2・3日様子を見ている範囲では今のところは大きな問題なく動いているようです。


【 カマダ (12.04/06) 】

RFCに「古い規格では許されていて現在許されていないメルアドでも""で囲めばOKだよ」という項目があれば、Davide Libenzi 氏に対応を聞いてみようと思ったのですが、紹介いただいたリンク先読んでもまだぴんと来ません(^_^;)

英文は何度も何度も読まないと理解できない物ですからすいません。


【 ガイア (12.04/06) 】

ここで問題になっている「メールアドレス」というのはSMTPセッションのMAIL FROM:かRCPT TO:のことですよね?
だとすると、フィルタで@@FILEを編集することでクオートできると思いますが。
「クオート」というのは具体的にどこをそうするでしょうか?


【 nakamura (12.04/06) 】

ガイア さん、こんばんは。

 "@"の手前のlocal-partをということです。

たとえば
 .name...abc.@sample.jp
というようなアドレスがあった場合、
".name...abc."@sample.jp
というような処理をして送信先のMTAに渡すということのようなのです。

 Postfixだと、以下のようなパラメーターで処理を制御できるようなのですが、Xmailについてはよくわからないでいます。
 smtp_quote_rfc821_envelope
 resolve_dequoted_address

関連情報がこの辺で取り上げられています。
http://sakaguch.com/PastBBS/0031/B0015802.html
http://d.hatena.ne.jp/stealthinu/20040730#p3

http://hxxk.jp/2004/10/23/1228.php
http://hxxk.jp/2004/10/10/1539


【 ガイア (12.05/06) 】

RCPT TO:の段階ではねられますね。
ここではねられるとメッセージファイル中にRCPT TO:が保存されないので、オンラインフィルタで加工できませんでした。


【 カマダ (12.06/06) 】

なぜかXMailのmlに私の出したメールが乗りません、
しかし英語に堪能な他の方が質問されていますのでかえって私の出したメールが乗らないで良かったかもしれません(^_^;)


【 ガイア (12.06/06) 】

strict mode と no-strict mode を起動オプションで選択できるようにしてもらえるといいですね。


【 nakamura (12.07/06) 】

こちらのページでも関連する話題があるようです。
「Belphegor の巣窟 - XMailのページ」
http://www.belbel.or.jp/~belphegor/xmail/index.shtml.ja

パッチをあてたXmail1.23のバイナリも公開されています。


【 カマダ (12.07/06) 】

XMailのmlにこの件で投稿してくれたのはこの方だったんですね、

1.23jとでも呼べばよいでしょうか?nakamuraさんはもう試していらっしゃるのかな?
この方のパッチをあててコンパイルした1.23改はいかがでしたでしょうか?


【 nakamura (12.07/06) 】

 今のところ1.22で安定して動いてもいますので、しばらくは様子見ということで考えています。どのみち、今月いっぱいは週末から日曜にかけての出張が重なっていて、障害対応以外にはあまり手をかけられないだろう状況でもあります。
 昨日見たら「2ちゃんねる 自作サーバ板 XMail スレッド」では今回の"."の取り扱いをスルーするためのソースの修正についても紹介されてました。

  それにしても、IPv6+SSLパッチなんて、やってみえる方があったんですね。


【 ADM (12.27/06) 】

この件、結局解決は難しいのでしょうか?
nakamuraさん記載のパッチを当てたのですが、動作しません。

どなたかパッチあてて成功した方の事例を下さい。よろしくお願いします。


【 TTT (12.27/06) 】

「Belphegorの巣窟」にあるバイナリを落として置き換えてみましたが、なぜか動きませんでした。

今は、ソースパッケージを落として、 http://pc8.2ch.net/test/read.cgi/mysv/1079151023/355 の通りにコメントアウトしてコンパイルして使っています。

友人に XXXXX.@docomo.ne.jp というアドレスがいるので、試しにメールを送ってくれるようにお願いはしているのですが、忙しいらしく、まだ試験はできていません。。。

他に、同じ書き換えを行って、動作している方がいれば、動作報告があると嬉しいです。
果たして、この2行の書き換えだけで、RFC違反をスルーしてくれているのか。。。


【 ADM (12.29/06) 】

TTTさん

こんにちは。やはりそのサイトのBinでは
動作しなかったようですね。
当方も大変困っております。XMail1.24が修正
される気配もなさそうですし。

もし、よろしければ、TTTさんが利用してます
Binをお借りできないでしょうか?

よろしくお願いいたします。


【 TTT (01.07/07) 】

ADMさん、大変遅くなりましたが、以下のファイルをどうぞ。
1.23の時の話でしたが、1.24が出ましたので、1.24のものをアップしました。

SMailUtils.cppの
  if (pszAtom == pszStr)
    return NULL;
をコメントアウトしてコンパイルしたものです。
それ以外はいじっていません。

http://rai777.ath.cx/xmail/xmail124.zip


【 shima (01.07/07) 】

TTTさん、ありがとうございます。
当方でも利用させてください。
ただ、ちょっと気になるのがオリジナル版よりも随分サイズが大きくなっていますが、これはどう理解すればいいのでしょうか。
当方、プログラミングは素人なので、もしお手間でなければ教えていただきたく思います。


【 TTT (01.07/07) 】

shimaさん、私のnmakeの指定の仕方が間違えていたようです…。
CFG=releaseと指定するところを、CFG=debugとしていました…。

同じところから、再ダウンロードしてみてください。
ファイルサイズがオリジナル版と同じものが落とせると思います。

私の環境では、RFC2822を本当にスルーしてくれているのか、実際にテストできていません。
動作確認をいただければ嬉しいです。


【 shima (01.07/07) 】

TTTさん、さっそくテストしてみました。
自分を違反アドレスにした場合は何も問題なく送信できました。相手にも届きました。
あて先を違反アドレスにするテストでは、実在アドレスを知らないのでdocomoあてに適当な違反アドレスにして送ると、"Mailbox unavailable ..." とdocomoから応答があるので、docomoへはちゃんと届いていると思います。

問題ないですよね。
本当にありがとうございます。


【 TTT (01.07/07) 】

早速のご報告ありがとうございます。
ファイルは、しばらくの間置いておきますので、ご入用の方はお持ちください。

ファイルへの直リンクではなく、 http://rai777.ath.cx/xmail/ で、説明書きなども書いたダウンロードするためのページを作ろうかとも考えてますが、どうなんでしょう?


【 ADM (01.07/07) 】

TTTさん、早速ありがとうございます。
今からバージョンアップ等の作業をいたしますので、それに併せてテストをしてみたいかと思っております。

報告は後ほどさせていただきます。


【 ADM (01.07/07) 】

TTTさん
お疲れ様です。バージョンアップ完了しました。送信NGだったアドレスへも問題なく送信できるようになりました。大変ありがとうございました。また、今後ともよろしくお願いします。


【 TTT (01.08/07) 】

ADMさん報告ありがとうございます。
RFC2822の処理はこれで問題ないようですね。
この方法で対処できる間は、こういう方法でやっていきたいと思います。


【 nakamura (01.08/07) 】

 年末からしばらくネットのない生活をしていました。10日近くPCからも遠ざかってました。ようやく昨日くらいからメンテナンスを再開しています。

 昨日、2chなどで紹介されていた修正を施したソースとVS2005、Xmail1.24に添付のMakefileでコンパイルしXmail1.24を動かしてみました。最初win32ssl関係のバイナリをXmailのルートディレクトリにコピーするのを忘れていてサービスが起動しなくとまどいましたが、今はきちんと動作しているようです。あわせて、XmailCFGを2.25に、K4を0.85にアップデートし、こちらも良好に動作しているようです。これで私のところの環境もXmail1.22+XmailCFG2.23という環境から移行ができそうです。

 TTTさん、バイナリの公開ご苦労様です。Davide Libenziさんは「ソースは公開するから修正の必要な人は自分で対処してね」という方のようですし、そのまま公開していただけると助かる方も多いのではないでしょうか。


【 Zaki (01.08/07) 】

xmailserver.jpの新掲示板でファイルをアップできるようになってますね。

記事の先頭へ▲ 
SUPER LABORATORY