メールアドレスの詳細分析

• メールアドレスは単純なユーザー名とドメインの組み合わせではなく、RFC標準で定義された複雑な構造と規則、セキュリティ上の落とし穴を含む体系
• ローカルパート（@の前）には、引用符形式、コメント、Unicode など、一般には知られていないさまざまな有効形式が存在するが、ほとんどの実務環境ではサポートされていない
• すべてのメールにはEnvelope Sender と From ヘッダーという2つの送信者アドレスが存在し、この違いがスプーフィングとフィッシングの根本原因となる
• Gmail のドット（dot）無視ポリシー、プラスアドレッシング、ドメインエイリアスなど、プロバイダーごとの固有動作がセキュリティやバリデーションに直接影響する
• メールアドレスを収集または検証するシステムを構築する際は、RFC標準と実際の動作の間にあるギャップを正確に理解することが不可欠

---

基本構造

• メールアドレスはローカルパート（@の前）、@区切り文字、ドメイン（@の後）の3つの部分で構成される
• 見た目は単純でも、各部分にはセキュリティ・プライバシー・バリデーションに影響する規則やエッジケースが存在する

ローカルパート（Local Part）

• 使用可能な文字

  • 標準の非引用形式（dot-atom）で使用可能な文字: 英字 a-z, A-Z, 数字 0-9, 特殊文字 . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • 最大長は64オクテット（octet）で、標準ASCIIでは64文字と同じだが、Unicode ローカルパートでは差が生じる
    • オクテットは正確には8ビットのグループを意味し、ネットワーキング（IPv4）で 0〜255 の範囲を表すのに使われる
    • 64オクテットは512ビット長のデータブロックに相当する

• 大文字・小文字の区別

  • RFC 5321によれば、ローカルパートは技術的には大文字・小文字を区別し、[e-mail] と [e-mail] は別個のメールボックスになり得る
  • 実際には主要なメールプロバイダーはすべて大文字・小文字を区別しないため、保存・比較前に小文字へ正規化するのが安全なデフォルト
  • ドメインパートは常に大文字・小文字を区別しない

• ドット（Dot）アドレッシング

  • ドットはローカルパートで使用可能だが、3つの制限がある: ドットで始められない、ドットで終えられない、連続ドット不可
  • Gmail のドット正規化: Gmail はローカルパート内のドットを完全に無視するため、[e-mail], [e-mail], [e-mail] はすべて同じ受信トレイに配信される
    • RFC標準ではなく Gmail 固有の動作
    • 攻撃者がドット違いのアドレスで別アカウントを作成し、単一アカウント制限の回避や無料トライアルの重複取得に悪用できる実際の攻撃ベクター

• サブアドレッシング（プラスアドレッシング）

  • 区切り文字を使ってローカルパートにタグを追加でき、メールサーバーはタグを保持したまま基本アドレスへ配送する（RFC 5233 標準）
  • 最も一般的な区切り文字は + で、Gmail、Outlook、ProtonMail、Fastmail などでサポートされる
    • Yahoo の一部構成や特定の Postfix 設定では - を使用
    • qmail では = がデフォルトの区切り文字で、これが VERP で @ を = にエンコードする理由
  • 主な活用例:
    • 漏えい追跡: サービスごとの固有タグ（例: [e-mail]）で登録し、スパム受信時に漏えい元を特定
    • 受信トレイのフィルタリング: メールルールで特定タグ宛てのメールを自動分類
    • 複数アカウント: プラスを正規化しないサービスでは、1つのメールで別アカウントを作成可能
  • 多くのWebサイトのメールバリデーターは + を拒否するが、これは検証コードのバグであり、メール自体の制限ではない

• 引用文字列形式（Quoted String Form）

  • ローカルパートを二重引用符で囲むと文字制限の大半が緩和され、空白、@、連続ドット、先頭・末尾ドットなどが許可される
  • 例: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • 実際にはほぼすべてのメールプロバイダーが引用符付きローカルパートを受け付けないため、RFC上は有効でも実務では無用

