[6]はやいはなしが、メイル・アドレスの @ の左側です。 * 仕様書 [REFS[ - [34] [CITE@en[[[RFC 5321]] - Simple Mail Transfer Protocol]], [TIME[2021-01-31T08:18:49.000Z]], [TIME[2021-02-22T11:29:17.308Z]] - [35] [CITE@en[[[RFC 5322]] - Internet Message Format]], [TIME[2021-02-14T08:16:00.000Z]], [TIME[2021-02-22T11:30:36.446Z]] - [36] [CITE@en-US-x-hixie[HTML Standard]], [TIME[2021-02-22T09:47:05.000Z]], [TIME[2021-02-22T11:32:40.216Z]] ]REFS] * 特別な local-part [FIG(short list)[ [24] 特別な [CODE[local-part]] - [CODE[postmaster]] - [CODE[info]] - [CODE[marketing]] - [CODE[sales]] - [CODE[support]] - [CODE[abuse]] - [CODE[noc]] - [CODE[security]] - [CODE[postmaster]] - [CODE[hostmaster]] - [CODE[usenet]] - [CODE[news]] - [CODE[webmsater]] - [CODE[www]] - [CODE[uucp]] - [CODE[ftp]] - [CODE[[VAR[*]]-request]] - [CODE[noreply]] ]FIG] [REFS[ - [25] [CITE@en[RFC 2142 - Mailbox Names for Common Services, Roles and Functions]] ([TIME[2017-07-09 18:09:30 +09:00]]) ]REFS] * 句点が混じる 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 は正しく扱えます。 (し、あつかわなければなりません。) ちなみに、 "." が混じっていなくても、 "" で括っても構いません。 「"foo"@hoge.test」は「foo@hoge.test」と同じ意味です。 ここで注意したいのは、 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[]] という値を [[From:]]とか [[To:]]とかに入れたメッセージが [[sendmail]] のような一部 [[MTA]] を通ると、その MTA のドメイン名が補われて [CODE[]] のようになることがあります。普通は問題ないのですが 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]] 版) [11] [CITE@ja[NTTドコモ、メールアドレスのルールを変更 ~ ピリオド連続などが使用不可に:RBB TODAY (ブロードバンド情報サイト) 2009/04/03]] ([TIME[2009-04-03 18:30:55 +09:00]] 版) >4月1日以降、メールアドレスを新規取得または変更する場合、新ルールが適用される。新ルールでは「○○..○○@docomo.ne.jp」(連続するピリオド)、「○○.@docomo.ne.jp」(@マーク直前のピリオド)といった命名方法が使用不可となる。すでに取得済みのアドレスについては、新ルールは適用されない。 [13] [[HTML5]] で定義されている[[電子メール・アドレス]]の構文 ([[妥当な電子メール・アドレス]]) では [[local-part]] での「[CODE(char)[[[.]]]]」の無制限の使用が意図的に認められています。 [49] [CITE@ja[特殊な形式のアドレス(RFC違反アドレス)のご利用について | ドコモメール | サービス・機能 | NTTドコモ]], [TIME[2025-11-05T14:43:31.000Z]] * 部分アドレス [15] [CODE[[[+]]]] が[[利用者]]名と任意の文字列の区切子として使われることがあります。 この慣習は[[部分アドレス]]などと呼ばれています。 * 局所部分で安全な文字 [8] 局所部分で使っても安全な文字の種類について、 [[ietf-822]] で話題になった時のまとめ (, 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)[ ] ]] は [[RFC 2732]] で[[予約]]文字に移動しましたが、安全でないことには変わりありません。 :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)[ [()[]\+*?{}.] ]]: メイルアドレスの一致検査に正規表現をよく使いますが、 特別に解釈され得る文字は無い方がいいです。 [28] [CODE[+]] が入っているとエラーにする壊れた実装があります。 [SEE[ [[au Online Shop]] ]] * 大文字と小文字 [45] [[メールアドレス]]を収集利用するシステムが[[大文字と小文字]]の区別を保存せず勝手に変換している事例があります: [[新生銀行]] * 一部を隠して表示する [47] [[セキュリティー]]を理由に一部を隠して表示されることがあります。 [SEE[ [[一部を隠して表示する]] ]] * メモ [37] [[UUCP Mail]] [9] [CITE[''''''[''''''mew-dist 27636'''''']'''''' Re: "が入ったメールアドレス]] ([[Kazu Yamamoto]] 著, [CODE[2007-04-19 06:54:18 +09:00]] 版) >> DoCoMoでは、このようなアドレスも取れるのですが、携帯の網外からは送れない場合があって、(ものすごく後ろ向きではありますが)これをSPAM対策の裏技的に使っている人を時々見かけます。 > はい。そういう都市伝説に惑わされて ".." を含むメールアドレスを 取り直す DoCoMo ユーザが多いと聞いています。 ([[名無しさん]]) [12] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]] ([TIME[2009-09-09 02:12:56 +09:00]] 版) [14] アンドロイドのメールアプリの中にはインテントでメールアドレスを受け取る時(?)に小文字に変換するものがあります。 [16] [CITE@en[RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2)]] ( ([TIME[2014-09-07 15:46:36 +09:00]] 版)) [17] [CODE[[[emailAddress]]]] は[[大文字・小文字不区別]]としています。 [FIG(quote)[ [FIGCAPTION[ [18] ([TIME[2014-11-01 05:54:38 +09:00]] 版) ]FIGCAPTION] > Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’, > ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), > followed by the Domain Name, which may be formed by pruning zero or more components from the > requested FQDN; ]FIG] [19] [CITE@en[Official Google Blog: A first step toward more global email]] ([TIME[2015-10-15 14:53:29 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [20] [CITE@en[RFC 4282 - The Network Access Identifier]] ([TIME[2015-10-16 10:47:33 +09:00]] 版) ]FIGCAPTION] > The grammar for the username is based on '''['''RFC0821''']''' ]FIG] [FIG(quote)[ [FIGCAPTION[ [21] [CITE@en[RFC 7542 - The Network Access Identifier]] ([TIME[2015-10-18 15:17:56 +09:00]] 版) ]FIGCAPTION] > Internationalization of the username portion of > the NAI is based on the "Internationalized Email Headers" '''['''RFC6532''']''' > extensions to the "local-part" portion of email addresses '''['''RFC5322''']'''. ]FIG] [22] [CITE@en[RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format]] ([TIME[2015-12-08 07:08:54 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [23] [CITE[au、Eメールアドレスの設定文字数を最大30文字に拡張]] (2006/06/01 11:57 [TIME[2017-06-01 12:35:55 +09:00]]) ]FIGCAPTION] > これまでEZwebのEメールアドレスに設定できる文字数(@ezweb.ne.jpより前のユーザー名)は20文字までとなっていたが、6月6日以降は30文字まで設定可能となる。これに合わせて、「_」(アンダースコア/アンダーバー)の利用や、「.」(ピリオド/ドット)の連続使用、@直前での利用も可能となる。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [26] [CITE@ja[RFC違反のキャリアメールアドレスという負の遺産、iOS 14で再び顕在化 | スラド モバイル]] ([TIME[2020-11-06T12:08:30.000Z]]) ]FIGCAPTION] > プロファイルを更新することで、アットマークの左側がクオートで囲まれ、RFC 5321 / RFC 5322 準拠の quoted-string 形式に変わるようだ。 > ]FIG] [27] [CITE@ja[インターネットラジオステーション<音泉>]] ([TIME[2020-11-07T02:19:41.000Z]]) [FIG(quote)[ [FIGCAPTION[ [29] [CITE@ja[お知らせ:ニュースサイト・アプリ・紙面ビューアーにログインできないお客様へ | [[毎日新聞]]]], 2021/2/19 [TIME[2021-02-22T11:15:05.000Z]] ]FIGCAPTION] > 新システムでは、「RFC」と呼ばれるインターネットメールの世界標準規格に合致していないアドレスでご利用のお客様は、ログインができなくなりました。 > お手数をおかけして申し訳ございませんが、改めて新規ご登録のお手続きをお願いいたします。 > なお、登録可能なメールアドレスの文字列は以下になります。 > ・全て半角英数字でご登録ください。 > ・使用できる記号は半角の「.」ドット、「-」ハイフン、「_」アンダースコアの3種類のみとなります。 > ・最初と最後(@の直前)に記号を使用しないでください。 > ・記号を2文字以上連続で使用しないでください。 ]FIG] [30] この構文を定めてる「「RFC」と呼ばれるインターネットメールの世界標準規格」はいったいどこにあるのだろうか。 どこのインターネットのどの RFC かくらい書こうよ。。。 [31] [[フェイクニュース]]のようにみえるが[[毎日新聞社]]独自の[[インターネット]](謎)の可能性が[[微レ存]]だからなw [FIG(quote)[ [FIGCAPTION[ [32] [CITE@ja[使用可能なメールアドレスについて(RFC準拠) - 会員について | ジーンズ、デニム通販のEDWIN(エドウイン)公式オンラインモール]] ([[EDWIN公式オンラインショップ]], [TIME[2021-02-22T11:18:07.000Z]]) ]FIGCAPTION] > 以下の条件に当てはまるメールアドレスの場合、世界共通となるインターネット通信規格RFC(Request for Comments)に準拠していない、または、当サイト内で利用不可能な文字もございますため、会員登録の情報やお問い合わせいただく際のメールアドレスとしてご利用いただけません。 > 1. 半角英数字と「-」「_」「.」「+」「?」「/」以外の記号が含まれている場合 > 2. 「.」を連続使用している場合 > 3. 「.」を最初と最後(@の直前)に使っている場合 > 4. @の前(左)部分で64文字以上になっている場合 > 5. メールアドレス全体で256文字以上になっている場合 ]FIG] [FIG(quote)[ [FIGCAPTION[ [33] [CITE@ja[メールアドレスの登録ができない お客様へ | シャルマンワイン・オンラインショップ]] ([TIME[2021-02-22T11:23:39.000Z]]) ]FIGCAPTION] > RFC違反メールアドレスとは、RFCで定められている仕様・要件に準拠しない アドレスのことを指します。 > 具体的には、 > ・アットマーク(@)の直前やメールアドレスの先頭にピリオド (.) がある > ・アットマーク(@)より前で、ピリオド (.) が連続している > ・半角英数字と一部の記号以外の文字列を含んでいる > 一部の記号:(. ! # $ % & ‘ * + – / = ? ^ _ ` { | } ~) ]FIG] [38] [CODE[tag:]] [[URL]] に似た構文がありますが、そちらはかなり厳しい制限が加わっています。 - [40] [CITE@ja[リクルートID登録しようとすると「このメールアドレスではリクルートIDからのメールを受信できません」とエラー表示される]], [TIME[2020-11-30T11:12:29.000Z]], [TIME[2021-11-30T11:15:23.468Z]] -[39] [CITE@ja[リクルートIDがinfo@など特定のユーザ名に制限。利用者には変更を要請 | スラド セキュリティ]], [TIME[2021-11-30T11:15:02.000Z]] [FIG(quote)[ [FIGCAPTION[ [41] [CITE@ja[「入力いただいたメールアドレスは利用できません」と表示される | ニコニコヘルプ]] ([TIME[2022-02-15T08:24:27.000Z]]) ]FIGCAPTION] > '''['''ニコニコに登録できるメールアドレス''']''' > 128文字以内 > 利用できる文字列は「英数字」「-(ハイフン)」「_(アンダーバー)」「.(ドット)」 ]FIG] [42] [CITE@ja[Gmail アドレスでのピリオドの扱い - Gmail ヘルプ]] ([TIME[2022-02-15T08:30:54.000Z]]) [FIG(quote)[ [FIGCAPTION[ [43] [CITE@ja[【重要】システム切替によるご登録メールアドレスの無効化について| CLUB Panasonic | パナソニックの会員サイト]] ([TIME[2022-07-20T11:14:55.000Z]]) ]FIGCAPTION] > ■ご登録メールアドレスが無効化されるケース > (1)メールアドレスのローカル部の書式が不正な場合 > 例:「@」より前に「.」が連続、もしくは先頭や末尾に「.」を含むなど > (2)メールアドレスのドメイン部の書式が不正な場合 > 例:「@」より後に「.」が連続、もしくは先頭や末尾に「.」を含むなど > (3)その他、メールアドレスの書式が不正な場合 > 例:メールアドレスに「+」を含むなど > ※本システム切替は、メールアドレスの国際基準に準拠するために実施するものであり、お客様の会員情報の削除ではありません。 ]FIG] [44] [CITE@ja[CLUB Panasonic、「+」を含むメールアドレスを不正な書式として無効化 | スラド IT]] ([TIME[2022-07-20T11:15:05.000Z]]) [46] [CITE@en[Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature / Mediumの独自ドメインプランを使って訪問者のメールアドレスが窃取できる脆弱性の開示 · GitHub]], [TIME[2023-08-28T07:14:55.000Z]] >[SNIP[]]Also, the domain part and the first two characters of the email address are not masked, so the full email address may be inferred or the mask may not work. eg: me@example.com [48] [CITE@ja[Xユーザーのナンジャモリスナーさん: 「@KFC_jp ケンタッキーのアプリにログインできなくなりました。+記号の入ったメールアドレスだと弾かれる仕様に変わったみたいです。メールアドレスを変更したいのですが、どうすればいいですか?」 / X]], [TIME[午前9:30 · 2024年7月28日][2024-07-28T00:30:58.000Z]], [TIME[2024-07-28T12:22:22.000Z]]