メールアドレスとは何かご存知ですか?

注目の返信

1. うわあ。それはかなり難しいですね。私は16/21を取得しましたが、インターネット関連の仕事に何十年も携わっています。

2. うわあ！「よくある」メールアドレスの検証にかなり時間を費やしたので、大丈夫だろうと思っていました。

   いや！なんて悪夢だ！

   デイブ

3. えーっと、有効の定義って何ですか？@は誰かに届いていますか？

4. 12/21。まあ、少なくとも（わずかに）50%を超えています。

5. 16/21ですが、それは私の推測が幸運だったというだけです。

6. 同上 – 16/21 ですが、少なくとも 4 つの答えは運が良かっただけです。

   素敵なクイズ、ありがとうアダム！

7. 16/21ですが、主張されているアドレスリテラルの例（「[…]」ドメイン部分）はすべて完全に間違っていることを確認しました。RFC 5321で規定されているので、その文書が公開される前に確認していたため、これは私を苛立たせました（IPv6の暗黙的なMXロジックに関する私のコメントの一部に対し、John Klensin氏が文書内で私に謝辞を述べてくださったことに驚きました）。例えば、IPv6のアドレスリテラルでは常に「ipv6:」が使用されるため、「magic@[::1]」は実際には「magic@[ipv6:::1]」であるべきです。彼のテストは、ライブラリが汎用的な方法で検証されるかどうかのみに基づいていたと想像しますが、確かに指示通りには動作しないでしょう。

   それでも、822/2822/5322の扱いにくい構文の多くを正しく理解できたことには満足しています。彼がグループ構文（「group: [email protected] , [email protected] ;」、または単に「undisclosed-recipients:;」）で私たち全員を苦しめなかったのは驚きです。これは、信じられないことに、Apple Mailが配布リストに送信する際に今でも使われていますが、多くの最近のソフトウェアは役に立たない方法でこれを処理します。あるいは、古き良きRFC 821（オリジナルのSMTP仕様）ソースルーティング「@central.hub , @connected.gateway :[email protected]」もあります。これは2000年代初頭でさえIPブロックを回避するのに非常に便利でしたが、インターネットと直接MXルーティングがメールをルーティングする唯一の合理的な方法になったため、必然的に廃れていきました。

   とにかく、とても楽しかったです。シェアしてくれてありがとう。もうお分かりでしょうが、私はメールにかなり夢中です。

8. 調査で述べられているように、関連する RFC の文言に従って許容されるものであれば何でも構いません。

   そのようなメッセージを受け入れるメール サーバーが見つかるかどうかは、まったく別の問題です。

9. よし、これはヤバい。
   …
   13/n が出ました。予想通りですね。

   以前、電子メール アドレスを検証する正規表現を Google で検索しようとしたのですが、最終的に完全に準拠していると主張していた正規表現は、6 行ほどに折り返されていました。

10. Avast によりサイトが感染していると報告されているため、クイズを受けることができません。

11. わかったよ…でも、すごいクイズだった。何度か息を呑んだ。

    やった！君は平均的だね！法学修士（LLM）に職を奪われたらどうするか、計画を立て始める時期だね。

12. TidBITS の友人 Paul Kafasis が電子メールでこの一文を共有してくれました:

    https://tidbits.com/2025/08/21/you-know-what-an-email-address-is-right/ に関連する興味深いメモ: HTML5 には、有効な電子メールの独自の定義があります。

    HTML標準

    この要件は、電子メール アドレスの構文を定義する RFC 5322 の意図的な違反です。この構文は、厳しすぎる (「@」文字の前)、曖昧すぎる (「@」文字の後)、緩すぎる (コメント、空白文字、引用符で囲まれた文字列をほとんどのユーザーに馴染みのない方法で許可する) ため、ここでは実用的ではありません。

    どうやら HTML5 が仕様を無視したようで、十分に普及しているため、実際には、これが有効な電子メール アドレスのより適切な「実際の」定義になるかもしれません。

    HTML 5 仕様で「故意の違反」が定義されている点が気に入っています。

