adiary開発日誌

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

• メールの仕組みについて
• CORESERVERのおさらい
• CORESERVERの血迷っ…素敵過ぎる仕様
  • Gmailには
• 総評
  • 追記

■メールの仕組みについて

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

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

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

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

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

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

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

■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)

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

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

• POP before SMTPの設定時間（タイムアウト）が３時間以上！
• POP before SMTPでsenderhostsリストに登録されると、そのIPからのSMTP接続はすべて外部への中継（リレー）として受け取る

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

つまり、

1. SMTPサーバでもあるIPで、CORESERVERからメールを受信する。
2. CORESERVER側でsenderhostsに登録される。
3. 手元のSMTPサーバからCORESERVER宛にメールを送信する。
4. CORESERVERはsenderhostsに登録さているという理由だけで、外部から自分宛のメール送信を強制的に内部(CORESERVER)から外部へのメール送信と見なす。
5. CORESERVERは外部へのメール送信のとき、予め登録された自ドメインとSMTPのFROM（SMTPにおけるFROMであるのでFROMヘッダとは異なる）が一致しないためメールを拒否する。
6. CORESERVERは自分宛のメールを552のエラーとして受取拒否する。

ということです。

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

Gmailには

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

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

■総評

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

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

追記

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