このページは福井県立大学の田中求之が2006年1月まで運用していた Mac のサーバ運用に関する会議室 「Web Scripter's Meeting」の記録です。情報が古くなっている可能性がありますのでご注意ください。

メール配送が2〜3日遅れるのは?

発言者:yoko
( Date Tuesday, April 30, 2002 20:20:43 )


EIMS 3.1でメールサーバーを立ち上げていますが、
最近、ある得意先へのメールだけ2〜3日も遅れて配送されている様なのです。
Mail logを確認しても、from弊社、to先方、sent先方のドメイン、の順で先方のサーバーへ送り出しています。
リターンメールも返ってきません。この現象はもう2週間も続いています。
先方はレンタルサーバーなので、そのISPに電話で質問したのですが、
「お互いのサーバーは正常なので、メールの配送経路が変わったのでしょう」という返事だけでした。
メールの容量も、添付ファイル付きの多い時で3MB程度です。
文字だけのメールの時は比較的スムーズに行くようです。(やはり遅れる時もあります。)
果たして、配送経路だけの問題なのでしょうか?
それとも何か他に原因があるのでしょうか?
(弊社、先方共容量制限は設けていません。)

今井真人 さんからのコメント
( Tuesday, April 30, 2002 22:36:43 )

相手側メールサーバのソフトウェアやバージョンを調べてみると
何か判るかも知れません。

例、telnet mail.aitenoServername 110
相手側から返すメッセージを読む。
quitで切断する。

yoko さんからのコメント
( Wednesday, May 01, 2002 00:44:02 )

telnetで調べてみました。

QPOP(Version 2.53) at flat02 starting.

というメッセージが返ってきました。
これで何か分かりますでしょうか?

ちなみに相手のメールアカウントをこちらで設定して、テスト送信した時の
Server Consoleのログを見てみると「Sendmail 8.9.3」となってました。

稲垣 さんからのコメント
( Wednesday, May 01, 2002 00:48:04 )

 まず、確認の常套手段はメールのReceived:ヘッダーの日付けをそれぞれ
見ることでしょう。

 これは、中継したサーバは必ず自分のサーバー名と処理日時を必ず付与してい
きますので、どのサーバ間で時間がかかったかが分かるかと思います。
 サーバの日付けが正確では無いときもありますが、数日程遅延が起きるので
あれば、明らかに時間がかかるところが分かるかと思います。

 で、それに関しては遅延したメールの情報を送ってもらうしかないです。
表示の方法はメールソフトによって異なりますので、利用者に確認してもらう
以外は無いですね。「ヘッダーを全て表示する」というのでヘルプやマニュア
ルを調べれば、記載されているかと思います。



yoko さんからのコメント
( Wednesday, May 01, 2002 12:36:27 )

ありがとうございます。先方からの情報を送ってもらうようにしました。
まだその情報は届いてないのですが、逆に先方がこちらに送った時のヘッダーは下記の通りでした。

Received: from 先方のサーバー (IPアドレス) 
     by 弊社のサーバー with SMTP (Eudora Internet Mail Server 3.1.1) 
     for <弊社のメールアドレス>;
     Tue, 23 Apr 2002 12:32:26 +0900
Received: from 先方のユーザー名 (*******.osaka.ocn.ne.jp [IPアドレス])
       by 先方のサーバー (8.9.3/3.7W-FLAT) with SMTP id ******;
       Tue, 23 Apr 2002 10:43:14 +0900 (JST)
       (envelope-from 先方のメールアドレス)

この場合は、送ってから到着するまで2時間かかりました。
このヘッダー情報には弊社と先方のサーバー以外に中継したサーバーはなかったという事なのでしょうか?

今井真人 さんからのコメント
( Wednesday, May 01, 2002 18:41:35 )

>QPOP(Version 2.53) at flat02 starting.
>Sendmail 8.9.3

有名どころのUNIX系メールサーバということだけはわかりました。

ところで、メールサーバのマックの時刻は正確ですか?

メールサーバに限らず、インターネットに接続されているサーバは
正確な時間に合わせておかないと不都合があります。

