> の箇所のように「件数上限 = 0」の指定で受信を行えば、
> メールの受信は行われないので、認証だけ行えるという事
> ですね！

これもやりたいことでした。何から何まで、本当にありがとうございました。

> POP before SMTP

桐の場合はリファレンスに書いてありますが、
> メールを送信するために、POP3サーバーにログインします。 
の箇所のように「件数上限 = 0」の指定で受信を行えば、
メールの受信は行われないので、認証だけ行えるという事
ですね！

hidetake様

> Yahoo!メールは、POP before SMTP もしくは SMTP-AUTH に対応しているらしいけど
> 「桐」は SMTP-AUTH に対応していないので、POP before SMTP で、事前に POP認証
> して、同じ IPアドレスで一定時間以内で無いと、送信を許可されたいという事です
> ね！

恥ずかしながら、このような知識は全くありませんでした。
送信出来たときがあったのは、偶然受信を行った後に送信していたのですね。納得です。

これで添付ファイルの送受信は、何とか出来そうです。いろいろと勉強になりました。
ありがとうございました。

> あとはログを取ってみればサーバの動きや最終的なエラーの内容もわかる
> と思います。

遅くなりました。ログを取ってみました。下記の通り（一部伏せ字）ですが何が問題なのか分かりません。
ニフティからヤフー宛のメール送信はアウトルックから問題なく行えています。
 
22:30:53 SMTP    : Connecting to ybbsmtp.mail.yahoo.co.jp:25    (11/27/05)
22:30:53 SMTP  < : 220 ybbsmtp17.mail.tnz.yahoo.co.jp ESMTP
22:30:53 SMTP  > : EHLO [19*.16*.12*.11*]
22:30:53 SMTP  < : 250-ybbsmtp17.mail.tnz.yahoo.co.jp
22:30:53 SMTP  < : 250-AUTH LOGIN PLAIN
22:30:53 SMTP  < : 250-PIPELINING
22:30:53 SMTP  < : 250 8BITMIME
22:30:53 SMTP  > : RSET
22:30:54 SMTP  < : 250 flushed
22:30:54 SMTP  > : MAIL FROM: <***@ybb.ne.jp>
22:30:54 SMTP  < : 521 ybbsmtp.mail.yahoo.co.jp closing transmission channel.  You must be pop-authenticated before you can use this smtp server, and you must use your yahoo mail address for the Sender/From field.
22:30:54 SMTP  > : QUIT
22:30:54 SMTP    : Recv failed
22:30:54         : Closing socket

このログは便利ですね。一括処理本体の動作をこのようにログに記録するこ
とは出来ないのでしょうか。

> # と言う事で、現状にて安心して使えるのは、kthree 様が想定している
> # という事はテストもされているだろうから、現実的には
> # 数MBから十数MBを限度に使うのが安全なのかな？ それにスピード的にも
> # 現実的かも知れない？

ありがとうございます。これをリファレンスに載せてほしいですね。

Ogo様、ヤフーメールのフォローありがとうございました。
 

> ヤフーメールでの送信可能メールサイズはいくらになっているのでしょうか？
> まずはその制限に引っかかっている可能性が一番大きいです。

以下の通りですので、どう考えても 20MB は無理ですね。

> 1つのメールにはファイルを5つまで、合計10MBまで添付できます。

> > そのような大きなサイズのファイルはないのでとりあえず桐のテーブルで５ＭＢ
> のものがあったのでテストしました。ヤフーメールでテストをしているのですが、
> 送信が成功するときとしないときがあります。桐の一括処理は全く同じなのに、送
> 信結果に違いがあります。
> > 桐が返す送信コマンドの終了状態は次のものです。
> 「-8 差出人のメールアドレスが、SMTPサーバーから拒否された。」
> メールアドレスが間違っているなら理解出来るのですが、何度確認しても合っているし
> 送信出来るときもあるので私の力では理解出来ません。

ヤフーメールでの送信可能メールサイズはいくらになっているのでしょうか？
まずはその制限に引っかかっている可能性が一番大きいです。

