« きょうのきょう(菱垣廻船西回り?) | トップページ | きょうのきょう(15年) »

2010年1月16日 (土)

CORESERVERへのSMTP接続が「smtp;552 sorry, your domain isn't in my list of allowed senderhosts」で拒否される件(メモ)

 移行したCORESERVER上のメアドにメールを送ると不達になることがある。送り先がCORESERVER以外ならこうした現象は発生せず、事象の差分を取ると原因はCORESERVER側にあると思われる。
 検索して収集した情報と実験した結果から推測される状況を記録しておく。

○現象
 CORESERVER上のメールアドレス宛にメールを送信すると、不達になる。場合によって、エラーメールが返る。返ってくるエラーメッセージは次のとおり。

Final-Recipient: rfc822;hogehoge@fugafuga.jp
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;552 sorry, your domain isn't in my list of allowed senderhosts (#5.7.1)

○原因
 CORESERVER上のSMTPサーバの設定に起因する。
 同様の現象は古くから報告されており、CORESERVER運用者も認識している。サポート掲示板には次のような回答が掲載されている。

webmaster
2004/03/15, 04:40 PM
原因ですが、

お使いのサーバー(A) --> POP認証OK --> XREAサーバー(B)
 
 この時点でBサーバーはAサーバーを正規利用ユーザーと見なします。
 
 次に、
 ヘッダ「From」が”正規利用ユーザーがBサーバー上で設定したものではない”状態で
 
お使いのサーバー(A) --> SMTP送信 --> XREAサーバー(B)
 
 を行いますと、正規ユーザーで設定したドメインがFromに存在しない
 ためエラーが発生。

という流れになります。

つまり、goo様のサーバーから、XREAサーバーにPOP受信を行った場合に同症状になります。

改善策ですが、「Aサーバーを正規利用ユーザーと見なす」状態が30分程度で
タイムアウトしますので時間を空けてお試し頂く他ございませんが、
こちらでの対応で改善可能か調査させて頂きます。

 まとめると発生する状況は次のようになる。
 ・送信したメールがFromアドレスを詐称している。
 ・送信側のSMTPサーバが受信側のSMTPサーバにSMTP接続する前にPOPアクセスしている。(POP before SMTPってこと?)
 ・POPアクセス後、一定時間(30分?)以内にSMTP接続(メール送信)している。

 言い換えると、POP before SMTPするようなSMTPサーバでFromアドレス詐称したメールを送ろうとすると、CORESERVERに拒否される可能性がある。

○対策
 メール送信に利用していたSMTPサーバをIISからPMail Serverに変更。まだ半日ほどしか経っていないが、拒否されることはなくなった。
 IISはPOP before SMTPしていると言うことだろうか? MUA(メールソフト)ならまだしも、MTAもそんなことをするのか?

○経緯
 送ろうとしたメールは、自宅のイントラサーバのSMTPサーバから送ったもので、Fromアドレスのドメインは自宅サーバのドメインとは一致していない。結果、Fromアドレス詐称メールになっている。当該メールは、自宅のNASのヘルスチェックメールで、ファームの都合上SMTP認証やPOP before SMTPなSMTPサーバは使えない。FromとToが一致する仕様になっているので、Fromアドレス詐称を回避しようとすると、送り先であるCORESERVER上のSMTPサーバを使うしかないが、そのサーバはSMTP認証なので使えない。仕方なく自宅に無防備な非公開サーバを立てて利用した次第。
 当初はIISのSMTP仮想サーバを使っていたのだが、このサーバで不達事件が発生した。SMTPサーバをPMailServerに替えたところ、送達されるようになった。

