ZENNOコム Logo
 Welcome
 リストマーク フリーメール  リストマーク 100円メール  リストマーク Webメール  リストマーク  初心者マーク 使い方 初心者マーク  リストマーク サポート
 リストマーク PukiWiki  リストマーク WebMail(Beta)  リストマーク リンク  リストマーク ダイナミックDNS  リストマーク ログイン

freeアイコン  フリーメール・サポート掲示板


 新規投稿 | ツリー | スレッド | タイトル | 一覧 | 検索 | ログ | 設定 

No.1310に関するツリー
-あて先に11件以上設定した際のエラーについて [hadsn] (07/01 19:24)
 └Re:あて先に11件以上設定した際のエラーについて [Ms] (07/01 19:27)
  └なぜ555から553に変更してほしいか [hadsn] (07/01 19:46)
   └550の方が良いかもしれない理由。 [hadsn] (07/01 19:52)
    └Re:550の方が良いかもしれない理由。 [ぜんの] (07/01 21:17)
     └Re[2]:550の方が良いかもしれない理由。 [hadsn] (07/01 22:06)
      └Re[3]:550の方が良いかもしれない理由。 [ぜんの] (07/01 22:43)
       └Too many RCPTぐらい入れてほしい。 [hadsn] (07/01 23:19)
        └Re:Too many RCPTぐらい入れてほしい。 [ぜんの] (07/01 23:47)
         └問い合わせるようにという意図の文でどうでしょう。 [hadsn] (07/03 00:01)
          └Re:問い合わせるようにという意図の文でどうでしょう。 [ぜんの] (07/03 16:21)

[1310] あて先に11件以上設定した際のエラーについて
Name: hadsn
Date: 07/01 19:24
555エラーじゃなくて553エラーを返すように設定を変えられないんですか?

返信する


[1311] Re:あて先に11件以上設定した際のエラーについて
Name: Ms (HOME)
Date: 07/01 19:27
>555エラーじゃなくて553エラーを返すように設定を変えられないんですか?
そう思われる理由について書いておくといいかもしれません。

返信する


[1312] なぜ555から553に変更してほしいか
Name: hadsn (HOME)
Date: 07/01 19:46
555は「MAIL/RCPT のパラメータエラー」なのに対して553は「要求されたコマンドは受け入れられない」だからです。
パラメータエラーなら良く解らないのに対して受け入れられないならまだ解り易いかと。
参考はURL

返信する


[1313] 550の方が良いかもしれない理由。
Name: hadsn
Date: 07/01 19:52
550でもかまいません。
「要求されたアクションを実行できない」だから。

返信する


[1314] Re:550の方が良いかもしれない理由。
Name: ぜんの (HOME)
Date: 07/01 21:17
このエラーコードは qmail に maxrcpt.patch を
そのまま適用した状態であまり意識していませんでした。

私もあまり詳しくないのですが私の勉強した範囲では
RFC 2821 で 返答コードの 第一文字目と第ニ文字目は
厳密に定義されていますが
第三文字目については第二文字目のカテゴリーをさらに
細かに意味づけるものということになっているのでは無いかと思います
http://tools.ietf.org/html/rfc2821#section-4.2.1

[hadsn]さん が参考されたURLの表にも RFCの例にないコード番号が掲載されていますが
555 自体も RFCに例として明示されていないコードです

maxrcpt.patch の作者は
553 でも 550 にも”ぴったり”こない別の分類として扱いたいと考えたのだと思います。

私の感覚としては {555 = MAIL/RCPT のパラメータエラー}
がグローバルスタンダードな解釈とは思いませんが
RCPTの数が多すぎるというエラーですから
MAIL/RCPT のパラメータエラー と解釈されても問題ないかと思います。

返信する


[1315] Re[2]:550の方が良いかもしれない理由。
Name: hadsn
Date: 07/01 22:06
個人的にはパラメータエラーというよりは要求された数が大杉で、これ以上RCPTが受け付けられない、
これ以上多いと送信が実行できないという解釈からです。
お手数かけました。

