パスワードを忘れた？ アカウント作成
Close
7417 story

次世代の電子メールのあるべき姿とは 148

ストーリー by yoosee
新たな舞台が欲しいひとのために 部門より

kappie曰く、"現在の電子メールのプロトコル群が生まれてから20年。そろそろ次世代の電子メールの規格を考えようよ、ということでIMC（電子メール業界におけるW3Cみたいなもの）のポール・ハフマン氏主催の私的勉強会「MAIL-NG」が発足し、メーリングリストで議論が始まっています。
1日数十通という活発な議論が展開されており、正直タレコミ人も追いつくのがやっとで発言なんてとてもという状態ですが、興味のある方は参加してみてはどうでしょうか。参加者による要約もありますが、論点としては

  • ストア＆フォワード、プッシュ型という現在のSMTPのような通信プロトコルの型を受け継ぐのか（配送の信頼性に関わるけど、今じゃメールロストなんて滅多にないよ）
  • データ形式は今のままテキストでいくのか、XMLにするのか（XMLはまだ枯れていない。大丈夫か？）
  • 差出人を認証するメカニズムを必須にするのか、現在のように匿名送信を認めるのか（匿名は大事かも知らんがスパムはイヤ！）
  • 文字コードはUnicodeを採用するのか（例によってUnicode好きと嫌いのかみ合わない話）
  • 暗号化、署名機能を必須にするのか（いまでもあるけど誰も使ってないよね。面倒くさいし。）
  • 他のメッセージング技術を統合する規格にするのか（後から出てきたIMの方が流行ってないか？　悔しいのぉ）
などがあります。この手の議論はHTTP-NGのように議論だけして実装されずに終わるという落ちがもっともあり得るわけですが、英語圏の人だけで規格が決められてしまわないように、1人でも多くの日本人が議論に加わることを切に願います。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

