メールアドレスで使用できる文字は何ですか？

メールの完全な検証については質問していません。

メールアドレスの文字とuser-nameそのserver一部に使用できる文字を知りたいだけです。これは単純化しすぎているかもしれませんし、メールアドレスが他の形を取ることもあるかもしれませんが、私は気にしません。この単純な形式user-name@server（例：wild.wezyr@best-server-ever.com）と、両方の部分で許可されている文字についてのみ質問しています。

参照してください。RFC 5322：インターネットメッセージ形式をより少ない程度に、そして、RFC 5321：簡易メール転送プロトコル。

RFC 822も電子メールアドレスをカバーしていますが、主にその構造を扱っています。

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

そしていつものように、ウィキペディアにはメールアドレスに関するまともな記事があります：

電子メールアドレスのローカル部分には、次のASCII文字を使用できます。

• 大文字と小文字のラテン文字Ato Zとato z;
• 数字0を9;
• 特殊文字!#$%&'*+-/=?^_`{|}~;
• .引用符で囲まれていない限り、最初または最後の文字ではないこと、および引用符で囲まれていない限り、連続して出現しないことを条件に、ドットを使用します（たとえばJohn..Doe@example.com、許可されていませんが許可されてい"John..Doe"@example.comます）。
• スペースと"(),:;<>@[\]文字は制限付きで許可されます（以下の段落で説明するように、引用符付きの文字列内でのみ許可されます。さらに、バックスラッシュまたは二重引用符の前にはバックスラッシュを付ける必要があります）。
• コメントは、local-partの両端に括弧を付けて許可されます。たとえばjohn.smith(comment)@example.comと(comment)john.smith@example.comはどちらもと同等john.smith@example.comです。

2012年の時点で、ASCII文字に加えて、RFC 6532仕様で説明され、Wikipediaで説明されているように、UTF-8としてエンコードされた上記の 国際文字を使用できます。2019年の時点では、これらの標準はまだProposedとマークされていますが、徐々に展開されています。この仕様の変更により、およびなどの許可および制限された特殊文字のルールに影響を与えることなく、基本的に国際文字が有効な英数字（atext）として追加されました。U+007F!#@:

検証については、正規表現を使用してメールアドレスを検証するをご覧ください。

domain一部が定義され、以下のように：

インターネット標準コンポーネントのホスト名のラベルが唯一のASCII文字を含むことがプロトコルの任務のために（要求のコメント）aを通じてz（大文字と小文字を区別しないようにし）、数字0を通して9、およびハイフン（-）。RFC 952のホスト名の元々の仕様では、ラベルは数字またはハイフンで始めることはできず、ハイフンで終わることはできません。ただし、その後の仕様（RFC 1123）では、ホスト名ラベルを数字で始めることが許可されていました。他の記号、句読文字、空白スペースは許可されていません。

気を付けて！このスレッドにはたくさんの知識が腐っています（以前は真実でしたが、今はそうではありません）。

現在および将来の世界で、そして世界中のどこからでも、実際の電子メールアドレスの誤検出拒否を回避するには、少なくともRFC 3490の「アプリケーションのドメイン名の国際化（IDNA）」の高レベルの概念を知っている必要があります。私は米国とAの人々がしばしばこれに気づいていないことを知っていますが、それはすでに世界中で広く普及しており、急速に増加しています（主に英語以外の支配的な部分）。

要点は、mason @日本.comやwildwezyr@fahrvergnügen.netのようなアドレスを使用できるようになったことです。いいえ、これはまだそこにあるすべてのものと互換性がありません（多くの人が上記で嘆いてきたように、単純なqmailスタイルの+ identアドレスでさえ、しばしば誤って拒否されます）。しかし、RFCがあり、仕様があり、IETFとICANNによってサポートされています。さらに重要なこととして、この改善をサポートする実装が多数あり、現在使用されています。

日本に戻り、hei @やる.caのような電子メールアドレスと次のようなAmazon URLを目にするようになるまで、私はこの開発についてあまり知りませんでした。

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ b / ref = topnav_storetab_e？ie = UTF8＆node = 3210981

