Loading article…
電子メールアドレスは、電子メールメッセージが配信されるメールボックスを識別するものです。初期のメッセージングシステムではさまざまなアドレス形式が使用されていましたが、今日の電子メールアドレスは、 1980年代にインターネット技術タスクフォース（IETF）によって標準化され、RFC 5322および6854によって更新された特定のルールセットに従います。この記事における「電子メールアドレス」という用語は、RFC 5322のセクション3.4にあるaddr-specのみを指します。RFCでは、アドレスをより広義に、メールボックスまたはグループとして定義しています。メールボックスの値は、表示名とaddr-specを含むname-addr、またはより一般的なaddr-specのみのいずれかになります。
jane.smith@example.comのような電子メール アドレスは、ローカル パート(記号 @) とドメイン(ドメイン名または括弧で囲まれたIP アドレス)で構成されます。標準ではローカル パートは大文字と小文字を区別すると規定されていますが[ 1 ]、受信ホストはメッセージを大文字と小文字を区別せずに配信するようにも推奨されています[ 2 ] 。たとえば、 example.comドメインのメール システムではJane.Smithをjane.smithと同等に扱う必要があります。(一部のメール システムでは、両方をjane smithと同等に扱う場合もあります。[ 3 ] ) メール システムでは、多くの場合、ユーザーが選択できる名前が RFC で許可されている文字のサブセットに制限されます。国際化ドメイン名の導入に伴い、電子メール アドレスで非ASCII文字を許可する取り組みが進んでいます。
今日では電子メールが広く普及しているため、ユーザープロファイルやアカウントを提供する多くのウェブサイトやサービスで、電子メールアドレスが通常のユーザー名として使用されています。 [ 4 ]例えば、ユーザーがXbox Live のビデオゲームプロファイルにログインしたい場合、この場合のサービスは電子メールではありませんが、Microsoft アカウントのユーザー名 ID として電子メールアドレスを使用します。
電子メールアドレスは、ローカル部分（ユーザー名の場合もありますが、必ずしもそうとは限りません）とドメインの2つの部分で構成されます。ドメインがIPアドレスではなくドメイン名の場合、SMTPクライアントはそのドメイン名のメール交換（MX）IPアドレスを検索します。電子メールアドレスの一般的な形式は、ローカル部分@ドメインです。例：jsmith@ [ 192.168.1.2 ]、jsmith@example.com。SMTPクライアントはメッセージをメール交換に送信し、メール交換はそれを別のメール交換に転送する可能性があり、最終的に受信者のメールシステムのホストに届きます。
送信者のコンピュータからインターネット上のメールホスト間への電子メールの送信には、RFC 5321および5322で定義されている簡易メール転送プロトコル（SMTP）と、 RFC 6531などの拡張機能が使用されます。メールボックスは、 SMTPプロトコルと、POP（ Post Office Protocol）またはIMAP（Internet Message Access Protocol ）のいずれかを使用するパーソナルコンピュータ、モバイルデバイス、またはウェブメールサイト上のアプリケーションによってアクセスおよび管理できます。
電子メールメッセージを送信する際、メールユーザーエージェント（MUA）とメール転送エージェント（MTA）は、ドメインネームシステム（DNS）を使用して、受信者のドメインのリソースレコード（RR）を検索します。メール交換リソースレコード（MXレコード）には、受信者のメールサーバーの名前が含まれています。MXレコードが存在しない場合は、アドレスレコード（AレコードまたはAAAAレコード）によってメールホストが直接指定されます。
電子メールアドレスのローカル部分は、最終的なメールボックスホスト以外の中間メールリレーシステムでは意味を持ちません。最終的なメールボックスホストがローカル部分を大文字小文字を区別する場合と区別しない場合があるため、電子メール送信者と中間リレーシステムはローカル部分を大文字小文字を区別しないと想定してはなりません。管理者が設定すれば、1つのメールボックスで複数の電子メールアドレス宛のメールを受信できます。逆に、1つの電子メールアドレスが、複数のメールボックスへの配信リストのエイリアスになることもあります。電子メールエイリアス、電子メールリスト、サブアドレス指定、キャッチオールアドレス（ローカル部分に関係なくメッセージを受信するメールボックス）は、さまざまな配信目標を達成するための一般的なパターンです。
電子メールメッセージのヘッダーフィールドに含まれるアドレスは、メール交換によってメッセージを配信するために直接使用されるわけではありません。SMTPメール転送では、送信システムが送信元アドレスと宛先アドレスを伝達します。この情報は「メッセージエンベロープ」と呼ばれることもあります。エンベロープアドレスとヘッダーアドレスは同じである場合もありますが、これは厳密には必須ではありません。[ a ]偽造または「なりすまし」された電子メールアドレスは、スパム、フィッシング、その他多くのインターネットベースの詐欺でよく見られます。このため、このような不正な電子メールの偽造を容易に発見できるようにするためのいくつかの取り組みが行われています。
電子メール アドレスの形式は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 ] ) および関連する正誤表に記載されています。
電子メールアドレスには、受信者の「表示名」（Display Name）が関連付けられている場合もあり、これはアドレス指定の前に、山括弧で囲まれて表示されます。たとえば、Jane Smith <jane.smith@example.org>のようになります。[ 7 ]メールスパマーやフィッシング詐欺師は、偽の表示名を使用したり、表示名として別の電子メールアドレスを使用したりして、被害者を騙すために「表示名スプーフィング」をよく使用します。[ 8 ]
インターネット以外のネットワークで使用される初期の電子メールアドレスには、 X.400で規定されている表記法や、UUCPのバンパス表記法などがありました。UUCPのバンパス表記法では、アドレスはメッセージの中継経路となるコンピュータのシーケンスとして指定されていました。この表記法は数年間広く使用されていましたが、インターネット技術タスクフォース（IETF）が制定したインターネット標準によって廃止されました。
メールアドレスのローカル部分は、引用符なしでも引用符で囲んでも構いません。
引用符で囲まれていない場合は、以下のASCII文字のいずれかを使用できます。
AZaz09!#$%&'*+-/=?^_`{|}~.、最初または最後の文字ではなく、連続して出現しない場合に限り使用できます（たとえば、Jane..Doe@example.comは許可されません）。[ 9 ]引用符で囲まれている場合、スペース、水平タブ (HT)、バックスラッシュと引用符以外の任意の ASCII 文字、およびバックスラッシュの後に HT、スペース、または任意の ASCII 文字が続く引用符で囲まれたペアを含めることができます。また、HT またはスペースが出現する場所であれば、行を分割することもできます。引用符で囲まれていないローカル パートとは異なり、アドレス".Jane.Doe"@example.com、"Jane.Doe."@example.comおよびが"Jane..Doe"@example.com許可されます。
電子メールアドレスのローカル部分の最大合計長は64オクテットです。[ 10 ]
"(),:;<>@[\]制限付きで使用できます（以下の段落で説明するように、引用符で囲まれた文字列内でのみ使用可能で、その引用符で囲まれた文字列内では、バックスラッシュまたは二重引用符の前に必ずバックスラッシュを1つ付ける必要があります）。jane.smith(comment)@example.comと は(comment)jane.smith@example.comどちらも と同じですjane.smith@example.com。上記のASCII文字に加えて、EHLOがSMTPUTF8を指定する場合、RFC 6531ではUTF-8でエンコードされたU+007F以上の国際文字が許可されていますが、SMTPUTF8と8BITMIMEをサポートするメールシステムでも、ローカルパーツを割り当てる際に使用できる文字が制限される場合があります。
ローカルパートはドット文字列か引用符付き文字列のいずれかであり、両方を組み合わせることはできません。ただし、引用符付き文字列や引用符付き文字は一般的に使用されていません。RFC 5321では、「メールを受信するホストは、ローカルパートで引用符付き文字列形式を必要とする（または使用する）メールボックスを定義することを避けるべきである」と警告しています。
ローカルパートpostmasterは特別扱いされます。大文字と小文字を区別しないため、ドメインのメール管理者へ転送する必要があります。技術的には、その他のローカルパートはすべて大文字と小文字を区別するため、janes@example.comそれぞれJaneS@example.com異なるメールボックスを指定します。しかし、多くの組織では大文字と小文字を同等に扱っています。実際、RFC 5321では、「メールを受信するホストは、ローカルパートが大文字と小文字を区別するようなメールボックスの定義を避けるべきである」と警告しています。
技術的には有効な特殊文字は多岐にわたるにもかかわらず、実際には組織、メールサービス、メールサーバー、メールクライアントはそれらすべてを受け入れるとは限りません。たとえば、Windows Live Hotmailでは.、英数字、ドット（ ）、アンダースコア（_）、ハイフン（ ）を使用してメールアドレスを作成することしかできません-。[ 11 ]一般的には、メールが拒否されるリスクを避けるために、一部の特殊文字の使用を避けるようにアドバイスされています。[ 12 ]
RFC 5321 2.3.11 「メールボックスとアドレス」によれば、 「ローカルパートは、アドレスのドメインで指定されたホストによってのみ解釈され、意味が割り当てられなければならない」。つまり、他のメールサーバーのローカルパートの意味について、いかなる推測もできないということである。それは完全にメールサーバーの設定に依存する。
ローカルパートの解釈は、メールサーバーに実装されている規則とポリシーに依存します。たとえば、大文字小文字の区別によって、ローカルパートの文字の大文字小文字のみが異なるメールボックスを区別できる場合がありますが、これはあまり一般的ではありません。[ 13 ]たとえば、Gmailはアカウント識別の目的で、ユーザーのメールアドレスのローカルパートにあるすべてのドットを無視します。[ 14 ]
一部のメールサービスでは、ローカル パートにタグを含めることがサポートされており、これによりアドレスはローカル パートのプレフィックスのエイリアスになります。通常はプラス記号の後の文字、まれにマイナス記号の後の文字がタグとして使用されるので、fred+bar@domain と fred+foo@domain は fred+@domain または fred@domain と同じ受信トレイに届く可能性があります。たとえば、joeuser+ tag @example.com というアドレスは、 joeuser@example.comと同じ配信アドレスを表します。RFC 5233 [ 15 ]ではこの慣例をサブアドレッシングと呼んでいますが、プラスアドレッシング、タグ付きアドレッシング、またはメール拡張機能とも呼ばれます。これは、メールを分類するためのタグ付けやスパム対策に役立ちます。[ 16 ]
ベース名とタグの間にさまざまな区切り文字を使用するこの形式のアドレスは、Andrew Project (plus)、[ 17 ] Runbox (plus)、[ 18 ] Gmail (plus)、[ 16 ] Rackspace (plus)、Yahoo! Mail Plus (ハイフン)、[ 19 ] AppleのiCloud (plus)、Outlook.com (plus)、[ 20 ] Mailfence (plus)、[ 21 ] Proton Mail (plus)、[ 22 ] Fastmail ( plusおよびサブドメインアドレス指定)、[ 23 ] postale.io ( plus)、 [ 24 ] Pobox (plus)、 [ 25 ] MeMail (plus)、[ 26 ]やMMDF (イコール)、Qmail、Courier Mail Server (ハイフン)などのMTAを含むいくつかのメールサービスでサポートされています。[ 27 ] [ 28 ] PostfixとEximでは、有効な文字セットから任意の区切り文字を設定できます。[ 29 ] [ 30 ]
タグのテキストは、フィルタリングを適用したり[ 27 ]、使い捨ての電子メールアドレスを作成したりするために使用できます[ 31 ]。
電子メールアドレスのドメイン名部分は厳格なガイドラインに準拠する必要があります。ホスト名の要件、ドットで区切られたDNSラベルのリスト（各ラベルは63文字以内）に一致し、以下の要素で構成されます。[ 9 ]： §2
AそれぞれとZまでaですz。0から まで9。ただし、トップレベルドメイン名がすべて数字でない場合。-、最初または最後の文字でない限り使用できます。このルールはLDH ルール(文字、数字、ハイフン) として知られています。また、ドメインは、やのように角括弧で囲まれたIP アドレスリテラルである場合もありますが、電子メール スパム以外ではめったに見られません。国際化ドメイン名(ホスト名の要件を満たすようにエンコードされています) では、非 ASCII ドメインの表示が可能です。 RFC 6531 および RFC 6532 に準拠したメール システムでは、電子メール アドレスは、ローカル パートとドメイン名の両方がUTF-8でエンコードされる場合があります。[]jsmith@[192.168.2.1]jsmith@[IPv6:2001:db8::1]
ドメイン内だけでなくローカルパート内にもコメントを記述できます。例えば、jane.smith@(comment)example.comと は とjane.smith@example.com(comment)同等ですjane.smith@example.com。
RFC 2606では、ドキュメントやテストを目的としたドメインなど、特定のドメインは解決できないようにし、その結果、それらのドメインおよびそのサブドメインのメールボックス宛てのメールは配信できないようにすることを規定しています。電子メールで注目すべきドメインは、 example、invalid、example.com、example.net、example.orgです。
simple@example.comvery.common@example.comFirstName.LastName@EasierReading.org（@記号の後と通常はその前では大文字小文字は区別されません）x@example.com（一文字のローカルパート）long.email-address-with-hyphens@and.subdomains.example.comuser.name+tag+sorting@example.com（user.name@example.comメールサーバーによっては受信トレイに転送される場合があります）name/surname@example.com（スラッシュは印刷可能な文字であり、使用が許可されています）admin@example( TLDのないローカルドメイン名。ただし、ICANNはドットなしのメールアドレスを強く推奨していません[ 32 ] )example@s.example（インターネットのトップレベルドメイン一覧を参照）" "@example.org（引用符の間にスペース）"jane..doe"@example.org（引用符は二重ドット）mailhost!username@example.org（UUCPメーラーに使用される、bangifiedホストルート）"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（ドメイン部分にはアンダースコアは使用できません）ウェブサイトでは、ユーザーの存在確認のためにメールアドレスの入力が求められることがよくあります。その他にも、携帯電話番号、住所、FAX番号など、様々な認証方法が利用可能です。
電子メールアドレスは一般的にアットマーク（@）で結合された2つの部分から構成されていると認識されていますが、RFC 822および後続のRFCで詳述されている技術仕様はより広範です。[ 33 ]
構文的に正しく検証済みのメールアドレスであっても、メールボックスの存在を保証するものではありません。そのため、多くのメールサーバーは他の手法を用いて、ドメインのドメインネームシステム（DNS）などの関連システムと照合したり、コールバック検証を用いてメールボックスの存在を確認したりしています。コールバック検証は、ディレクトリハーベスト攻撃を防ぐために無効化される場合や、コールバックがスパムとして報告され、 DNSBLに登録される可能性があるため、完全な解決策とは言えません。
ユーザーのメールアドレスを検証するために、いくつかの検証手法が利用できます。たとえば、[ 34 ]
一部の企業は、 APIなどを利用してメールアドレスを検証するサービスを提供していますが、正確な結果が得られる保証はありません。
IETFは電子メール アドレスの国際化問題に特化した技術および標準化ワーキング グループを運営しており、その名称は電子メールアドレスの国際化( EAI、別名 IMA、国際化メール アドレス) です。[ 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形式のアドレスも取得できます。国際化されたドメイン名とメールアドレスを認識するアプリケーションは、これらの表現を変換する機能を備えている必要があります。
中国、日本、ロシア、その他ラテン文字以外の表記体系を使用するユーザー層が多い市場では、こうした住所に対する大きな需要が見込まれる。
例えば、インド政府は 2011 年にトップレベル ドメイン.inに加えて[ 39 ]、「.bharat」（Bhārat Gaṇarājyaから）を承認しました。これは、グジャラート語、マラーティー語、ベンガル語、タミル語、テルグ語、パンジャブ語、ウルドゥー語を話す人が使用するために 7 つの異なる文字で書かれています[ 40 ] [ 41 ]。インドの企業 XgenPlus.com は、世界初の EAI メールボックス プロバイダーであると主張しており[ 42 ] 、ラジャスタン州政府は現在、州のすべての市民にドメイン राजस्थान.भारत で無料の電子メール アカウントを提供しています[ 43 ]。大手メディア企業 Rajasthan Patrika は、連絡可能な電子メールを備えた IDN ドメイン पत्रिका.भारत を立ち上げました。
以下の例のアドレスは、拡張機能のないRFC 5321ベースのサーバーでは処理されませんが、 RFC 6530および6531のUTF8SMTP拡張機能では許可されています。これに準拠するサーバーは、これらのアドレスを処理できます。
メールボックスのローカル パートは、大文字と小文字を区別して扱われなければなりません。
、メールボックスのローカル パートの大文字小文字の区別を利用すると相互運用性が損なわれるため、推奨されません。
は、任意のアドレスで "+anystring" (拡張子を含む) の使用をサポートしています。
Wikibooksでメールアドレスを検証するWikibooksにおけるベストプラクティス
ウィキメディア・コモンズにあるメールアドレス関連のメディア