稲垣 さんからのコメント
( Wednesday, May 01, 2002 20:16:07 )

> この場合は、送ってから到着するまで2時間かかりました。
> このヘッダー情報には弊社と先方のサーバー以外に中継したサーバーはな
> かったという事なのでしょうか?

 そうですね。メールサーバとして経由すれば必ずReceived:ヘッダをつけるので
間には無いと思われます。

 ただ、メールの容量や回線の込み具合にも寄りますが、通常はものの数秒で
送信されますので、どこかに大きなボトルネックがあると思われます。
 心当たりはあるでしょうか?

 また、メールで添付ファイルを送る場合、中身はテキストデータに変換
されて1.2~1.3倍増しになります。
 ですので、3Mのデータを送る場合ややもすると4Mに成っているかと思い
ます。これで回線が細いと一発で送信できても数十分以上にかかると思い
ますので、遅延の原因になってしまうでしょう。


たまちゃん さんからのコメント
( Wednesday, May 01, 2002 20:54:20 )

確認ですが,こちら側(EIMS 側)では相手に送ることができるま
で queue が残ったままなのですね。

しあわせのツボ さんからのコメント
( Wednesday, May 01, 2002 21:42:48 )

2時間というのは一般的なリトライ間隔ですね。
128kの線で4MB送っても5分弱ですから、サイズや回線の問題で
何時間も遅れることはまずないと思います。

EIMSではありませんが、うちでも特定の相手だけ
何度かリトライしていることがあります。
そのうち通りますし、大抵はフリーメールや携帯キャリア宛
(>まず間違いなく私用メール)なので、あまり深く考えずに
放置しています…。
# サボっているとも言う(^^;

yoko さんからのコメント
( Wednesday, May 01, 2002 21:46:36 )

>ところで、メールサーバのマックの時刻は正確ですか?

はい、大丈夫です。

>どこかに大きなボトルネックがあると思われます。
>心当たりはあるでしょうか?

接続状況は先方、弊社ともADSLなのです。
メールクライアントの送受信は早いですし、サーバーはモデム直結なので
ボトルネックは心当たりがないのですが・・・

>こちら側(EIMS 側)では相手に送ることができるまで queue が残ったままなのですね。

いいえ、queue に残らず、すぐに送り出せています。

今井真人 さんからのコメント
( Wednesday, May 01, 2002 22:50:03 )

一番手っ取り速いのは*******.osaka.ocn.ne.jpの動作記録を見ることができれば最高なんだけど。

yoko さんからのコメント
( Wednesday, May 01, 2002 23:09:33 )

>一番手っ取り速いのは*******.osaka.ocn.ne.jpの
>動作記録を見ることができれば最高なんだけど。

これって、サーバーではなく先方の接続ISPなのですが、
中継も含むサーバーのせいばかりではなく、
接続ISPの動作もあやしいって事なのでしょうか?

そういえば、思い出しました!
届かないって先方とやりとりしている時に
先方の自社ドメインのアドレスからではなく、
接続ISP(OCNですが)から与えられているメールアドレスからも
送ってもらったのですが、それは今も届いておりません!(送信日時:4/23)
って事は??? どこが悪いのかしら?

>大抵はフリーメールや携帯キャリア宛

ウチの場合そうではないのですが・・なぜ?

今井真人 さんからのコメント
( Thursday, May 02, 2002 07:09:59 )

先方のIPアドレスの逆引が *******.osaka.ocn.ne.jp なんですね。
とすると、*******.osaka.ocn.ne.jp とは先方のメールサーバ
ですね。

今井真人 さんからのコメント
( Thursday, May 02, 2002 07:13:56 )

私は *******.osaka.ocn.ne.jp側の設定が怪しいと思いますが、
出張して見せてもらうという訳にはいかないでしょうか?

見るところは *******.osaka.ocn.ne.jpから御社メールサーバ
のnslookupをやってみるあたりと、デフォルトゲートウェイが
2つセットされてないか。それからsendmailの設定をどのよう
にして設定したのか。

