/
995.txt
171 lines (138 loc) · 11.7 KB
/
995.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
[6]はやいはなしが、メイル・アドレスの @ の左側です。
[[#comment]]
* 句点が混じる local-part
[7] RFC 822/2822 では、
句点 (".") は、 local-part の最初と最後に、そのままでは書けません。
ですから、「foobar.@foo.example」は誤りです。 iモードの
携帯電話のメイル・アドレスには、このようなのが使われている
ようですが、誤りです。 RFC 822/2822 に厳密に従う UA では
取り扱えません。
こういうときは正しくは、 [[quoted-string]] を使います。
ですから、正しくは「"foobar."@foo.example」になります。
これなら、 RFC 822/2822 に従う UA は正しく扱えます。
(し、あつかわなければなりません。)
ちなみに、 "." が混じっていなくても、 "" で括っても構いません。
「"w"@suika.fam.cx」は「w@suika.fam.cx」と同じ意味です。
ここで注意したいのは、 RFC 822/2822 の表現では引用符が
要るというだけであって、意味論的には引用符はアドレスの一部
ではありません。先ほどの例でいえば、 foo.example というところの
「foobar.」 という宛先、という意味であって、 「"foobar."」
という宛先ではありません。 RFC 822/2822 以外の世界においては、
foobar.@foo.example という表現が正しい''かも''しれません。
(ただし、 Internet の世界でそういうところはほとんどありません。)
RFC 822/2822 の local-part 中で "." は特別な
意味を持った文字として扱われています。 (ですから、ふつーにそのまま
かけなくて、 quote する必要があるのです。)
歴史的にはどうやら、 "." は経路情報みたいなものの区切りに使われていた
ようです。 RFC 822 の @bar.example,@foo.example: というような
route とか、 foo%bar.example@foo.example みたいにする %-hack
とか、そういうのの親戚みたいなものですか?
今でこそ、 @ の左側は ''local''-part で、右側は世界的な domain
という意識がありますが、昔は @ にはそれほど強い意味は無かった
ってことでしょう。 (だって、 foo at bar at hoge みたいに
書いてたんでしょ、そもそも。)
おっと、脱線しすぎなんでこのくらいにして。
にしても、 "foo.bar".foo@foo.example と
"foo.bar.foo"@foo.example と foo.bar.foo@foo.example
って結局のところ、等価なんですかね? 厳密には同一視しては
いけないんだろうけど、過去から現代にわたってずっと、
区別しないといけないことってあったんだろうか?
と疑問に思ってます。 (ちなみに RFC 2822 では最初の例は旧式構文。)
もはや "." にかつてのように特別な意味は無いんだけど、
歴史的理由によって扱いがちょっとやばいという、普通に戻れない
普通の文字、ってことでしょか(謎)。
- [1] [CODE[<foo>]] という値を [[From:]]とか [[To:]]とかに入れたメッセージが [[sendmail]] のような一部 [[MTA]] を通ると、その MTA のドメイン名が補われて [CODE[<foo@foo.example>]] のようになることがあります。普通は問題ないのですが spam などがドメイン名なしで送られてきた時に、中継 MTA がこのような動作をすると勘違いの元で危険です。注意が必要です。
- [2] NTT DoCoMo のメイル・アドレス ([VAR[*]]@docomo.ne.jp) で句点が含まれている場合によく送信できないと問題になりますが、 [[quoted-string]] を使えば問題なく送信できます。
- [3] >>2 数年以上前の [[sendmail]] なら [CODE[quoted-string]] があるとうまく送れないかもしれない (未確認。) ですが、いまどきそんなの使ってるところなんてないでしょう。 (あったら spam の温床じゃないかな。)
- [4] 局地部分。
- [5] >>4 局所部分
[10]
[CITE@ja[hxxk.jp - メールアドレスに使用できる文字列および、メールアドレスの判定の正規表現関連のまとめ]] ([[望月真琴]] 著, [TIME[2008-04-14 13:49:38 +09:00]] 版) <http://hxxk.jp/2007/11/20/2309#replies-730>
[11]
[CITE@ja[NTTドコモ、メールアドレスのルールを変更 ~ ピリオド連続などが使用不可に:RBB TODAY (ブロードバンド情報サイト) 2009/04/03]] ([TIME[2009-04-03 18:30:55 +09:00]] 版) <http://www.rbbtoday.com/news/20090403/59059.html>
>4月1日以降、メールアドレスを新規取得または変更する場合、新ルールが適用される。新ルールでは「○○..○○@docomo.ne.jp」(連続するピリオド)、「○○.@docomo.ne.jp」(@マーク直前のピリオド)といった命名方法が使用不可となる。すでに取得済みのアドレスについては、新ルールは適用されない。
[13] [[HTML5]] で定義されている[[電子メール・アドレス]]の構文 ([[妥当な電子メール・アドレス]])
では [[local-part]] での「[CODE(char)[[[.]]]]」の無制限の使用が意図的に認められています。
* 部分アドレス
[15] [CODE[[[+]]]] が[[利用者]]名と任意の文字列の区切子として使われることがあります。
この慣習は[[部分アドレス]]などと呼ばれています。
* 局所部分で安全な文字
[8] 局所部分で使っても安全な文字の種類について、
[[ietf-822]] で話題になった時のまとめ
(<mid:2147483647.1030011437@dsl108-043.brandx.net>,
2002年8月)
をもとにまとめてみました:
:安全な文字 [CODE(regex)[ [A-Za-z0-9] ]]:
すべてのシステムで安全 (なはず) です。
大文字・小文字の区別は (特別な局部部分 [CODE[[[postmaster]]]] : [[RFC822]] を除き) ありませんが、
多くのシステムでは同一視が行われます。
:条件付安全文字 [CODE(regex)[ [_.=+/-] ]]:
システムによっては最初や最後の文字に使えません。
また、部分名の区切りに使われることがあります。
[CODE[_]] は、最初の文字として使えないシステムがあります。
姓名の区切りによく使われます。
[CODE[.]] は、最初や最後の文字として使うときは [[quote]]
しないといけません。歴史的に特別な意味を持っていましたが、
今では勘違いされる虞も無いでしょう。
CMU Cyrus サーバーはメイル箱階層区切子として使います。
[CODE[-]] は [[qmail]] が部分番地区切子に使います。
システムが特別扱いしていないとしても、意味的に階層区切子と使われることが非常に多いです [WEAK[(特に ML とかで : [[RFC2142]])]]。
一般の単語区切子に使われることも多いです。
[CODE[=]] も階層区切子に使われることがあります。
[CODE[+]] も iPlanet Messaging Server,
SIMS, PMDF, CMU Cyrus で階層区切子に使われます。
[CODE[/]] は [[X.400]] 関門などで特別な意味を持ちます : [[RFC2846]]。
:シェルやファイルシステムのメタ文字など [CODE(regex)[ [$&*?!~^()[]{}"'`\|#/<>] ]], コロン, 間隔, 制御文字, 0x80 以上:メイルはしばしばファイルシステムに局所部分の名前のファイルやディレクトリに蓄積されますし、メイルアドレスがシェルのプロンプトで入力されることもよくあります。
これらの文字を局所部分に使うと、これらの場面で不都合なことがあります。: URI 予約文字 [CODE(regex)[ [;/?:@&=+$,] ]] :
メイル・アドレスが [[URI参照]]の一部に使われることはよくありますが、予約文字
([[RFC2396]]) は特別な意味に解釈され得ますし、
そうでなくても [[URI符号化]]形とそうでない形の区別が意味を持ってしまいますから、
迂闊に使うと手抜き実装で痛い目に合います。 ([CODE(URI)[[[mailto]]:]] scheme などの場合の他に、 [[Webメイル]]が [CODE(URI)[[[http]]:]] scheme などで使われることもあります。)
:URI 非安全文字 [CODE(regex)[ [{}|\^[]`<>#%"] ]], 間隔, 制御文字, 0x80〜:
URI で使うときには必ず符号化しないといけませんが、手抜き実装で痛い目に(以下略)。
なお、 [CODE(URI)[ [ ]] と [CODE(URI)[ ] ]] は [[RFC2774]]
で[[予約]]文字に移動しましたが、安全でないことには変わりありません。
:822 特殊文字 [CODE(regex)[ [()<>[]@,;"\] ]], コロン, 間隔, 制御文字:
局所部分で使うときは、必ず quote しないといけませんが、
quote に対応していないシステムも多いので困ります。
(RFC 821, 822, 2821, 2822)
:0x80〜:
電子メイルでは 0x7E 以下しか扱えません。
(RFC 821, 822, 2821, 2822)
:NULL 0x00:
[[C]] をはじめ多くのシステムでは 0x00 を扱えません。
RFC 2822 も禁止しています (RFC 822 は認めていました)。
:経路指定 [CODE(regex)[ [!%@.] ]]:
伝統的に経路指定に使われてきました。
システムによっては今でもその意味で使われます。
:[[IMAP]] 修正 [[UTF-7]] [CODE(char)[&]]:
IMAP 修正 UTF-7 で [CODE(char)[&]] は特別な意味を持ちますから、
いい加減な IMAP の実装で(以下略)。
:[CODE(ABNF)[[[encoded-word]]]] [SAMP(MIME)[=?[VAR[〜]]]]:
いい加減な実装は所構わず [CODE(ABNF)[encoded-word]] を解読しようとするかもしれませんので(以下略)。
:[[LDAP]] 検索濾過特殊文字 [CODE(regex)[ [*()\] ]], NULL:
iPlanet Messaging Server などは LDAP ([[RFC2254]]) を内部的にも使ってますが、
その時の特殊文字をちゃんと処理していないシステムもあったりします。
:[[ECMAScript]] 特殊文字 [CODE(regex)[ ['"\] ]]:
[[JavaScript]] でメイルアドレスの構文をチェックしたりするのはよく行われますが、いい加減な(以下略)。
:[[Perl]] 特殊文字 [CODE(regex)[ [$@\"'`[]{}/], [CODE[->]] ]]:
Perl で [[CGIスクリプト]]を実装して、その中でメイルアドレスを扱ったりよくしますが、いい加減(ry。
あるいは文字列として書くときにも特別に解釈され得る文字は無いほうがいいですし。
:[[正規表現]]特殊文字 [CODE(regex)[ [()[]\+*?{}.] ]]:
メイルアドレスの一致検査に正規表現をよく使いますが、
特別に解釈され得る文字は無い方がいいです。
[[#comment]]
* メモ
[9]
[CITE[''''''[''''''mew-dist 27636'''''']'''''' Re: "が入ったメールアドレス]] ([[Kazu Yamamoto]] 著, [CODE[2007-04-19 06:54:18 +09:00]] 版) <http://permalink.gmane.org/gmane.mail.mew.general.japanese/5990>
>> DoCoMoでは、このようなアドレスも取れるのですが、携帯の網外からは送れない場合があって、(ものすごく後ろ向きではありますが)これをSPAM対策の裏技的に使っている人を時々見かけます。
> はい。そういう都市伝説に惑わされて ".." を含むメールアドレスを
取り直す DoCoMo ユーザが多いと聞いています。
([[名無しさん]])
[12] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]]
([TIME[2009-09-09 02:12:56 +09:00]] 版)
<http://tools.ietf.org/html/rfc5321#section-4.5.3.1.1>
[14] アンドロイドのメールアプリの中にはインテントでメールアドレスを受け取る時(?)に小文字に変換するものがあります。
[16] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]]
( ([TIME[2014-09-07 15:46:36 +09:00]] 版))
<http://tools.ietf.org/html/rfc3801#section-4.1.1>