メールの場合、添付ファイルはテキストファイルで送られるので、バイナリ
ファイルは BASE64 と言う方式でテキストに変換されます。この変換で元々
のバイナリサイズより、実際は相当大きなサイズに脹れあがります。
ですので、「添付ファイルの元々のサイズ ＝ メールの制限サイズ以内」と
言うわけにはいきません。



> > 次のような表示でコメントいただいていますが、どのようなソフトで出力されているの
> でしょうか。これを用いれば私の不具合も調査出来るのでしょうか。

KIRI9.ENV の [一括処理] セクションに次の記述を設定すればログファイルが取れるようです。

[一括処理]
Mail Log File=x:\kirimail.log

なお、テスト以外ではこの設定は外した方が良かろうと思われます。

hidetake様
 
> 舩井さんが、500MB とか、あるいは 1GB のファイルを添付して
>「桐」から送信テストしてみて下さい。

そのような大きなサイズのファイルはないのでとりあえず桐のテーブルで５ＭＢ
のものがあったのでテストしました。ヤフーメールでテストをしているのですが、
送信が成功するときとしないときがあります。桐の一括処理は全く同じなのに、送
信結果に違いがあります。

桐が返す送信コマンドの終了状態は次のものです。
「-8 差出人のメールアドレスが、SMTPサーバーから拒否された。」
メールアドレスが間違っているなら理解出来るのですが、何度確認しても合っているし
送信出来るときもあるので私の力では理解出来ません。

次のような表示でコメントいただいていますが、どのようなソフトで出力されているの
でしょうか。これを用いれば私の不具合も調査出来るのでしょうか。
> 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
> 10:04:51 SMTP    : Connecting to mail.asahi-net.or.jp:25    (11/22/05)
> 10:04:51 SMTP  < : 220 mail.asahi-net.or.jp ESMTP Postfix
> 10:04:51 SMTP  > : EHLO hoge.hoge.org
> 10:04:51 SMTP  < : 250-mail.asahi-net.or.jp
> 10:04:51 SMTP  < : 250-PIPELINING
> 10:08:02 SMTP  > : <MAIL DATA>
> 10:33:27 SMTP  > : .
> 10:33:27 SMTP  < : 250 Ok: queued as 177602588F
> 10:34:50         : Closing socket
> 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

> 問い合わせ結果です。
> > 「添付ファイルの容量(大きさ)は、桐には制限はありません。」
> > この件については、たった一行でした。

舩井さんが、500MB とか、あるいは 1GB のファイルを添付して
「桐」から送信テストしてみて下さい。

もし、そのまま通って、テスト相手(自分でも可)にメールも送られ、
でも、中身が無かったら「桐」はどんなサイズの添付ファイルでも
送れない事になります。
その際に、相手に届いたメールの中身と、「桐」がメールを送った
際に保存される .eml ファイルを比べてみるとよろしいかと思います。
もし、相手に添付ファイルの中身の無いメールが届いて、 .eml に
も添付ファイルの中身の無かったら、桐は送る段階で正しく大きな
添付ファイルを取り扱えなかった事になります。

hidetake様

> 別にアンチウィルスソフトは拡張子では中身を判断しませんよ！
> そんなんで通ったらアンチウィルスソフトの意味はなしません。

そのとおりですね。失礼しました。

hidetake様
 
> あとで気になったのですが、このようなアンチウィルスの動作で時間がかかる
> 場合、添付ファイルが圧縮ファイルだったら(展開のために)更に時間がかかる
> ため送れるサイズに影響は出るのでは無いだろうかと言う疑問から、ZIP 形式
> で圧縮してあるファイルについて送信テストしてみました。

とんでもない発想ですが、ＺＩＰファイルの拡張子を無理矢理ＴＸＴなどに変更すると
どのような動作になるのでしょうか。
サーバ側は、ファイルの中身を自動判定しているのでしょうか。ＴＸＴでも中身のむち
ゃくちゃなものがあるかも知れない、と思ってしまうのですが。

hidetake様
 