返信する


[1316] Re[3]:550の方が良いかもしれない理由。
Name: ぜんの (HOME)
Date: 07/01 22:43
先に書いたとおり
パラメータエラー と解釈しておられるのは
http://www.7key.jp/nw/technology/protocol/smtp.html
の方の見解で
私どもは パラメータエラー のつもりで出しているのではありません

RFCを読み進めて、さらに該当する部分を見つけました
http://tools.ietf.org/html/rfc2821#section-4.5.3.1
の最終部分

-----------
If an SMTP server has an implementation limit on the number of RCPT
commands and this limit is exhausted, it MUST use a response code of
452 (but the client SHOULD also be prepared for a 552, as noted
above). If the server has a configured site-policy limitation on the
number of RCPT commands, it MAY instead use a 5XX response code.
This would be most appropriate if the policy limitation was intended
to apply if the total recipient count for a particular message body
were enforced even if that message body was sent in multiple mail
transactions.
-----------
SMTP サーバーが RCPT コマンドの数に実装上の制限を持っており、その限界まで使い尽くされた場合、そのサーバーはレスポンスコード 452 を使用しなければならない(ただし、クライアントは 552 の準備も出来ているべきである)
そのサーバーが RCPT コマンドの数に設定済みサイトポリシーによる制限を課している場合、そのサーバーは代わりにレスポンスコード 5XX を使用しても良い
-----------------------------
と定められていることから
基本的には452の一時エラーを返すべきだが
当サイト独自の制限には任意の5XXのコードを返すこと
がRFCに準拠できていることになります。


555 を パラメータエラー と定義した箇所は見つけられませんでした。

返信する


[1317] Too many RCPTぐらい入れてほしい。
Name: hadsn
Date: 07/01 23:19
勝手な解釈をしてしまいすみませんでした。
でも、定義されていないものを独自仕様として使うのはあまりよくないかと思います。
さらに555 syntax error(#5.5.4)と訳のわからない状況にしておくのはもっと良くないかと。
まぁ、混乱して暴れているだけですけどw

返信する


[1318] Re:Too many RCPTぐらい入れてほしい。
Name: ぜんの (HOME)
Date: 07/01 23:47
> Too many RCPTぐらい入れてほしい
まさに、これについては仰るとおりです、

また

555 syntax error(#5.5.4) が何を表すエラーなのかを
このサイト内で調べられるように表示しておくべきですね
なるべく早く用意します。
というか別途準備しているところでしたが
まだタイトルだけでした。

> 定義されていないものを独自仕様として使うのはあまりよくないかと
先に書いたRFCのとおり良くなくは無いと思われます
他のサイトではエラーにならない固有の制限でのエラーは
むしろ通常一般的に使われているエラーコードを使用するより
原因の切り分けに誤解が生じにくいはずです。

別の観点から、その制限自体の根本的な目的である
悪意のあるユーザーの大量送信を防ぐためには
エラーの発生原因を特定させない、問い合わせないとわからない、という状態が望ましいのですけど。。

返信する


[1319] 問い合わせるようにという意図の文でどうでしょう。
Name: hadsn
Date: 07/03 00:01
>他のサイトではエラーにならない固有の制限でのエラーは
>むしろ通常一般的に使われているエラーコードを使用するより
>原因の切り分けに誤解が生じにくいはずです。
言われてみればごもっともです。
>エラーの発生原因を特定させない、問い合わせないとわからない、という状態が望ましい
タイトルのようにされてはいかがでしょうか。

返信する


[1320] Re:問い合わせるようにという意図の文でどうでしょう。
Name: ぜんの (HOME)
Date: 07/03 16:21
そうですね。
次回のサーバー改修時に採用したいと思います
ご提案ありがとうございました。
見本になるような英文探してみます。

返信する


レッツPHP!