電子メールアドレス

電子メール アドレスは、メッセージが配信される電子メールボックスを識別します。初期のメッセージング システムでは、さまざまな形式のアドレス指定が使用されていましたが、今日の電子メール アドレスは、1980 年代にインターネット技術特別調査委員会(IETF) によって最初に標準化され、RFC  5322 および 6854 によって更新された一連の特定の規則に従います。この記事の電子メール アドレスという用語は、RFC 5322 のセクション 3.4 のaddr-specのみを指します。RFC では、アドレスをより広義に、メールボックスまたはグループとして定義しています。メールボックスの値は、 display-nameとaddr-spec を含むname-addrか、より一般的なaddr-specのみのいずれかになります。

john.smith@example.comなどの電子メール アドレスは、ローカル部分、記号 @、およびドメイン(括弧で囲まれたドメイン名またはIP アドレス)で構成されます。標準ではローカル部分の大文字と小文字を区別する必要がありますが、^[1]受信側のホストでは大文字と小文字を区別せずにメッセージを配信することも推奨されています。^[2]たとえば、ドメインexample.comのメール システムはJohn.Smith をjohn.smithと同等に扱います。メール システムによっては、これらをjohnsmithと同等に扱う場合もあります。^{[3]メール システムでは、ユーザーの名前の選択肢が技術的に許可されている文字のサブセットに制限されることがよくあります。}国際化ドメイン名の導入により、電子メール アドレスで非ASCII文字を許可する取り組みが進められています。

今日の世界では電子メールが普及しているため、ユーザープロファイルやアカウントを提供する多くのウェブサイトやサービスでは、電子メールアドレスが通常のユーザー名としてよく使用されています。 ^{[4]たとえば、ユーザーが}Xbox Liveビデオゲーム プロファイルにログインする場合、この場合のサービスは電子メールではありませんが、ユーザー名 ID として電子メール アドレスの形式の Microsoft アカウントを使用します。

電子メール アドレスは、ローカル部分 (ユーザー名の場合もありますが、常にそうとは限りません) とドメインの 2 つの部分で構成されます。ドメインが IP アドレスではなくドメイン名である場合、SMTP クライアントはドメイン名を使用してメール交換機の IP アドレスを検索します。電子メール アドレスの一般的な形式は、ローカル部分@ドメインです(例: jsmith@[192.168.1.2]、jsmith@example.com )。SMTP クライアントはメッセージをメール交換機に送信し、メール交換機はそれを別のメール交換機に転送して、最終的に受信者のメール システムのホストに到達します。

著者のコンピュータからの電子メールの送信、およびインターネット上のメール ホスト間の電子メールの送信には、 RFC 5321 および 5322 で定義されているSimple Mail Transfer Protocol (SMTP)と、 RFC 6531 などの拡張機能が使用されます。メールボックスは、 SMTPプロトコルとPost Office Protocol (POP) またはInternet Message Access Protocol (IMAP) のいずれかを使用して、 パーソナル コンピュータ、モバイル デバイス、またはWeb メールサイト上のアプリケーションからアクセスおよび管理できます。

電子メール メッセージを送信する際、メール ユーザー エージェント(MUA) とメール転送エージェント(MTA) は、ドメイン ネーム システム(DNS) を使用して受信者のドメインのリソース レコード(RR)を検索します。メール エクスチェンジャ リソース レコード ( MX レコード) には、受信者のメール サーバーの名前が含まれています。MX レコードがない場合は、アドレス レコード ( AまたはAAAA ) がメール ホストを直接指定します。

電子メール アドレスのローカル部分は、最終メールボックス ホスト以外の中間メール リレー システムでは意味を持ちません。電子メールの送信者と中間リレー システムは、大文字と小文字を区別しないと想定してはなりません。最終メールボックス ホストは、大文字と小文字を区別しないものと見なす場合とそうでない場合があります。管理者が構成した場合、1 つのメールボックスで複数の電子メール アドレスのメールを受信できます。逆に、1 つの電子メール アドレスは、多数のメールボックスへの配布リストのエイリアスになる場合があります。電子メール エイリアス、電子メール リスト、サブ アドレス指定、キャッチオールアドレス (後者は、ローカル部分に関わらずメッセージを受信するメールボックス) は、さまざまな配信目標を達成するための一般的なパターンです。

