Since the introduction of Internet standards for multimedia mail [12], message lengths on the Internet have grown dramatically, and message size restrictions should be avoided if at all possible. SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension [18], and SMTP client systems that will send large messages SHOULD utilize it when possible.
だいたい、自分で付けた "MUST BE at least 64k octets" をどう読んだら『64K octets未満にしなければならず』という日本語になるんだか。
普通、at least なんとかなら最低限なんとかって訳になるんじゃないかと思うんですが。(少なくとも私の通ってた中学じゃそう教えてたような気がする)
ただ、いずれにしても続く文言でも書かれていることは up to date な MTA ならもっと長いメッセージが扱えるべきってことだし、そういう背景を前提とした上で 50KB 固定で分割ってのは今どき変だ、ってのが #625527 [srad.jp]での私の意見なのです。
うちの会社的にやってはいけないこと (スコア:1)
「やってはいけない」、「やってしまうと恥ずかしいですよ」と口を酸っぱくして社内に行ってまわってるんですが、、、
Re:うちの会社的にやってはいけないこと (スコア:-1, 余計なもの)
なぜ、わかっているのにAL-Mailに分割させる……
#有無をいわせずってか、自分で選択してるだけじゃん
Re:うちの会社的にやってはいけないこと (スコア:2, 参考になる)
添付する際に「分割する」というチェックボックスにチェックを入れなければ分割されませんが...
マイナスモデついてますが、つけた人は事実をちゃんと確認したんでしょうかね?
してないでしょ。 (スコア:1)
もしくは、古いバージョンを使っている/いた、でしょうね。
AL-Mail32 Ver.1.13の変更点 [almail.com]に
とある通り、以前は確かにデフォルトが「分割して送信する」でした。
でも、おっしゃる通りファイル添付時に出る上記のダイアログでチェックを外せば分割はされないので、元発言のように「問答無用」というのはちょっと違うと思いますけどね。ダイアログの文面なんざろ
Re:してないでしょ。 (スコア:1)
もと発言者です。
書き方が悪くて誤解を招いたようですみません。
言いたかったのは「分割しようとすると有無を言わさず50KBに分割してしまう」ということです。
まぁ、そもそも分割メールで送るってこと自体が時代から外れたこと(分割メールだとわざと受け取らない MTA すらあります)なんですが、中途半端に仕入れた知識で、大きなメールは分割して、、、なんてやられたときに 50KB
MUST BE at least 64k octets (スコア:1, 参考になる)
> ルだとわざと受け取らない MTA すらあります)なんですが、中途半端に仕入れ
> た知識で、大きなメールは分割して、、、なんてやられたときに 50KB なんて細
> かく割って一斉に送りつけると、ほとんど DoS 攻撃になってしまうんですねー。
RFC 2821によるとmessage contentは64K octets未満にしなければならず、
その扱いはMUST BEです。
文字列を64K octetsに押え込もうとするとbase 64化される前のデータは
およそ50K byte
Re:MUST BE at least 64k octets (スコア:1)
ダウト。
RFC-2821 [ietf.org] にあるのは
sec.4.5.3.1 "Size limits and minimums"
で、SMTP サーバの実装として「最小でも64Kオクテットのメッセージを受け取れなければならない」が正解。
この項では続いて
Re:MUST BE at least 64k octets (スコア:0)
続く文言も「可能な限り」ということなので、可能ではないように実装されていれば、結局のところ 64KB が RFC 的に言えば最も安全なメッセージサイズであると言えるのでは?
RFC の文では 64KB 以下を担保しているけど、
64KB 以上は可能な限りということなので、送信できなくても仕方が無い。
元コメントの表現というかRFC
Re:MUST BE at least 64k octets (スコア:1)
という議論であれば「間違ってはいない」とは言えますね。
ただ、だからと言って 64K オクテットしか扱えない実装の MTA があったら、実際には「その MTA やっぱヘンだよ」とは言ってしまうと思いますが。
問題なのは RFC を論拠に引くようなふりをして
こうして原文に当たらずに捏造されたウソが一人歩きしていくんでしょうね。
だいたい、自分で付けた "MUST BE at least 64k octets" をどう読んだら『64K octets未満にしなければならず』という日本語になるんだか。
普通、at least なんとかなら最低限なんとかって訳になるんじゃないかと思うんですが。(少なくとも私の通ってた中学じゃそう教えてたような気がする)
ただ、いずれにしても続く文言でも書かれていることは up to date な MTA ならもっと長いメッセージが扱えるべきってことだし、そういう背景を前提とした上で 50KB 固定で分割ってのは今どき変だ、ってのが #625527 [srad.jp]での私の意見なのです。
Re:MUST BE at least 64k octets (スコア:0)
>問題なのは RFC を論拠に引くようなふりをして
これは同意。
>モデしちゃう
まぁ皆さん時間ないでしょうし、暇な人ばかりにモデ権が行くわけでもないので、あまり責められないとは思います。
>50KB 固定で分割ってのは今どき変だ
こっちは激しく同意しておきます