| 2005/11/20(Sun) 23:24:53 編集(投稿者)
> 添付ファイルも送れるようですが、容量に制限はあるのでしょうか。
このような内容は開発元に問い合わせるのが一番だし確実だと思います。
ヘルプファイルなどには制限などの記述は無いので普通に取れば無制限
だとも取れますが、確実にどんな容量でも取り扱えるとは限りませんの
で・・・
ここからは私の手元環境で調べた内容であり、一般的なメールの使い方
であれば、特に問題になる方な事は無いと思います。・・・
で、手元のサーバで試してみました。
環境は Linux Server の Turbo Linux 8 Server で、sendmail 8.12.10
にアンチウィルス関係で H+BEDV AntiVir UNIX MailGate が入っています。
もちろん、メールサーバの容量による制限はかけてない状態です。
まず、試しにどこまで大容量のメールが本当に送れるかどうかを試す
ために CMAIL WRITER Ver.2.39.0.1 で 500MB の添付ファイルを送って
見ました！ CMAIL は送信ファイルをエンコードする段階で作業ファイル
を作りますが、この段階で大変な時間を要しました。そして、配信すべき
ファイルが完成すると実際の送信に取りかかるわけですが、実際の送信
はうまくいき送信完了します。
この段階でメールサーバは、クライアントからのメールを一旦スプールし
スプールが完了した段階で、AntiVir がウィルスチェックを開始し、これ
が完了した段階で、メールサーバはクライアントに受信完了の指令を出す
ようです。この段階で CMAIL は送信がうまく完了したと判断し終了します。
ここから、メールサーバはシステム上のスプールファイルを、実際のメール
ユーザのメールボックスに配信しますが、私のメールサーバでは procmail
が使用されますが、500MB のサイズでは procmail が EX_TEMPFAIL の
エラーを発生しユーザのメールボックスに配信する事ができませんでした。
さて、同じ 500MB の巨大なファイルを「桐9-2004sp2」で送信してみますと
偉く早い時間で送信完了したかと感じると、実際のメールは Multipart の
中身の添付ファイルが BASE64 でエンコードされている中身が全く抜け落ち
た状態で配信されました。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
メールメールの送信テスト
---059bdla40e3UYegjj7_Multipart=_--
Content-Type: application/octet-stream; name="test.iso"
Content-Disposition: attachment; filename="test.iso"
Content-Transfer-Encoding: base64
---059bdla40e3UYegjj7_Multipart=_----
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
(kisend0.emlの中身からも「桐」のデータ作成においての不具合です)
次に 130MB ほどのファイルを「桐」で送信してみますと、これは問題なく
送信できました。
さて、ではいったいいくらまで送信できるか確かめるために、今度は 284MB
のファイルを送ってみますと、「桐」は次のような挙動を示しました。
まずは、桐もメールで送るためのエンコードを行うと思いますが、「桐」は
どうも作業ファイルは使わずメモリ上で作業を行っているようです。
実際の送信が行われる前段階で、タスクマネージャーを見ていると 800MB超
までメモリの使用量が拡大しました。
500MB だとさぞかし大量のメモリを使うと考えられます。もちろん、OS は
スワップファイル(仮想メモリ/ページングファイル)を使用するようになって
いるわけで、アプリケーションもうまく作られていれば、これで即制限が
出てくるわけでは無いと思いますが・・・
さて、桐がメモリ上でデータを作り終えた後で実際のメール送信に入ります
が、桐はどうもタイムアウトを短く見ているようです。
データの送信開始からでも2分ほどで、完了の応答が無いと失敗したと判断して
しまうようです。
「.」(終わり)の送信からだと、たったの10秒です。
# サーバのレスポンスが悪かったり 10秒以内に受信完了を答えられない
# サーバ(状態)では「桐」はエラーになるのかな？
# CMAIL は長い間、待ってくれましたが・・・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
22:00:25 SMTP : Connecting to hoge.org:25 (11/20/05)
22:00:25 SMTP < : 220 hoge.org ESMTP Sendmail; Sun, 20 Nov 2005 22:00:25 +0900
22:00:25 SMTP > : EHLO hoge.hoge.org
22:00:25 SMTP < : 250-hoge.org Hello hoge..hoge.org [192.168.x.y], pleased to meet you
22:00:25 SMTP < : 250-ENHANCEDSTATUSCODES
22:00:25 SMTP < : 250-PIPELINING
22:00:25 SMTP < : 250-EXPN
22:00:25 SMTP < : 250-VERB
22:00:25 SMTP < : 250-8BITMIME
22:00:25 SMTP < : 250-SIZE
22:00:25 SMTP < : 250-DSN
22:00:25 SMTP < : 250-ETRN
22:00:25 SMTP < : 250-DELIVERBY
22:00:25 SMTP < : 250 HELP
22:03:00 SMTP > : RSET
22:03:00 SMTP < : 250 2.0.0 Reset state
22:03:01 SMTP > : MAIL FROM:<name@hoge.org>
22:03:01 SMTP < : 250 2.1.0 <name@hoge.org>... Sender ok
22:03:01 SMTP > : RCPT TO:<name@hoge.org>
22:03:01 SMTP < : 250 2.1.5 <name@hoge.org>... Recipient ok
22:03:01 SMTP > : DATA
22:03:01 SMTP < : 354 Enter mail, end with "." on a line by itself
22:03:01 SMTP > : <MAIL DATA>
22:05:15 SMTP > : .
22:05:25 SMTP : Recv failed
22:05:28 SMTP > : QUIT
22:05:38 SMTP : Recv failed
22:05:38 : Closing socket
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
送信が完了すると、サーバ側から
23:05:12 SMTP < : 250 2.0.0 jAKE5BAh026223 Message accepted for delivery
のようなメッセージが返され
23:05:56 : Closing socket
する。「桐」はこの送信完了を待ちきれない！？
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
メールサーバの方は、いろんな作業を行っているわけだし、これほどの
巨大なファイルになると、その時間も相当かかるわけですが、「桐」は
短い時間でタイムアウトし、処理を打ち切ってしまうようです。
でのすので「桐」は次のようなメッセージを表示し途中終了してしまい
ました。
----------------------------------------------------------------
KU1827:ﾒｰﾙｻｰﾊﾞｰと通信ができませんでした (recv)
----------------------------------------------------------------
(このエラーが発生すると kisend0.eml は作成されないので、メール送信
完了後、メモリ上から kisend0.eml は作成されるのかな？)
メールサーバの方は実際にはアンチウィルスソフトがデータを検査して
いる段階です。
で、桐はエラーを出し途中で止まってしまいましたが、メールサーバは
一応スプールファイルとしてデータは全部を受け取った後なので、ウィ
ルスの検査の後、拒否する状態でも無かったので、ユーザのメールボッ
クスまで配信されました。
テストの結果、あまりに大きなデータのおそらくは「桐」上の不具合と
実際に送れても送信完了を待てないという「桐」のタイムアウトの関係の
２段階で、桐のメール送信のサイズの制限は出てきそうです。
なお、あくまでもテストは私の環境での結果であり、環境が変われば違い
も出てくるかも知れません。
と、言う事で、まぁ〜フツーの使用では問題ないでしょうが、あまりに
大きいと影響は出てきそうだと言う？内容だと思います。
|
