まだ重たいCMSをお使いですか?
毎秒1000リクエスト を捌く超高速CMS「adiary

2009/11/30(月)CORESERVER、メールの凶悪仕様(Gmailとの不具合の理由)

訳あってレンタルサーバのCORESERVER.JP(Value Domain)の利用を検討していたのですが、メールがらみでひどい素敵仕様を発見したので記録しておきます。GmailとCORE SERVERの相性が悪いという話がネットであちこち書かれていますが、おそらくこれが原因ではないかと思います。

メールの仕組みについて

問題について述べる前にメールサーバについて簡単におさらいしておきます。そんなの分かってるという人は飛ばしてください。

いわゆるメールサーバというのは、SMTPというプロトコルによってメールをサーバからサーバへ転送するサービスをしています。このSMTPというのは元々サーバも受信者も送信者もなにも区別がないプロトコルで、「SMTPサーバからSMTPサーバへどんどんタライまわしをしているといずれ受信サーバにたどりつく」というSPAMなんて存在しない、インターネットが限られた利用者が使用する紳士的な世界だった頃に作られました。その名残から、今もって

  • メール送信時にメールクライアントソフト(メーラー)が自分のメール送信用サーバに対してメールのデータを送るSMTP
  • メールサーバ間でメールのデータをやりとりするときに使われるSMTP

2つには何の差も存在しません。こんな仕様だから、メール設定のいわゆるSMTPサーバ(送信サーバ)として使用するサーバには何かしら制限を加えておかないと、世界中からそのサーバを中継(経由)してSPAMを送り放題になってしまいます。このように「本来想定している人以外からのメールを送ること」を第三者中継といいます*1。第三者中継をしないために通常は次のような制限を加えておきます(いずれかもしくは複数)。

  • 特定のIPからしか送信できないようにする。プロバイダのSMTPサーバが、そのプロバイダの利用者IPのみに中継を許可する。
  • SMTP-AUTH等の認証をする。ID/パスワードを確認するので、正規のID/パスワードを持つ利用者のみに中継を許可できる。
  • POP before SMTPという特殊な方法を利用する。メール送信前に1度メールを受信させることで、そのIP利用者に短時間だけ(1~5分程度)中継を許可する。

最初の方法だけで済めばよいのですが、どうしてもホテルやモバイルパソコンからメールを送信したいとなったときに必ずしも同じプロバイダを利用できるとは限らないので他の方法が必要になります。SMTP-AUTHがまだそんなに普及していなかった頃*2、過渡的な措置としてPOP before SMTPというものが考えられました。

以上はあくまで送る側の話で、SMTPサーバは送るためのサーバであると同時に受信サーバでもあることが多くあります*3。このままだと何処から送られてくるかわからない自分宛のメールを受け取れなくなってしまうので、自分宛のメールは無条件で受け取るという設定をします。例えば、xxx@foo.com ならば foo.com は自分宛ですよと登録しておきます。

*1 : 199x年頃はこの第三者中継が標準でonになっていたのだから恐ろしいものです。

*2 : いくらその仕組みを用意してもクライアントソフトが対応するまで利用できる人が限られていた

*3 : この2つは分けることもできるが、小規模なケースでは一緒にしてしまうことが多い

CORESERVERのおさらい

  • CORESERVERは送信メールサーバ=受信メールサーバ
  • CORESERVERはPOP before SMTPのみ対応(SMTP-AUTH未対応

CORESERVERの血迷っ…素敵過ぎる仕様

CORESERVERで普通にメールサーバを設定して、設定したサーバ宛にメールを送ろうとしたらこんなエラーメールが帰ってきました。

<test@s1xx.coresv.jp>: host s1xx.coresv.jp[202.172.28.1xx] said: 552 sorry, your
    domain isn't in my list of allowed senderhosts (#5.7.1) (in reply to MAIL
    FROM command)

要するに「あなたのドメインは送信元ドメイン許可リストに入っていません」と言っている。にも関わらず、他のぜんぜん関係ないメールサーバ(メールアカウント)からメールを送るとちゃんと受け取る。さっぱり意味不明。検索すると同じようにハマっている人多数

色々調べてみたところ、原因がはっきりしました。

  • POP before SMTPの設定時間(タイムアウト)が3時間以上!
  • POP before SMTPで「リレー許可リスト」に登録されると、そのIPからのSMTP接続はすべて外部への中継(リレー)として扱われる

どちらの仕様もバカ素敵すぎて言葉もない。

つまり、

  1. SMTPサーバでもあるIPで、CORESERVERからメールを受信する。
  2. CORESERVER側で「リレー許可リスト」に登録される。
  3. 手元のSMTPサーバからCORESERVER宛にメールを送信する。
  4. CORESERVERは「リレー許可リスト」に登録さているという理由だけで、外部から自分宛のメール送信を強制的に内部(CORESERVER)から外部へのメール送信と見なす。
  5. CORESERVERは外部へのメール送信のとき、予め登録された自ドメイン(senderhosts)にSMTPのFROM*4ドメインが含まれないためメールを拒否する。
  6. CORESERVERは自分宛のメールを552のエラーとして受取拒否する

ということです。

そしておそらく「リレー許可リスト」はサーバごとに全ユーザ共有だと思われるので(未確認)、たとえ自分でPOPしていなくても時々メールが送れないサーバが出てくる……と。

Gmailには

Gmailには、Gmailに統合してあるアカウント名義でメールを送信する目的で外部SMTPサーバを使用してメールを送信する機能がありまして、それを使うとバッチリメールが送れなくなるわけです。

これをしないと、GmailではFromの代理送信表示がされてしまいます。

*4 : SMTPにおけるFROMであるのでFROMヘッダとは異なる

総評

VALUE DOMAINのDNS設定も、何行か書くとすぐバグるし(行を入れ替えないとダメとか)、いまいちツメが甘い印象がぬぐえない。所詮、安かろうなんたらでしょうか。サーバスペックはいいんだけど、障害対応も遅いみたいだしねぇ。今回は安定性重視なのでCORESERVERは却下の方向。

どこか、もちょっとマトモなレンタルサーバ知りませんか?(苦笑)

追記

なんかググってたらこの記事のほぼコピペのブログが。せめてリンクぐらいしようや……。*5

*5 : 少し書き換えてあるのがなおたち悪い。どっちにしろ著作権的にはアウトだけども。

OK キャンセル 確認 その他