用語辞典・メール

ローカルパート

ローカルパートとは

ローカルパートは、メールアドレスの@より前にあり、そのドメイン内の受信先を識別する部分です。英語ではlocal-part(ローカル・パート)と呼びます。基本形local-part@ドメインのうち、@の左側です。

「ローカル」は、その意味を最終的に決めるのが@の右側のドメインパートを管理するメールシステムだからです。同じローカルパートでもドメインが違えば、無関係な受信先です。

外部の送信者はローカルパートを宛先文字列として正確に運びます。大文字・小文字、点、+以降を同一視するかは、受信側の規則を知らずに決められません。

メールが対象ドメインへ着いた後、左側の識別子を受信システム内でメールボックスや別名へ対応させるローカルパートの解釈は、そのドメインを運用する側の責任範囲
一つの組織内に三つの受信箱があり、届いた封筒を選ばれた一つの箱へ振り分けるローカルパートの役割を示すピクトグラム図解
図1ローカルパートは世界共通の利用者番号ではありません。右側のドメインと組み合わせて初めて配送可能な宛先になります。

構文、提供者の規則、実在確認を三段に分ける

文字列として書けることと、その提供者が受け付けること、実際に利用者がいることを別々に確かめる正規表現だけで有効なメールボックスまで証明することはできない
Syntax規格上の構文

dot-atomや引用形式など、メール形式として解析できる並びかを確認する

Provider提供者の受付規則

利用可能文字、点、タグ、大小文字、長さをサービス側の規則で絞る

Mailbox配送先の存在

受信サーバーがその宛先を受理し、利用者が確認できるかは別に確かめる

Alias別名・転送

一つの文字列が別の箱や複数人へ展開されても外部からは見分けられない

Identity本人との対応

受信できることは、氏名・所属・権限まで自動的に証明しない

Lifecycle作成・停止・再利用

組織の運用で有効性が変わるため、古い確認結果を永久に使わない

図2入力欄では、自社サービスが必要とする最低限の構文を検査し、本人確認が必要なら確認メールを別工程で行います。

通常はdot-atom形式だが、引用形式も規格にある

よく見るローカルパートは、英数字と許可された一部記号を並べ、点で区切るdot-atom(ドット・アトム)形式です。点を先頭・末尾に置いたり、連続させたりはできません。

RFC 5322には引用符で囲むquoted-stringもあります。空白や通常とは異なる記号を表現できますが、登録画面やメールサービスが受け付けるとは限りません。規格の最大集合と製品の受付条件を同じにしません。

大文字・小文字は、外部システムが勝手に同一視しない

SMTPではメールボックスのローカルパートを大文字・小文字を保って転送し、受信ホストだけが意味を決めます。実際の多くのサービスは区別しませんが、すべてのドメインに適用できる保証ではありません。

会員登録システムで自動的に小文字化すると、理論上は別のメールボックスを統合できます。入力値を保存し、自組織が管理するドメインにだけ既知の比較規則を使います。@右側のDNS名は大小文字を区別しないため、左右で扱いが異なります。

点の無視と+タグは、提供者固有の配送規則である

一部サービスはローカルパート内の点を無視したり、+以降をタグとして同じ受信箱へ届けたりします。これは迷惑メールの流入元整理や振り分けに便利ですが、SMTP全体の共通規則ではありません。

別の提供者では点を含む文字列が別の宛先になり、+も普通の文字として扱う場合があります。ログイン重複判定や連絡先統合で、他社の規則を推測して文字を削りません。

国際化ローカルパートにはSMTPUTF8対応が必要になる

従来のSMTPメールボックスはASCII中心でした。SMTPUTF8(エスエムティーピー・ユーティーエフエイト)拡張では、ローカルパートへUTF-8の文字を使えます。ただし送信、各中継、受信、保存、表示の対応が必要です。

対応しない中継へ単純なASCII代替表記へ変換できるとは限りません。国際化ドメインのA-ラベルと、国際化ローカルパートを混同せず、利用するサービスの対応範囲を確認します。

長さは文字数ではなく、転送時のオクテット数で制約される

SMTPの経路では、ローカルパートは最大64オクテットとして扱われます。UTF-8文字は一文字が複数オクテットになるため、画面上の文字数と一致しません。製品はさらに短い上限を設ける場合があります。

表示名、コメント、山括弧はローカルパートに含めません。メールアドレスを解析するときは、RFC 5322のメールボックス表示と、SMTPで使うaddr-specを分けます。

存在確認のために無差別なSMTP照会をしない

受信サーバーは宛先列挙を防ぐため、VRFYを無効にしたり、RCPT段階で一律に受理して後で判断したりできます。SMTP応答だけで本人の利用状況を収集しようとすると、迷惑行為や個人情報の探索になります。

構文確認、提供者規則、確認メールの受信、本人・権限の確認を目的に応じて分け、不要なアドレスを保存・公開しないことが安全です。

構文と配送の確認資料:RFC 5321「SMTP」RFC 5322「Internet Message Format」RFC 6531「SMTPUTF8」

関連用語