[postfix-jp: 3492] Re: docomoに関するリターンメールの読み方について

[IWAMOTO Kouichi <sue@xxxxxxxx>]

岩本です。

何か誤解があるような気がするので…

On Mon, 25 May 2009 16:30:51 +0900
"N.Takaesu" <takaesu@xxxxxxxxxxxxxxxx> wrote:

> えーっと、今も確認しましたが、 aaa に届いていました。
> SMTP 的には ccc に届くのは正しい...んですよね?

cccへの配送は別SMTPセッションの為aaa/bbbへの配送結果の影響は受けないので、
cccに届くのは正しいです。

aaaへの配送は、エラー通知メールの内容から、bbbと同一のSMTPセッションで配送を
行おうとしたはずです。
# 別セッションだった場合、エラー通知も別々に送られてきます
また、どの段階でエラーになったかについても"in reply to end of DATA command"
という事から、end of DATA command (<CRLF>.<CRLF>)でエラーになっています。

RFC5321には "4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>"
というまさに今回のケースに関する節がありまして、そこには

|   When an SMTP server returns a permanent error status (5yz) code after
|   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
|   any subsequent attempt to deliver the message.

というように、続くメッセージの配送を試みてはいけない(MUST NOT)と書かれて
いるので、aaaへメールを配送するのはRFC的には誤りという事になります。

> 心情的には aaa に届いて欲しい気もしますが、docomo の特殊な仕様も
> 気になるところです。

今回の件(aaa/bbb両方がエラーになったように見える)については、特殊な仕様
というわけではないですよ。
# エラーになったはずのaaaに届いているというのは特殊と言えますが
少なくとも、docomoが個別にエラーに出来るけれど意図的に丸ごとエラーに
なったように装っているという事はありません。
aaaがエラーになったように見えるのは、SMTPの仕様です。

前のメールで書いた事の繰り返しになってしまいますが、SMTPでのメール配送の
大雑把な流れは以下のようになります。
# クライアント側の送信内容に注目した場合です

1. HELO
2. MAIL FROM
3. RCPT TO を宛先の数だけ繰り返す
4. DATA
5. メール本文
6. <CRLF>.<CRLF> (end of DATA)

メールボックスが無いとかアクセス制限などの理由で個別のアドレスへの配送を
エラーにする場合、3の段階でエラーを返します。
この場合は宛先アドレスを通知する段階でエラーになっていますので、どのメール
アドレスがエラーになったかをクライアント側で認識でき、エラー通知も該当の
メールアドレスについてのみ報告します。

しかし、今回の場合は6のend of DATAでエラーになっています。
この場合はメール本文でエラーになった事になるので、どれか一つの宛先がエラーに
なったのではなく、すべての宛先がエラーになったとクライアントは認識します。
# どれか一つの宛先のみエラーだったとしても、クライアントには判別出来ません

ではend of DATAでエラーにするのが特殊かというと、そういうわけでもありません。
3のRCPT TOの段階で判明している情報は、
・接続元IPアドレス
・HELOコマンドのホスト名
・エンベロープの送信者アドレス
・エンベロープの受信者アドレス
くらいです。

メール本文については5.の段階で送られて来るので、メール本文の内容に基づいて
拒否する場合は、どうしても6のend of DATAでエラーにする必要があります。

そして、docomoは(エンベロープの送信者ではなく)メールのFromヘッダので制限を
かけているようです。
メールのFromヘッダのアドレスはメール本文扱いなので、どうしてもend of DATAで
エラーにする必要があります。
エンベロープの送信者ではなくFromヘッダで制限をかけている事については、ユーザに
見えるのはFromヘッダなので、特に携帯電話ユーザであるという事を考えると妥当な
ように思えます。
# 一般ユーザにエンベロープの事を理解しろといっても難しいでしょう

なので、aaaも一緒にエラーになったように見えるのはある意味仕方ないと思います。
# 強いていうならば、メール本文に基づいた制限をユーザ毎にかけさせるのが
# 無理が有るという事でしょうか

仕様(RFC)的に一番問題があるaaaに届いてしまう事についても、他のユーザの制限の
巻き添えを食う事を考えれば、RFC的には間違っているけれど配送してしまうという
選択も理解出来ない事はないです。
# RFCをちゃんと理解した上での選択かどうかは判りませんが

> > docomo宛ては1アドレス毎に別々に送信するようにした方がいいかもしれませんね。
> > # 別々に送るようにした場合、また別の問題が起きるかもしれませんが
> 
> 実際には docomo宛は .forward に記載されていたんです。
> なので話がややこしくなり、苦労しました。
> 利用者に説明して納得させるのは難しい気がします。

ユーザ側に対処してもらうのは確かに難しいでしょうね。
私が考えていたのは、Postfix側での対処です。

例えば以下のような設定を行うと、docomo宛メールに関しては1アドレス毎に
独立に配送するようになりますので、bbbが配送エラーになったとしても、
その影響でaaaへの配送がエラーになる(ように見える)事はなくなります。
# ただ、結果としてメールの数が増える事になるので、別の問題が発生する
# 可能性はあります。(spam扱いされるとか)

[master.cf]
smtp-docomo   unix   -   -   n   -   -   smtp

[main.cf]
smtp-docomo_destination_recipient_limit = 1
transport_maps = ${config_directory}/transport

[transport]
docomo.ne.jp   smtp-docomo:

-- 
いわもと こういち(sue@xxxxxxxx/sue@xxxxxxxxxx/sue@xxxxxxxxxxxx)
# なるようになれ、明日もイケイケ♪

_______________________________________________
Postfix-jp-list mailing list
Postfix-jp-list@xxxxxxxxxxxxxxxxxxxx
http://lists.sourceforge.jp/mailman/listinfo/postfix-jp-list