You Know What an Email Address Is, Right?

Wow. That is pretty tricky. I got 16/21 and I’ve been working with the Internet for decades.

Holy smokes! I spent a lot of time on validating “common” email addresses so I thought I’d do OK.

Not! Whatta nightmare!

Dave

Er, what’s our definition of valid? Is @ getting delivered to someone?

12/21. Well, at least it’s (marginally) more than 50%.

16/21 but that only means my guesses were lucky.

Ditto – 16/21 but at least four answers were blind luck!

Lovely quiz thank you Adam!

16/21, however I verified that all the claimed address-literal examples (“[…]” domain part) are categorically wrong, which irritated me because I reviewed RFC 5321, where they’re specified, before publication of that document (I was astonished to find that John Klensin was kind enough to acknowledge me in the document for some of my comments about implicit MX logic on IPv6). As an example, IPv6 address literals always use “ipv6:”, so “magic@[::1]” should actually be “magic@[ipv6:::1]”. I imagine his testing was purely based on whether the library validated in a generic way, but it certainly would not be delivered as indicated.

But, still. I was gratified to get a lot of the trickier 822/2822/5322 syntax right. I’m surprised he didn’t torment us all with group syntax (“group:[email protected],[email protected];”, or, simply, “undisclosed-recipients:;”) which is, incredibly, still used by Apple Mail when sending to distribution lists, though a lot of modern software just chokes on it in unhelpful ways. Or, there’s the good old RFC 821 (original SMTP spec) source routing: “@central.hub,@connected.gateway:[email protected]”, which was very handy for working around IP blocks even in the early 00s, but inevitably, it faded into obsolescence as the Internet and direct MX routing became the only sensible way to route mail.

Anyway, great fun, thanks for sharing. Email is a wee obsession of mine, as I’m sure you’ll have guessed by now. )

As the survey said, anything that is acceptable according to the letter of the relevant RFCs.

Whether or not you’ll find a mail server that will accept such messages is a completely separate question.

Okay, this is going to be bad.
…
I got 13/n, which is about what I’d expect.

I once tried to Google up a regex to validate email addresses, and the one that I finally found that claimed to be fully compliant wrapped around to like six lines.

Unable to take the quiz because Avast is saying the site is infected.

I got this…. What a quiz though. Gasped a few times.

Yay! You’re average! Time to start making plans for what you’ll do when an LLM takes your job.

Friend of TidBITS Paul Kafasis shared this bit in email:

An interesting note related to https://tidbits.com/2025/08/21/you-know-what-an-email-address-is-right/: HTML5 has its own definition of a valid email!

HTML Standard