13. ほら、そこが問題なんです。サーバーは、許可されるメールアドレスの定義をどうしているんでしょうか？RFCで定められているものとは明らかに違います。もし木が倒れたとして…もしメールアドレスが実際に使えないなら、それは本当に「有効」なのでしょうか？

14. 何が問題なの？これはCNA試験じゃない。くだらないウェブクイズだし、そのクイズの最初のページに、どのような基準で出題されているかが明記されている。

    このサイトを、無害な楽しみ以上のものとして見る人は、地球上に一人もいないと思います。

15. こんにちは！独身です！クイズの問題ではなく、有効なメールアドレスが実際には有効ではない可能性があるという事実についてです。

16. もうこれ以上の議論は終わりにしましょう。確かに、例や解答の一部には異論もあるでしょうが、このクイズは、理論的には仕様に沿っていながらも、物事がいかに不自然になり得るかを楽しく例示するためのものです。

17. XKCD は簡潔にまとめています:

    

18. 皮肉なことに、これはすべて有効と無効に関するものなので、私の ISP (Astound) はドメイン e-mail.wtf、またはおそらく HLD 全体をブロックしており、ホワイトリストに追加する必要がありました。

19. 21点中8点でした。うわあ。1988年から何百人もの大学1年生と2年生にメールの使い方を教えてきました。退職してよかった。

20. おかげで、私の11/21はそれほど悪くないように見える。私がつまずいたのは、ほとんどが彼ら自身から「ええ、私たちも分かりません」と言われたことだ。

    有効／無効の仕様の多くは非論理的で（そもそもアドレスの一部を空白で囲むことをなぜ許可するのか？）、特にこれらの「公式に有効な」形式の多くを実際に受け入れるサーバーがほとんどないことを考えると、実質的な意味をなしていないように思われます。これは、RFCが重要な情報をすべて提供していないことを如実に示しています。

    でも、フォーク爆弾が入っていたのにはすごく面白かったです。真面目なオタクの内輪ネタですね。彼らは自分のオーディエンスをよく分かっていました。

21. これらの標準の多く (特に最も古いもの) は、電子メールとインターネットがまだ別々のものだった時代に作成されました。

    かつては、互いに互換性がなく、それぞれ独自のアドレス形式を持つ電子メール ネットワークが数多く存在していました。

    メールのアドレス指定とヘッダーに関する初期の標準の多くは、これらすべての異なるネットワーク間でメールを転送するために使用できる単一の共通ヘッダー標準を構築しようとする試みでした。

    今日ではまったく意味をなさない要件の多くは、メール サーバー ソフトウェア開発者 (および彼らが貢献した RFC) が、互換性のないすべてのネットワーク間でメール メッセージを橋渡ししようとしていた世界では完全に意味をなしていました。

    これらの「機能」の一部は、解決しようとしていた問題が存在しなくなったため廃止されましたが、完全になくなるものはありません。

22. @Incompatible さんと同じように、私もかつてメールアドレスを検証・解析する正規表現を書こうとしたことがありました。髪の毛がすごく多いので、本当にゾッとする経験でした。だから、クイズの最初の2問を終えた時点で、すぐに「NO！」と諦めてその場を立ち去りました。

23. サーバーだけの問題ではありません。ユーザー名にメールアドレスを必要とする多くのサービスが、私の有効なメールアドレスで処理を妨げています。さらに、新規取引にメールアドレスを要求するサービスもあり、以前何度も使用し、登録されているメールアドレスでも拒否されてしまいます。

24. えっと、8/21で落第しちゃったんです。メールアドレスでそんなことができるなんて知りませんでした。8-\

25. 最初の質問で「正しい」答えが「有効」だったため、古い RFC では許可されていたものの、その後の、このクイズが採点対象と主張していた同じ RFC によって無効に変更されたという時点で、私は諦めました。

    クイズ。アメリカ合衆国憲法とその修正条項に厳密に従うと、州議会が上院議員を任命することは合法ですか？
    私：それは違法です。
    クイズ：違います。憲法の批准後は合法でした！ 1913年の第17次修正以降は違法になりました。