仕様へのリンクが不要であることは承知していますが、インターネットフォーラムでのハッカーの古い知識にのみ依存している場合、メールバリデーターは、英語を話さないユーザーがますます期待するメールアドレスを拒否することになります。それらのユーザーにとって、そのような検証は、私たち全員が嫌う一般的な脳死のフォーム、+や3部のドメイン名などを処理できないものと同じように迷惑になります。

だから、それが面倒ではないと言っているわけではありませんが、「一部/すべて/なしの条件で許可されている」文字の完全なリストは、（ほぼ）すべての言語のすべての文字です。「すべての有効な電子メールアドレスを受け入れる（および多くの無効な電子メールアドレスも受け入れる）」場合は、IDNを考慮する必要があります。これにより、最初に国際化された電子メールアドレスをPunycodeに変換しない限り、文字ベースのアプローチは役に立たなくなります（申し訳ありません）。

その後、上記のアドバイス（のほとんど）に従うことができます。

電子メールアドレスの形式は次のとおりですlocal-part@domain-part（最大64 @ 255文字、合計で256文字以下）。

local-partそしてdomain-partそれに複数のルールがあるとして許可された文字の異なるセットを持つことができ、それは、すべてではありません。

一般に、ローカル部分には次のASCII文字を含めることができます。

• 小文字のラテン文字：abcdefghijklmnopqrstuvwxyz、
• 大文字のラテン文字：ABCDEFGHIJKLMNOPQRSTUVWXYZ、
• 数字：0123456789、
• 特殊文字：!#$%&'*+-/=?^_`{|}~、
• ドット：（.最初または最後の文字ではなく、引用符で囲まれていない限り繰り返されます）、
• 次のようなスペース句読点：（"(),:;<>@[\]いくつかの制限あり）、
• コメント：（()かっこ内で使用できます(comment)john.smith@example.com。例）

ドメイン部分：

• 小文字のラテン文字：abcdefghijklmnopqrstuvwxyz、
• 大文字のラテン文字：ABCDEFGHIJKLMNOPQRSTUVWXYZ、
• 数字：0123456789、
• ハイフン：（-最初または最後の文字ではない）、
• 角かっこで囲まれたIPアドレスを含めることができます：jsmith@[192.168.2.1]またはjsmith@[IPv6:2001:db8::1]。

次の電子メールアドレスは有効です：

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com （1文字のローカル部分）
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• example-indeed@strange-example.com
• admin@mailserver1 （トップレベルドメインのないローカルドメイン名）
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org （引用符の間のスペース）
• example@localhost （localhostから送信）
• example@s.solutions（インターネットのトップレベルドメインのリストを参照）
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

そして、無効なこれらの例：

• Abc.example.com（@キャラクターなし）
• A@b@c@example.com（@引用符の外では1つだけ許可されます）
• a"b(c)d,e:f;gi[j\k]l@example.com （このローカル部分の特殊文字は、引用符の外では使用できません）
• just"not"right@example.com （引用文字列は、ドットで区切られているか、ローカル部分を構成する唯一の要素である必要があります）
• this is"not\allowed@example.com （スペース、引用符、バックスラッシュは、引用符で囲まれた文字列内で、バックスラッシュが前にある場合にのみ存在できます）
• this\ still\"not\allowed@example.com （エスケープされていても（バックスラッシュが前にある）、スペース、引用符、バックスラッシュは引用符で囲む必要があります）
• john..doe@example.com（前に二重ドット@）; （注意：Gmailではこれが可能です）
• john.doe@example..com（の後の二重ドット@）
• 先頭にスペースがある有効なアドレス
• 末尾にスペースがある有効なアドレス

出典：ウィキペディアのメールアドレス

メールを検証するためのPerlのRFC2822正規表現：

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

RFC2822アドレスの完全な正規表現は、わずか3.7kでした。

参照：PHPでのRFC 822電子メールアドレスパーサー。

電子メールアドレスの正式な定義は次のとおりです。

• RFC 5322（セクション3.2.3および3.4​​.1、廃止されたRFC 2822）、RFC 5321、RFC 3696、
• RFC 6531（許可されている文字）。

関連：