今井真人 さんからのコメント
( Thursday, May 02, 2002 07:16:49 )

>先方の自社ドメインのアドレスからではなく、
>接続ISP(OCNですが)から与えられているメールアドレスからも
>送ってもらったのですが、それは今も届いておりません!(送信日時:4/23)

メーラーとメールサーバの接続の設定は、プロでも間違うときがあります。
私は、メールサーバを先方のサーバにしたまま、ocn名で発信しようとした
ので、止められた可能性が高いと思ってます。

今井真人 さんからのコメント
( Thursday, May 02, 2002 07:32:51 )

面白い方法としては、先方のメールサーバの特別なメールアカウントを
準備してもらい、yokoさんサーバの特別なアカウントへの転送する設
定をしてもらいます。

そうして、yokoさんサーバの特別なアカウントから、先方のメールサー
バの特別なメールアカウントにメールを送信します。帰ってくる時間や
中継された時間やサーバ名もすべて記録されます。そのメールの
配信の際のログの提出も、特別なアカウントなので追及しやすいと
思います。


こういう話ができない管理者だと、原因の追及は難しいでしょうけど。

今井真人 さんからのコメント
( Thursday, May 02, 2002 07:37:47 )

>面白い方法としては、先方のメールサーバの特別なメールアカウントを
>準備してもらい、yokoさんサーバの特別なアカウントへの転送する設
>定をしてもらいます。

この逆の設定をyokoさんサーバにも設定して、先方にテストしてもらうというパターンも最初の取り掛かりとして、いいかも。

yoko さんからのコメント
( Thursday, May 02, 2002 12:20:52 )

今井真人さん、たくさんのコメントありがとうございます!

少し説明不足&私の理解不足の為、申し訳ありませんが、
ここで一度整理してみていいでしょうか?

<先方の環境>
  ・自社のドメインを持っているが、サーバーは「ベッコアメ」のレンタルサーバーを利用
  ・インターネットの接続はフレッツADSLでISPは「OCN」のADSL用接続サービスを利用

<弊社の環境>
  ・自社ドメインを自社サーバーで利用
  ・フレッツADSLで1固定IPアドレスなので、1台のMacでDNS,WWW,MAILを運営
  ・サーバーはLANに繋がず、ADSLモデムに1台のみ接続
  ・クライアントマシンは、Bフレッツで複数台をルーター接続

という状況だと「*******.osaka.ocn.ne.jp」は、やはり先方の接続ISPの情報ではないのでしょうか?


>メールサーバを先方のサーバにしたまま、ocn名で発信しようとしたので,
>止められた可能性が高いと思ってます。

なるほど、これはそうかも知れません!


>こういう話ができない管理者だと、原因の追及は難しいでしょうけど。

先方は管理者いないんですよね・・。
なかなかヘッダー情報も送ってもらえなくって。。。

yoko さんからのコメント
( Thursday, May 02, 2002 12:34:06 )

ウチのサーバー構成だと逆引きが出来ない(逆引きはISPの情報になる)ので
メールが正常に配送出来ないって事も考えられるのでしょうか?

今井真人 さんからのコメント
( Thursday, May 02, 2002 14:04:05 )

>ウチのサーバー構成だと逆引きが出来ない(逆引きはISPの情報になる)

最近はメールのドメイン名のチェックと、サーバの逆引ドメインを検査して
スパムかどうか判断している例もありますので、注意しておいたほうがいい
でしょう。

今井真人 さんからのコメント
( Thursday, May 02, 2002 14:05:54 )

メールサーバがベッコアメで、OCN経由でインターネットアクセスですね。

ベッコアメ側はどのような判断で、不正アクセスかどうかチェックしてい
るのでしょうか?

メールヘッダの記録の中にベッコアメのサーバの記録がないのが気になり
ます。

今井真人 さんからのコメント
( Thursday, May 02, 2002 14:07:11 )

>「*******.osaka.ocn.ne.jp」は、やはり先方の接続ISPの情報ではないのでしょうか?

そのようですね。

