電子メールアドレス

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

[email protected]などの電子メール アドレスは、ローカル部分、記号 @、およびドメイン(ドメイン名または括弧で囲まれた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]、[email protected]）。SMTPクライアントはメッセージをメール交換機に送信し、メール交換機はメッセージを別のメール交換機に転送して、最終的に受信者のメールシステムのホストに到達します。

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

電子メールメッセージを送信する際、メールユーザーエージェント（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 によって書かれた^{[ 6 ]} ) と関連のエラッタに記載されています。

メールアドレスには、受信者の「表示名」（ディスプレイネーム）が関連付けられている場合があり、これはアドレス指定の前に山括弧で囲まれて表示されます。例：John Smith <[email protected]> ^{[ 7 ]}。スパムメールやフィッシング詐欺師は、偽の表示名を使用したり、別のメールアドレスを表示名として使用したりすることで、「表示名のなりすまし」によって被害者を騙すことがよくあります。^{[ 8 ]}

インターネット以外のネットワークにおける初期のメールアドレスの形式には、 X.400で要求される表記法や、メッセージが中継されるコンピュータのシーケンスの形式でアドレスを指定するUUCP のバンパス表記法など、他の表記法が含まれていました。この表記法は数年間広く使用されていましたが、インターネット技術タスクフォース(IETF) によって制定されたインターネット標準に取って代わられました。

ローカル部分

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

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

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

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

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

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

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

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

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

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

RFC 5321 2.3.11 Mailbox and Addressによれば、 「ローカルパートは、アドレスのドメインに指定されたホストによってのみ解釈され、意味が割り当てられなければならない」とされています。これは、他のメールサーバーのローカルパートの意味について推測することはできないことを意味します。これは完全にメールサーバーの設定次第です。

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

サブアドレス指定

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

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

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

ドメイン

電子メールアドレスのドメイン名部分は、厳格なガイドラインに従う必要があります。ホスト名の要件、ドットで区切られたDNSラベルのリストに一致している必要があり、各ラベルの長さは63文字に制限され、次のもので構成されます。^{[ 9 ]：§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と は と[email protected](comment)同等です[email protected]。

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

例

有効なメールアドレス

• [email protected]
• [email protected]
• [email protected](大文字と小文字は @ の後と通常は @ の前で常に無視されます)
• [email protected]（1文字のローカル部分）
• [email protected]
• [email protected]（[email protected]メールサーバーによっては受信トレイにルーティングされる場合があります）
• name/[email protected]（スラッシュは印刷可能な文字であり、使用できます）
• admin@example（ TLDのないローカルドメイン名。ただしICANNはドットなしの電子メールアドレスを強く推奨していない^{[ 32 ]}）
• [email protected]（インターネットトップレベルドメインの一覧を参照）
• " "@example.org（引用符の間にスペース）
• "john..doe"@example.org（二重引用符）
• [email protected](UUCP メールプログラムで使用される、bangified ホスト ルート)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com(英字以外の文字と複数のアットマークを含み、最初のアットマークは二重引用符で囲みます)
• user%[email protected](% エスケープされたメールは example.org 経由で [email protected] にルートされます)
• [email protected](ローカル部分は、印刷可能な文字リストにある英数字以外の文字で終わる)
• 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](アンダースコアで始まる構文が異なります)

SMTPUTF8 を使用した有効なメールアドレス

• I❤️[email protected]（絵文字はSMTPUTF8でのみ使用できます）

無効なメールアドレス

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

検証と検証

ウェブサイトでは、ユーザーの存在確認のため、メールアドレスの入力が求められることがよくあります。携帯電話番号、郵便、FAXなどの他の検証方法も利用可能です。

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

構文的に正しく検証済みのメールアドレスは、メールボックスの存在を保証するものではありません。そのため、多くのメールサーバーは他の手法を用いて、ドメインのドメインネームシステム（DNS）などの関連システムと照合し、メールボックスの存在を確認したり、コールバック検証を用いてメールボックスの存在を確認したりしています。コールバック検証は、ディレクトリハーベスト攻撃（DIR）を回避するために無効化される場合や、コールバックがスパムとして報告され、 DNSBL（DNS Logging List）に登録される可能性があるため、完全な解決策とは言えません。