>>添付ファイルも送れるようですが、容量に制限はあるのでしょうか。
> 
> このような内容は開発元に問い合わせるのが一番だし確実だと思います。
> 
問い合わせ結果です。

「添付ファイルの容量(大きさ)は、桐には制限はありません。」

この件については、たった一行でした。

いろいろと試してくださり感謝します。それにしてもサーバ側のウィルスチェックの機能が
仇になるのですね。
開発元に問い合わせると、一行の回答なのにここで質問させていただくとかなり具体的な回
答が得られて頼もしい限りです。

ありがとうございます。

最近は spam 対策のフィルターなども多く導入されているわけですが
これなども負荷が大きくなってレスポンスがかかるようになると「桐」
のメール送信でも影響が出てくるかも知れませんね？

# でも、エラーを受けてでは無く、単純 10秒待ちって、やはり短すぎ
# では？　RFC 等ではこの辺の規定などあるのだろうか？

> >>考えている送信容量は、２０ＭＢもないので１３０ＭＢで成功したとの話は
> >>嬉しい限りです。

結局、私のところのメールサーバでは、通常状態の AntiVirus を活かした状態
で、完全無負荷の状態で 8MB は通らず 7MB は OK でした！　orz

# 受信の方は「桐」は APOP 不可なのでテストも行えず。　(;_;)

> > 考えている送信容量は、２０ＭＢもないので１３０ＭＢで成功したとの話は
>>嬉しい限りです。

ガァ〜ん！　AntiVirus を活かした状態では 22.2MB の添付ファイルも
------------------------------------------------------------
KU1827:ﾒｰﾙｻｰﾊﾞｰと通信ができませんでした (recv)
------------------------------------------------------------
のエラーが発生しました。(なお実際のデータは通っているわけですが！)

私のメールサーバは sendmail + milter と言って、sendmail が受信
したメール(スプールデータ)を、内部で一旦 milter 方式の AntiVirus 
にチェックさせ、問題が無かったら sendmail に戻され、そして、内部
(外部)へと配信される方式なのですが、この方式だとチェックが終わる
まで本当に受け入れて良いのか判断は待たされるので、今の「桐」だと
10秒以内でウィルスチェックできるサイズと言う事で、キツく！なって
しまいますねぇ〜

# なんも無しで素通りだと 10秒は短くも無いかも知れないけど？

> 考えている送信容量は、２０ＭＢもないので１３０ＭＢで成功したとの話は
> 嬉しい限りです。

念のため、再度 130MB の添付ファイル送信を「桐」でやってみたら
今度は失敗でした。
------------------------------------------------------------
KU1827:ﾒｰﾙｻｰﾊﾞｰと通信ができませんでした (recv)
------------------------------------------------------------
と出ました。

良く思い出すと 500MB の後の 130MB 送信は AntiVirs ソフトの
悪影響が出ないようにと AntiVirs を殺した状態でのテストでした。

ですので、130MB あたりだと「桐」自体が送れないサイズでは無い
ようです。

ただし、先に書いたように「桐」がメールデータを送信後、メール
サーバに対して、これで終わりだよ！と言う目印の「.」を送信した
後、「桐」はサーバからの受信完了メッセージを 10秒間までしか
待ってくれません。

ですので、ここいら辺の制限はサーバのレスポンスや、アンチウィ
ルスソフトの動作等で時間を要するものは、「桐」のタイムアウト
時間により引っかかってしまう事でしょう。

サーバの混んだ時間帯や、あるいは、サーバの構成、アンチウィルス
ソフトの有無などで、数十メガのファイルでも送れない場合は出て
くるかも知れません。

そして、数百メガのオーダーだとうまくいったように見えても中身
の無いファイルが送られてしまうかも知れません。

試しに、普通に数メガ、数十メガの制限のある ISP のメールサーバ
に対して、1GB オーダーの添付ファイルを「桐」で送ったら、おそ
らくは通ると思います。中身は無いので・・・

# それにしても、タイムアウト 10秒って言うのは短すぎでは！？