○周辺
 Web上に報告されている不具合情報を見ると、私のような自宅サーバ以外に、Gmailなどのフリーメールで独自ドメインを運用している場合に同様の事象が発生しているようだ。正常に送られていたものがある日突然届かなくなるとか、時々しか起きないと言う報告もあって怪奇性を帯びているようだ。POPから30分以内に起きるという柔らかい(?)条件が効いているのだろうか。
 GmailネイティブのFromアドレスを使っていて詐称をしていない場合も同様の事象が発生しているという情報もあってこれは謎。原因が異なるのかも。

 SMTPサーバ機とは異なるが同じネットワーク内のPCからは常時POPでメールを監視しているので、逆にPMail Serverで送信可能というのも不思議な気がする。POP before SMTPの有効期間が極短く、IIS自身がPOPしているということなのだろうか。この辺は謎のままなので、解決したのかどうかやや疑問。

 何だか面倒なサーバである。スパム対策ということのようだ。そう言う意味では正当なのかもしれない。しかし、中継メールを遮断するのなら社会的意義もあろうが、受信するメールなのだから来るものは拒まずで全て受信し、その後にフィルタリングツールを充実させれば良さそうなもの。提供されているフィルタリングがあまり便利ではないのでその補完のつもりだろうか。逆引きできないドメインのサーバを運用している時点でFromアドレス詐称もへったくれもあったものではない、という気がするが。

 これが原因でメールサーバを他社に移行するユーザも多いようだ。DNS、Web、メール、shellを一括して比較的自由にいじれるので気に入っているのだが、意外なところでミソを付けてくれた。以前検討したさくらのメールサーバだと強制的にToアドレスもFromアドレスも独自ドメインからさくらの初期ドメイン(hogehoge.sakura.ne.jp)に書き換えられてしまって使い物にならなかったのだが、同じような発想に基づいているのだろう。さくらはこれが原因で却下したのだが。

 おもしろい対策としては、送信に使う(CORESERVER以外の)SMTPサーバのアドレスをDNSのtxtレコードに書いてしまおうというアイデアもあったのだが、解決策にはならなかったようだ。

 ここのサーバは逆引きできないメールサーバからの接続は拒否するという設定もあって問題の種は尽きないようだ。

<おまけ>
 PMail Serverのフリー版ではPOP before SMTPがデフォルトになっていて、変更できない。NASのようにPOPできないMUAの為に次の設定で回避できる。
 PMailServer Managerで、「サーバ管理」→「SMTP用」→「SMTP認証」タグを開き次の設定をする。(最後のIPアドレス,ネットマスクは、MUAのネットワークを指定する。)
 ・SMTP認証:なし
 ・SMTP認証を無視できるIPアドレス:192.168.0.0,255.255.255.0

<追記>
 PMail Serverのフリー版はDateヘッダがない場合、補完してはくれないらしい。NASが生成するメールにはDateヘッダがないので、そのまま届くとヘッダを見ただけではいつのヘルスチェックだかわからない。IISはちゃんと補完してくれていたのだが。

<追記2>
 通常使用しているグローバルIPアドレスとは別のアドレスでも試験を実施。「通常のIPアドレス」からは常時CORESERVERにPOPアクセスをしてメールチェックしている。「別のIPアドレス」からはPOPアクセスはしていない。結果は次の通り。いずれの場合も、CORESERVER以外の宛先には配信できている。
 POPアクセスとは関係なく、MTAとの相性なのかも。

             POPしているアドレス   POPしていないアドレス
 IIS               ×                 ×
 PMailServer         ○                 ○
 BlackJumboDock      ×                 ×

  BlackJumboDockはMTAとしてのメール転送時に転送先のSMTPサーバを静的に指定する。この際に、CORESERVER上のSMTPサーバを指定すると552エラーを起こす。同じくIIJmioのSMTPサーバを指定するとCORESERVER上のメアド宛のメールでも正しく配信される。
 Fromアドレス詐称メールでも、MUAが使用するSMTPサーバとしてIIJmioのSMTPサーバを指定するとCORESERVER宛のメールが届いている。
 やっぱり、MTAとの相性なのかも。

 IISからでもCORESERVERに配信されてくる事がある。配信されず溜まっていたメールがどばっと届けられるようだ。これとは別に、IISの設定でIIJmioのSMTPサーバ経由で配信(転送)するようにすれば常にCORESERVERに届くようになる。

