アカウント名:
パスワード:
# I will work seriously this year!
エンコード方法を気にしてた時代ははるか昔となりましたね。
ですから、受信に関しては何100MBであろうと受け入れます。 （さすがにGB単位になったらCDorDVDにしてくれ～と思いますが） もちろん送る時には相手に合わせます。あくまでも「受け入れ」の話。
# むしろ、FTPなどでダウンロードできる場所にテンポラリに置いてある巨大ファイルをいつまでも消さずに置いておかれる方が迷惑
決してMTAプログラマやメールクライアントプログラマの失業対策にあまり関心がない。
プログラマーはこんな矛盾した要求だらけの複雑怪奇なものには近寄りたくない
エンコーディング形式とファイル形式は可分です。マルチバイトか 2 Bytes 固定か 4 Bytes 固定か、big endian か little endian か、といったことと、○×語のこの文字にどの値を割り当てるか、といったことは独立して考えればよいのです。
で、メールのことを考えるなら 7 bits 伝送が基本なので、ファイル形式のことは考えなくてよいことになります。そして、実用されている世界中の文字コードという文字コードは、ASCII のサブセットです。
XML のヘッダ部分は ASCII で書くわけですから、エージェントは難なくその XML がどのエンコーディングで記述されているのかを知ることができます。
Unicode を使うメリットは、ここでエージェントが知らないエンコーディング形式に出会った場合はそのメールを閲覧できなくなる、という問題がなくなることにあるわけですが、そもそもそんな未知のエンコーディング形式 (恐らくそれは自分には関わりの無い言語によるもの) のメールはエージェントが読めてもユーザーは読めなかったりするわけで（ｗ、エージェントが Unicode の恩恵を受けることはあっても、ユーザーが Unicode の恩恵を受けることはあんまり無いかもしれない、という方々の方が、実は圧倒的多数であるような気もします。
# それでも、一部の他言語同時使用を望む方々 (決して「少数」ではないと思う) のために、Unicode のような 多言語サポートした文字コードは有用 だとは思うのですが、個人的には漢字が cjk 一絡げにされたり Windows 独自仕様が紛れ込んだりでややこしいことになっている Unicode はあまり好きじゃないというか、少なくともこれでどうにかする何かを作るような仕事には関わりたくないなぁというか。。。
そんな可能性って、現実的に、あるのでしょうか？
まぁUnicode自体が将来へツケをまわしてるような物だとは思うが。
英語で議論するときの準備段階として日本語で議論するのならともかく、最後まで英語ぬきで通すのは無理ですよ。
世界中で、英語圏はほんの一部だけです。それ以外の人たちはみんな、世界中で使う規格を話し合うときには外国語としての英語を苦労して使ってるんです。日本人だけわがまま言うことは許されません。というか単に無視されるだけでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
署名機能の義務づけ (スコア:3, 興味深い)
Signature ヘッダが無ければ無条件で弾き、あったらあったで公開鍵で復号して同一性を確認できなきゃそもそもメールを開かない。
これなら現状のメールシステムに大きな変更を加える事無く、メールクライアントの実装で対応できますよね。署名を付けたり確認したりはメールクライアントが自動処理可能ですし。
公開鍵はFromのメールアドレスの発行元が配布する、と決めてしまえば、Fromのメールアドレスが実在するかどうかも、サーバレベルで確認可能なんじゃないですかね。
ユーザーもメールアドレス取得時に鍵を生成するだけでいいので、そんなに手間じゃないと思うんですが。
匿名性が欲しければ匿名メールアドレスを配布してる業者(今のウェブメールはほとんどそうですよね)からもらえばいいわけで。
なんてことを考えつつ、それを英語で表現できない自分が悲しい……。
Re:署名機能の義務づけ (スコア:2)
> 匿名性が欲しければ匿名メールアドレスを配布してる業者
> (今のウェブメールはほとんどそうですよね)からもらえばいいわけで。
むしろ、匿名性をいかに排除するかが重要になると思います。
メールアドレスの正当性を確認するのではなく、
メール送信者（つまり個人とか団体）の正当性を確認する方法
が必要だと思います。
Re:署名機能の義務づけ (スコア:2, 興味深い)
正直、個人的にspamには困ってないんです。
むしろアドレス詐称による return mail がpostmaster宛にごろごろくるのが非常に腹だたしいわけで。
しかし、この仕組みだけでもある程度のspam減らしにはなると思いますよ。
なんせ自分のメールアドレス以外からは送れなくなるわけですから、身分を晒す事になります。
今までのようなreturn mailが大量に帰ってくる総当たりメールアドレス生成では、あっという間にISPから追い出されますね。
したがって有効アドレス収集になるわけですが、今までと違って送信者がわかるわけですから、ISPに苦情が殺到すればやはり追い出されるでしょう。
少なくとも自分のアドレスが有効アドレスであることをわざわざ教える事になるから出した人に文句も言えない、という状況は改善されると思います。
メールアドレス (スコア:3, 参考になる)
可能なため、正規表現では示すことができないそうです。
（メールアドレスの正規表現 [din.or.jp]）
しかも、そのコメントを無視しても、すさまじい長さの
正規表現になっちゃいます。
今度は、もっと短い正規表現で表現できるアドレスのフォーマットにしてもらいたいなぁ。
勝手に投げ込まれるのは、もう勘弁 (スコア:3, 興味深い)
現状では、受信側が勝手に投げ込まれてくるメール容量のストレージ維持を強いられている訳だが、送信側が負担しても良いよな。
もうひとつ、メール添付について (スコア:2, 興味深い)
私は1MB以上なら添付せずに郵送で送るか、FTPであげるか、はたまた他のサービス [filesend.to]を利用しているのですが、私がメールのやりとりをしている人の中には何の迷いも無く４０MBぐらいのファイルを添付ししようとするひとがいて、それ自体は悪くはないのだけどこのあたりのルールも作ってほしいものです。
そうすればメールサーバに必要以上に費用を出さなくていいですし。
みなさんは添付ファイルの容量って気にしてます？
気にしているなら何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:もうひとつ、メール添付について (スコア:1)
メールエージェントの連携、協調動作っていうのは確かに面白いかも。
Re:もうひとつ、メール添付について (スコア:1)
Re:もうひとつ、メール添付について (スコア:2, 興味深い)
たしかに、当時はやはりメールを使う人間が限られ小数だったこともあり、「それぞれが気をつけましょう」「大きなファイルは迷惑ですよ」という暗黙の了解的意識が強かったのかもしれません。
そのころはそれでも良かったんですが、今は通信速度の向上でネットワークの利用のされかたが多様化している今は「暗黙の了解」ではいけないんだなと実感します。
ただ、そのころの意識が強かった人間は今でも同じ意識で「10MB？そんなのメールで送ってくるな！」なんてことを言ってしまうのです。（私のことですが…）
だからこそ、明示的にルールを作る、もしくは添付ファイルは他のサービスにシフトしてもいいのかなと思うのです。
Re:もうひとつ、メール添付について (スコア:1)
大きくなったら圧縮して、FTPDなりHTTPDなりを経由させます。
メールの添付ファイルのサイズはSMTPDの設定しだいで切られることがあるので
巨大(感覚的には3MB以上)なものを送る時には"危ないかもしれない"と思います。
Re:もうひとつ、メール添付について (スコア:1)
また、受け取った側でも「受信したよ～。消してもいいよ」とか連絡する必要が無いとか、MTAがLAN等高速でアクセス可能な所にあるのであれば、ファイルを送られた事を感知してから手元に来るまでの時間が短くて済むというあります。
ですから、受信に関しては何100MBであろうと受け入れます。
（さすがにGB単位になったらCDorDVDにしてくれ～と思いますが）
もちろん送る時には相手に合わせます。あくまでも「受け入れ」の話。
# むしろ、FTPなどでダウンロードできる場所にテンポラリに置いてある巨大ファイルをいつまでも消さずに置いておかれる方が迷惑
Re:もうひとつ、メール添付について (スコア:1)
# 身の回りでは、もう全然見かけませんが…
次世代メールが目指すもの (スコア:2, 参考になる)
/K
Re:ユーザーは： (スコア:2)
温泉旅館のようなもので、これを温存し拡張し続けることが
短期的な失業対策としてはもっとも有効。
Re:次世代メールが目指すもの (スコア:2)
必要とされるのはそれが理由だ。
MLに登録してみると…… (スコア:1)
IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
モチベーションが薄くない？ (スコア:1)
そろそろ20年になるから新しいのがいるよね、ってだけで突っ走ってても、タレコミ子が書いているように、導入に至らず、議論するだけで終わってしまう気がする。（それはそれで有益かもしれないが）
そのプロトコルを導入することで何が劇的によくなるのか？
革新的なものでなければ、既存のものを置き換えることなんてできない。SMTP や POP を置き換えたいなら、これという目玉があるべきで、それは議論せずとも明らかなものでないといけないんじゃないか？
Re:モチベーションが薄くない？ (スコア:1)
POPの置き換えには程遠いような。
最近の人が平気で何十Mものメールをやり取りしてるなら
全部サーバにおくとたいへんな気が
IPv6の二の舞にならないように…… (スコア:1)
現在の電子メールの上位互換をきちんと確保して、一般ユーザがシームレスに乗り換えられる様に考えないと、IPv6の二の舞になりかねないのでは？
参考:
覚悟はできてますか? - トンでもなく高価なIPv6 [unixuser.org]
だが、いいこともあるぞ、外の天気は上々なんだ
Re:IPv6の二の舞にならないように…… (スコア:1)
現在、spamは社会的問題であり、トラフィックの面からも重要な課題です。
新システムへの移行はメリットが薄いどころか急務ではないでしょうか。
こっちはspamこないぞーって言えば、少々の手間があったとしてもみんな喜んで乗り換えるんじゃないですかね。
手間という意味では程度問題かもですが。
# 元コメントのIPv6問題のリンク先も読みました。
# どうせNATするならlocal addressよりIPv6使えばいいじゃん。
# IPv6同士はそのまま通信できるんだしー。
# とか思っちゃうのはダメなんですかね。
Unicode (スコア:1)
それはそうと、なんで単一の文字コードにしたがるのか理解に苦しむな。
xml のようにヘッダに文字コード付ければいいだけのような。完璧な文字コー
ドが存在するならともかく。
// 将来もっと素晴しい○○コードが生まれるかもしれないのに、猫も杓子も
// Unicode という現状はあまり好きではない。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:Unicode (スコア:1)
メールクライアントがそれを全部サポートしないといけなかったり、
文字化けの原因になったりするとおもいます。
なので、文字コードはひとつでいいんじゃないかなぁ。
#文字化けしないようにいろいろ大変なの。
Re:Unicode (スコア:1)
ただ始めのコメントでも言ったように、将来 Unicode に取って変わる規格が生
まれた時に困りませんか？……ということです。
Unicode 決め打ち、拡張性を両立できる方法ができたとしても、デファクトス
タンダードとして Unicode しか使われないのならば、それを前提とした行儀の
悪いコードが生まれるでしょうし。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
Re:Unicode (スコア:2, 興味深い)
エンコーディング形式とファイル形式は可分です。マルチバイトか 2 Bytes 固定か 4 Bytes 固定か、big endian か little endian か、といったことと、○×語のこの文字にどの値を割り当てるか、といったことは独立して考えればよいのです。
で、メールのことを考えるなら 7 bits 伝送が基本なので、ファイル形式のことは考えなくてよいことになります。そして、実用されている世界中の文字コードという文字コードは、ASCII のサブセットです。
XML のヘッダ部分は ASCII で書くわけですから、エージェントは難なくその XML がどのエンコーディングで記述されているのかを知ることができます。
Unicode を使うメリットは、ここでエージェントが知らないエンコーディング形式に出会った場合はそのメールを閲覧できなくなる、という問題がなくなることにあるわけですが、そもそもそんな未知のエンコーディング形式 (恐らくそれは自分には関わりの無い言語によるもの) のメールはエージェントが読めてもユーザーは読めなかったりするわけで（ｗ、エージェントが Unicode の恩恵を受けることはあっても、ユーザーが Unicode の恩恵を受けることはあんまり無いかもしれない、という方々の方が、実は圧倒的多数であるような気もします。
# それでも、一部の他言語同時使用を望む方々 (決して「少数」ではないと思う) のために、Unicode のような 多言語サポートした文字コードは有用 だとは思うのですが、個人的には漢字が cjk 一絡げにされたり Windows 独自仕様が紛れ込んだりでややこしいことになっている Unicode はあまり好きじゃないというか、少なくともこれでどうにかする何かを作るような仕事には関わりたくないなぁというか。。。
むらちより/あい/をこめて。
Re:Unicode (スコア:2, 参考になる)
反対理由としてはきわめて貧弱。
XML をたとえば UTF-8 で記述する際に、「これは UTF-8 ですよ」
と記載しておけば良いだけの話で、それ以上の心配は無駄です。
日本語に関して言えば、見掛け上、XML の記述に従来の文字コード
(ISO-2022-JP, EUC-JP, Shift_JIS) を使うことは出来るのだけれど、
これだけでは Unicode へのマッピング指定が不十分なので、
将来誰かが泣きを見ることになります。
2000年問題の例を挙げるまでもなく、将来にツケをまわすのは
システム開発者の得意技ではありますが、いわゆる「職人」の
職業倫理とは相容れないものです。
Re:Unicode (スコア:2)
つまんでいる状態になぞらえるなら、Unicodeへの移行はいわば
債務の集約にあたる。借金が消える訳ではないが、従来よりも
少しは状況をハンドリングしやすくなった。
SGML から XML への移行は、この変化にエンパワーされて起こった、
と私は理解している。Unicode がお気に召さないのなら、SGML時代に
舞い戻るという選択が君にはある。
実際の郵便を想定してみる。 (スコア:1)
考えてみると、
・内容証明（こう書いてあっただろ！とはっきり言うため）
・到着確認メール
・特定の相手からの受取拒否（USなどでDMの受取拒否が
できるらしい）。
・（実際の郵便にはないけど）開封した・取り込んだという
記録（今さっき読んだばかりです、という蕎麦屋の出前み
たいな返事をさせないため）。
今でもMTAの設定では実現できそうなものはありますね。
プロトコルとして規定するのはどうかと思いますが、念のた
め。
-- gonta --
"May Macintosh be with you"
Re:実際の郵便を想定してみる。 (スコア:1)
> 内容証明
PGPでもRSAでも電子署名はそのためにあるのでしょう。
自分自身ですら改ざんすれば明白なのですから。
それとも欲しいのは公証役場ですか？
> 到着確認メール
開封通知要求なら↓参照。
そうでなければ何が知りたいのか...
相手サーバまで到達したことを知りたい？
> 特定の相手からの受取拒否
RFC2635でもフィルタを使いなさいと。
管理者がユーザ思いならサーバサイド，そうでなければクライアントサイドということで。
> 開封した・取り込んだという記録
開封通知要求はRFC2298のDisposition-Notification-To:，あるいはRFC2076のReturn-Receipt-To:で規定されています。もちろん応じるかどうかはメーラーの対応及び受信者の意志に委ねられます。
Re:実際の郵便を想定してみる。 (スコア:1, 参考になる)
「こんな内容の手紙を、いつ、誰が、誰に送ったということを郵便局が証明してくれる」
というものです。
同じく配達証明は、「確実に配送したことを第三者が証明してくれる」サービスです。
要は、
「そんなこと書いてなかったぞ。捨てちゃったけど。」
「メール？そんなもん届いてないぞ。」
とか言われないための物です。
#普通は金銭トラブルとか、弁護士絡むようなことに使われると思うけど。
#メールで無料で出来るようになったら、仕事のメールみんなこれになりそうな･･･。
#でもって自分のtypoで自分の首を絞めると･･･。
Re:実際の郵便を想定してみる。 (スコア:1)
開封確認はOutlook Expressやmozilla等のMUAで既に実現されてるけど
spamで有効アドレス確認に使われることのほうが多かったので無効にしてる（開封確認に返信しない）
重要度とかのoptional headerも同様に事実上役立たず。
>特定の相手からの受取拒否
もたいていのMUAにありますね。mailboxまでは届いちゃうけど
Re:いろいろと (スコア:2, すばらしい洞察)
英語で議論するときの準備段階として日本語で議論するのならともかく、最後まで英語ぬきで通すのは無理ですよ。
世界中で、英語圏はほんの一部だけです。それ以外の人たちはみんな、世界中で使う規格を話し合うときには外国語としての英語を苦労して使ってるんです。日本人だけわがまま言うことは許されません。というか単に無視されるだけでしょう。
Re:いろいろと (スコア:1, おもしろおかしい)
Re:いろいろと (スコア:1, 参考になる)
各国ローカルで議論した事を纏め上げる仕組みがあれば。
「誰か」が英語はできなきゃいけませんし、英語ができればそれに越したことはありませんけど。
Re:まったくの新規で (スコア:1)
・ＤＮＳに登録されているメールサーバー以外からの
メール送受信禁止や問い合わせ拒否機能を標準に取り込む
- 逆引きするだけ
・利用地域毎の区分けと階層化機能
- internic -> 地域nic -> 国別NICの階層でIPアドレスの割り当てが公表されてるのでdbにして引くだけ（バナー広告とかでやってる）
結局「特定IPをはねるかどうか」だから、プロトコル以前の問題
そういう機能のメールサーバ実装がない（か知らない）だけで
Re:まったくの新規で (スコア:1)
> それに対応したソフトが出ないと、ですが。
これまでも「Rough Consensus & Running Code」の下、さまざまなプロトコルと
その実装が生まれ、残るものは残り、さらに発展し、消え去るものは消えさりました。
問題はプロトコルだけではなく、新しい価値を提案できるような実装を提示し、
人々にそのメリットを直観的に理解させることができるか、でしょうね。
メールの場合、相互運用性がないと、実用性が失われるという問題はありますが、
もしかしたら、それは、既存のSMTP/POP3/IMAP4との相互運用性を捨てた
実装かもしれません。
標準化は必ずしも重要ではないでしょう。少なくとも普及当初は。
Re:オイオイ、みんな落ち着け！ (スコア:2, すばらしい洞察)