• コメント（Comments）

  • 括弧内のコメントはローカルパートの先頭または末尾に置くことができ、メールサーバーが削除し、配送には影響しない
  • RFC 5322に従えば技術的には有効だが、現代では使われていない
  • 括弧を拒否するバリデーターはRFCより厳格であることを意味する

• Unicode ローカルパート（EAI）

  • RFC 6530、6531、6532で定義されたメールアドレス国際化（EAI）により、ローカルパートで UTF-8 文字が使用可能
  • SMTP セッションでは SMTPUTF8 拡張を使用する必要があり、送信・受信サーバーの両方が対応している必要がある
  • 2026年時点では採用は限定的で、Unicode 文字は2〜4オクテットを使用するため、見た目の文字数より少なくても64オクテット制限に達する可能性がある

• 歴史的な形式

  • Bang path (UUCP): DNS 以前にモデム接続された Unix マシンのネットワークで、! 区切りのホスト名経路（machine1!machine2!user）を使ったルーティング方式であり、使用可能文字一覧に ! が含まれる理由。現在は完全に廃止
  • パーセントハック（Percent hack）: [e-mail] 形式のリレー用ルーティングトリックで、% 文字はルーティング機構が RFC 5321 で廃止された後もローカルパートで依然として有効
  • ソースルーティング（Source routing）: SMTP RCPT TO コマンドで明示的なリレーホップ一覧（@relay1,@relay2:user@domain）を指定する方式。RFC 5321で廃止

• VERP（Variable Envelope Return Path）

  • 大量メールシステムで、バウンスを発生させた正確な受信者を追跡するための技術
  • 受信者アドレスをエンベロープ送信者（MAIL FROM）にエンコードし、受信者アドレスの @ を = に置き換える
    • 例: bounces+alice=[e-mail]
  • Mailchimp、SendGrid、Amazon SES などが大規模なバウンス処理に VERP またはその派生を使用

• SRS（Sender Rewriting Scheme）

  • サーバーがメールを転送する際、SPF 検査を通過させるためにエンベロープ送信者を書き換えると現れるアドレス形式
  • SRS0=HASH=TT=originaldomain.com=[e-mail] 形式
  • 複数ホップ転送時は SRS1=HASH=[e-mail] 形式
  • 構造的には有効なメールアドレスだが、インフラが生成する副産物であり、人が使うアドレスではない
  • HASH 構成要素はタイムスタンプと元のアドレスに対する HMAC で、偽造防止とトークン有効期限の制限の役割を持つ

ドメインパート (Domain Part)

• ラベル規則

  • ドメインはドットで区切られたラベルで構成され、各ラベルでは英字 a-z、数字 0-9、ハイフン - を使用可能
  • ハイフンで始まったり終わったりすることはできず、3〜4文字目の位置に連続ハイフンは不可（ただし、xn-- で始まる Punycodeラベル は例外）
  • ラベルは最大 63文字、ドメイン全体は最大 253文字、メールアドレス全体（addr-spec）は最大 254文字

• サブドメイン

  • ドメインは複数レベルを持つことができ、ドメイン全体の253文字という制限以外に、サブドメインの深さに対する厳密な上限はない
  • 一般的な用途: メールインフラ（mail.、smtp.、mx.）、組織分離（sales.company.com）、ESP送信（email.company.com）

• IPアドレスリテラル

  • ドメイン名の代わりに角括弧内のIPアドレスを使用可能: user@[192.168.1.1]、user@[IPv6:2001:db8::1]
  • RFC 5321に従えば有効だが、公開メールサーバーではほとんど受け入れられず、内部メールシステムとSMTPテスト に使われる

