アカウント名:
パスワード:
実は、連続ドットやアットマーク直前のドットがあるメールアドレスを発行していた3キャリアは、実はRFC的には問題ありませんでした。
というメールアドレスであっても MTA が とすれば良いだけなのです。quoted-string 形式を扱えないタコな MTA で不具合が生じていただけで、3キャリアはRFC的には悪くありませんでした。
問題となっているRFCは、通信に使われるメッセージフォーマットを定めたものであって、ユーザーが使用するメールアドレス、つまりはMUAのアドレス欄とかWebのフォーム等に入力するメールアドレスの表示を定めたものではありません。即ち、エンドユーザーのメーラーの表示は「"hoge..hoge."@example.com」であっても「hoge..hoge.@example.com」であってもどちらでもよろしいです。それを外部に出す前に適切に quoted-string 形式に変換すれば良いだけなので、Webフォームでは「hoge..hoge.@example.com」を validation で弾くのではなく、「"hoge..hoge."@example.com」に escape すべきなのです。
3キャリアはRFCを読んだことのない人達やRFCで定められたquoted-string 形式をまともに扱えないタコなMTAを使っている事業者から、冤罪で「RFC違反」というレッテル張りをされた被害者です。
2行目は、スラド側で半角 < から 半角 > までの間がHTMLタグと判定されて消されたようなので、2行目だけ再投稿します。
<hoge..hoge.@example.com> というメールアドレスであっても MTA が <"hoge..hoge."@example.com> とすれば良いだけなのです。
このMTAっていうのは3キャリアのMTAのことです。
外部に出すメッセージフォーマットとして、<"hoge..hoge."@example.com> にしていれば問題ないわけですし、割と初期から(本当の大昔はどうだったか知りませんが少なくともRFC違反がどうのという騒ぎがネット上である程度大きくなってからは)3キャリアのメールサーバはそういう処理をしていました。
RFCが定めているのはメッセージフォーマットなのですから、例えば3キャリアにメールを送るユーザーがMUAに <hoge..hoge.@example.com> を入力したならば、MUA はそれを MTA に送る前に RFC に準拠した quoted-string 形式 である <"hoge..hoge."@example.com> に変換すべきです。そうすれば、正しいメッセージフォーマットで SMTP が使用されたことになり、タコなMTAが無ければ何の問題も生じなかったのです。
3キャリアのMUA(ガラケーに内蔵されていたメーラー)はメールメッセージをMTAへ送る前にクォートしていたのですか? その部分はインターネットではなく、たまたまインターネットと同じインフラを流用した3キャリアの閉域網だから、RFCに従う必要はないという理屈でしょうか?
その通りです。そもそも、ガラケーはWebもメールもキャリアのゲートウェイで変換する前提となっており、インターネットではありません。メールだって、通信量を減らすため、ガラケーでの表示に影響のないヘッダーも削除されるし、文字コードその他もゲートウェイで変換されます。そのゲートウェイの仕様はRFCがどうのとかは全く関係ない独自のものになっています。
インターネットの世界から考えれば、ガラケー本体とガラケーのゲートウェイサーバ、両方合わせて「MUA」として初めて機能する形となっております。現にガラケー本体から直接外のSMTPサーバと通信することなどできないのですから。
ガラケー網の外の世界にデータが投げられるとき、初めてRFCに従う必要が出てくるのです。
別に閉域網なら誰も文句は言わなかった。ただ、インターネットと接続する以上、その理屈は通用しない。RFCではメッセージフォーマットだけではなく、アドレス形式も定めている。インターネットと接続するならRFCに準拠したアドレスへの変更を呼び掛けるべきだったのに、ドコモはそれを怠った。結果、ドコモから送信はできるけれども、ドコモへ送信できないという事態が頻発した。これはMTAがタコだったわけではなく、RFCに準拠していないメールは配送途中で紛失のおそれがあったため、事前にMTA側でエラーを返すという考えに基づくもの。完全にドコモの自業自得。
はい、嘘松。それ、ドコモが批判を受けた時に言い出した屁理屈ですよね。
RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES [ietf.org]
6. ADDRESS SPECIFICATION 6.1. SYNTAX address = mailbox ; one addressee / group ; named list group
word = atom / quoted-stringquoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or quoted chars.
qtext = <any CHAR excepting <">, "\" & CR, and including linear-white-space>
ぱっと見3.3にはこう書いてある””で括ればいいような気がしちゃうんだが違うの?
「abc.@example.jp」と「"abc."@example.jp」を同一のアドレスとみなす保証がどこにもないので第三者が勝手に括るのは危険
「abc.@example.jp」は不正な形式だから、どう解釈すればいいかは定義されていない、だからどこがlocalpartかも決定できないそれなのに「"abc."@example.jp」と勝手にlocalpartの範囲を「abc.」と決めつけて引用符をつけているこれは、docomoの独自仕様だ!
って理解でいいのかな
でもこの理解だと、RFC822では「”abc."@example.jp」の扱い方は定義してあるから、そういうメールアドレスを作ってはいけないって話にならない気がするちゃんと「"abc."@example.jp」って書け!「abc.@〜」はやめろ!ってしか言えなくなっちゃう
RFC 822中の独立した章で定義されていたところで、それはあくまでRFC 822中で使うために定義されているのであって、RFC 822に準拠したメッセージの読み書き以外の文脈で従う義理はない。実際、RFC 821はmailboxについてRFC 822を参照せず独自に定義している。
RFC 822冒頭の「1.1 SCOPE」にも
This standard specifies a syntax for text messages that are sent among computer users, within the framework of "electronic mail". The standard supersedes the o
つまり元コメの
即ち、エンドユーザーのメーラーの表示は「"hoge..hoge."@example.com」であっても「hoge..hoge.@example.com」であってもどちらでもよろしいです。
それを外部に出す前に適切に quoted-string 形式に変換すれば良いだけなので、Webフォームでは「hoge..hoge.@example.com」を validation で弾くのではなく、「"hoge.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
そもそも、quoted-string 形式を扱えないタコなMTAが原因で3キャリアは冤罪被害者だった (スコア:0)
実は、連続ドットやアットマーク直前のドットがあるメールアドレスを発行していた3キャリアは、実はRFC的には問題ありませんでした。
というメールアドレスであっても MTA が とすれば良いだけなのです。
quoted-string 形式を扱えないタコな MTA で不具合が生じていただけで、3キャリアはRFC的には悪くありませんでした。
問題となっているRFCは、通信に使われるメッセージフォーマットを定めたものであって、ユーザーが使用するメールアドレス、つまりはMUAのアドレス欄とかWebのフォーム等に入力するメールアドレスの表示を定めたものではありません。
即ち、エンドユーザーのメーラーの表示は「"hoge..hoge."@example.com」であっても「hoge..hoge.@example.com」であってもどちらでもよろしいです。
それを外部に出す前に適切に quoted-string 形式に変換すれば良いだけなので、Webフォームでは「hoge..hoge.@example.com」を validation で弾くのではなく、「"hoge..hoge."@example.com」に escape すべきなのです。
3キャリアはRFCを読んだことのない人達やRFCで定められたquoted-string 形式をまともに扱えないタコなMTAを使っている事業者から、冤罪で「RFC違反」というレッテル張りをされた被害者です。
Re: (スコア:0)
2行目は、スラド側で半角 < から 半角 > までの間がHTMLタグと判定されて消されたようなので、2行目だけ再投稿します。
<hoge..hoge.@example.com> というメールアドレスであっても MTA が <"hoge..hoge."@example.com> とすれば良いだけなのです。
Re: (スコア:0)
このMTAっていうのは3キャリアのMTAのことです。
外部に出すメッセージフォーマットとして、<"hoge..hoge."@example.com> にしていれば問題ないわけですし、割と初期から(本当の大昔はどうだったか知りませんが少なくともRFC違反がどうのという騒ぎがネット上である程度大きくなってからは)3キャリアのメールサーバはそういう処理をしていました。
RFCが定めているのはメッセージフォーマットなのですから、例えば3キャリアにメールを送るユーザーがMUAに <hoge..hoge.@example.com> を入力したならば、MUA はそれを MTA に送る前に RFC に準拠した quoted-string 形式 である <"hoge..hoge."@example.com> に変換すべきです。
そうすれば、正しいメッセージフォーマットで SMTP が使用されたことになり、タコなMTAが無ければ何の問題も生じなかったのです。
Re: (スコア:0)
3キャリアのMUA(ガラケーに内蔵されていたメーラー)はメールメッセージをMTAへ送る前にクォートしていたのですか? その部分はインターネットではなく、たまたまインターネットと同じインフラを流用した3キャリアの閉域網だから、RFCに従う必要はないという理屈でしょうか?
Re: (スコア:0)
その通りです。
そもそも、ガラケーはWebもメールもキャリアのゲートウェイで変換する前提となっており、インターネットではありません。
メールだって、通信量を減らすため、ガラケーでの表示に影響のないヘッダーも削除されるし、文字コードその他もゲートウェイで変換されます。
そのゲートウェイの仕様はRFCがどうのとかは全く関係ない独自のものになっています。
インターネットの世界から考えれば、ガラケー本体とガラケーのゲートウェイサーバ、両方合わせて「MUA」として初めて機能する形となっております。現にガラケー本体から直接外のSMTPサーバと通信することなどできないのですから。
ガラケー網の外の世界にデータが投げられるとき、初めてRFCに従う必要が出てくるのです。
Re: (スコア:0)
別に閉域網なら誰も文句は言わなかった。
ただ、インターネットと接続する以上、その理屈は通用しない。
RFCではメッセージフォーマットだけではなく、アドレス形式も定めている。
インターネットと接続するならRFCに準拠したアドレスへの変更を呼び掛けるべきだったのに、ドコモはそれを怠った。
結果、ドコモから送信はできるけれども、ドコモへ送信できないという事態が頻発した。
これはMTAがタコだったわけではなく、RFCに準拠していないメールは配送途中で紛失のおそれがあったため、事前にMTA側でエラーを返すという考えに基づくもの。
完全にドコモの自業自得。
Re: (スコア:0)
はい、嘘松。それ、ドコモが批判を受けた時に言い出した屁理屈ですよね。
RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES [ietf.org]
Re: (スコア:0)
word = atom / quoted-string
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or quoted chars.
qtext = <any CHAR excepting <">, "\" & CR, and including linear-white-space>
ぱっと見3.3にはこう書いてある
””で括ればいいような気がしちゃうんだが違うの?
Re: (スコア:0)
「abc.@example.jp」と「"abc."@example.jp」を同一のアドレスとみなす保証がどこにもないので第三者が勝手に括るのは危険
Re: (スコア:0)
「abc.@example.jp」は不正な形式だから、どう解釈すればいいかは定義されていない、だからどこがlocalpartかも決定できない
それなのに「"abc."@example.jp」と勝手にlocalpartの範囲を「abc.」と決めつけて引用符をつけている
これは、docomoの独自仕様だ!
って理解でいいのかな
Re: (スコア:0)
でもこの理解だと、RFC822では「”abc."@example.jp」の扱い方は定義してあるから、
そういうメールアドレスを作ってはいけないって話にならない気がする
ちゃんと「"abc."@example.jp」って書け!「abc.@〜」はやめろ!ってしか言えなくなっちゃう
Re: (スコア:0)
RFC 822中の独立した章で定義されていたところで、それはあくまでRFC 822中で使うために定義されているのであって、RFC 822に準拠したメッセージの読み書き以外の文脈で従う義理はない。実際、RFC 821はmailboxについてRFC 822を参照せず独自に定義している。
RFC 822冒頭の「1.1 SCOPE」にも
Re: (スコア:0)
つまり元コメの