受信済みメールの再度の受信No.09108
nakanaka2001 さん 05/03/17 23:40
 
特定メールを、鶴亀で再度受信する方法はあるのでしょうか。

「受信解析のやり直し」ができるように、受信ログを残すように設定変更しました。
再度受信し、受信解析のやり直しをして、HTMLメールで見たいためです。

Ver. 4.07 使用

[ ]
RE:09108 受信済みメールの再度の受信No.09109
おひ さん 05/03/18 00:06
 
おひと申します.

メールサーバにまだメールが残っているならば,
「送受信」メニューから「リモートメール」等で再受信できると思います.

[ ]
RE:09108 受信済みメールの再度の受信No.09116
秀まるお さん 05/03/18 16:49
 
 「送受信」メニュー中の「リモートメール - 現在メールの再受信」というの
があります。

 「受信解析のやり直し」でも結果的には同じことになると思いますけど。(受
信ログが残っているなら)

[ ]
RE:09116 受信済みメールの再度の受信No.09119
nakanaka2001 さん 05/03/18 17:18
 
リモートメールを始めて使い再受信できました。
ありがとうございました。

ところで、その後作成したメールが送信できなくなってしまいました。

■アカウント: 鶴亀メール でのエラー。
EHLOコマンドで、サーバーがエラーを返しました。エラー内容 = 535 authorization
 failed (#5.7.0)

これはどういう事なのでしょうか。

[ ]
RE:09119 受信済みメールの再度の受信No.09120
秀まるお さん 05/03/18 17:54
 
 今まで使えていたのがある日突然エラーになったってことなら、相手側のトラ
ブルかもしれませんけど…。

 可能性として、POP before SMTPがONでないとダメとかってこともあるかもし
れません。「アカウント毎の設定・メールサーバー」の「認証方式」の所にその
オプションがあります。

 具体的に、プロバイダーがどこか教えていただければ、例えばそこのプロバイ
ダーの設定ページを探して「こうすべき」みたいなアドバイスは出来ますけど。

[ ]
RE:09120 受信済みメールの再度の受信No.09121
nakanaka2001 さん 05/03/18 18:43
 
いつもお世話になります。

POP before SMTPはONで行っています。
SMTP認証もONで使えていました。
認証方式は、この2つがONです。

プロバイダーは、eoの64エアです。


[ ]
RE:09119 受信済みメールの再度の受信No.09122
おひ さん 05/03/18 18:52
 
リモートメールが関係あるのかと思い,ちょっと試してみましたが,
こちらでは問題ありませんでした.

> EHLOコマンドで、サーバーがエラーを返しました。エラー内容 = 535 authorization
>  failed (#5.7.0)

なので,「設定」-「アカウント毎の設定」の「メールサーバ」で
”SMTP認証”を設定されているような気がします.

もしかして,”セキュリティで保護されたパスワード認証”を意図せず
ON にされてたりしませんでしょうか?
#これで送信を拒否する MTA もいます.

普通のプロバイダ屋さんのメールサーバであれば ”POP before SMTP”
のみで*とりあえず*は送受信できると思います.
#Gmail とか XXXX とかは除く.


送信できた時から,設定変更とかしていない,と言うのであれば,多分
メールサーバ側の問題だと思います.

[ ]
RE:09121 受信済みメールの再度の受信No.09123
アルビレオ さん 05/03/18 19:38
 
鶴亀ユーザーのアルビレオです。

>POP before SMTPはONで行っています。
>SMTP認証もONで使えていました。
>認証方式は、この2つがONです。
>
>プロバイダーは、eoの64エアです。

eo64のwebサイトを見てみましたが、SMTP認証を利用するにはプロバイダ側の設
定も必要なようです。
http://eonet.jp/option/mail_security/
>※ SMTP認証、APOPは各種事務手続きでの利用開始設定
>およびメールソフトでの設定が必要です。

おひさんも書かれているようにエラーメッセージから推測すると、サーバー側が
SMTP認証を受け付けていないようなので、そちらを確認してみた方がいいですね。

POP before SMTPについては何も触れていないので、不要かもしれません。
(ONにしたままでも送信できなくなることはないですが)

[ ]
RE:09123 受信済みメールの再度の受信No.09124
nakanaka2001 さん 05/03/18 21:22
 
いろいろありがとうございます。

SMTP認証、APOPは、以前から設定済みです。
webサイトを見ても、一度設定しておけば良いと記されていました。

鶴亀が使えませんので、とりあえず、今はWEBメールでしのいでいます。
送信できない今の現象は、関連の有無は不明ですが、
鶴亀の「リモートメール」で特定メールを再受信をし、「受信解析のやり直し」を実
行してからの事です。
その他の設定は、送受信平常時から何ら変更箇所はありません。

[ ]
RE:09124 受信済みメールの再度の受信No.09125
秀まるお さん 05/03/18 21:40
 
 一度SMTP認証をOFFにしてみたらいいんじゃないかと思います。SMTP認証をOFF
にしてもPOP before SMTPがONなら問題なく送信できるんじゃないかと思います。

 心配ならさらにSMTP over SSLを使ってみるのもいいかもしれません。

> 鶴亀の「リモートメール」で特定メールを再受信をし、「受信解析のやり直し」を実
> 行してからの事です。

 一応それは関係ないはずですけど…。EHLOコマンドでエラーが返るっていうの
ならば、SMTP認証をOFFにする以外に解決手段は無いような気がします。

[ ]
RE:09124 受信済みメールの再度の受信No.09126
アルビレオ さん 05/03/18 22:06
 
アルビレオです。

>SMTP認証、APOPは、以前から設定済みです。
>webサイトを見ても、一度設定しておけば良いと記されていました。

そうでしたか。
まあ535を返しているということは、EHLOコマンド自体は正しく受け取っている
ので可能性は低いですが、念のためにプロバイダの設定画面で「今の状態」を確
認しておいた方がいいと思います。

今までは正しく動作していたといっても実際に送信に失敗しているのだから、鶴
亀側のパスワードやサーバーの設定も確認した方がいいでしょう。
もう一度送信してみて[送受信]-[直前のやりとりの記録]の内容をここに書けば、
もっと詳しいことがわかるかもしれません。

[ ]
RE:09124 受信済みメールの再度の受信No.09128
おひ さん 05/03/18 22:59
 
みなさんも書かれておりますが….

受信は問題ない訳ですよね!? であれば,

・SMTP認証    :全てOFF
・POP before SMTP:OFF
・APOP      :OFF          ;ついでに

を設定後,受信→送信すると,エラーメッセージが変わると思います.

#…って,これでも送受信できるプロバイダさん(設定/契約)ですよね!?
#鶴亀ではなく,別の通信ツールが原因だったり…とか.

[ ]
RE:09125 受信済みメールの再度の受信No.09129
nakanaka2001 さん 05/03/19 19:30
 
SMTP認証をOFFにしても、送信エラーです。

SMTPサーバーのアドレスを、vcsmtp.eonet.ne.jpから、vcを消し
smtp.eonet.ne.jpと設定すると送信できる事がわかりました。

以前からウィルスチェックをプロバイダーで受けていますので、
その時点から、SMTPサーバーのアドレスは、vcsmtp.eonet.ne.jpを
使って支障なく使用してました。(この時は、SMTP認証をONです)

現在プロバイダーから詳しい説明を受けていて、次回22日の予定です。

いろいろ有難うございます。

[ ]
RE:09129 受信済みメールの再度の受信No.09144
nakanaka2001 さん 05/03/22 21:45
 
プロバイダーと話は終わりましたが、送信不可が解決できていません。

★希望
ウィルスバスター使用中の鶴亀ユーザーに、
双方の設定方法を教えて頂ければ有難いです。

整理して問題点を記します。
★当方の環境
OS XP  I.E 6.0 SP2
鶴亀:Ver. 4.07
   アカウント設定
   送信サーバー:vcsmtp.eonet.ne.jp
   認証方式    :SMTP認証、POP before SMTP を ON
ウィルスバスター2005:常駐
プロバイダー:eo64

★問題点
1.鶴亀メールの送信が4,5日前からできなくなった。
   (それまでは、支障なし)
2.受信は支障なし。
3.SMTP認証をOFFにしても解決しない。

★現状
1.プロバイダーは、vcsmtp設定とウィルスバスターとの相性を指摘。
2.送信サーバー設定のvcを消し、smtp.eonet.ne.jpとすれば
  送信可能。

[ ]
RE:09144 受信済みメールの再度の受信No.09145
秀まるお さん 05/03/22 22:04
 
 すみません。今さら言うのもなんですが、SMTP認証の方式を変更すれば解決す
る可能性が高い気がします。

 「アカウント毎の設定・上級者向け」の「上級者向け設定を表示する」をONに
します。そして、「アカウント毎の設定・メールサーバー・トラブル対策」の
「SMTP認証の方式」を「PLAIN」にしてみて欲しいです。

 それでもダメなら、認証方式を「LOGIN」にすると解決するかもしれません。

 という話は以前から時々出ていることだったりします。ウィルスバスターうん
ぬんに気を取られて、肝心なこと(一般的な対策のこと)を忘れてました。

 あと、鶴亀メールの1つバグがあります。

    EHLOコマンドで、サーバーがエラーを返しました。
    エラー内容 = 535 authorization failed (#5.7.0)

 のようなエラーが出てるんだと思いますが、別にEHLOコマンドでエラーになっ
てる訳じゃなくて、「AUTH」コマンドでエラーになってるんだと思います。こち
らでその「vcsmtp.eonet.ne.jp」に無理矢理接続してテストしたら、AUTHでエ
ラーになってるようでして…。

 それはそれでバグとして修正させていただきます。
 (もともとこのバグのせいで話をややこしくしてしまいました。)

[ ]
RE:09144 受信済みメールの再度の受信No.09146
おひ さん 05/03/23 05:24
 
ISP HP に書いてあることだと思いますが,
  vcsmtp.eonet.ne.jp: SMTP認証必須 (LOGIN/CRAM-MD5/PLAIN)
  smtp.eonet.ne.jp  : SMTP認証不要 (というか未サポート)
なようです.

> ★問題点
> 1.鶴亀メールの送信が4,5日前からできなくなった。
>    (それまでは、支障なし)
> 2.受信は支障なし。
> 3.SMTP認証をOFFにしても解決しない。

上記理由のためだと思います.

> ★現状
> 1.プロバイダーは、vcsmtp設定とウィルスバスターとの相性を指摘。

ISP 側がおっしゃっている「vcsmtp設定」というのは鶴亀メールを意味
しているのだと思いますが,試しに一度,ISP 推奨メールソフト&手順
にて送信してみるのが良いのでは無いかと思います.
それでもダメなら 再度 ISP へ相談.

> 2.送信サーバー設定のvcを消し、smtp.eonet.ne.jpとすれば
>   送信可能。

SMTP認証不要なサーバのようですので,SMTP認証の設定有無に関わらず
送信できているのだと思います.


#パスワードを変更してみるのも一案かと.

[ ]
RE:09145 受信済みメールの再度の受信No.09147
nakanaka2001 さん 05/03/23 09:11
 
秀まるおさん  おひ さん
ありがとうございます。

> 「アカウント毎の設定・上級者向け」の「上級者向け設定を表示する」をONに
>します。そして、「アカウント毎の設定・メールサーバー・トラブル対策」の
>「SMTP認証の方式」を「PLAIN」にしてみて欲しいです。

この設定ひとつで、正常化しました。
メールサーバー・認証方式は、「SMTP認証」と「POP bifore SMTP」二つをONにして
います。

サポートフォーラムは、「ウィルスバスター」で検索していました。他のどこかに、
今回と同じことが記されているようですね。
これからは、検索に気をつけます。ありがとうございました。

[ ]
RE:09147 受信済みメールの再度の受信No.09148
おひ さん 05/03/23 13:20
 
nakanaka2001 さん直って良かったですね.


ところで,結果からちょっと「?」と思ったので,すいませんが便乗で
ご質問させて下さい.
#スレッドこのままでご容赦を.

SMTP認証を ON にした場合,多分「自動」がデフォルトだと思うのです
が,この「自動」の動きはどうなっているのでしょうか.

 (1) MTA の応答内容から使えるものを鶴亀側で判断し,CRAM-MD5 ->
     PLAIN -> LOGIN の優先順位で認証している.

 (2) 単純に CRAM-MD5 -> PLAIN -> LOGIN の優先順位で認証している.
   (この動きはしてなさそうですが)

といったどちらかのような気がするのですが,如何なのでしょうか?
#どちらでも「?」は解決しませんが….


#かくいうわたしはこべつしてい

[ ]
RE:09148 受信済みメールの再度の受信No.09149
秀まるお さん 05/03/23 13:37
 
> SMTP認証を ON にした場合,多分「自動」がデフォルトだと思うのです
> が,この「自動」の動きはどうなっているのでしょうか.

 メールサーバーがサポートしてる認証方式の中から優先順位の高い物を選ぶ形
になります。優先順位は、

 CRAM-MD5 > LOGIN > PLAIN

 です。CRAM-MD5でトライして失敗しても、LOGIN/PLAINでやり直すような処理
はありません。しかし、今回のようなトラブルもあるので、エラーになった時の
エラーメッセージに補足を付けて出すようにします。

[ ]
RE:09149 受信済みメールの再度の受信No.09150
おひ さん 05/03/23 14:58
 
おひと申します.
いつもお世話になっております.

ご回答有難うございます.

At Wed, 03/23/2005 13:37, 秀まるお<413360xxxxxxxxxxxxx@maruo.co.jp> wrote:
> > SMTP認証を ON にした場合,多分「自動」がデフォルトだと思うのです
> > が,この「自動」の動きはどうなっているのでしょうか.
>
>  メールサーバーがサポートしてる認証方式の中から優先順位の高い物を選ぶ形
> になります。優先順位は、
>
>  CRAM-MD5 > LOGIN > PLAIN

えっ.
LOGIN/PLAIN なアカウントも持っているのですが,こちらでは PLAIN
が選択されています.もちろん,どちらも使えてます.

>  です。CRAM-MD5でトライして失敗しても、LOGIN/PLAINでやり直すような処理
> はありません。しかし、今回のようなトラブルもあるので、エラーになった時の
> エラーメッセージに補足を付けて出すようにします。

メールサーバからの応答を見て,サポートしている方式を上記優先順位
に従い,自動的に選択してくれる.でも,選択したものがダメだからと
いって,次の方式をトライすることはない.という事ですね.

了解致しました.有難うございました.


#ということで,このスレッドの問題納得.
 SMTP AUTH Response と 使えるかどうかは別問題,なパターンですな.
 または,内/外別なパターンかな.

[ ]
RE:09150 受信済みメールの再度の受信No.09151
たまちゃん さん 05/03/23 15:22
 
>#ということで,このスレッドの問題納得.

納得までにもう少し。(^^

vcsmtp.eonet.ne.jp は3つの認証方式すべてに対応しています。
したがって鶴亀側が自動で認証方式を選択している場合にきちん
と応答しないといけない「はず」です。

CRAM-MD5 で決め打ちをして認証に失敗すれば eonet 側の問題
であることが判明すると思います。

>SMTP AUTH Response と 使えるかどうかは別問題

使えないのに DIGEST-MD5 に対応していると嘘の反応を示すもの
もありましたので,Response自体を疑う必要があるかもしれませ
ん。


[ ]
RE:09151 受信済みメールの再度の受信No.09152
秀まるお さん 05/03/23 16:02
 
 以前から何度か起きてる話なんですが、メールサーバー側はたしかにCRAM-MD5
に対応しているにも関わらず、なぜか鶴亀メールでのCRAM-MD5方式でのSMTP認証
がうまくいかない場合があります。

 なぜうまくいかないのかはよく分かりませんが、鶴亀メールは、実はnPOPとい
うソフトのソースコードを見てこの辺の(CRAM-MD5関係の)処理を実装していま
す。で、nPOPでも鶴亀メールと同じく、特定のメールサーバーに対してCRAM-MD5
での認証がうまくいかない場合があります。

 他に、CRAM-MD5方式で記述されたソースコードも見たことがありますが、それ
も鶴亀メール/nPOPと同じ方式でした。

 なので、鶴亀メールもnPOPも間違ってはいないと思うし、実際、今の鶴亀メー
ルのままでうまくCRAM-MD5が成功するメールサーバーも多く存在します。

 で、なぜそういうメールサーバーがあっても普通のユーザーさんは問題になら
ないかというと、Outlook ExpressではSMTP認証の方式として、PLAINにしか対応
していません。CRAM-MD5でダメなメールサーバーの場合でも、PLAINだとうまく
通ってしまいます。

 っということで、じゃぁ鶴亀メールもOutlook Expressのまねをして常にPLAIN
でやればいいんですけど、それはそれで一部の上級ユーザー様から「パスワード
をPLAINで流すのがデフォルトでは困る」という話がありました。

 という長々とした話をしてもなんですが…。

 とにかくV4.13にてエラーメッセージを改良したので、それで今後はこういう
トラブルも減るかなぁと思います。

[ ]
RE:09151 受信済みメールの再度の受信No.09153
おひ さん 05/03/23 18:54
 
独り言に反応してもらって恐縮です.(^^;


私はこの IPS 契約者ではないので,外側から見た前提で.

> vcsmtp.eonet.ne.jp は3つの認証方式すべてに対応しています。
見た目はそうですね.

> したがって鶴亀側が自動で認証方式を選択している場合にきちん
> と応答しないといけない「はず」です。
SMTP AUTH Response の通りに ISP 側がどの方式もサポートして
いる*なら*,鶴亀側で対応できていないのはマズイと思います.

> CRAM-MD5 で決め打ちをして認証に失敗すれば eonet 側の問題
> であることが判明すると思います。
ですね.でも,契約者ではなので確認とれず.

> >SMTP AUTH Response と 使えるかどうかは別問題
>
> 使えないのに DIGEST-MD5 に対応していると嘘の反応を示すもの
> もありましたので,Response自体を疑う必要があるかもしれませ
> ん。

ですね.
Response と 認証モジュールが正しく動作する,は別問題ですから.
#「ちゃんとサーバはメッセージを返してきてるんですが,認証がうま
  くいかないんですぅ〜」なパターンはありがち.
 #だって,返してくるメッセージはあなたが手打ちしたものだし,
  言われた通りに事務的に返しているんだから….
  #イヤ,ものにもよりますが.

ので私は,勝手にこっちの想定で自己解決させちゃいました.(^^;


…と書いているうちに,やっぱり適当な妄想はマズイので,ISP の HP
をサラッと覗いて見ましたが,どの認証方式をサポートしているのか
見つけられませんでした….
でも,OE/Becky! さん云々って書いているので,CRAM-MD5/LOGIN なのかな?


まぁ,vcsmtp 自体,外部に対しては Official ではないようですし,
外から見る分にはこれぐらいの妄想しかできませんねぇ….
内は内で,またそれなりに事情があったりするんでしょうし….
鶴亀側にも事情があったり….
#と,お茶を濁してみたり….


#私が契約者ならもちろんツッコンでみますよ.:-P

[ ]
RE:09152 受信済みメールの再度の受信No.09154
おひ さん 05/03/23 18:57
 
おひと申します.
いつもお世話になっております.


> に対応しているにも関わらず、なぜか鶴亀メールでのCRAM-MD5方式でのSMTP認証
> がうまくいかない場合があります。

あっ,そういうケースもあるんですね.
#SMTP AUTH を複数行返してくるから,とか.

>  なぜうまくいかないのかはよく分かりませんが、鶴亀メールは、実はnPOPとい
> うソフトのソースコードを見てこの辺の(CRAM-MD5関係の)処理を実装していま

余談ですが nPOP は出先とかでたまに使います.

| LOGIN/PLAIN なアカウントも持っているのですが,こちらでは「自動」に
| すると PLAIN が選択されています.もちろん,どちらも使えてます.

鶴亀と同じ CRAM-MD5 > LOGIN > PLAIN みたいですね.<初めて知った
でも,nPOP の場合 LOGIN で認証しました.

> ないかというと、Outlook ExpressではSMTP認証の方式として、PLAINにしか対応

えっ,たしか OE は LOGIN ではないでしょうか?
#でも OE 起動しないので確認できず….今は変わったのかな?

> でやればいいんですけど、それはそれで一部の上級ユーザー様から「パスワード
> をPLAINで流すのがデフォルトでは困る」という話がありました。

個人的には今のままで良いと思います.


#--enable-login=yes 外そうなか,といってみるテスト.でも無理.

[ ]
RE:09154 受信済みメールの再度の受信No.09155
たまちゃん さん 05/03/23 19:53
 
>#SMTP AUTH を複数行返してくるから,とか.

この問題(2行応答してくるケース)には大昔に対応していただき
ました。その節はお世話になりました。秀まるおさん。

>えっ,たしか OE は LOGIN ではないでしょうか?

そうだったと思います。

<余談>SMTP認証もへたな運用をすると踏み台になってしまうので,
ほんと管理サイドとしては気をもみます(汗)。</余談>

[ ]