ユーザーのメールアドレスを検証するためには、いくつかの検証手法が利用できる。例えば、^{[ 34 ]}

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

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

国際化

IETFは、電子メールアドレスの国際化問題に特化した技術・標準化ワーキンググループ「電子メールアドレス国際化（EAI、IMA（Internationalized Mail Address）とも呼ばれる）」を運営しています。[ 37 ]このグループ^{はRFC 6530、6531、6532、6533}を作成し、EAI関連のRFCの作成を続けています。  

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

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

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

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

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

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

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

参照

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

参考文献

1. J. Klensin (2008年10月). 「一般構文原則とトランザクションモデル」 . Simple Mail Transfer Protocol . p. 15. sec. 2.4. doi : 10.17487/RFC5321 . RFC 5321.メールボックスのローカルパートは、大文字と小文字を区別して扱わなければなりません。
2. J. Klensin (2008年10月). 「一般構文原則とトランザクションモデル」 . Simple Mail Transfer Protocol . p. 15. sec. 2.4. doi : 10.17487/RFC5321 . RFC 5321.ただし、メールボックスのローカルパートの大文字と小文字の区別を利用すると相互運用性が損なわれるため、推奨されません。
3. 「…実際の送信先アドレスを変更せずに、メールアドレスにドットを追加または削除できます。それらはすべて受信トレイに届きます…」、Google.com
4. Morrison, Sara (2021年9月6日). 「シンプルなメールアドレスが物事を複雑にする方法」 . Vox . 2024年7月15日閲覧。
5. Klensin, J. (2008年10月). 「サイズの制限と最小値」 . Simple Mail Transfer Protocol . IETF . sec. 4.5.3.1. doi : 10.17487/RFC5321 . RFC 5321 .
6. J. クレンシン、 RFC 5321、IETF、2008 年 10 月
7. 「アドレス仕様」 .インターネットメッセージフォーマット. sec. 3.4. doi : 10.17487/RFC5322 . RFC 5322. 2023年3月14日閲覧。
8. 「スプーフィングの見分け方」 cyber.nj.gov 2020年11月19日. 2023年4月17日閲覧。
9. Klensin, J. (2004 年 2 月)。RFC 3696。IETF。土井: 10.17487/RFC3696。2017 年 8 月 1 日に取得。^{: §3}
10. Klensin, J. (2008年10月). RFC 5321 . IETF . sec. 4.5.3.1.1. doi : 10.17487/RFC5321 . 2019年8月1日閲覧。
11. 「Windows Live にサインアップ」。2008年7月26日閲覧。ただし、このフレーズは隠されているため、読むには、 me#1などの無効なIDが使用可能かどうかを確認するか、 no-styleやソースビューなどの代替表示に頼る必要があります。
12. 「電子メールアドレスのローカル部分の文字」 。 2016年3月30日閲覧。
13. メールアドレスは大文字と小文字を区別しますか？ 2016年6月3日アーカイブ、Wayback MachineにてHeinz Tschabitscher著
14. 「他人のメールを受信する」 . google.com .
15. Murchison, K. (2008). Sieve Email Filtering: Subaddress Extension . IETF . doi : 10.17487/RFC5233 . RFC 5233 . 2019年2月9日閲覧。
16. 「別のアドレスまたはエイリアスからメールを送信する」。Gmailヘルプ。 2023年12月13日閲覧。
17. 「アンドリューメッセージシステムの概要」(PDF) . 2023年4月17日閲覧。
18. 「サブアドレス指定/プラスアドレス指定」 。 2024年1月1日閲覧。
19. 「Yahooメールの使い捨てアドレス」Yahooヘルプ
20. Rivera, Rafael (2013年9月17日). 「Outlook.comはよりシンプルな「+」メールエイリアスもサポートしています」 . Windows内. 2014年2月20日時点のオリジナルよりアーカイブ。 2023年12月4日閲覧。
21. 「プラスアドレス指定：2024年にスパマーを追跡する最良の方法」 mailfence.com 2024年9月3日。
22. 「アドレスとエイリアス」 . proton.me .
23. 「Plus アドレス指定とサブドメイン アドレス指定」 www.fastmail.com . 2020年10月6日時点のオリジナルよりアーカイブ。 2020年10月6日閲覧。
24. postale.ioのサブアドレスに関するFAQ」。postale.io 。2020年10月6日時点のオリジナルよりアーカイブ。2020年10月6日閲覧。
25. 「Poboxアカウントで[email protected]を使用できますか？」 . helpspot.pobox.com . nd 2020年10月3日時点のオリジナルよりアーカイブ。2020年10月3日閲覧。Poboxは、任意のアドレスで「+anystring」（拡張子付き）の使用をサポートしています。
26. "MeMail" . www.memail.com . 2020年10月6日閲覧。
27. 「Dot-Qmail、メールメッセージの配信を制御する」 。 2012年1月26日時点のオリジナルよりアーカイブ。 2012年1月27日閲覧。
28. Sill, Dave. 「4.1.5. 拡張アドレス」 . Life with qmail . 2012年1月27日閲覧。
29. 「Postfix 設定パラメータ」 . postfix.org .
30. 「Exim 設定パラメータ」、「local_part_suffix」「 . exim.org .
31. Gina Trapani (2005)「インスタント使い捨てGmailアドレス」
32. 「新しいgTLDのドットなしドメイン名は禁止」 www.icann.org ICANN 2020年3月23日閲覧。
33. 「Dominoが送信メッセージの送信者のインターネットアドレスをフォーマットする方法」 IBM Knowledge Center . 2019年7月23日閲覧。
34. 「M3AAWG送信者ベストコモンプラクティス、バージョン3」（PDF） .メッセージング、マルウェア、モバイル不正使用対策ワーキンググループ. 2015年2月. 2019年7月23日閲覧。
35. メールアドレスの品質保証のための検証と妥当性確認のテクニック、 Jan Hornych著、2011年、オックスフォード大学
36. 「4.10 フォーム — HTML5」 . w3.org .
37. 「Eai Status Pages」 . Email Address Internationalization (Active WG) . IETF. 2006年3月17日 – 2013年3月18日. 2008年7月26日閲覧。
38. 「Email Address Internationalization (eai)」 IETF 2010年11月30日閲覧。
39. 「2011年1月25日 - インドを代表する7つのトップレベルドメインのさまざまな言語での委任の承認」features.icann.org。
40. 「国際化ドメイン名（IDN） | Registry.In」 . registry.in . 2016年10月17日閲覧。
41. 「今すぐヒンディー語のメールアドレスを取得しましょう」。エコノミック・タイムズ。 2016年10月17日閲覧。
42. 「インドにおける普遍的な受容」 2017年2月15日。
43. "देश में पहला, प्रदेश के हर नागरिक के लिएログイン して翻訳を追加する - 「」。वसुन्धरा राजे (ヒンディー語)。 2017-08-18 。2017 年 8 月 20 日に取得。

さらに読む

• RFC  821シンプルメール転送プロトコル（RFC  2821および5321により廃止）
• RFC  822 ARPA インターネットテキストメッセージのフォーマットの標準（RFC  2822により廃止）（エラッタ）
• RFC  1035ドメイン名、実装および仕様（正誤表）
• RFC  1123インターネットホスト、アプリケーションおよびサポートの要件（RFC  2821、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 Simple Mail Transfer Protocol ( 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のベストプラクティス
• ウィキメディア・コモンズのメールアドレスに関連するメディア

「 https://en.wikipedia.org/w/index.php?title=Email_address&oldid=1337505707#Internationalization」より取得