次世代の電子メールのあるべき姿とは More

  • 署名機能の義務づけ (スコア:3, 興味深い)

    by koshian (6999) on 2004年02月02日 14時55分 (#486270) ホームページ 日記
    Signature というヘッダを定義して、そこに本文を秘密鍵で暗号化したものを加えてからSMTPに送信する、ということを義務づけるだけでいいんじゃないかと思うんですよね。
    Signature ヘッダが無ければ無条件で弾き、あったらあったで公開鍵で復号して同一性を確認できなきゃそもそもメールを開かない。
    これなら現状のメールシステムに大きな変更を加える事無く、メールクライアントの実装で対応できますよね。署名を付けたり確認したりはメールクライアントが自動処理可能ですし。
    公開鍵はFromのメールアドレスの発行元が配布する、と決めてしまえば、Fromのメールアドレスが実在するかどうかも、サーバレベルで確認可能なんじゃないですかね。
    ユーザーもメールアドレス取得時に鍵を生成するだけでいいので、そんなに手間じゃないと思うんですが。
    匿名性が欲しければ匿名メールアドレスを配布してる業者(今のウェブメールはほとんどそうですよね)からもらえばいいわけで。

    なんてことを考えつつ、それを英語で表現できない自分が悲しい……。
    • この仕組みだと、署名を付ければSPAMも送信できそうですが？

      > 匿名性が欲しければ匿名メールアドレスを配布してる業者
      > (今のウェブメールはほとんどそうですよね)からもらえばいいわけで。

      むしろ、匿名性をいかに排除するかが重要になると思います。

      メールアドレスの正当性を確認するのではなく、
      メール送信者（つまり個人とか団体）の正当性を確認する方法
      が必要だと思います。
      シェア
      親コメント

      • Re:署名機能の義務づけ (スコア:2, 興味深い)

        by koshian (6999) on 2004年02月02日 16時40分 (#486351) ホームページ 日記
        ああ、すいません。ちょっと言葉が足りなかったかもですね。
        正直、個人的にspamには困ってないんです。
        むしろアドレス詐称による return mail がpostmaster宛にごろごろくるのが非常に腹だたしいわけで。

        しかし、この仕組みだけでもある程度のspam減らしにはなると思いますよ。
        なんせ自分のメールアドレス以外からは送れなくなるわけですから、身分を晒す事になります。
        今までのようなreturn mailが大量に帰ってくる総当たりメールアドレス生成では、あっという間にISPから追い出されますね。
        したがって有効アドレス収集になるわけですが、今までと違って送信者がわかるわけですから、ISPに苦情が殺到すればやはり追い出されるでしょう。
        少なくとも自分のアドレスが有効アドレスであることをわざわざ教える事になるから出した人に文句も言えない、という状況は改善されると思います。
        シェア
        親コメント

  • メールアドレス (スコア:3, 参考になる)

    by penguin3rd (14704) on 2004年02月02日 16時25分 (#486337) ホームページ
    現在のメールアドレスにはネストしたコメントを入れることが
    可能なため、正規表現では示すことができないそうです。
    （メールアドレスの正規表現 [din.or.jp]）
    しかも、そのコメントを無視しても、すさまじい長さの
    正規表現になっちゃいます。

    今度は、もっと短い正規表現で表現できるアドレスのフォーマットにしてもらいたいなぁ。

  • 勝手に投げ込まれるのは、もう勘弁 (スコア:3, 興味深い)

    by naruaki (2658) on 2004年02月02日 19時31分 (#486517) 日記
    UUCPの話も出てますが、今や常時接続があたりまえだろうから、メールはヘッダのみを相手に送る事とし、受信側が読みたいものを送信者サーバから拾ってくるという方式も可能だろう。
    現状では、受信側が勝手に投げ込まれてくるメール容量のストレージ維持を強いられている訳だが、送信側が負担しても良いよな。
  • 仕事柄、ファイルのやりとりをすることが多くてそのときにいつも感じるのです。

    私は1MB以上なら添付せずに郵送で送るか、FTPであげるか、はたまた他のサービス [filesend.to]を利用しているのですが、私がメールのやりとりをしている人の中には何の迷いも無く４０MBぐらいのファイルを添付ししようとするひとがいて、それ自体は悪くはないのだけどこのあたりのルールも作ってほしいものです。
    そうすればメールサーバに必要以上に費用を出さなくていいですし。

    みなさんは添付ファイルの容量って気にしてます？
    気にしているなら何MBまでが妥当だと？

    「信じられない！メールでなんでもかんでも送っちゃうなんて！」
    なんて言ったら「考え方が古いよお前は。」って言われてしまいました。
    --

    # I will work seriously this year!

    • Re:もうひとつ、メール添付について (スコア:2, 参考になる)

      by F8 (19734) on 2004年02月02日 14時51分 (#486265) 日記
      ネチケットガイドライン(RFC1855)日本語版 [cgh.ed.jp]には次のように書かれています。

      • 50キロバイトよりも大きいファイルを送らない
      • 他の方法でファイルを転送する
      • 分割して別のメールで送る


        • # この文書は95年に書かれているので、ファイルサイズ等は再考したほうが良さそうです。

        当時のエチケットが規格として定義されてしまうのは淋しいような気がします。「メーラー側でファイルサイズを確認して、FTP等の利用を勧めるメッセージを表示する。」ってのはどうでしょう？
      シェア
      親コメント
      • >「メーラー 側でファイルサイズを確認して、FTP等の利用を勧
        >めるメッセージを表示する。」ってのは どうでしょう？

        MIMEでMessage/External-Bodyとかあるんですけどね～

        そのあたりすら知られてないってのがなんとも……
        ま、もちろん、一般に使われるためには、送信者のプロバイダの
        サポートなんかも要るわけですが。
        --
        IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
        シェア
        親コメント
      • 「ネチケット」という言葉も懐かしい感がありますが、たしかにこういったものを規格化してしまう場合はその時代に応じた変化も取り込めるだけの柔軟性が必要かもしれません。
        しかし、それでは規格という性格が失われそうですし、「柔軟な変更」が加わってからその規格が伝播するまでに時間もかかる気がしますね。

        現在、HTMLメール（これもどうかと思うが）などでは画像をすでにあるサーバ上において利用されていますが、通常のメールもこのようにメールエージェントが行うのはテキストのメッセージングサービスだけで、他のサービスを「付随」させるという考え方のほうがいいのかなと思います。

        なら、「メール」サービスはメッセージングサービスのみに集中でき、「付随」サービスではアップグレードが容易になるのかなと。

        ここで、現状の「メール」サービスを拡張しようとすると「メール」サービスを利用しているユーザに、新たに「拡張した機能」への対応をせまることになるのかもしれません。

        正直、私も1行だけのメールもあれば、HTMLメール（メルマガなどで）や添付ファイルなど利用することは多様で1行のみのメッセージに「多機能」はいらないと感じますから。
        --

        # I will work seriously this year!

        シェア
        親コメント
        • >「ネチケット」という言葉も懐かしい感がありますが、たしかに
          >こういったものを規格化して しまう場合はその時代に応じた変化
          >も取り込めるだけの柔軟性が必要かもしれません。

          それ以前に、本質的に規格化できるものではないでしょう。
          RFCの唾棄すべきアレだって、Informationalなんだし。
          --
          IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
          シェア
          親コメント
      • >当時のエチケット

        ちがいます。
        RFC1855は「エチケットのガイドライン」の最小限の組み合わせにしか過ぎません。
        RFC1855にあるような合意はローカルではあったかもしれませんが、一般的にはなされてません。
        冒頭にもちゃんと書いてあるのに……
        シェア
        親コメント
        • ご指摘の通りですね。「当時のエチケット」＝「ネチケット」と捉えた方が他にもいたら、それは誤解です。失礼しました。書き直しますね。

          当時、添付ファイルのサイズはある程度個人の良識に任せられていたと思います。ローカルルールがある組織もありましたが、規格により定義されてはいませんでした。それが、規格として定義したほうが良いと言われてしまう今の状況は、なんだか淋しい気がします。規格として定義しなくとも、現状を打破する方法はあるのではないでしょうか？

          # 日本語って難しいな～
          シェア
          親コメント
      • UUCPでFTPメールしてた立場から見れば、これも随分新しい意見だな、とか思った。

        # 近所の大学にバイトに行った友人に、
        # ○○コンパイルして、分割してメールで送ってくれ、
        # とか言われて送った事あったなぁ。
        # 非力なマシンで、コンパイルするよりか、uudecode した方が
        # 早いんだよー、UUCPの待ち時間入れてもさ～、だとか。
        シェア
        親コメント
    • > このあたりのルールも作ってほしいものです。

      ローカルルールを作ればいいじゃない。
      ISPではすでに1通あたり10MBまでとかやってるよね。

      グローバルルールだと、数字をどのあたりにするかでもめるので
      ローカルルールにしておくのが具合がよいと思う。
      シェア
      親コメント

      • Re:もうひとつ、メール添付について (スコア:2, 興味深い)

        by Anonymous Coward on 2004年02月02日 14時49分 (#486264)
        新しいインフラ作ろうという話なんだから、送信側と受信側でネゴるようにするべきでしょうね。
        シェア
        親コメント

        • 大好評！社長ネタ (スコア:3, おもしろおかしい)

          by u1p (2709) on 2004年02月02日 18時16分 (#486442) 日記
          > 新しいインフラ作ろうという話なんだから、送信側と受信側でネゴるようにするべきでしょうね。

          うちのサーバは社長の横暴、いや要望で、50MBまで通すように
          設定させられていました。で、在宅スタッフが使っている
          ISP発効アドレスへ30MB程度のファイルをアタッチしたところ、
          向こうの設定(10MBまで…ちなみに受信メールボックスのquotaも
          10MBだったようですが(汗))で、届きませんでした。

          「俺のところは通すんだから、お前のところも通せ」

          とネゴ、いやゴネてました。
          (ウェブには一切、そこの問い合わせ電話番号なんか書いてないのに、
          なぜか電話してました。不思議だ。)
          シェア
          親コメント

        • Re:もうひとつ、メール添付について (スコア:2, 参考になる)

          by wlint (18720) on 2004年02月02日 15時23分 (#486288)
          > 新しいインフラ作ろうという話なんだから、送信側と受信側でネゴるようにするべきでしょうね。

          受信側がメールの受け入れ可能なサイズを表明するという機能は
          ESMTPのSIZEとして、既に実装されています。

          　次世代というなら、マルチメディア前提で作る事になるでしょうから、
          サイズだけじゃなくて、コンテンツの種類とかもネゴできるようになると、
          無駄な添付(読めないアプリデータやエンコード等。)の送受信を抑制
          できるようになるかもしれませんが。

          # そうなったら、個人的にはHTMLを受信拒否に設定しそうですが(苦笑)
          シェア
          親コメント
          • ＞# そうなったら、個人的にはHTMLを受信拒否に設定しそうですが(苦笑)
            次世代なら逆にHTMLのサブセットを標準にしてもいいかも。
            セキュリティ上問題があるからスクリプト禁止、外部参照禁止ってところで（リンクは別）。どうしても画像等張りたいならそれも添付（これも禁止でもいいかもしれないが）。
            次世代なんだから「ウチの環境では読めないから・・・」ってのは関係ないし。
            シェア
            親コメント
        • おぉ、なるほど。それは思いつかなかった。

          メールエージェントの連携、協調動作っていうのは確かに面白いかも。
          シェア
          親コメント
    • イッツ・コミュニケーションズ（昔の東急インターネット）は現在でこそ一通の制限が２０ＭＢ [itscom.net]となってますけど、昔はほぼ無制限だったらしく、ＣＤ－ＲＯＭの内容をそのまま添付した豪傑のためにメールサーバがダウンしたそうです。　私自身は大きなメールを送る時というのは、Ｗｅｂｍａｉｌしか使えない環境で自分宛にデータを送りたい時なので、メールボックスは可能な限り大きいほうがいいです（ftpとかストレージサービスを使えばいいという話しも有り）。他人に送る場合は社内ならほぼ気にせず。外部に送る場合も、仕事なら１～２ＭＢぐらいは気にせず送っています。エンコード方法を気にしてた時代ははるか昔となりましたね。
      シェア
      親コメント
      • エンコード方法を気にしてた時代ははるか昔となりましたね。

        たしかに、当時はやはりメールを使う人間が限られ小数だったこともあり、「それぞれが気をつけましょう」「大きなファイルは迷惑ですよ」という暗黙の了解的意識が強かったのかもしれません。
        そのころはそれでも良かったんですが、今は通信速度の向上でネットワークの利用のされかたが多様化している今は「暗黙の了解」ではいけないんだなと実感します。
        ただ、そのころの意識が強かった人間は今でも同じ意識で「10MB？そんなのメールで送ってくるな！」なんてことを言ってしまうのです。（私のことですが…）
        だからこそ、明示的にルールを作る、もしくは添付ファイルは他のサービスにシフトしてもいいのかなと思うのです。
        --

        # I will work seriously this year!

        シェア
        親コメント
    • 私もだいたい1MBが境界線です。
      大きくなったら圧縮して、FTPDなりHTTPDなりを経由させます。
      メールの添付ファイルのサイズはSMTPDの設定しだいで切られることがあるので
      巨大(感覚的には3MB以上)なものを送る時には"危ないかもしれない"と思います。
      シェア
      親コメント
    • メールで大きなサイズのファイルを添付する場合のメリットとして、相手にファイルが渡った後で別途削除しなくても良いというのがあります。
      また、受け取った側でも「受信したよ～。消してもいいよ」とか連絡する必要が無いとか、MTAがLAN等高速でアクセス可能な所にあるのであれば、ファイルを送られた事を感知してから手元に来るまでの時間が短くて済むというあります。

      ですから、受信に関しては何100MBであろうと受け入れます。
      （さすがにGB単位になったらCDorDVDにしてくれ～と思いますが）
      もちろん送る時には相手に合わせます。あくまでも「受け入れ」の話。

      # むしろ、FTPなどでダウンロードできる場所にテンポラリに置いてある巨大ファイルをいつまでも消さずに置いておかれる方が迷惑

      シェア
      親コメント

  • 次世代メールが目指すもの (スコア:2, 参考になる)

    by kappie (9734) on 2004年02月02日 20時56分 (#486591) ホームページ 日記
    提案はMLでやっていただくとして、現在のところの補足事項です。次世代メールが目指すものして、一般ユーザーに提示できる項目が以下のようにデイブ・クロカー氏によって投稿されました。

    • ユーザーは大量のスパムに煩わされることなくメールを読みたい
    • ユーザー（スパマーを含むがMLも同じ）は低いコストでたくさんの人にメッセージを送りたい
    • ユーザーは自分のコンピュータがウイルスやワームの脅威にさらされることなくメールを読みたい
    • ユーザーは自分の送信したメッセージが自分の知らないところでさらしものになることなくメッセージを交換したい
    • ユーザーはメールの仕組みが信頼できるものであってほしい（正当な理由がない限りきちんと届いて欲しい）
    • ユーザーはメッセージが相手に届いたかどうかを知りたい
    • ユーザーはメッセージを送ったのが実際に誰なのかを知りたい
    • ユーザーの中には匿名でメールを送りたい人もいる
    • 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい
    • 受信者は自分がメッセージを読んだことを送信者に知られずに読みたい
    • ユーザーは文書ファイルをそのままの形式で（いちいち変換せずに）やり取りしたい
    • ユーザーは文書ファイルの形式を受信者が読めるかどうか気にせずにメッセージをやり取りしたい
    • ユーザーは自分が読み書きできる言葉でメールをやり取りしたい
    • ユーザーは母国語で自分のメールアドレスを表記したい
    • ユーザーは自分のメールアドレスが受信者にとって読み書きできるものであって欲しい
    • ユーザーはデスクトップ、Webメール、PDA、携帯電話といったデバイスの違いにとらわれずに自分のメールボックスを利用したい
    • ユーザーの中にはボイスメールやFAXを電子メール経由で利用したい人もいる
    • ユーザーはメールソフトをとまどうことなく設定したい
    • ユーザーは受信者がまだ読んでいなければメッセージの送信を取り消したい
    • ユーザーは期限付きのメッセージを送信したい

      ここにないことを思いついたら投稿しよう！
    --

    /K
  • confirmationなしで登録されてしまったのはなぜ～
    --
    IN EARTH AND SKIE AND SEA STRANGE THYNGES THER BE.
  • 新しいプロトコルを作ろう、というモチベーションが薄い気がする。
    そろそろ20年になるから新しいのがいるよね、ってだけで突っ走ってても、タレコミ子が書いているように、導入に至らず、議論するだけで終わってしまう気がする。（それはそれで有益かもしれないが）

    そのプロトコルを導入することで何が劇的によくなるのか？
    革新的なものでなければ、既存のものを置き換えることなんてできない。SMTP や POP を置き換えたいなら、これという目玉があるべきで、それは議論せずとも明らかなものでないといけないんじゃないか？
  • 一番大事なのは現在の電子メールとの互換性だと思う。
    現在の電子メールの上位互換をきちんと確保して、一般ユーザがシームレスに乗り換えられる様に考えないと、IPv6の二の舞になりかねないのでは？

    参考:
    覚悟はできてますか? - トンでもなく高価なIPv6     [unixuser.org]
    --
    だが、いいこともあるぞ、外の天気は上々なんだ
    • IPv6の普及が進まないのは、IPv6によるメリットが薄いからですよね。
      現在、spamは社会的問題であり、トラフィックの面からも重要な課題です。
      新システムへの移行はメリットが薄いどころか急務ではないでしょうか。
      こっちはspamこないぞーって言えば、少々の手間があったとしてもみんな喜んで乗り換えるんじゃないですかね。

      手間という意味では程度問題かもですが。

      # 元コメントのIPv6問題のリンク先も読みました。
      # どうせNATするならlocal addressよりIPv6使えばいいじゃん。
      # IPv6同士はそのまま通信できるんだしー。
      # とか思っちゃうのはダメなんですかね。
      シェア
      親コメント
  • 宗教戦争はダメですよ(￣ー￣)ﾆﾔﾘ

    それはそうと、なんで単一の文字コードにしたがるのか理解に苦しむな。
    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)

      by penguin3rd (14704) on 2004年02月02日 16時16分 (#486327) ホームページ
      利用可能な文字コードを増やすと言うことは、
      メールクライアントがそれを全部サポートしないといけなかったり、
      文字化けの原因になったりするとおもいます。

      なので、文字コードはひとつでいいんじゃないかなぁ。
      #文字化けしないようにいろいろ大変なの。
      シェア
      親コメント
      • 一つに統一することのメリットは分かってるつもりです。

        ただ始めのコメントでも言ったように、将来 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.
        シェア
        親コメント
  • 実際の郵便のサービスを元に、あったらいいなぁと
    考えてみると、

    ・内容証明（こう書いてあっただろ！とはっきり言うため）
    ・到着確認メール
    ・特定の相手からの受取拒否（USなどでDMの受取拒否が
    　できるらしい）。
    ・（実際の郵便にはないけど）開封した・取り込んだという
    　記録（今さっき読んだばかりです、という蕎麦屋の出前み
    　たいな返事をさせないため）。

    今でもMTAの設定では実現できそうなものはありますね。
    プロトコルとして規定するのはどうかと思いますが、念のた
    め。
    --
    -- gonta --
    "May Macintosh be with you"
    • もうちょっとよく調べてからポストされた方がよろしいのでは？

      > 内容証明

      PGPでもRSAでも電子署名はそのためにあるのでしょう。
      自分自身ですら改ざんすれば明白なのですから。
      それとも欲しいのは公証役場ですか？

      > 到着確認メール

      開封通知要求なら↓参照。
      そうでなければ何が知りたいのか...
      相手サーバまで到達したことを知りたい？

      > 特定の相手からの受取拒否

      RFC2635でもフィルタを使いなさいと。
      管理者がユーザ思いならサーバサイド，そうでなければクライアントサイドということで。

      > 開封した・取り込んだという記録

      開封通知要求はRFC2298のDisposition-Notification-To:，あるいはRFC2076のReturn-Receipt-To:で規定されています。もちろん応じるかどうかはメーラーの対応及び受信者の意志に委ねられます。
      シェア
      親コメント

      • Re:実際の郵便を想定してみる。 (スコア:1, 参考になる)

        by Anonymous Coward on 2004年02月02日 17時01分 (#486367)
        内容証明郵便とは、
        「こんな内容の手紙を、いつ、誰が、誰に送ったということを郵便局が証明してくれる」
        というものです。
        同じく配達証明は、「確実に配送したことを第三者が証明してくれる」サービスです。

        要は、
        「そんなこと書いてなかったぞ。捨てちゃったけど。」
        「メール？そんなもん届いてないぞ。」
        とか言われないための物です。

        #普通は金銭トラブルとか、弁護士絡むようなことに使われると思うけど。
        #メールで無料で出来るようになったら、仕事のメールみんなこれになりそうな･･･。
        #でもって自分のtypoで自分の首を絞めると･･･。
        シェア
        親コメント
    • >開封した・取り込んだという記録
      開封確認はOutlook Expressやmozilla等のMUAで既に実現されてるけど
      spamで有効アドレス確認に使われることのほうが多かったので無効にしてる（開封確認に返信しない）
      重要度とかのoptional headerも同様に事実上役立たず。

      >特定の相手からの受取拒否
      もたいていのMUAにありますね。mailboxまでは届いちゃうけど
      シェア
      親コメント
typodupeerror

犯人はmoriwaka -- Anonymous Coward