421 で拒否された場合の挙動
Shigeharu TAKENO
クロスポストです。
お尋ねしたいのですが、local の MTA が SMTP で remote の MX である
メールサーバ host1 に接続してコード 421 で拒否された場合、もしそ
の MX のセカンダリ host2 (preference 値が host1 より大きいもの)
があったとして、その後どう動作するのが MTA の正しい挙動なのでしょ
うか。
[a] local のキューに入れ、後で host1 に再送を試みて、何回かやって
ダメならエラーメールとして送信元に返す
[b] (必要ならば host1 への再送を試みた後で) host2 に送ろうとする
[c] MTA の実装依存で、[a],[b] どちらが正しいとは決まっておらず、
どちらでもよい
[d] [a],[b] どちらでもない
このような事例が、私が知っているところで発生して、その local の管
理者によると
・qmail はどうやら [a] を行なうよう
・他の MTA (sendmail や postfix ?) だと [b] のよう
という話のようでした。しかも、その remote の方を問い合わせてみた
ところ
・host1 は外部からのメールは拒否する内部向けメールサーバである
・外部からのメールは [b] となる挙動を期待している
ということだったそうです。よって、そこには qmail からはメールが送
れないがその他の MTA からはメールが送れる、という現象が起こってい
るようである、ということでした。
なんとなくその MX (host{1,2}) の設定状況自体腑に落ちないのですが
元の問題に戻ると、正しい挙動は [a],[b],[c],[d] どれなのでしょう。
qmail の本やコウモリ本、RFC などを見たのですがよくわかりませんで
した。
そして、もう一件、qmail の挙動が [a] で、かつ他の MTA が [b] だと
すると、qmail に [b] を行なわせるための設定等はあるのでしょうか。
以上何か情報等ありましたらよろしくお願い致します。
+=================================================+
竹野茂治 〒945-1195 新潟工科大学 情報電子工学科
sh...@iee.niit.ac.jp TEL(&FAX): 0257-22-8161
+=================================================+
MAEDA Atusi
> お尋ねしたいのですが、local の MTA が SMTP で remote の MX である
> メールサーバ host1 に接続してコード 421 で拒否された場合、もしそ
> の MX のセカンダリ host2 (preference 値が host1 より大きいもの)
> があったとして、その後どう動作するのが MTA の正しい挙動なのでしょ
> うか。
>
> [a] local のキューに入れ、後で host1 に再送を試みて、何回かやって
> ダメならエラーメールとして送信元に返す
> [b] (必要ならば host1 への再送を試みた後で) host2 に送ろうとする
> [c] MTA の実装依存で、[a],[b] どちらが正しいとは決まっておらず、
> どちらでもよい
> [d] [a],[b] どちらでもない
qmailの作者の解釈では[c]のようです。
http://cr.yp.to/im/remote.html には、
The client can stop at any point in the list after the first
address. (For example, most mailers will stop if an SMTP
connection is established but then fails temporarily. Lotus Notes
reportedly stops after two MX records in all cases.) This means
that, if all of the lowest-distance hosts are persistently
unreachable, there is no guarantee that mail will be delivered,
even if there are reachable higher-distance hosts in the MX list.
とあります。また、http://qmail.jp/QA/implementation.html には
Q: 優先度の低いMXホスト[Secondary MX]へメイルが送られませんでした。
なぜですか。
A: 優先度の高いMXホストの「SMTPポートへの接続に成功した」後は 途中
で配送に失敗(4xx：一時的問題)しても、 ほかのホストへの配送は試みま
せん。優先度の高いホストのSMTPポートに接続できなかったときは次の優
先度のホストに 接続を試みますので、心配はありません。
とありますから、この振舞いについては良く知られているのでしょう。
一方RFC2821には、
To provide reliable mail transmission, the SMTP client MUST be
able to try (and retry) each of the relevant addresses in this
list in order, until a delivery attempt succeeds. However, there
MAY also be a configurable limit on the number of alternate
addresses that can be tried. In any case, the SMTP client SHOULD
try at least two addresses.
とあります(Section 5)。「until a delivery attempt succeeds」をDJBは
「SMTPで接続できるまで」と解釈しているのでしょうか。良く分かりません。
いずれにせよ、
> ・host1 は外部からのメールは拒否する内部向けメールサーバである
> ・外部からのメールは [b] となる挙動を期待している
この場合「421(あとでもう一度試みて)」という返答はおかしいですね。
フィルタで接続を拒否するべきでしょう。
しかも、外から送れないサーバをなぜMXで外に宣伝するのか...謎だ。
> そして、もう一件、qmail の挙動が [a] で、かつ他の MTA が [b] だと
> すると、qmail に [b] を行なわせるための設定等はあるのでしょうか。
qmail自体を改造しない限り無理でしょう。[b]の挙動はqmail-remote.c自体に
hard codeされています。
前田敦司
MAEDA Atusi
> > そして、もう一件、qmail の挙動が [a] で、かつ他の MTA が [b] だと
> > すると、qmail に [b] を行なわせるための設定等はあるのでしょうか。
>
> qmail自体を改造しない限り無理でしょう。[b]の挙動はqmail-remote.c自体に
> hard codeされています。
×[b]の挙動はqmail-remote.c自体に...
○[a]の挙動はqmail-remote.c自体に...
前田敦司
Shigeharu TAKENO
記事 <m38ys7o...@maedapc.cc.tsukuba.ac.jp> において
MAEDA Atusi <ma...@cc.tsukuba.ac.jp> さんは書きました:
> qmailの作者の解釈では[c]のようです。
> http://cr.yp.to/im/remote.html には、
>
> The client can stop at any point in the list after the first
> address. (For example, most mailers will stop if an SMTP
> connection is established but then fails temporarily. Lotus Notes
> reportedly stops after two MX records in all cases.) This means
> that, if all of the lowest-distance hosts are persistently
> unreachable, there is no guarantee that mail will be delivered,
> even if there are reachable higher-distance hosts in the MX list.
なるほど。
> とあります。また、http://qmail.jp/QA/implementation.html には
>
> Q: 優先度の低いMXホスト[Secondary MX]へメイルが送られませんでした。
> なぜですか。
>
> A: 優先度の高いMXホストの「SMTPポートへの接続に成功した」後は 途中
> で配送に失敗(4xx：一時的問題)しても、 ほかのホストへの配送は試みま
> せん。優先度の高いホストのSMTPポートに接続できなかったときは次の優
> 先度のホストに 接続を試みますので、心配はありません。
>
> とありますから、この振舞いについては良く知られているのでしょう。
あ、ちゃんとこういう情報があるのですね。調べ方がまるで甘かったよ
うです。どうもありがとうございました。
> 一方RFC2821には、
>
> To provide reliable mail transmission, the SMTP client MUST be
> able to try (and retry) each of the relevant addresses in this
> list in order, until a delivery attempt succeeds. However, there
> MAY also be a configurable limit on the number of alternate
> addresses that can be tried. In any case, the SMTP client SHOULD
> try at least two addresses.
>
> とあります(Section 5)。「until a delivery attempt succeeds」をDJBは
> 「SMTPで接続できるまで」と解釈しているのでしょうか。良く分かりません。
良く読んでみればこれでちゃんと ([b] のように ?) 規定されているよ
うに読めますね。見落としていました。どうもありがとうございます。
# そういえば RFC の日本語訳も榊さんの本についていたんだ...
しかし、言われてみると確かに変な気がしますね。4XX でセカンダリに
流したくない、っていう心情はわからなくもないんですが。
> > ・host1 は外部からのメールは拒否する内部向けメールサーバである
> > ・外部からのメールは [b] となる挙動を期待している
>
> この場合「421(あとでもう一度試みて)」という返答はおかしいですね。
> フィルタで接続を拒否するべきでしょう。
と私も思いますし、
> しかも、外から送れないサーバをなぜMXで外に宣伝するのか...謎だ。
とも思います。local の管理者は、とりあえず MX を参照せず静的にセ
カンダリに配送することで逃げる、と言っていましたが、
> > そして、もう一件、qmail の挙動が [a] で、かつ他の MTA が [b] だと
> > すると、qmail に [b] を行なわせるための設定等はあるのでしょうか。
というのがないかなと思ったのですが、
> qmail自体を改造しない限り無理でしょう。[b]の挙動はqmail-remote.c自体に
> hard codeされています。
っていうのも感じていました。ただ、改造するにしてもどういう挙動に
するのがいいのかな、ということも確認したかったので。
色々どうもありがとうございました。
ka...@sra-tohoku.co.jp
本筋ではないですが
>> ・host1 は外部からのメールは拒否する内部向けメールサーバである
>> ・外部からのメールは [b] となる挙動を期待している
のであれば外から見える MX には内部用のサーバーを書かない、
てのは正しい設定でしょうな…
SMTPではなく DNS の問題。
内向けと外向けの挙動を変えられないDNSサーバーだと
めんどくさそうですが。
--
kabe