• 正規表現の真の力

ウィキペディアにはこれに関する良い記事があり、公式の仕様はここにあります。ウィキディアから：

電子メールアドレスのローカル部分では、次のASCII文字を使用できます。

• 大文字と小文字の英字（az、AZ）
• 数字0から9
• キャラクター！＃$％＆ '* +-/ =？^ _ `{| }〜
• キャラクター 。（ドット、ピリオド、フルストップ）最初または最後の文字ではなく、連続して2回以上出現しないことも条件です。

さらに、引用符で囲まれた文字列（例： "John Doe" @ example.com）が許可されているため、通常は禁止されている文字も許可されますが、一般的には表示されません。RFC 5321はまた、「メールを受信することを期待するホストは、ローカル部分が引用文字列形式を必要とする（または使用する）メールボックスを定義することを避けるべきである」とも警告しています。

グーグルは彼らのgmail.comアドレスで面白いことをします。gmail.comアドレスでは、文字（az）、数字、およびピリオド（無視されます）のみを許可します。

たとえば、pikachu @ gmail.comはpi.kachu@gmail.comと同じで、両方のメールアドレスが同じメールボックスに送信されます。PIKACHU@gmail.comも同じメールボックスに配信されます。

そのため、質問に答えるために、RFC標準のどれだけを追跡したいかは、実装者に依存する場合があります。Googleのgmail.comアドレススタイルは標準と互換性があります。彼らは、別の人が同じようなメールアドレスをとるような混乱を避けるために、そのようにしています。

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

ウィキペディアのリンクは、電子メールアドレスで一般的に許可されているものについての優れたリファレンスです。 http://en.wikipedia.org/wiki/Email_address

あなたはウィキペディアの記事から始めることができます：

• 大文字と小文字の英字（az、AZ）
• 数字0から9
• キャラクター！＃$％＆ '* +-/ =？^ _ `{| }〜
• キャラクター 。（ドット、ピリオド、フルストップ）最初または最後の文字ではなく、連続して2回以上出現しないことも条件です。

名前：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

サーバ：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

@とを確認します。確認するメールを送信します。

誰かがメールの検証を失敗したか、新しいアドレスが有効であると見なされるため、インターネット上のサイトの20％で.nameメールアドレスをまだ使用できません。

短い答えは、2つの答えがあるということです。何をすべきかについて、1つの基準があります。つまり、賢明で、トラブルからあなたを守る行動。問題なく受け入れる必要のある動作には、別の（より広い）標準があります。この二元性は、電子メールの送受信に有効ですが、幅広い用途があります。

あなたが作成するアドレスへの良いガイドのために; 参照：http : //www.remote.org/jochen/mail/info/chars.html

有効なメールをフィルタリングするには、次のステップを確認するのに十分理解できるものを渡してください。または、RFCの束を読み始めてください、注意してください。

問題についての良い読み。

抜粋：

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

受け入れられた回答は、メールアドレスの有効なローカル部分について議論するときのWikipediaの記事を参照していますが、Wikipediaはこれについての権威ではありません。

IETF RFC 3696 はこの問題に関する権限であり、セクション3で相談する必要があります。5ページの電子メールアドレスの制限：

現在のメールアドレスは、「ドメイン部分」（完全修飾ドメイン名）からアットマーク（「@」）で区切られた「ローカル部分」で構成されています。ドメイン部分の構文は、前のセクションの構文に対応しています。そのセクションで識別されたフィルタリングと名前のリストに関する懸念は、電子メールのコンテキストで使用されるドメイン名にも適用されます。ドメイン名は角かっこで囲まれたIPアドレスに置き換えることもできますが、テストやトラブルシューティングの目的を除いて、この形式はお勧めしません。

ローカル部分は、以下で説明する引用規則を使用して表示される場合があります。引用されたフォームは実際にはめったに使用されませんが、いくつかの正当な目的のために必要です。したがって、それらはフィルタリングルーチンで拒否されるべきではなく、代わりに宛先ホストによる評価のために電子メールシステムに渡される必要があります。