26. 「アンダースコア」を有効だと表示した後、実際にはスペースだと説明されたのが気に入りませんでした…一体どうしたらそんなことが分かるというのでしょう？質問に答えた後にスペースだと教えられるのは、全く逆です。

    全体的にあまり意味のないクイズですが、ただの楽しみのためだと思います。

27. 以下の内容に基づいてクイズを見たいです:

    • プログラマーが時間について信じている虚偽
    • プログラマーが名前について信じている虚偽 | Kalzumeus Software

    （各リストの元のソースがない可能性があります）

    時間リストに見当たらないのは、日付と時刻を同じ呼び出しで取得すること、あるいは基盤APIが1つの呼び出しで取得するメソッドを使うことの重要性です。これを行わないコードも見かけます。それらのコードは、日付を取得するために1回目の呼び出し（例えばCOBOLの「accept from date」）を使用し、時刻を取得するために2回目の呼び出しを使用しています。しかし、2回の呼び出しが深夜0時前と深夜0時以降の場合はどうなるのでしょうか？

28. 時間に関する虚偽の元の情報源は次のとおりです (かなり長い間ブックマークしていました)。

    • プログラマーが時間について信じている虚偽への公式パーマリンク
    • 続編：プログラマーが時間について信じているさらなる嘘「群衆の知恵」編

    「プログラマが名前について信じている虚偽」へのリンクは (私の知る限り) オリジナルのソースです。

    これは問題でしょうか？最近のほとんどのオペレーティングシステム（Unix系OSやクラシックMac OSも含む）は日付と時刻を区別しません。OSの呼び出しは、既知のエポックからの経過時間を返します。

    ISO C 標準の関数は、POSIX システムでは 1970 年 1 月 1 日の午前 0 時 (UTC) からの秒数であるtime()抽象値を返します。time_t

    C 標準の定義では他の表現も許可されていますが、標準ライブラリの時間関数 (および呼び出しなど) を使用して実際の単位との間で変換できる算術値 (整数または浮動小数点) である必要がありlocaltime()ますgmtime()。

    Linuxのclock_gettime()関数も同様ですが、コンピュータの精度に対応するためにナノ秒単位の解像度で動作します。C++標準にも同様の関数があり、macOSとWindowsのAPIにも同様の機能があると思います。

    つまり、アプリは日付と時刻を別々の呼び出しで取得するのではなく、両方を表す単一の値を取得する必要があります。この値は、アプリケーションがユーザーに値を提示する際に、必要な日付/時刻の単位に変換されます。

    COBOL 言語にはこの機能がないのでしょうか?

29. 例:

    1. REXXにはdate()とtime()という別々の関数があり、date_time関数はありません。日付と時刻を一貫して取得するには、両方の関数を同じ式または句で呼び出す必要があることに注意してください。
    2. 以前のバージョンのCOBOLでは、日付と時刻を返す動詞が別々に存在していました。これらを組み合わせる方法はなかったと思います。最近のCOBOLでは可能ですが、正しい構文の使い方を知っておく必要があります。この点を理解していないプログラムをよく見かけます。

31. うわあ。言語に重大な欠陥があるみたいですね。REXXのリファレンスをざっと見てみましたが、C言語のような「UTC」時刻を生成する方法はないようですねtime_t。つまり、正確さを求めるなら、タイムゾーン、夏時間、閏年／秒といった厄介な問題に対処しなければならないということですね。

    REXXを使っていた頃（何年も前、OS/2ソフトウェアを開発していた頃）、私は主に拡張バッチファイル言語として使っていました。今回のような問題が発生する可能性のある本格的な作業には、常にC言語を使っていました。

    実際に REXX で製品版ソフトウェア (ヘルパー スクリプトだけではなく) を作成する人はいるのでしょうか?

