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

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


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

[ 前の 20 件 | 123 /150ページ | 次の 20 件 ]

[1331] 削除
Name:
Date:
この記事は削除されました

返信する


[1330] 削除
Name:
Date:
この記事は削除されました

返信する


[1329] Re:アカウントが削除されたようです。
Name: Ms (HOME)
Date: 07/05 21:10
http://office.seth.jp/faq/etc8.php

返信する


[1328] アカウントが削除されたようです。
Name: ryu
Date: 07/05 21:08
しばらく送受信していなかったところ、
久しぶりに受信したらエラーになりました。
アカウントの情報を貴ホームページで見たところ
「○○@to.707.to は以前使用されていました。 」と表示されます。
家族のほかのアドレスは「△△@to.707.to は既に登録されております。」と表示され送受信できます。
アカウントが削除されたようですが、復活してもらうことはできますか?

返信する


[1327] 感謝です。
Name: monkey
Date: 07/04 23:55
素人の質問に丁寧にお答えいただいてありがとうございます。
また何か問題がありましたらよろしくお願いいたします

返信する


[1326] Re:できました。
Name: Ms (HOME)
Date: 07/04 22:23
別に問題ありません。気にしなくてもOKです。

(SMTPポートを25から587にしたままってことですよね?)

返信する


[1325] できました。
Name: monkey
Date: 07/04 21:27
速攻の回答ありがとうございました。
ポート番号の変更で無事に送信できるようになりました。

あつかましいですがもうひとつお聞きしたいのですが
このポート番号の変更は変更したままにしておいて問題ないのでしょうか?

返信する


[1324] Re:続・送信できません
Name: 再出発
Date: 07/04 21:21
@「op25b」は関係ありませんか。A他のメーラーでも同じですか?Bセキュリティソフトは削除してみましたか?

返信する


[1323] Re:続・送信できません
Name: Ms (HOME)
Date: 07/04 21:22
Outbound Port25 Blockingの影響かと思われます。
-- http://office.seth.jp/faq/setting2.php

(21:22 編集)
それと、何か出来なかったときに必ずエラー文が表示されると思いますが、そのエラー文を載せたほうが的確なアドバイスが受けられます。

返信する


[1322] 続・送信できません
Name: monkey
Date: 07/04 21:00
すみません。書き忘れましたが
受信はきちんとできています

メーラーの設定もやり直してみましたが
やはり受信のみ可能で送信しようとすると
サーバーにつながらないようです

返信する


[1321] 送信できません
Name: monkey
Date: 07/04 20:59
数日前よりメールの送信ができなくなってしまいました。
その日の午前中までは問題なかったですし
特に設定変更等は行っていないのですが・・・

サーバー側の問題でなければこちらの問題でしょうが
一度調べていただけないでしょうか?

返信する


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

返信する


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

返信する


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

また

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

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

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

返信する


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

返信する


[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 を パラメータエラー と定義した箇所は見つけられませんでした。

返信する


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

返信する


[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 のパラメータエラー と解釈されても問題ないかと思います。

返信する


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

返信する


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

返信する


[ 前の 20 件 | 123 /150ページ | 次の 20 件 ]

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


レッツPHP!