電子メール メッセージのヘッダー フィールドにあるアドレスは、メール交換でメッセージを配信するために直接使用されるわけではありません。電子メール メッセージには、メール ルーティングの情報を含むメッセージ エンベロープも含まれています。エンベロープ アドレスとヘッダー アドレスは同じである場合もありますが、偽造された電子メールアドレス (スプーフィングされた電子メール アドレスとも呼ばれる) は、スパム、フィッシング、その他の多くのインターネット ベースの詐欺でよく見られます。このため、このような詐欺メールの偽造を容易に見分けられるようにするための取り組みがいくつか行われています。

電子メールアドレスの形式はlocal-part@domainで、local-partの長さは最大64オクテット、domainの長さは最大255オクテットです。^[5]正式な定義はRFC 5322（セクション3.2.3および3.4​​.1）とRFC 5321にあります。より読みやすい形式は、情報提供用のRFC 3696（RFC 5321の著者であるJ. Klensin著）と関連する正誤表に記載されています。

電子メールアドレスには、受信者の「表示名」（表示名）が関連付けられている場合もあります。これは、アドレス指定の前に付けられ、山括弧で囲まれます。例：John Smith <john.smith@example.org>。^[6]電子メールのスパマーやフィッシング詐欺師は、偽の表示名を使用したり、表示名として別の電子メールアドレスを使用したりして、被害者を騙すために「表示名のなりすまし」を使用することがよくあります。^[7]

インターネット以外のネットワークの電子メール アドレスの以前の形式には、 X.400で要求される表記法や、メッセージが中継されるコンピュータのシーケンスの形式でアドレスが与えられるUUCP バン パス表記法などがありました。これは数年間広く使用されていましたが、インターネット技術タスク フォース(IETF) によって公布されたインターネット標準によって置き換えられました。

電子メール アドレスのローカル部分は引用符で囲まないことも、引用符で囲むこともできます。

引用符で囲まれていない場合は、次のASCII文字のいずれかを使用できます。

• 大文字と小文字のラテン文字AtoZとatoz
• 数字0を9
• 印刷可能な文字!#$%&'*+-/=?^_`{|}~
• ただし、ドットは.最初または最後の文字ではなく、連続して現れないことが条件である（例えば、John..Doe@example.comは許可されない）。^[8]

引用符で囲む場合、スペース、水平タブ (HT)、バックスラッシュと引用符を除く任意の ASCII グラフィック、およびバックスラッシュに続く HT、スペース、または任意の ASCII グラフィックからなる引用符付きペアを含めることができます。また、HT またはスペースが出現する任意の場所で行を分割することもできます。引用符で囲まれていないローカル部分とは対照的に、アドレス".John.Doe"@example.com、"John.Doe."@example.comおよび"John..Doe"@example.comが許可されます。

電子メールアドレスのローカル部分の最大合計長は64オクテットである。^[9]

• スペースと特殊文字は"(),:;<>@[\]制限付きで使用できます (以下の段落で説明するように、引用符で囲まれた文字列内でのみ使用でき、その引用符で囲まれた文字列内では、バックスラッシュまたは二重引用符の前に 1 回バックスラッシュを置く必要があります)。
• ローカル部分の両端に括弧を付けてコメントを記述できます。たとえば、john.smith(comment)@example.comと は(comment)john.smith@example.comどちらも と同等ですjohn.smith@example.com。

上記の ASCII 文字に加えて、UTF-8としてエンコードされた U+007F を超える国際文字は、 EHLO がSMTPUTF8 を指定している場合に RFC 6531 によって許可されますが、 SMTPUTF8 と 8BITMIME をサポートするメール システムでも、ローカル部分の割り当て時に使用する文字が制限される場合があります。