<追記3>
 その他の組み合わせ試験結果は次の通り。

   From        MTA(0)       MTA(1)      MTA(To)      結果
   CORESERVER  home/IIS                CORESERVER   ×→△
   CORESERVER  home/IIS                Gmail         ○
   CORESERVER  home/PMS               CORESERVER   

   CORESERVER  home/PMS               Gmail        ○
   CORESERVER  home/BJD    CORESERVER   CORESERVER   ×
   CORESERVER  home/BJD    CORESERVER   Gmail        ○
   CORESERVER  home/BJD    IIJmio        CORESERVER   ○
   CORESERVER  home/BJD    IIJmio        Gmail         ○
   CORESERVER  IIJmio                   CORESERVER   ○
   CORESERVER  CORESERVER              CORESERVER   ○
   Gmail        Gmail                   CORESERVER   ○
   GApps       Gmail                   CORESERVER   ○
   GApps       Gmail                   Gmail         ○

   CORESERVER  home/IIS     IIJmio        CORESERVER    ○
   CORESERVER  home/IIS     CORESERVER   CORESERVER   ○→△

   From:Fromアドレス
   MTA(0):MUAで指定したMTA
   MTA(1):MTA(0)で指定した転送先MTA(smtp認証して転送)
   MTA(To):Toアドレス
   PMS:PMailServer
   BJD:BlackJumboDock

   
GApps:GoogleAppsのメアド(必然的にFromアドレス詐称になる)
   △:届く時と届かない時がある
   ○:届く、×:届かない

 smtp認証して転送しても届かなくなった(というか転送できなくなった)というのはどういう事だろう。設定はいじっていないので、CORESERVER側の動作ということになる。

 わけわかめ。面倒だな。なんで素直な設定にしとかないのかな。腹立ってきた。

 スパムだろうがなんだろうが、送られたものを届けるのがキャリアとプロバイダの務め。どのような言い訳をしようとも、勝手な判断で届かなくしてしまうのなら、「サーバの信頼性が低い」と言うことになる。

 ユーザの利便性の為と言うより、サーバの負荷を押さえる為の措置らしい。本来はその負荷に耐えるようサーバを強化すべきなのだが、それをせずに安易な対応に流れてしまうのは安かろう悪かろうということか。確かに、この値段でこの容量でこの自由度ってホスティングはなかなかないし、仕方ないのかも。

<追記4>
 他にもLF(x0A)が単独で含まれているとエラーで配信されないようだ。


 451+See+http://pobox.com/~djb/docs/smtplf.html. SMTP" 0 47

 CRLF(x0D0A)だと正常に配信される。
 この点はIISで直接配信しても、スマートホストにCORESERVERを指定して配信しても同じ。

|

« きょうのきょう(菱垣廻船西回り?) | トップページ | きょうのきょう(15年) »

コメント

どうも、良く判らないけど、本文の From: を独自ドメインのアドレスに
すると拒否されるって事かな?、通常の設定だと SMTP、SMTP AUTHの
エンベロープは自分の属するするドメインでないと拒否されますが、
本文の From: まではチェックしないのが普通だと思うのですが...、
そうでないと複数のアドレスを持っていて From を使い分けると言う事
が出来なくなって不便ですよね。

投稿: TIKA | 2010年1月17日 (日) 09時23分

 そう、不便なんです。というか、私が不便なんじゃなくて、私宛にメールを送信してくれる人が不便な思いをすることになるので、余計に厄介なんです。(-_-;)

投稿: ichi | 2010年1月18日 (月) 00時09分

コメントを書く



(ウェブ上には掲載しません)




« きょうのきょう(菱垣廻船西回り?) | トップページ | きょうのきょう(15年) »