• 単一ラベルドメイン

  • ドットのないドメイン（例: user@localhost）は一部の文脈では技術的に有効だが、公開メールサーバーでは拒否される
  • postmaster@localhost はUnix系システムでの ローカルシステムメールにおける慣例的な特別ケース

• 国際化ドメイン名（IDN）とPunycode

  • DNSはASCII専用のため、非ASCII文字は Punycode（RFC 3492）でエンコードされ、すべてのエンコード済みラベルは xn-- 接頭辞で始まる
  • メールクライアントはネイティブスクリプトで表示し、SMTPはPunycode形式で送信する
  • ホモグラフ攻撃: 別のUnicodeスクリプトの見た目が同一の文字を使って、よく知られたドメインに似たドメインを登録できる。ブラウザには疑わしいIDNに対してPunycodeを表示する防御機能があるが、メールクライアントの多くにはこうした防御がないため、メールのほうがより効果的な攻撃対象になる

• 末尾ドット (Trailing Dot)

  • DNSではすべてのドメインは技術的にはルートゾーンを示す末尾ドットで終わるが、メールでは常に暗黙的であり省略される
  • ほとんどのバリデーターは [e-mail]. の形式を拒否する

• MXレコード

  • メールアドレスのドメインが必ずしもメールサーバーの所在先とは限らず、送信サーバーは MX（Mail Exchanger）DNSレコード を参照して実際のメールサーバーのホスト名を確認する
  • 優先度番号は低いほど優先度が高く、MXレコードがまったく存在しない場合はドメインの Aレコードにフォールバック する
  • ドメインが絶対にメールを受信すべきでない場合、null MXレコード（MX 0 .）を公開し、送信サーバーに配送を試みないよう明示的に知らせる（RFC 7505）

トップレベルドメイン (TLD)

• 元来の一般TLD

  • 初期インターネットの7つのgTLD: .com（商業、現在は無制限、Verisign運営）、.net（ネットワーク、無制限）、.org（組織、無制限）、.edu（米国認定教育機関、制限あり）、.gov（米国政府、制限あり）、.mil（米軍、制限あり）、.int（条約ベースの国際機関、非常に限定的）
  • .arpa はIANAが管理する インフラTLD で、逆引きDNS参照に使われる

• 国コードTLD (ccTLD)

  • ISO 3166-1 alpha-2の国コードに基づく2文字コードで、約250個存在
  • 一部のccTLDは他業界向けに用途転用されている:
    • .io（イギリス領インド洋地域 → テック企業）、.tv（ツバル → メディア・ストリーミング）、.ai（アンギラ → AI企業）、.co（コロンビア → .com の代替）、.me（モンテネグロ → 個人サイト）、.ly（リビア → URL短縮）、.sh（セントヘレナ → ソフトウェアプロジェクト）
  • 用途転用されたccTLDを使うと、技術的には 当該国のレジストリの管轄下 に置かれ、ICANNではなく元の国のレジストリがドメインを管理する

• スポンサー付きTLD (sTLD)

  • スポンサー組織と資格要件のあるTLD: .aero（航空輸送、SITAがスポンサー）、.coop（協同組合）、.museum（博物館）、.jobs（雇用）、.xxx（成人向け）、.post（郵便）、.cat（カタルーニャ語・文化）

• 新しい一般TLD（2012年以降）

  • 2012年にICANNが新規gTLD申請を開放し、1,200個以上 の新しいTLDが委任された
  • メールバリデーションへの重要な影響: TLD長を4〜6文字に制限する バリデーターは破綻する（.photography、.international、.construction など）
  • 開発者向け: .app、.dev、.web、.code / 商業: .shop、.store、.online / コンテンツ: .blog、.news、.media / ビジネス: .tech、.agency、.cloud
  • 新gTLDは低い登録コストと一部レジストリの弱い悪用対策ポリシーにより、スパムやフィッシングで過剰に使われる傾向 がある