ローカル部分はドット文字列または引用符付き文字列のいずれかであり、組み合わせることはできません。ただし、引用符付き文字列と文字は一般的に使用されません。^{[引用が必要]} RFC 5321 では、「メールを受信することを想定しているホストは、ローカル部分が引用符付き文字列形式を必要とする (または使用する) メールボックスの定義を避けるべきである」とも警告しています。

ローカル部分はpostmaster特別に扱われます。大文字と小文字は区別されず、ドメインの電子メール管理者に転送する必要があります。技術的には、他のすべてのローカル部分は大文字と小文字が区別されるためjohns@example.com、JohnS@example.com異なるメールボックスを指定します。ただし、多くの組織では大文字と小文字を同等に扱います。実際、RFC 5321 では、「メールを受信することを想定しているホストは、ローカル部分が大文字と小文字を区別するメールボックスの定義を避ける必要があります」と警告しています。

技術的に有効な特殊文字の範囲は広いものの、組織、メールサービス、メールサーバー、メールクライアントは実際にはそれらのすべてを受け入れないことがよくあります。たとえば、Windows Live Hotmailでは.、英数字、ドット（ ）、アンダースコア（_）、ハイフン（ ）を使用したメールアドレスの作成のみが許可されています-。^[10]一般的なアドバイスとしては、メールが拒否されるリスクを回避するために、一部の特殊文字の使用を避けることです。^[11]

RFC 5321 2.3.11メールボックスとアドレスによれば、「ローカル部分は、アドレスのドメインで指定されたホストによってのみ解釈され、意味が割り当てられる必要があります」。つまり、別のメール サーバーのローカル部分の意味については推測できません。これは、メール サーバーの構成に完全に依存します。

ローカルパートの解釈は、メールサーバーに実装されている規則やポリシーに依存します。たとえば、大文字と小文字の区別により、ローカルパートの文字の大文字と小文字のみが異なるメールボックスを区別できますが、これはあまり一般的ではありません。^[12]たとえば、Gmailはアカウントの識別を目的として、@gmail.comアドレスのローカルパートのドットをすべて無視します。 ^[13]

一部のメールサービスでは、ローカルパートにタグを含めることができます。これにより、アドレスはローカルパートのプレフィックスのエイリアスになります。通常はプラス記号に続く文字、まれにマイナス記号に続く文字です。そのため、fred+bah@domain と fred+foo@domain は、fred+@domain または fred@domain と同じ受信トレイに届く可能性があります。たとえば、アドレスjoeuser+tag@example.comは、 joeuser@example.comと同じ配信アドレスを示します。RFC  5233 ^[14]では、この規則をサブアドレス指定と呼んでいますが、プラスアドレス指定、タグ付きアドレス指定、メール拡張子とも呼ばれています。これは、メールをタグ付けして仕分けしたり、スパムを制御したりするのに役立ちます。^[15]

ベース名とタグの間にさまざまな区切り文字を使用するこの形式のアドレスは、Andrew Project (プラス)、^[16] Runbox (プラス)、^[17] Gmail (プラス)、^[15] Rackspace (プラス)、Yahoo! Mail Plus (ハイフン)、^[18] Apple のiCloud (プラス)、Outlook.com (プラス)、^[19] Mailfence (プラス)、^[20] Proton Mail (プラス)、^[21] Fastmail (プラスおよびサブドメイン アドレス指定)、^[22] postale.io (プラス)、^[23] Pobox (プラス)、^[24] MeMail (プラス)、^[25]およびMMDF (イコール)、Qmail、Courier Mail Server (ハイフン)などのMTA でサポートされています。^{[26] [27]} PostfixとExim では、有効な文字セットから任意の区切り文字を設定できます。^{[28] [29]}

タグのテキストはフィルタリングを適用したり、^{[26]使い捨ての}電子メールアドレスを作成したりするために使用できます。^[30]

電子メールアドレスのドメイン名部分は、厳格なガイドラインに従う必要があります。ホスト名の要件、ドットで区切られたDNSラベルのリストに一致している必要があり、各ラベルの長さは63文字に制限され、次のもので構成されます。^{[8] ：§2}