32. 私はISPFダイアログ開発の豊富な経験を持つz/OS開発者としてお話しします。TSO/E REXX [ユーザーズガイド] [リファレンス] を初めて使い始めたのは1990年です。IBM向けにこの言語を開発したMike Cowlishaw氏のREXX書籍も所有しています。

    忌々しいCLIST言語の代替として、REXXは素晴らしいものです。しかし、多くの制限があります。私はこれをスクリプト言語として捉えています。z/OSではREXXが広く普及していることに注意してください。REXXをサポートしていない製品は、購入する価値がありません。

    私が見た限りでは、z/OS上で動作する商用製品の大部分はREXXで書かれていません。REXXが最もよく使われると思われるISPFアプリケーションは、通常C、アセンブラ、またはIBM社内のPL/ASバリアントのいずれかです（PL/ASを使用できるのはIBMだけです）。古いアプリケーションの中にはPL/Iで書かれているものもあります。これは、システムロードライブラリをスキャンし、各モジュールにリンクされているすべてのプログラムで使用されている言語とコンパイラーのバージョンを正確に報告するユーティリティを作成したことがあるからです。REXX（コンパイル済み）のインスタンスを1つも見たことがありません。

    しかし、z/OSのお客様はどうでしょうか？その場合、大規模なREXXアプリケーションを作成することに決めるかもしれません。私がサポートしているシステムでは、REXXでいくつかの小規模な本番環境ステップを作成しましたが、それはREXXを他の製品とインターフェースさせる必要がある場合、またはREXXの解析機能が有利な場合に限られていました。

    また、IDEのようなシステムもサポートしています。これはCLISTからREXXに完全に書き直したものです。メインのexecは4500行あります。ISPFアプリケーションですが、完全にREXXではありません。REXXではできない処理はアセンブラプログラムで実行しています。（このアプリケーションが最初に作成された当時は、このようなプログラムにCOBOLを使用できない制限がありました。）

    とはいえ、商用アプリケーションのREXXコンポーネントがあまりにも酷いことに遭遇したことがあります。その一つがIBMのISMF（Integrated Storage Management Facility）ISPFアプリケーションです。ISMF自体はREXXではないと思いますが、NaviQuestというバッチレポート機能があり、これは完全にREXXでできているようです。

    REXXが実稼働アプリケーションで使われない理由の一つは、他の言語に比べて処理速度が遅いことだと思います。特にI/Oが遅いです。数百万件ものレコードを含むファイルの読み取りにREXXを使うなんて考えられません。他の言語ならすぐにできるのに。

33. 史上最悪のWi-Fiパスワード

    [字幕をオフにしてご覧ください。そうでないとネタバレになります]

    

34. SlashDotの名前の由来を思い出しました。URLを誰かに声に出して読んでみてください。https://slashdot.org/

35. メールヘッダーの生成など、ローカル時刻からUTC時刻へのオフセットを生成するためのREXXコードが必要です。z/OSではこのアルゴリズムを使用しており、常に正常に動作します。

    /***********************************************************************
    * time_zone *
    * Calculate the local timezone offset from MVS system variables *
    ***********************************************************************/
    time_zone: procedure days_different = mvsvar('SYMDEF','LYR4') - mvsvar('SYMDEF','YR4') if days_different = 0 then days_different = mvsvar('SYMDEF','LJDAY') -, mvsvar('SYMDEF','JDAY') hours_different = mvsvar('SYMDEF','LHR') -, mvsvar('SYMDEF','HR') + (24 * days_different) min_different = right(abs(mvsvar('SYMDEF','MIN') -, mvsvar('SYMDEF','LMIN')),2,'0') sign = substr('+-',(hours_different < 0)+1,1) return sign || right(abs(hours_different),2,'0')min_different
    

36. 更新: Tor で動作しました。

    私が見たリンクは

    https://e-mail.wtf/

    ブラウザでは見つけられません。