今井真人 さんからのコメント
( Thursday, May 02, 2002 14:17:23 )

>先方は管理者いないんですよね・・。

う〜ん。解決は望み薄ですね。

メールサーバの運営は、スキルが高くないとトラブル時にどうやって
いいやら、さっぱり判らんでしょう。ここの話が判る人がいることが
最低条件です。

yoko さんからのコメント
( Thursday, May 02, 2002 14:20:21 )

またまた説明不足のようで..
先方から遅れて届いたヘッダー情報は

Received: from flat02.bekkoame.ne.jp (***.***.***.***)  ←先方のレンタルサーバー(ベッコアメ)
     by 弊社ドメイン with SMTP (Eudora Internet Mail Server 3.1.1) 
     for <yoko@弊社ドメイン>; Tue, 23 Apr 2002 12:32:26 +0900
Received: from nakanishi (**********.osaka.ocn.ne.jp[61.207.174.201])
     by flat02.bekkoame.ne.jp (8.9.3/3.7WFLAT)with SMTP id ******; Tue, 23 Apr 2002 10:43:14 +0900 (JST)

という事なので、ちゃんとベッコアメの情報は入ってます。
(省略した書き方がわかりにくくてスミマセンでした。。。)

今井真人 さんからのコメント
( Thursday, May 02, 2002 16:48:13 )

flat02.bekkoame.ne.jpにLoginして、mailqってやれば、どれだけ配送が
貯まっているかわかるんでしょうけど。権限外で無理な話でしょうね。

yoko さんからのコメント
( Thursday, May 02, 2002 21:35:27 )

先方から権限いただいてメールボックスの中を見る事が出来ました!
なんと102通も迷子メール(@から前が間違っているもの)がたまっていました!(とほほ・・)
確認して全て削除させてもらったのですが、これも遅延の原因のひとつでしょうか?

344 さんからのコメント
( Friday, May 03, 2002 00:20:24 )

>確認して全て削除させてもらったのですが、これも遅延の原因のひとつでしょうか?

サーバー側のMaolBoxの容量オーバーではないでしょうか?

[yokoさんサーバー] > 送信する
[受け取りサーバー] > 空きが無いから後でまた送ってねの返事を返す
の繰り返し・・・

で、該当ユーザーがメールチェックする > 空きができる。
ようやく[受け取りサーバー]がメールを受け取ることができる。

「Error log」で「空き容量が有りません」のようなメッセージは
ありませんか?(多分、英文です)

今井真人 さんからのコメント
( Friday, May 03, 2002 09:43:05 )

ほほう。権限をいただきましたか。ちょっと怖い話でありますが。意外な展開
で面白いです。

cd /var/log
ls
more mail.log
more mail.err
として、メール関係のログをちょっと見てはいかがでしょう。

また、メールアカウントを1つ追加して、.forwardファイルにyokoさんの
メールアドレスを書いて、転送設定をしてメールの返送テストもできそう
ですね。

今井真人 さんからのコメント
( Friday, May 03, 2002 10:14:22 )

>サーバー側のMailBoxの容量オーバーではないでしょうか?

これも関係あるかも、特に先方のユーザが複数で使っている場合
メーラー設定で、メールを残す設定にしていることも、考え
られます。

私の管理しているEIMSもメールを残さない設定にしてください
という話はしているものの、どうしても抜けがあります。

そこで30日前のメールはEIMS Utilityで削除すると通知してます。

今井真人 さんからのコメント
( Friday, May 03, 2002 10:15:50 )

> 102通も迷子メール(@から前が間違っているもの)がたまっていました

1台のサーバを1つの会社が占有して使うのは希なので、別なドメインの
メールも扱っているのではないでしょうか。

たまちゃん さんからのコメント
( Friday, May 03, 2002 21:10:11 )

>サーバー側のMaolBoxの容量オーバー

ちょっと気になったので,このような場合の EIMS 側の動作につい
て調べました。

EIMS 3.1 からは以下の記事にあるように以前と変わったようです。


→  Re: EIMS 3.1 Choking problem possibly found