• ブランドTLD

  • 2012年のICANN拡張時に大企業が独自TLDを申請: .google、.youtube、.gmail、.apple、.microsoft、.amazon、.chase、.barclays、.bmw
  • その大半は公開メールアドレスには使われず、主に 内部用途 か、まったく未使用である

• 地理・都市TLD

  • 都市や地域の独自TLD: .nyc、.london、.paris、.berlin、.tokyo、.sydney、.wales、.scot
  • 登録時には通常、その地域との 関連性の証明が必要 となる

• 国際化TLD

  • 非ASCIIスクリプトのTLDが多くの国に存在し、DNSではPunycodeでエンコードされる
    • .xn--p1ai（ロシア、キリル文字）、.xn--fiqz9s（中国、簡体字）、.xn--mgberp4a5d4ar（サウジアラビア、アラビア文字）、.xn--h2brj9c（インド、デーヴァナーガリー文字）

• 予約・文書化用TLD

  • RFC 2606、RFC 6761でテストおよび文書化のために予約されたTLD:
    • .test（公開DNSに絶対に存在しないためソフトウェアテストに安全）、.example（文書例示用）、.invalid（確実に解決されないドメインが必要な場合）、.localhost（ループバック用）
  • IANAは文書と例示用に example.com、example.net、example.org を登録しており、実在のメールボックスに届く心配なくコード例に自由に使える

• 廃止されたTLD

  • 国の消滅により削除されたccTLD: .yu（ユーゴスラビア、2010年削除）、.cs（チェコスロバキア、1995年削除）、.dd（東ドイツ、1990年削除）、.tp（東ティモール、.tl に置き換え後2015年に完全削除）
  • 例外: .su（ソ連） は1991年の解体後もなお有効なドメインが存在し、IANAが長年移行を協議しているものの、現在もアクティブな状態にある

ccTLDの第2レベルドメイン

• 多くのccTLDでは、登録可能な名前とTLDの間に機能的な第2レベルカテゴリが追加されている
  • 英国: .co.uk, .org.uk, .gov.uk / オーストラリア: .com.au, .edu.au / 日本: .co.jp, .ac.jp / インド: .co.in, .gov.in / ブラジル: .com.br, .gov.br
• メール認証システムで 組織ドメインを見つける必要がある場合、妥当性検証と組織ドメイン検出に影響する

• Public Suffix List (PSL)

  • publicsuffix.orgでコミュニティが管理する一覧で、インターネット利用者が直接名前を登録できるすべての ドメイン接尾辞 を収録
  • 公式委任（.co.uk, .com.au）と私設レジストリ（github.io, wordpress.com, herokuapp.com）の両方を含む
  • ワイルドカード記法を使用（例: *.ck）、例外は ! で示す（例: !www.ck）
  • メールバリデーターやスパムフィルターが、ドメイン文字列全体から 組織ドメインを識別 するために使用する
  • IETF標準ではないが、この問題に対する 事実上の標準（de facto standard）

メールアドレスのフォーマット形式

• 基本アドレス (Bare Address)

  • local@domain 形式の addr-spec で、SMTPコマンドや単純なコンテキストで使われる

• 山括弧形式

  • SMTPでは MAIL FROM と RCPT TO コマンドで 山括弧でアドレスを囲む: MAIL FROM:<[e-mail]>
  • 山括弧はSMTPコマンド構文の一部であり、アドレス自体の一部ではない

• 表示名形式 (Display Name Format)

  • メッセージヘッダー（From, To, Cc）では、人が読める名前を山括弧付きアドレスの前に置ける: "John Doe" <[e-mail]>
  • 表示名に特殊文字が含まれる場合は引用符が必須
  • 表示名スプーフィング: 送信者は表示名を自由に設定できるため、"PayPal Security <[e-mail]>" <[e-mail]> 形式の攻撃が可能
    • 多くのメールクライアントは受信トレイ一覧で表示名しか見せないため、最も一般的なフィッシング手法 の1つ