• 大文字と小文字のラテン文字AtoZとato z;
• 0から までの数字9。ただし、トップレベルドメイン名がすべて数字ではない場合に限ります。
• ハイフン（-最初または最後の文字ではない場合）。

このルールはLDH ルール(文字、数字、ハイフン)として知られています。さらに、ドメインはや のように角括弧で囲まれたIP アドレスリテラルである場合もありますが、これは電子メールスパム以外ではほとんど見られません。国際化ドメイン名(ホスト名の要件に準拠するようにエンコードされている) を使用すると、非 ASCII ドメインを表示できます。RFC 6531 および RFC 6532 に準拠したメールシステムでは、電子メールアドレスは、ローカル部分とドメイン名の両方 がUTF-8としてエンコードされる場合があります。[]jsmith@[192.168.2.1]jsmith@[IPv6:2001:db8::1]

コメントはドメイン内とローカル部分の両方で使用できます。たとえば、john.smith@(comment)example.comおよび は とjohn.smith@example.com(comment)同等ですjohn.smith@example.com。

RFC  2606 では、ドキュメントやテスト用のドメインなど、特定のドメインは解決不可であり、その結果、それらのドメインとそのサブドメイン内のメールボックス宛てのメールは配信不可となることが規定されています。電子メールで注目すべきドメインは、 example、invalid、example.com、example.net、example.orgです。

• simple@example.com
• very.common@example.com
• FirstName.LastName@EasierReading.org(大文字と小文字は @ の後では必ず無視され、通常は @ の前では無視されます)
• x@example.com(1文字のローカル部分)
• long.email-address-with-hyphens@and.subdomains.example.com
• user.name+tag+sorting@example.comuser.name@example.com(メールサーバーによっては受信トレイにルーティングされる場合があります)
• name/surname@example.com(スラッシュは印刷可能な文字であり、使用できます)
• admin@example（ TLDのないローカルドメイン名。ただし、ICANNはドットなしの電子メールアドレスを強く推奨していません^[31]）
• example@s.example（インターネットトップレベルドメインのリストを参照）
• " "@example.org（引用符の間にスペース）
• "john..doe"@example.org（二重引用符）
• mailhost!username@example.org(uucp メーラーに使用されるバンギングされたホスト ルート)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(英字以外の文字と複数のアットマークを含み、最初のアットマークは二重引用符で囲みます)
• user%example.com@example.org(% エスケープされたメールは example.org 経由で user@example.com にルートされます)
• user-@example.org(ローカル部分は、印刷可能な文字のリストにある英数字以外の文字で終わる)
• postmaster@[123.123.123.123](角括弧内の場合はドメインの代わりに IP アドレスを使用できますが、強く推奨されません)
• postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](IPv6では異なる構文を使用します)
• _test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334](アンダースコアで始まる構文が異なります)

• I❤️CHOCOLATE@example.com(絵文字はSMTPUTF8 でのみ使用できます)

• abc.example.com（@文字なし）
• a@b@c@example.com(引用符の外側には 1 つの @ のみ使用できます)
• a"b(c)d,e:f;g<h>i[j\k]l@example.com(このローカル部分の特殊文字は引用符の外側では使用できません)
• just"not"right@example.com(引用符で囲まれた文字列はドットで区切るか、ローカル部分を構成する唯一の要素である必要があります)
• this is"not\allowed@example.com(スペース、引用符、バックスラッシュは引用符で囲まれた文字列内でバックスラッシュが先行する場合にのみ使用できます)
• this\ still\"not\\allowed@example.com（エスケープ（バックスラッシュが先行）されている場合でも、スペース、引用符、バックスラッシュは引用符で囲む必要があります）
• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com(ローカル部分が 64 文字を超えています)
• i.like.underscores@but_they_are_not_allowed_in_this_part(ドメイン部分にはアンダースコアは使用できません)

ユーザーの存在を確認するために、Web サイトへの入力として電子メール アドレスが要求されることがよくあります。携帯電話番号の検証、郵便の検証、ファックスの検証 など、他の検証方法も利用できます。

電子メールアドレスは、一般的にアットマーク（@）で結合された2つの部分で構成されていると認識されていますが、RFC 822およびそれ以降のRFCで詳述されている技術仕様はより広範囲にわたります。^[32]