37. これがURLです。WTFトップレベルドメインは2014年から存在していますが、このドメインを使用しているサイトは初めて見ました。

38. ノートン氏も同意

39. 私はあえて言いますが、それらの有効な例の大部分は、どこにも伝えられたり受け入れられたりするに値しません。

    名前やメールアドレスについては、何でも受け入れますが、わざわざ奇妙な名前を選ぶのはあなたの責任です。

40. 同意です！有効だからといって、必ずしも有効であるとは限りません。

41. 9つ！インターネットも何十年も使っています

    いくつかは非常にばかげていて、有効だと推測すべきでしたが、論理を使用しようとしました。

42. 1990年代後半に起きた「is」の定義に関する議論を蒸し返す恐れはありますが、あなたの質問は「[疑問文としては不適切な語順]合法か」という問いかけだったことを指摘しておきます。「is」はbe動詞の現在形なので、違法です。

43. このクイズの問題にはもっと根本的な問題があると思います。「厳密に」なのか、合法性なのか、憲法なのか、それとも何か他のことなのか、はっきりしません。

    英語が絶えず変化していることを示す、もう一つの例でしょうか？ 平叙文に疑問符を付けて疑問を表すという最近の傾向は、英語をアジアの言語に近づけているのでしょうか？

    ;-)

44. タイプミスです。「合法ですか…」と聞きたかったのですが、修正しました。

45. 今日、顧客を訪問する際、「Lee Way Court」という通りを通りました。電話で誰かにその住所を伝えてみてください。

46. OK、楽しみのため、そしてフォーラムの他の 2 人の Regex オタクのために...

    数年前、私は自由形式の住所認識アプリ「FormalAddress」（ウェブページをコピーして、3つの住所、電話番号、メールアドレスを検出し、アドレス帳に送信するアプリ）を開発しました。しかし、維持費が収益をはるかに上回ったため、現在は販売を終了しています。

    メールアドレス認識ツールの簡易版をご紹介します。数千人のユーザーを対象に長年にわたり動作し、世界中から数十万件のアドレスを半ランダムに抽出してテストされました。

    皆さんの楽しみのためにドキュメントのコメントを記載しました。

    # Python flavor of grep.
    # V4 20170302 Yeesh. Let's add all sorts of RFC characters nobody
    # uses and watch performance plummet.
    # V4 20180112 changed TLD to accept unlimited length
    # (Sheesh, I'm so eighties...) (?<!\.)([-\w.&*~#+%!{}]+)\x20?@\x20?([-a-zA-Z0-9]+\.)+[a-zA-Z]{2,} # Case Insensitive and Multi line
    

    これは検証用の正規表現ではないことに注意してください。括弧が不揃いであっても、そのまま認識されます。何らかの理由で、多くの人がウェブサイト上のメールアドレスが正しいことを確認していないため、メールアドレスらしきものを取得し、ユーザーに修正してもらうようにしています。

    FormalAddress に5、6年間集中的に取り組んでいた間、あのとても面白いクイズのメールフォームを一度も見たことがなかったと思います。まあ、どこかの研究室で一度だけ見たことがあったかもしれませんが。

    デイブ

47. 参考までに。一般的に、使用前に検証を試みることはお勧めしません。単にメールを送信し、受信者が返信すれば有効と判断されます。こうすることで、完全に有効なアドレスが、間違った理由で拒否された場合に、歯ぎしりせずに済むからです。

    もちろん、メールサーバー／プラットフォームにアドレスを提供する際は、明確な方法でのみ、つまり、メール以外の何物にも解釈されない方法でのみ、細心の注意を払う必要があります。例えば、それ以上解釈されないコマンドライン引数や、挿入されたパラメータを含まないSMTPコマンドなどです。開発プラットフォームが対応していれば、柔軟性が最も高く、多くの点で正規表現を使用して同じ目的を達成するよりもはるかにクリーンです。ただし、セキュリティ上の脆弱性を誤って追加しないように、細心の注意を払う必要があります。