アカウント名:
パスワード:
# I will work seriously this year!
受信側がメールの受け入れ可能なサイズを表明するという機能は ESMTPのSIZEとして、既に実装されています。
これ、いくつものサーバを経由するときはどう働くんでしょうね。 クライアントから要求があったときに、全部のサーバについて調べてから配送を開始するようになっていればいいんですが。
エンコード方法を気にしてた時代ははるか昔となりましたね。
ですから、受信に関しては何100MBであろうと受け入れます。 (さすがにGB単位になったらCDorDVDにしてくれ~と思いますが) もちろん送る時には相手に合わせます。あくまでも「受け入れ」の話。
# むしろ、FTPなどでダウンロードできる場所にテンポラリに置いてある巨大ファイルをいつまでも消さずに置いておかれる方が迷惑
また、受け取った側でも「受信したよ~。消してもいいよ」とか連絡する必要が無い
それはまた別の話ですね。 メールとは別に用意した大容量ファイルを削除するきっかけとしての連絡が必要無いという事を書いたまでです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
もうひとつ、メール添付について (スコア:2, 興味深い)
私は1MB以上なら添付せずに郵送で送るか、FTPであげるか、はたまた他のサービス [filesend.to]を利用しているのですが、私がメールのやりとりをしている人の中には何の迷いも無く40MBぐらいのファイルを添付ししようとするひとがいて、それ自体は悪くはないのだけどこのあたりのルールも作ってほしいものです。
そうすればメールサーバに必要以上に費用を出さなくていいですし。
みなさんは添付ファイルの容量って気にしてます?
気にしているなら何MBまでが妥当だと?
「信じられない!メールでなんでもかんでも送っちゃうなんて!」
なんて言ったら「考え方が古いよお前は。」って言われてしまいました。
Re:もうひとつ、メール添付について (スコア:2, 参考になる)
# この文書は95年に書かれているので、ファイルサイズ等は再考したほうが良さそうです。
当時のエチケットが規格として定義されてしまうのは淋しいような気がします。「メーラー側でファイルサイズを確認して、FTP等の利用を勧めるメッセージを表示する。」ってのはどうでしょう?
Re:もうひとつ、メール添付について (スコア:1)
>めるメッセージを表示する。」ってのは どうでしょう?
MIMEでMessage/External-Bodyとかあるんですけどね~
そのあたりすら知られてないってのがなんとも……
ま、もちろん、一般に使われるためには、送信者のプロバイダの
サポートなんかも要るわけですが。
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
Re:もうひとつ、メール添付について (スコア:2, 参考になる)
RFC 1873 - Message/External-Body Content-ID Access Type [faqs.org]
RFC 2017 - Definition of the URL MIME External-Body Access-Type [faqs.org]
RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types [faqs.org]
Re:もうひとつ、メール添付について (スコア:1)
しかし、それでは規格という性格が失われそうですし、「柔軟な変更」が加わってからその規格が伝播するまでに時間もかかる気がしますね。
現在、HTMLメール(これもどうかと思うが)などでは画像をすでにあるサーバ上において利用されていますが、通常のメールもこのようにメールエージェントが行うのはテキストのメッセージングサービスだけで、他のサービスを「付随」させるという考え方のほうがいいのかなと思います。
なら、「メール」サービスはメッセージングサービスのみに集中でき、「付随」サービスではアップグレードが容易になるのかなと。
ここで、現状の「メール」サービスを拡張しようとすると「メール」サービスを利用しているユーザに、新たに「拡張した機能」への対応をせまることになるのかもしれません。
正直、私も1行だけのメールもあれば、HTMLメール(メルマガなどで)や添付ファイルなど利用することは多様で1行のみのメッセージに「多機能」はいらないと感じますから。
Re:もうひとつ、メール添付について (スコア:1)
>こういったものを規格化して しまう場合はその時代に応じた変化
>も取り込めるだけの柔軟性が必要かもしれません。
それ以前に、本質的に規格化できるものではないでしょう。
RFCの唾棄すべきアレだって、Informationalなんだし。
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
Re:もうひとつ、メール添付について (スコア:1)
ちがいます。
RFC1855は「エチケットのガイドライン」の最小限の組み合わせにしか過ぎません。
RFC1855にあるような合意はローカルではあったかもしれませんが、一般的にはなされてません。
冒頭にもちゃんと書いてあるのに……
Re:もうひとつ、メール添付について (スコア:1)
当時、添付ファイルのサイズはある程度個人の良識に任せられていたと思います。ローカルルールがある組織もありましたが、規格により定義されてはいませんでした。それが、規格として定義したほうが良いと言われてしまう今の状況は、なんだか淋しい気がします。規格として定義しなくとも、現状を打破する方法はあるのではないでしょうか?
# 日本語って難しいな~
Re:もうひとつ、メール添付について (スコア:1)
# 近所の大学にバイトに行った友人に、
# ○○コンパイルして、分割してメールで送ってくれ、
# とか言われて送った事あったなぁ。
# 非力なマシンで、コンパイルするよりか、uudecode した方が
# 早いんだよー、UUCPの待ち時間入れてもさ~、だとか。
Re:もうひとつ、メール添付について (スコア:1)
ローカルルールを作ればいいじゃない。
ISPではすでに1通あたり10MBまでとかやってるよね。
グローバルルールだと、数字をどのあたりにするかでもめるので
ローカルルールにしておくのが具合がよいと思う。
Re:もうひとつ、メール添付について (スコア:2, 興味深い)
大好評!社長ネタ (スコア:3, おもしろおかしい)
うちのサーバは社長の横暴、いや要望で、50MBまで通すように
設定させられていました。で、在宅スタッフが使っている
ISP発効アドレスへ30MB程度のファイルをアタッチしたところ、
向こうの設定(10MBまで…ちなみに受信メールボックスのquotaも
10MBだったようですが(汗))で、届きませんでした。
「俺のところは通すんだから、お前のところも通せ」
とネゴ、いやゴネてました。
(ウェブには一切、そこの問い合わせ電話番号なんか書いてないのに、
なぜか電話してました。不思議だ。)
Re:もうひとつ、メール添付について (スコア:2, 参考になる)
受信側がメールの受け入れ可能なサイズを表明するという機能は
ESMTPのSIZEとして、既に実装されています。
次世代というなら、マルチメディア前提で作る事になるでしょうから、
サイズだけじゃなくて、コンテンツの種類とかもネゴできるようになると、
無駄な添付(読めないアプリデータやエンコード等。)の送受信を抑制
できるようになるかもしれませんが。
# そうなったら、個人的にはHTMLを受信拒否に設定しそうですが(苦笑)
Re:もうひとつ、メール添付について (スコア:1)
次世代なら逆にHTMLのサブセットを標準にしてもいいかも。
セキュリティ上問題があるからスクリプト禁止、外部参照禁止ってところで(リンクは別)。どうしても画像等張りたいならそれも添付(これも禁止でもいいかもしれないが)。
次世代なんだから「ウチの環境では読めないから・・・」ってのは関係ないし。
Re:もうひとつ、メール添付について (スコア:1)
で、規格に取り込まれてセキュリティ上の問題も排除されるなら拒否する理由ってなくなるよなぁ、っていうのが感想。
Re:もうひとつ、メール添付について (スコア:0)
Re:もうひとつ、メール添付について (スコア:1)
これ、いくつものサーバを経由するときはどう働くんでしょうね。
クライアントから要求があったときに、全部のサーバについて調べてから配送を開始するようになっていればいいんですが。
Re:もうひとつ、メール添付について (スコア:1)
メールエージェントの連携、協調動作っていうのは確かに面白いかも。
Re:もうひとつ、メール添付について (スコア:1)
Re:もうひとつ、メール添付について (スコア:2, 興味深い)
たしかに、当時はやはりメールを使う人間が限られ小数だったこともあり、「それぞれが気をつけましょう」「大きなファイルは迷惑ですよ」という暗黙の了解的意識が強かったのかもしれません。
そのころはそれでも良かったんですが、今は通信速度の向上でネットワークの利用のされかたが多様化している今は「暗黙の了解」ではいけないんだなと実感します。
ただ、そのころの意識が強かった人間は今でも同じ意識で「10MB?そんなのメールで送ってくるな!」なんてことを言ってしまうのです。(私のことですが…)
だからこそ、明示的にルールを作る、もしくは添付ファイルは他のサービスにシフトしてもいいのかなと思うのです。
Re:もうひとつ、メール添付について (スコア:1)
と、ネタは置いておいて、特定の人にだけファイルを渡せるようなサービスがあると便利ですね。
ftpとかで渡すとするとそこら辺めんどくさいから。
Re:もうひとつ、メール添付について (スコア:1)
大きくなったら圧縮して、FTPDなりHTTPDなりを経由させます。
メールの添付ファイルのサイズはSMTPDの設定しだいで切られることがあるので
巨大(感覚的には3MB以上)なものを送る時には"危ないかもしれない"と思います。
Re:もうひとつ、メール添付について (スコア:1)
でも、7~10MBくらいになると、大きすぎるようなきがしますねぇ。
1を聞いて0を知れ!
Re:もうひとつ、メール添付について (スコア:1)
また、受け取った側でも「受信したよ~。消してもいいよ」とか連絡する必要が無いとか、MTAがLAN等高速でアクセス可能な所にあるのであれば、ファイルを送られた事を感知してから手元に来るまでの時間が短くて済むというあります。
ですから、受信に関しては何100MBであろうと受け入れます。
(さすがにGB単位になったらCDorDVDにしてくれ~と思いますが)
もちろん送る時には相手に合わせます。あくまでも「受け入れ」の話。
# むしろ、FTPなどでダウンロードできる場所にテンポラリに置いてある巨大ファイルをいつまでも消さずに置いておかれる方が迷惑
Re:もうひとつ、メール添付について (スコア:1)
httpd とかの方が、(自分でサーバを立てている場合なら)ログをチェックすることで、相手が受け取ったかどうかある程度チェックできて便利だと思います。https使えば経路の暗号化もできるし。
# でも、確実を期すならやっぱり連絡は必要...
なんちゃってプログラマ?
Re:もうひとつ、メール添付について (スコア:1)
それはまた別の話ですね。
メールとは別に用意した大容量ファイルを削除するきっかけとしての連絡が必要無いという事を書いたまでです。
Re:もうひとつ、メール添付について (スコア:1)
なんちゃってプログラマ?
Re:もうひとつ、メール添付について (スコア:0)
>なんて言ったら「考え方が古いよお前は。」って言われてしまいました。
その人の言うとおり、考え方が古いと思います。
今なら、P2P で(ry
Re:もうひとつ、メール添付について (スコア:1)
# 身の回りでは、もう全然見かけませんが…