yoko さんからのコメント
( Monday, May 06, 2002 07:41:11 )

連休の間サーバーのメンテを行っておりまして御無沙汰しちゃいました!色々な情報ありがとうございす。

>「Error log」で「空き容量が有りません」のようなメッセージはありませんか?(多分、英文です)

それが返って来なかったので、おかしいなぁと・・・。

>1台のサーバを1つの会社が占有して使うのは希なので、別なドメインのメールも扱っているのではないでしょうか。

おっしゃる様に、共用サーバーの様です。運営形態は下記の様な記述がありました。
 ・いわゆるバーチャルドメインを採用しており、1つのIPアドレスを200程度のドメインで共有。
 ・ディスクスペースは50MB、メールボックスは20個までご利用できます。
 ・メールボックスのスペースの容量は、ディスクスペースとは別になっており、
  容量や保存期日などの制限はありません。また、送信時の容量制限もありません。

102通たまっていたメールは、先方のドメイン専用のメールボックスだったのですが、
実は、102通+各個人のメールボックスにも100通程たまっていたのも後日発見しました。
先の102通は「USER UNKNOWN」で、これをサーバーは返さない設定にしているのに対して、
先方はメーラー等、これらをどこへも受けずにいた様です。
個人の分は「サーバーに残す」設定だったようです。

>メールアカウントを1つ追加して、.forwardファイルにyokoさんのメールアドレスを書いて、
>転送設定をしてメールの返送テストもできそうですね。

やってみました!ところが、すこぶる調子がよくて即時に転送するんですよねぇ・・
5MB程の添付ファイル付でもやってみたのですが、これもまたまたOK。
うーん、やっぱり先方のメールボックスの容量オーバーだったって事でしょうか・・。
エラーメッセージもなく、遅延だけするっていうのはやっかいです。

>EIMS 3.1 からは以下の記事にあるように以前と変わったようです。

英語が苦手なので、翻訳ソフトに頼って読んでみたのですが、余計に訳の分からない日本語にされて・・
もうちょっと解読してみます。

>cd /var/log
>ls
>more mail.log
>more mail.err
>として、メール関係のログをちょっと見てはいかがでしょう。

やっぱ、これが一番気になります。
telnet(?)あんまり使った事がないので間違ったやり方したのかも分かりませんが、
文字化けしちゃって、何が書いてあるかメッセージが読めないんです。
勉強して再度トライしてみます。

→  ベッコアメのホスティングサービス

たまちゃん さんからのコメント
( Monday, May 06, 2002 09:02:19 )

ユーザ側のメールボックスが一杯(full)になったときの EIMS 側
の動作ですが

「EIMS 3.1 は(受け取りを)拒否します。EIMS 3.1 以前ではメール
(incoming mail)がユーザアカウント(の最大容量)よりも大きい
ときには受け取りを拒否するか,ユーザアカウントが一杯のときは
一時的なエラーを返します(何故そうするかといえばメールボック
スが一杯のユーザにメールボックスを整理するために時間を与える
ためです。しかし SMTP SIZE コマンドをサポートしていないサーバ
があったり,再送を必要以上に繰り返すサーバがあるので,この方
式(= EIMS 3.1 以前の方式)はうまく機能しなくなっています)。」

というようなことだと思います。

1通あたりのメールのサイズを a
ユーザのメールボックスの(最大)容量を b
現在のユーザのメールボックスの使用量を c

とすると

1.a>b のときは EIMS のいずれのバージョンも受け取りを拒否
2.a>b-c のときは EIMS 3.1 では受け取りを拒否,EIMS 3.1
    以前では temporary error を返す

ということだと理解しています(b=c のときが full です)。

yoko さんからのコメント
( Monday, May 06, 2002 15:23:23 )

たまちゃんさん、翻訳ありがとうございます!
さすが、ムチャクチャ分かりやすい日本語解説です!

上記の仕様だと、
 ・EIMSのユーザー → メールが配送されて、拒否した事は知らない。
 ・送り側 → メールを送信してエラーメールが返ってこないので、受信出来ていると思っている。