正確な規則は、制御文字を含むすべてのASCII文字が引用符で囲まれて表示されるか、引用符で囲まれた文字列で表示される可能性があることです。引用が必要な場合は、円記号を使用して次の文字を引用します。例えば

  Abc\@def@example.com

メールアドレスの有効な形式です。次のように、空白も表示される場合があります

  Fred\ Bloggs@example.com

バックスラッシュ文字は、それ自体を引用するために使用することもできます。例えば、

  Joe.\\Blow@example.com

バックスラッシュ文字を使用した引用に加えて、従来の二重引用文字を使用して文字列を囲むことができます。例えば

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

上記の最初の2つの例の代替形式です。これらの引用されたフォームはめったに推奨されておらず、実際には一般的ではありませんが、前述のように、電子メールアドレスを処理するアプリケーションによってサポートされる必要があります。特に、引用されたフォームは、他のシステムおよびコンテキストからの遷移に関連付けられたアドレスのコンテキストで表示されることがよくあります。これらの移行要件は依然として発生します。ユーザーが指定したメールアドレスを受け入れるシステムは、そのアドレスがレガシーシステムに関連付けられているかどうかを「知る」ことができないため、アドレスフォームを受け入れてメール環境に渡す必要があります。

引用符がない場合、ローカル部分は
アルファベット文字、数字、または特殊文字の任意の組み合わせで構成されます

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

ピリオド（ "。"）も表示されますが、ローカルパーツの開始または終了に使用することはできません。また、2つ以上の連続するピリオドを表示することもできません。言い換えると、アットマーク（ "@"）、バックスラッシュ、二重引用符、カンマ、または角括弧以外のASCIIグラフィック（印刷）文字は、引用符なしで表示される場合があります。除外された文字のリストのいずれかが表示される場合は、引用符で囲む必要があります。などのフォーム

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

は有効であり、かなり定期的に表示されますが、上記の文字はすべて許可されます。

他の人と同じように、PHPとJavaScriptの両方で機能する正規表現を送信してメールアドレスを検証します。

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

見られるように、このウィキペディアのリンク

電子メールアドレスのローカル部分には、次のASCII文字を使用できます。

• 大文字と小文字のラテン文字Ato Zとato z;

• 数字0を9;

• 特殊文字!#$%&'*+-/=?^_`{|}~;

• .引用符で囲まれていない限り、最初または最後の文字ではないこと、および引用符で囲まれていない限り、連続して出現しないことを条件に、ドットを使用します（たとえばJohn..Doe@example.com、許可されていませんが許可されてい"John..Doe"@example.comます）。

• スペースと"(),:;<>@[\]文字は制限付きで許可されます（以下の段落で説明するように、引用符付きの文字列内でのみ許可されます。さらに、バックスラッシュまたは二重引用符の前にはバックスラッシュを付ける必要があります）。

• コメントは、local-partの両端に括弧を付けて許可されます。たとえばjohn.smith(comment)@example.comと(comment)john.smith@example.comはどちらもと同等john.smith@example.comです。

上記のASCII文字に加えて、UTF-8としてエンコードされたU + 007Fより上の国際文字はRFC 6531で許可されていますが、メールシステムはローカルパーツを割り当てるときに使用する文字を制限する場合があります。

引用符で囲まれた文字列は、ローカルパーツ内にドットで区切られたエンティティとして存在する場合と、最も外側の引用符がローカルパーツの最も外側の文字である場合に存在する場合があります（abc."defghi".xyz@example.comまたは、または"abcdefghixyz"@example.com許可されています。逆に、そうでabc"defghi"xyz@example.comはありません。どちらもないabc\"def\"ghi@example.com）。ただし、引用符付きの文字列と文字は一般的に使用されません。RFC 5321はまた、「メールを受信することを期待するホストは、ローカル部分が引用文字列形式を必要とする（または使用する）メールボックスを定義することを避けるべきである」とも警告しています。

ローカル部分postmasterは特別に扱われます。大文字と小文字は区別されないため、ドメインのメール管理者に転送する必要があります。技術的には他のすべてのローカル部分は大文字と小文字が区別されるためjsmith@example.com、JSmith@example.com異なるメールボックスを 指定します。ただし、多くの組織では大文字と小文字を同等に扱います。