• グループ構文 (Group Syntax)

  • RFC 5322で定義された、複数受信者向けの名前付きグループ形式: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • 非公開受信者パターン: To: undisclosed-recipients:; — 空のグループ構文で、実際の受信者はSMTPエンベロープ（RCPT TO）にあり、メッセージヘッダーには表示されない

• エンコードされた表示名

  • 旧来のメールシステムでは、表示名の非ASCII文字をRFC 2047のエンコード語として扱う: =?charset?encoding?encoded_text?=
  • エンコードは B（base64）または Q（quoted-printable）
  • 現代の SMTPUTF8 をサポートする場合、このエンコードラッパーなしでヘッダー内で直接UTF-8を使える

すべてのメールに2つの送信者がある

• エンベロープ送信者 (Envelope Sender / MAIL FROM)

  • SMTP MAIL FROM: コマンドで設定され、メッセージ内容そのものの一部ではない
  • バウンスのルーティング に使われ、SPF検査時の検証対象であり、最終受信サーバーが Return-Path: ヘッダーとして保存する
  • envelope from、reverse path、RFC5321.MailFrom とも呼ばれる

• Fromヘッダー

  • メッセージの From: ヘッダーにあるアドレスで、メールクライアントが 送信者として表示するもの
  • DMARCがSPFまたはDKIMアライメントとともに保護する対象
  • 送信者が自由に設定でき、多くのメールサーバーでは 固有の検証がない
  • この2つのアドレスは完全に異なる場合があり、これは正常で想定されたシナリオである:
    • ESPの大量配信では MAIL FROM は [e-mail]、Fromヘッダーは [e-mail]
    • メーリングリストでは MAIL FROM はリストのバウンスアドレス、Fromヘッダーは元の投稿者
    • メール転送では転送サーバーがSRSでMAIL FROMを書き換える一方、Fromヘッダーは元の送信者を維持する
  • ドメインにDMARCが適用されていなければ、誰でも まったく無関係なMAIL FROMを使いながら、そのドメインをFromヘッダーに入れて 送信できる

• Senderヘッダー

  • メッセージの実際の送信主体がFromアドレスと異なる場合に、実際の送信者を識別する: Sender: [e-mail]

• Reply-Toヘッダー

  • 返信先を指定し、Fromアドレスと異なる場合がある
  • フィッシングベクトルとしても悪用される: 攻撃者がFromを正規に見えるよう設定し、Reply-Toを自分のアドレス に設定する

• Null Sender

  • MAIL FROM:<> は有効で重要なSMTP構造であり、空のエンベロープ送信者はバウンスメッセージ、自動応答、自身でバウンスを生成すべきでないメッセージに使われる
  • 2つのシステムが失敗通知を送り合い続ける 無限バウンスループの防止

ロールベースアドレス (Role-Based Addresses)

• RFC 5321 必須

  • postmaster@domain: RFC 5321により、メールを受け付けるすべてのドメインでこのアドレス宛メールの受信が 必須、例外なし

• RFC 2142 推奨

  • abuse@domain（スパム・不正利用の通報）、hostmaster@domain（DNSゾーン管理）、security@domain（脆弱性開示・セキュリティ報告）、webmaster@domain（Webサーバー問題）、noc@domain（ネットワーク運用）

• 慣例的なロールアドレス

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ など、公式標準ではないが広く使われている
  • ロールアドレスは通常 複数人で共有 されるため、機密情報送信時には複数のチームメンバーが閲覧できる可能性がある
  • abuse@ と postmaster@ は苦情メールを受信するため、ソーシャルエンジニアリングの標的 になる