This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the “@” character), too vague (after the “@” character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

It seems like HTML5 overruled the specs, and it’s widespread enough that practically, that might be a better “real” definition of a valid email address.

I love the fact that the HTML 5 spec defines a “willful violation.”

See, that’s the issue. What definition of an allowable email address is the server using? Clearly different than what the RFCs outline. If a tree falls in the…if an email address can’t actually be used, is it actually “valid”?

What issue? This isn’t a CNA exam. It’s a silly web-quiz, and the quiz explicitly states on the first page what criteria it is using.

I don’t think there is a single person on Earth who will see this site as anything more than a bit of harmless fun.

Hi! Single person here! And it’s not the quiz, it’s the fact that a valid email address might not actually, you know, be valid.

Enough with the back-and-forth. Yes, people have quibbles with some of the examples and answers, but the quiz is just meant to be a fun illustration of how wonky things can get while still theoretically adhering to a spec.

CleanShot 2025-08-22 at 17.35.43@2x1438×312 54.6 KB

XKCD summed things up concisely:

Ironically, since this is all about what’s valid and invalid, my ISP (Astound) is blocking the domain e-mail.wtf, or maybe the whole HLD, and I had to whitelist it.

I scored 8/21. Yeesh. I taught hundreds of first- and second-year university students how to use email starting in 1988. Thank goodness I’ve retired.

That makes my 11/21 not look so bad. Most of the ones that tripped me up were ones that they themselves said, “Yeah, we don’t get it either.”

A lot of these valid/invalid specs are illogical (why allow white space surrounding a segment of the address at all?) and don’t seem to serve any real purpose, especially considering that few servers will actually accept many of these “officially valid” forms. It goes to show just how much RFCs don’t tell you everything that matters.

I was highly amused by the inclusion of the fork bomb, though. Serious geek in-joke. They knew their audience.

A lot of these standards (especially the oldest ones) were written when e-mail and the Internet were two separate things.

Once upon a time, there were many mutually incompatible e-mail networks, with their own distinct address formats.

Many of those early standards for mail addressing and headers was an attempt to construct a single common header standard that could be used to forward mail between all of these different networks.

Many of the requirements that don’t make any sense today made perfect sense in a world where mail server software developers (and the RFCs they were contributing to) were trying to bridge mail messages between all these otherwise incompatible networks.

Some of these “features” have since been deprecated, because the problem they were trying to solve no longer exists, but nothing ever completely goes away.

Much like @Incompatible, I once tried to write a regex to validate and parse email addresses. It was a hair-raising experience, and I have a lot of hair. So after the first two questions of the quiz, I NOPE’d out of there right quick.

It’s not just the servers. Many entities that require an email address to be used as a username choke on my valid email address. And then there’s one that requires an email address for any new transaction, and it rejects the email address that I have used multiple times before and that it has on file.

Well, I flunked with 8/21. Had no idea you could that sort of stuff with an email address. 8-\

I bailed when I got to the first question where the “correct” answer was “valid” because it was permitted under an older RFC, even though it was changed to be invalid by a later, superseding RFC – the same RFC that the quiz claimed to be scoring against.

Quiz. Strictly according to the US constitution and its amendments, is it legal for state legislatures to appoint senators?
Me: That is illegal.
Quiz: Wrong, it was legal following the ratification of the constitution! It became illegal after the 17th amendment in 1913.

I didn’t like how, after I indicated “underscores” as valid, it explained those were actually spaces… how the heck was I supposed to do know that? And telling me they are spaces after I answer the question is just backward.

Pretty pointless quiz overall, though I guess it’s just for fun.

I’d like to see quizzes based on:

• Falsehoods programmers believe about time
• Falsehoods Programmers Believe About Names | Kalzumeus Software

(I may not have the original source of each list)

One I don’t see in the time list is the importance of getting date and time in the same call, or using a method where the underlying API is using one call. I see code that doesn’t do this; they’ll use one call to get a date (e.g. COBOL “accept from date”) and a second call to get the time. But what if the two calls are before and after midnight?

Here are the original sources for the falsehoods about time (I’ve had them bookmarked for quite some time):

• Official permalink to Falsehoods programmers believe about time
• And the sequel: More falsehoods programmers believe about time; “wisdom of the crowd” edition

Your link to Falsehoods Programmers Believe About Names is (as far as I know) the original source.

Is this an issue? Most operating systems these days (including everything Unix-derived and even classic Mac OS) don’t distinguish between date and time. The OS call returns a count of time-units since a well-known epoch.

The ISO C standard’s time() function returns an abstract time_t which on POSIX systems is a count of seconds since midnight January 1, 1970, UTC.

Although the C standard’s definition allows for other representations, it is required to be an arithmetic (integer or floating point) value that can be converted to/from real-world units using the standard library’s time functions (e.g. the localtime() and gmtime() calls).

Linux’s clock_gettime() function is similar, but with nanosecond resolution, in order to accommodate whatever accuracy/precision the computer is capable of. There are similar such functions in the C++ standard and I assume macOS and Windows APIs as well.

In other words, apps shouldn’t be getting date and time as separate calls. They should be getting a single value representing both. That value may be converted into whatever date/time units the application requires when presenting the value to the user.

Does the COBOL language not have this capability?

Some examples:

1. REXX has separate functions for date() and time(); there is no date_time function. You need to know that to get a consistent date & time together, you must make both function calls in the same expression or clause.
2. Older versions of COBOL had separate verbs for returning date and time; I don’t think there was any way to get them together. Modern COBOL can, but you have to know to use the right syntax. I frequently see programs that don’t realize this.

I bombed that test so bad.

“And now for something completely different“:

https://www.mcsweeneys.net/articles/e-mail-addresses-it-would-be-really-annoying-to-give-out-over-the-phone

Yuck. Sounds a like a gross deficiency in the language. I started skimming through a REXX reference, and it also appears that there is no way to generate a “UTC” time similar to C’s time_t, which means you end up forced to deal with nastiness like time zones, DST and leap years/seconds if you need accuracy.

When I used REXX (years ago, when I was developing OS/2 software), I primarily used it simply as an enhanced batch file language. For anything serious, where issues like this might arise, I always wrote a C program.

Do people actually write production software (not just helper scripts) in REXX?

I’m speaking as a z/OS developer with a lot of ISPF dialog development experience. I first started using TSO/E REXX [User’s Guide] [Reference] in 1990. I own Mike Cowlishaw’s REXX book – he invented the language for IBM.

As a replacement for the loathsome CLIST language, REXX is great. But it has a lot of limitations. I view it as a scripting language. Note that on z/OS, REXX is pervasive. A product that doesn’t support REXX isn’t work buying.

From what I see, the vast majority of commercial products that run on z/OS are not written in REXX. ISPF applications, where you’d think REXX would be best used, are usually C, assembler, or one of IBM’s internal PL/AS variants. (Only IBM gets to use PL/AS.) Some older applications may be PL/I. I know this because I have written a utility that scans the system load libraries and reports on the exact language and compiler version used by every program linked into every module. I haven’t seen a single instance of (compiled) REXX.

But what about customers of z/OS? In that case, they might decide to write large REXX applications. In the system I support, I’ve created a few small production steps in REXX, but only in cases where I needed the ability of REXX to interface with another product, or the REXX parsing capabilities were advantageous.

And, I support an IDE kind of system that I completely rewrote from CLIST to REXX. Its main exec is 4500 lines long. It is an ISPF application, but it isn’t 100% REXX; it uses assembler programs for things that can’t be done in REXX. (At the time the application was originally written there were limitations that would preclude using COBOL for such programs.)

That being said, I have run into monstrous REXX components of commercial applications. One is the IBM ISMF (Integrated Storage Management Facility) ISPF application. ISMF itself isn’t REXX, I think, but it has a batch reporting facility called NaviQuest which seems to be 100% REXX.

I think one reason why REXX isn’t used for production applications is that it is slow compared to the alternatives. It is especially slow at I/O. There’s no way I’d use it to read a file with millions of records – something that can be done quickly in other languages.

Worst Wifi Password Ever

[watch it with captions OFF, otherwise it spoils it]

Reminds me of the reason why SlashDot got its name. Try reading the URL to someone aloud: https://slashdot.org/

I need REXX code to generate the offset from local to UTC time, such as for generating email headers. I use this algorithm on z/OS, which always works.

/***********************************************************************
*                          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

UPDATE: It worked with Tor.

The link I see is

https://e-mail.wtf/

which the browsers don’t find.

That is the URL. The WTF top-level domain has existed since 2014, although this is the first site I’ve run across that uses it.

Norton concurrs

I’m going to go out on a limb and say that the vast bulk of those valid examples do not deserve to ever be delivered or accepted anywhere.

While I’m willing to accept anything as a name, for an email address, if you go out of your way to choose a bizzaro one that’s on you.

Agreed! Valid can be not terribly valid.

Nine! Also using internet for decades

Some were so silly that I should’ve guessed valid but tried to use logic.

At the risk of reopening the late 1990s debate on what the definition of “is” is, I’d note that your question asked whether “it is [poor word order for a question] legal.” “Is” is the present tense of the verb to be, so it is illegal.

I’d say there is a more fundamental problem with that quiz question? It isn’t clear if the question involves “strictly”, legality, the Constitution, or something else?

Yet another example of how English is continually changing? The current trend of indicating a question by adding a question mark to a declarative sentence instead of word order is moving English closer to Asian languages?

;-)

Typo, I meant to ask “is it legal…”. Fixed now.

As I was going to a client today, I passed a street called “Lee Way Court”; try telling somebody on the phone that address!

OK, for fun and the two other Regex geeks on the forum. . . .

Some years ago I wrote a freeform address recognition app, FormalAddress, (think of copying a webpage and having it find three street addresses, phone numbers, and emails and sending them to your address book). It’s off the market, now, because the cost of maintaining it came to far surpass the revenue.

Here is the simplified version of the e-mail address recognizer. It worked for years for a few thousand users and was tested against a semi-random sample of a couple hundred thousand world wide addresses.

I’ve included the documentation comments for your amusement.

# 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

Note this is not a validation regular expression. If you have unbalanced brackets in there it will still take it. For some reason many, many people don’t make sure the email address on their website is correct so we just grabbed what looks email-y and let the user fix it.

In the five or six years I was working on FormalAddress in intensive sprints I don’t think I ever saw any of the email forms in that very amusing quiz. Well, maybe once—some research lab somewhere.

Dave

FWIW. I generally recommend against trying to validate at all before use; simply send an email to it, and if the recipient responds, it’s valid. This saves a lot of grinding of teeth when a perfectly valid address is rejected because reasons—wrong reasons.

Of course, now you have to be extremely careful that you only provide the address to your email server/platform in a way that’s unambiguous, i.e. so it can’t be interpreted as anything but an email, for instance, a command line argument that undergoes no further interpretation, or an SMTP command that contains no injected parameters. But, if your development platform allows, that provides the greatest flexibility and is in many ways much cleaner than using regexes to achieve the same goal. But, it does require great care to ensure you don’t inadvertently add a security vulnerability.