といった現象がおこる可能性があるという事でしょうか?

また、これはメールボックスの容量制限をしていなければ大丈夫ですよね?

たまちゃん さんからのコメント
( Monday, May 06, 2002 17:49:26 )

EIMS 側のユーザは(管理者ではないので)メールボックスが一杯
になったことによるエラーには気付きません。送った側は 400 番台
のエラー(temporary error)か 500 番台のエラー(fatal error)
を受け取り,メール自体が送信できずに残ったままになります。
メールソフトによっては(例えば Eudora)500 番台(この場合は
相手のメールボックスが一杯になった旨)のエラーを残してくれる
ので送ることが出来なかった原因が分かります(これは送り元も
EIMS の場合,送り元が別の MTA であった場合上に書いたような変
な挙動を起こすこともあります)。

>また、これはメールボックスの容量制限をしていなければ大丈夫ですよね?

これはその通りです。

MTA によってはエラーを Return-Path ではなく,送信元に送り返
す変なものもあります(メーリングリストを購読していてケータイ
のアドレスに転送してケータイ側のメールボックスが一杯になった
ときなどはケータイ側の MTA がこのような仕様の時,送信元は迷
惑を被ります)。

yoko さんからのコメント
( Monday, May 06, 2002 21:21:57 )

なるほど・・大変勉強になります<(_ _)>
EIMSの場合はエラーメッセージが相手に出るので、
送信できてない事がわかるのですね。

先方のサーバーである「QPOP」でも、
メールボックスが一杯の場合、おそらくエラーが返ってきますよね?
容量制限がなくて遅れて届くって事は、やはり先方のメールボックスが一杯で、
何度かリトライして、空いた時にメールボックスに入ることが出来る、
という事を想像するのですが、その場合って、こちらのEIMSのOutgoing Mailに
残るのではないのでしょうか?
今回の場合Outgoing Mailに残ってなかったんです。

たまちゃん さんからのコメント
( Monday, May 06, 2002 21:54:09 )

>今回の場合Outgoing Mailに残ってなかったんです。

EIMS 側で「Message sent OK」となっていれば,とにかく相手方に
は届いているはずです。その上で遅配が生じているとすれば問題は
相手方(の配送)にあることになります。

どうでもいいことですが,

>先方のサーバーである「QPOP」でも

qpopper は POP3 サーバです。

#bekkoame の Apache のバージョンにびっくり。。

yoko さんからのコメント
( Tuesday, May 07, 2002 17:09:48 )

>その上で遅配が生じているとすれば問題は相手方(の配送)にあることになります。
それを聞いて少し安心しました!

>qpopper は POP3 サーバです。
そうですね、失礼しました(笑)

>#bekkoame の Apache のバージョンにびっくり。。
私もビックリしました。。

連休が明けて先程先方と連絡がとれたので、その後ベッコアメのサポートと連絡をとったか聞いてみたら、
連絡はとったらしく、この現象を説明すると「あ、分かりましたなおしておきます。」
とだけ言われたそうです。原因を追求して欲しかったのですが、
「お願いします。」と告げて電話を切ってしまったそうです・・・。
なんか思い当たる原因があったという事なのか!!
という事で私から直接聞いてみる事にします。(しかも電話の担当者名を聞いていないらしい・・)

yoko さんからのコメント
( Tuesday, May 07, 2002 18:54:04 )

ベッコアメに追求したところ、原因がわかりました。

先方のレンタルサーバー(ベッコアメ)は共有サーバーなのですが、
4/27頃に他の人のドメインがメールを大量に受信した為(spam?)
サーバーPCに負荷がかかり、ダウンしてしまい、
サーバーの入れ替え(メンテ)を行っていたそうです。
その間にやりとりを行ったメールが、行方不明 or 遅延になっていたそうです。

なんともおそまつな結果で、この会議室を汚してしまってスミマセンでした・・

※しかし3回も問い合わせをしているのに、世界1周しているだの、10tトラックを待っているだの
 もっとマシなサポートを出して欲しいと思う今日この頃。。。