• キャッチオールアドレス (Catch-All Addresses)

  • 特定のメールアドレス形式ではなく メールサーバーの設定 であり、特定のメールボックスが存在しないローカルパートに対しても配送を受け付ける
  • 活用例: タイプミスの捕捉、開発者テスト、正式なエイリアスシステムなしでのサービスごとの固有アドレス生成
  • 欠点: どのローカルパートでも配送されるため 大量のスパム流入 が起こり、SMTPプロービングによるアドレス有効性検証が不可能（すべてのプローブに成功応答を返す）

プロバイダー別の固有挙動

• Gmail

  • ドット正規化: ローカルパート内のすべてのドットを無視
  • プラスアドレッシング: + 区切りをサポート
  • @googlemail.com: ドイツ・英国での 商標紛争 により生まれた @gmail.com の歴史的エイリアスで、両ドメインとも同じ受信箱に配送
  • 文字制限: ローカルパートでは英字、数字、ドットのみ許可（プラスアドレッシング用の + を含む）。RFC の全文字セットは未対応
  • ローカルパート長の制限: RFC の最大 64 文字よりはるかに低い 30 文字

• Microsoft (Outlook, Hotmail, Live)

  • ドット正規化なし: [e-mail] と [e-mail] は 別個のメールボックス
  • ドメインエイリアス: @hotmail.com、@live.com、@outlook.com は、エイリアス構成時に同一アカウントを参照できる
  • プラスアドレッシング をサポート

• Apple (iCloud)

  • ドメインエイリアス: @icloud.com、@me.com、@mac.com は同じ受信箱に届く（.mac → .me → .icloud という サービス名変更の履歴）
  • プラスアドレッシング をサポート
  • Hide My Email: [e-mail] 形式の ランダムなエイリアスを生成 し、各サービスやアプリごとに固有のエイリアスで実際のアドレスを非公開に維持

• ProtonMail / Proton

  • ドメインエイリアス: @proton.me、@protonmail.com、@pm.me は同じ受信箱
  • プラスアドレッシング をサポート

• メールエイリアスサービス

  • 使い捨てメールとは別に、恒久的で制御可能な 転送アドレスを生成するサービス:
    • SimpleLogin（Proton 傘下）: カスタム・ランダムエイリアスで任意の受信箱へ転送
    • Addy.io（旧 AnonAddy）: SimpleLogin に類似、セルフホスティング可能
    • Firefox Relay（Mozilla）: 無料プランでは制限付きのランダムエイリアス
    • DuckDuckGo Email Protection: @duck.com エイリアス
  • 送信者から見ると、実際の受信箱と 構造的に見分けのつかないアドレス を生成
  • 使い捨てメールとの中核的な違い: エイリアスは恒久的で制御可能であり、特定のエイリアスの無効化、サービス別の送信確認、希望する受信箱への転送が可能

使い捨て・一時メール

• 登録不要で、通常は短期間後に期限切れとなる受信箱を提供し、Mailinator、Guerrilla Mail、10 Minute Mail、TempMail などが代表的
• 多くは キャッチオールルーティング を使うため、そのドメインのどのローカルパートでも受信箱に配送される
• 多くの受信箱が 公開 されており、アドレスを知る誰でもメッセージを閲覧できる
• 既知の使い捨てドメインのブロックリスト（disposable-email-domains GitHub リポジトリが最もよく参照される）が存在するが、常に不完全であり、ブロック回避のため 継続的に新しいドメインへ置き換え られている

バリデーション

• 技術的妥当性 vs 実務的妥当性

  • RFC 上は有効でも実際のサーバーではほとんど受け入れられないもの: 引用符内の空白(" "@example.com)、引用符内の @("user@name"@example.com)、IP リテラルドメイン(user@[192.168.1.1])、単一文字/単一ラベル(a@b)
  • RFC 上も有効で実務でも受け入れられるもの: [e-mail]、[e-mail]、[e-mail]、[e-mail]
  • ほとんどのアプリケーションでは、実用的なバリデーターが完全な RFC 準拠チェッカーより優れている: 基本構造の確認、妥当な文字セットの検証、必要に応じてドメインの DNS MX 参照を実施

