私はJavaでより完全な電子メール検証ツールに取り組んでおり、「ユーザー名」と「アドレス」の両方の部分で電子メール内にコメントを埋め込む興味深い機能に出くわしました。
http://www.dominicsayers.com/isemail/からの次のスニペットには、電子メール内のコメントについての記述があります。
コメントは（これらのように）括弧で囲まれたテキストです。これらは問題ありませんが、アドレスの一部にはなりません。つまり、first.last @ example.comに送信されたメールは、first（a）.last（b）@example（c）.com（d）と同じ場所に送信されます。奇妙ですが本当です。
「google（ignore）.com」などのURLを入力しようとしましたが、Firefoxやその他のブラウザが失敗しました。これは間違っているのでしょうか、それともホスト名のコメントを知らないのでしょうか。
その構文--内のコメント--は、元の電子メールRFC、 RFC822addr-specによって実際に許可されていました。ただし、そのRFCがRFC 2822によって改訂されたとき...10年前に、コメントを使用したいようなコメントの配置は廃止されました。現在のバージョンであるRFC5322では、引き続き廃止としてマークされています。その構文を使用して何かを発行するための良い言い訳はありません。
アドレスパーサーは、ここで利用しようとしているような10年の非推奨ビットを含む、考えられるすべてのケースをカバーするために、下位互換性があると想定されています。しかし、多くの受信メールエージェントがこれらのコメントを適切に解析できないことは間違いありません。したがって、RFCの「廃止されたアドレス指定」セクションを介して技術的に抜け穴を見つけたとしても、実際にはあまり役に立たない可能性があります。
HTTPに関しては、構文規則は電子メールの構文規則と同じではありません。ご覧のとおり、RFC822のコメントセクションは適用されません。
仕様でそれができるからといって、そうすべきだという意味ではありません。たとえば、Gmailはそのコメント形式のアドレスを受け入れません。
第二に、（最後のポイントまで）電子メールアドレスで許可されている親コメントは、それらがURLに対して機能することを意味するわけではありません。
最後に、私のアドバイス：バリデーターの完全性を要件に合わせて調整します。新しいMTA（メール転送エージェント）を作成している場合は、おそらくすべてを行う必要があります。ユーザー入力用のバリデーターを作成する場合は、単純にしてください。