技術的に有効な幅広い特殊文字にもかかわらず、組織、メールサービス、メールサーバー、およびメールクライアントは、実際にはそれらすべてを受け入れるわけではありません。たとえば、Windows Live Hotmailでは、英数字、ドット（.）、下線（_）、ハイフン（-）を使用した電子メールアドレスの作成のみが許可されます。一般的なアドバイスは、メールが拒否されるリスクを回避するために、いくつかの特殊文字を使用しないことです。

答えは（ほぼ）ALL（7ビットASCII）です。
包含ルールが「...一部/すべて/なしの条件で許可...」の場合

17ページの上部にあるRFC 5322の「ドメインテキスト」部分で許可されるテキストのいくつかの可能な包含ルールの1つを見るだけで、次のことがわかります。

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

この説明で欠落している3つの文字のみがdomain-literal []で使用され、引用符付きペア\と空白文字（％d32）を形成しています。これにより、範囲32-126（10進数）が使用されます。同様の要件が「qtext」および「ctext」として表示されます。多くの制御文字も許可/使用されます。そのような制御文字の1つのリストは、31ページのRFC 5322のセクション4.1に obs-NO-WS-CTLとして表示されます。

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

セクション3.5の冒頭で述べたように、この制御文字はすべて許可されています。

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

したがって、そのような包含ルールは「広すぎる」のです。または、別の意味では、期待されるルールは「単純すぎる」です。

簡単にするために、検証前に二重引用符内のすべてのテキストとそれに関連する二重引用符を削除し、許可されていないものに基づいて電子メールアドレスの送信にキボッシュを配置することで、送信をサニタイズします。誰かがJohn .. "The * $ hizzle * Bizzle" .. Doe@whatever.comアドレスを持つことができるからといって、システムで許可する必要があるわけではありません。私たちは将来、無料のメールアドレスを取得するのに時間がかかるかもしれません。そして、何が許可されて何が許可されていないかを示す入力のすぐ隣に電子メールの基準が組み込まれていないわけではありません。

また、引用された資料が削除された後、さまざまなRFCで特に許可されていないものをサニタイズします。特に許可されていない文字とパターンのリストは、テストするのにはるかに短いリストのようです。

禁止：

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

与えられた例では：

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

メールアドレスを追加または変更しようとしたときに残りの結果に確認メールメッセージを送信すると、送信されたメールアドレスをコードで処理できるかどうかを確認できます。電子メールが必要なだけのサニタイズのラウンド後に検証に合格した場合、その確認を開始します。確認リンクからリクエストが返された場合、新しいメールを保留||一時||整理ステータスまたはストレージから移動して、実際の真に一流の保存メールにすることができます。

配慮が必要な場合は、メールアドレス変更の失敗または成功の通知を古いメールアドレスに送信できます。未確認のアカウント設定は、妥当な時間の後に完全に失敗した試みとしてシステムから外れる可能性があります。

私のシステムでは、悪臭メールを許可していません。多分それはお金を捨てているだけです。しかし、99.9％の人は、正しいことを行って、エッジケースの互換性シナリオを利用して、適合性の制限を瀬戸際に追いやらないメールを持っています。正規表現のDDoSに注意してください。これはトラブルが発生する可能性がある場所です。そして、これは私が行う3番目のことと関連しており、1つのメールを処理する時間に制限を設けています。検証するためにマシンの速度を落とす必要がある場合は、着信データAPIエンドポイントロジックを通過していません。

編集：この答えは、「悪い」という理由でどんどんどんどん解かれ続けており、おそらくそれに値するものでした。多分それはまだ悪いかもしれませんが、そうではないかもしれません。

私のPHPではこのチェックを使用します

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

自分で試してくださいhttp://phpfiddle.org/main/code/9av6-d10r

RFCガイドラインに従ってこの正規表現を作成しました。

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

Gmailでは、特殊文字として+記号のみが許可され、場合によっては（。）が許可されますが、その他の特殊文字はGmailでは許可されません。RFCでは、特殊文字を使用できると述べていますが、特殊文字を含むメールをGmailに送信することは避けてください。