• 一般的なバリデーターのバグ

  • ローカルパートで + を拒否: [e-mail] は完全に有効で、非常によくあるバグ
  • ローカルパートで _ を拒否: これも有効
  • ローカルパートで % を拒否: 有効な文字であり、廃止されたのは percent-hack ルーティングの使用だけ
  • TLD 長を 4〜6 文字に制限: .photography、.international、.construction など数百の 新しい gTLD をブロック
  • ハードコードされた TLD 一覧で検証: 一覧は継続的に変化するため、バリデーターが陳腐化する
  • 誤った総文字数制限: 254 ではなく 255 または 256 を使用。RFC 3696 正誤表番号 1690 により、広く引用されていた誤った値 320 は 254 に修正 された
  • ローカルパートで大文字を拒否: RFC 上は有効
  • [e-mail] を拒否: 有効であり、2 次 ccTLD パターンの複数ドットドメインは正常
  • .dev、.app、.io を TLD として拒否: いずれも有効に委任された TLD

• 長さ制限

  パート	制限
  ローカルパート	64 オクテット
  ドメインラベル	63 オクテット
  ドメイン全体	253 オクテット
  アドレス全体(addr-spec)	254 オクテット

• ローカルパートの制限は文字数ではなく オクテット単位 なので、マルチバイト Unicode 文字を含む EAI アドレスでは、見た目は 64 文字未満でもオクテット制限に達する可能性がある

• DNS ベースのバリデーション

  • MX レコード確認: ドメインに MX レコードがあるかを検証し、高速かつ低リスク。A レコードフォールバックを使うドメイン（MX 未設定）はこの検査に失敗する可能性がある
  • Null MX 確認: ドメインに MX 0 . がある場合、メールを 明示的に受信しない
  • SMTP RCPT TO プロービング: メールサーバーに接続して RCPT TO コマンドを発行し、アドレス受理可否を確認するが、多くのサーバーはアドレス収集を防ぐため全アドレスに 250 応答を返すため 信頼できない。キャッチオールドメインは常に肯定応答となる。プローブ IP がブラックリストに追加されるリスクもある
  • メールアドレスを完全に信頼性高く検証する唯一の方法は、実際にメッセージを送って到達を確認すること であり、それ以外はすべてヒューリスティックである

セキュリティ上の含意

• 表示名スプーフィング

  • 誰でもメールの表示名を好きなように設定でき、表示名だけを見せる受信箱ビューでは、ユーザーは実際のアドレスを明示的に確認しない限り、正規の送信者と なりすましを区別できない

• Punycode によるホモグラフ攻撃

  • 異なる Unicode スクリプトの文字を使って、実在する有名ドメインと 視覚的に同一のドメイン を登録できる
  • メールクライアントはブラウザと異なり、通常これに対する 警告を表示しない

• Gmail のドットトリックによるアカウント回避

  • Gmail はドットを無視するため、攻撃者は既存の Gmail アドレスのドット違いでサービスに登録し、単一アカウント制限の回避、無料トライアルの重複取得、本来のアカウント所有者宛てのメール受信が可能

• メールアドレスの再利用

  • メールプロバイダーが 放棄されたアドレスを新しいユーザーに再割り当て することがあり、新しいアカウント所有者が以前の所有者が登録していたサービスのアカウント復旧メールを受け取り、パスワードリセットによって アカウントを乗っ取れる可能性 がある
  • Gmail はアドレスを再割り当てしないと明らかにしているが、他の一部プロバイダーには歴史的に再割り当ての事例がある

• サブアドレスタグの露出

  • [e-mail] で登録すると、受信サービスはタグを含む完全なアドレスを確認できる
  • プラスタグを削除して保存するサービスはベースアドレスを露出させ、完全なアドレスをそのまま保存するサービスは、アカウント設定やデータエクスポートで 追跡戦略が露呈する