構文的に正しく検証された電子メール アドレスは、電子メール ボックスが存在することを保証するものではありません。そのため、多くのメール サーバーは他の手法を使用して、ドメインのドメイン ネーム システムなどの関連システムに対してメールボックスの存在を確認したり、コールバック検証を使用してメールボックスが存在するかどうかを確認したりします。コールバック検証は、ディレクトリ ハーベスト攻撃を回避するために無効にされたり、コールバックがスパムとして報告されてDNSBLにリストされたりする可能性があるため、完全なソリューションではありません。

ユーザーの電子メールアドレスを検証するためには、いくつかの検証手法が利用される。例えば、^[33]

• 検証リンク: 電子メール アドレスの検証は、多くの場合、Web サイトでのアカウント作成時に、特別な一時的なハイパーリンクを含む電子メールをユーザーが指定した電子メール アドレスに送信することで行われます。受信すると、ユーザーはリンクを開き、すぐにアカウントをアクティブ化します。電子メール アドレスは、Web サイトからのメッセージ (ユーザー メッセージ、ユーザー アクションなど) を電子メールの受信トレイに配信する手段としても役立ちます。
• 公式および非公式の標準: RFC 3696 は、電子メール アドレスを含むインターネット識別子を検証するための具体的なアドバイスを提供します。一部の Web サイトでは、代わりに、+や/などの有効な文字を含むアドレスを拒否したり、任意の長さ制限を適用したりするなど、任意の標準を使用して電子メール アドレスの有効性を評価しようとします。電子メール アドレスの国際化では、 UTF-8としてエンコードされた U+0080 を超えるすべての Unicode 文字など、現在の多くの検証アルゴリズムで許可されているよりもはるかに広い範囲の文字が提供されます。
• アルゴリズムツール：大規模なウェブサイト、大量メール送信者、スパマーは、電子メールアドレスを検証するための効率的なツールを必要とします。このようなツールは、ヒューリスティックアルゴリズムと統計モデルに依存しています。^[34]
• 送信者の評判: 電子メールの送信者の評判は、送信者が信頼できるか、潜在的なスパマーであるかを確認するために使用される場合があります。送信者の評判の評価に組み込むことができる要素には、送信者の IP アドレスまたは電子メール アドレスとの過去の連絡の質、送信者から提供されたコンテンツ、およびエンゲージメント レベルが含まれます。
• ブラウザベースの検証：多くのブラウザに実装されているHTML5フォームでは、電子メールアドレスの検証をブラウザで処理できます。^[35]

一部の企業では、アプリケーション プログラミング インターフェイスを使用して電子メール アドレスを検証するサービスを提供していますが、正確な結果が得られるという保証はありません。

IETFは、電子メールアドレスの国際化問題に特化した技術および標準化ワーキンググループを運営しており、その名称は「電子メールアドレス国際化（EAI、IMA、国際化メールアドレスとも呼ばれる）」です。^[36]このグループはRFC  6530、6531、6532、6533を作成し、さらにEAI関連のRFCの作成を続けています。

IETF の EAI ワーキング グループは、電子メール アドレスのローカル部分とドメインの両方で非 ASCII 文字を使用できるようにする RFC 6530「国際化電子メールの概要とフレームワーク」を公開しました。RFC 6530 は、Unicodeの完全なレパートリーを許可するUTF-8エンコーディングに基づく電子メールを提供します。RFC 6531 は、SMTP サーバーがSMTPUTF8コンテンツの送信をネゴシエートするためのメカニズムを提供します。

EAIの基本概念は、UTF-8でメールを交換することです。当初の提案では、レガシーシステム用のダウングレードメカニズムが含まれていましたが、これは現在では削除されています。^[37]ローカルサーバーはアドレスのローカル部分を担当し、ドメインは国際化ドメイン名のルールによって制限されますが、UTF-8で送信されます。メールサーバーは、IMA形式とASCIIエイリアス間のマッピングメカニズムも担当します。

