[1] 妥当な電子メール・アドレスvalid e‐mail addressおよび妥当な電子メール・アドレス・リストvalid e‐mail address listは、 HTML における電子メールのアドレスの表現方法として Web Applications 1.0 (HTML5) で規定されている構文です。

仕様書

構文

妥当な電子メール・アドレス

[3] 妥当な電子メール・アドレスは、 ABNF (STD 68) 生成規則

と一致する文字列です Web Applications 1.0。

  1. +
    1. |
      1. atext
      2. .
  2. @
  3. ldh-str
  4. *
    1. .
    2. ldh-str

[6] Web Applications 1.0 は Note (参考) で次のように述べています。

妥当な電子メール・アドレス・リスト

[4] 妥当な電子メール・アドレス・リストは、妥当な電子メール・アドレスを字句とする、 読点分離字句の集合です Web Applications 1.0。

処理モデル

妥当な電子メール・アドレス・リスト

[5] 利用者エージェントは妥当な電子メール・アドレス・リストから字句のリストを得るに当たり、 読点で文字列を分離しなければなりません Web Applications 1.0。

一部を隠して表示する

[21] セキュリティーを理由に一部を隠して表示されることがあります。 一部を隠して表示する

歴史

[8] Web Forms 2.0 ではじめて <input type=email> が規定されましたが、当時は RFC 2822 (後の RFC 5322) のものから注釈などを認めないというような記述で、 構文には特に名前は与えられていませんでした。

[9] Web Forms 2.0 の HTML5 への統合に伴い仕様書が書き直された際に、 「妥当なメール・アドレス」と呼ばれるようになりました。

[10] 更に multiple 属性が追加され、 「妥当なメール・アドレス・リスト」なる構文も定義されました。

>>9-10 の辺りの時系列は要確認です。

[11] その後定義が実用上の観点から見直され、 RFC 5322 に対する意図的違反が行われるに至りました。

[12] Web Applications 1.0 r5796 allow @localhost addresses for testing. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=5795&to=5796

関連

[7] 妥当な電子メール・アドレスや妥当な電子メール・アドレス・リストは <input type=email> の値で用いられています。

[23] [whatwg] Comments on the definition of a valid e-mail address (Ian Hickson著, ) https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Aug/0807.html

[13] About notification emails - User Documentation ( ()) https://help.github.com/articles/about-notification-emails/

In addition, there's a second Cc email address that matches the notification reason. The suffix for all of these notification reasons is @noreply.github.com. The possible notification reasons are:

[14] 「アイドルマスター ミリオンライブ! シアターデイズ」 事前登録キャンペーン |バンダイナムコエンターテインメント () https://prereg.bn-ent.net/common/serial.php?action=input&device_type=2&app=imasml_theater

__(アンダースコア連続) と --(ハイフン連続)と..(ドット連続)を含むメールアドレスではご利用いただけません。

[15] RFC 5070 - The Incident Object Description Exchange Format () https://tools.ietf.org/html/rfc5070#section-2.14

[16] RFC 7970 - The Incident Object Description Exchange Format Version 2 () https://tools.ietf.org/html/rfc7970#section-2.12

[17] GitHub Flavored Markdown Spec () https://github.github.com/gfm/

An email address, for these purposes, is anything that matches the non-normative regex from the HTML5 spec

[18] RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME () https://tools.ietf.org/html/rfc8162#section-3

[19] rfc4151, https://datatracker.ietf.org/doc/html/rfc4151#section-2.1

emailAddress

tag:

[20] 【共同発表】世界初、ミュー粒子による地下ナビゲーションに成功(発表主体:国際ミュオグラフィ連携研究機構) - 東京大学生産技術研究所 (, ) https://www.iis.u-tokyo.ac.jp/ja/news/4237/

E-mail: ht"at"muographix.u-tokyo.ac.jp

ht"at"eri.u-tokyo.ac.jp

ht"at"virtual-muography-institute.org

※3つのアドレスすべてにお送りください。

※"at"を@に変えてください。

[22] かこがわアプリ - データセット - 加古川市オープンデータAPI () https://opendata-api-kakogawa.jp/ckan/dataset/kakogawa_app

上記のメールアドレスの「●」を「@」へ、「■」を「.」へ置き換えて送付ください。

[24] Xユーザーのなるせあおとさん: 「「メールアドレス長すぎ罪」で捕まってしまった (サイレント変更ではなく事前に通知してくれるのとてもありがたい) https://t.co/bmLGG9omMa」 / X, , https://x.com/surrogatepair/status/1975773741423743430/photo/1

[25] >>24 50文字以下という制限を新たに設けたシステム。事前に通知しているだけマシではあるが、 なぜ設計段階で既存アドレスの長さを確認しなかったのか、と考えるとシステム開発の手順が根本的に間違っていることがわかろう。