EAI を使用すると、ユーザーは、ネイティブ言語のスクリプトまたは文字セットでローカライズされたアドレスを使用できるほか、レガシー システムとの通信やスクリプトに依存しない使用のために ASCII 形式を使用することもできます。国際化されたドメイン名とメール アドレスを認識するアプリケーションには、これらの表現を変換する機能が必要です。

このようなアドレスは、ラテン文字をベースとしない表記体系のユーザーベースが大きい中国、日本、ロシアなどの市場で大きな需要が見込まれます。

例えば、.inトップレベルドメインに加えて、インド政府は2011年に^[38]「.bharat」（Bhārat Gaṇarājyaに由来）の承認を得ました。これは、グジャラート語、マラーティー語、ベンガル語、タミル語、テルグ語、パンジャブ語、ウルドゥー語の話者が使用できるように、7つの異なる文字で表記されています^{[39] [40]}。インドの企業XgenPlus.comは、世界初のEAIメールボックスプロバイダーであると主張しており、^[41]ラジャスタン州政府は現在、州のすべての市民にराजस्थान.भारतドメインの無料メールアカウントを提供しています。^[42]大手メディアハウスRajasthan Patrikaは、連絡可能なメールを備えたIDNドメインपत्रिका.भारतを開始しました。

 以下の例のアドレスは、拡張子のないRFC 5321 ベースのサーバーでは処理されませんが、 RFC 6530 および 6531のUTF8SMTP拡張機能では許可され ます。これに準拠するサーバーは、次のアドレスを処理できます。

• 発音区別記号付きラテンアルファベット: éléonore@example.com
• ギリシャ語アルファベット: δοκιμή@παράδειγμα.δοκιμή
• 繁体字中国語文字: 我買@屋企.香港
• 日本語文字: 二ノ宮@黒川.日本
• キリル文字: медведь@с-балалайкой.рф
• デーヴァナーガリー文字: संपर्क@डाटामेल.भारत

• スパム対策技術
• メールクライアント
• メールボックス
• メール認証
• インターネット以外のメールアドレス
• 国際メール

• RFC  821 シンプルメール転送プロトコル (RFC 2821 および 5321 により廃止)
•  ARPA インターネット テキスト メッセージのフォーマットに関するRFC 822 標準 (RFC 2822 により廃止) (Errata)
• RFC  1035 ドメイン名、実装および仕様 (正誤表)
• RFC  1123 インターネットホスト、アプリケーション、およびサポートの要件 (RFC 2821、RFC 5321 により更新) (正誤表)
• RFC  2142 共通サービス、役割、機能のメールボックス名 (正誤表)
• RFC  2821 シンプル メール転送プロトコル (RFC 821 を廃止、RFC 1123 を更新、RFC 5321 で廃止) (エラッタ)
• RFC  2822 インターネット メッセージ形式 (RFC 822 は廃止、RFC 5322 により廃止) (正誤表)
• RFC  3696 名前のチェックと変換のアプリケーション技術 (正誤表)
• RFC  4291 IP バージョン 6 アドレス アーキテクチャ (RFC 5952 により更新) (正誤表)
• RFC  5321 シンプルメール転送プロトコル (RFC 2821 を廃止、RFC 1123 を更新) (エラッタ)
• RFC  5322 インターネット メッセージ形式 (RFC 2822 は廃止され、RFC 6854 によって更新されました) (正誤表)
• RFC  5598 インターネットメールアーキテクチャ
• RFC  5952 IPv6 アドレステキスト表現に関する推奨事項 (RFC 4291 の更新) (正誤表)
• RFC  6530 国際化電子メールの概要とフレームワーク (RFC 4952、5504、5825 は廃止)
• RFC  6531 国際化電子メールの SMTP 拡張 (RFC 5336 は廃止)
• RFC  6854 「From:」および「Sender:」ヘッダー フィールドでグループ構文を許可するためのインターネット メッセージ形式の更新 (RFC 5322 の更新)

• Wikibooks でメールアドレスを検証する
• Wikibooks のベストプラクティス
• ウィキメディア・コモンズの電子メールアドレスに関連するメディア