As a security person its hard as heck training (some of) our users to understand how basic domain formats work. We use a phishing simulation service, and outside of certain content,putting part or all of our company name in the domain but adding other words/underscores/etc is what tricks a lot of people. I tend to explain how it works in a basic format, and often you can see the light bulb go off when I point out how a subdomain works and why an underscore or dash creates a whole new domain anybody can register while a subdomain is something our company can only create/use (mind you, I'm not going to confuse them by explaining how this can be abused, these people i talk to about this are having enough trouble grasping the basics).

I registered .com domains with my kids' names when they were born, and when one of them discovered that they could get the email address [email protected] he was stoked. His friends don't understand how it's possible for that email address to work. As a practical joke, he always says "what do you mean? Doesn't [email protected] not work too?"

Somewhat similar to this... My full name is Tambe Barsbay, so I bought the domain mbebarsbay.com and have [email protected] as my email.

As a human who had to describe the internet, computers and email addresses to some of our older population, I agree, stuff is really hard for newcomers. Most of them barely understand the mouse abstraction, so getting them to understand some of the finer details of the modern computing world is a exercise in humongous patience.

This stuff is not really well made for normal people, to be honest. Just look at all the discussions and troubles (tickets, misunderstandings, security risks) related to email and hyperlink parsers..

It took me a while to know that FQDNs can (and sometimest must?) start at root with a period, meaning every address you've ever typed could have finished with a period (news.ycombinator.com.) and I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall. And this is a valid email address apparently: #!$%&’*+-/=?^_`{}|[email protected]

RFCs/codified norms by tech people are just weird to normal people.

Please stop downvoting this. If not an unpleasant truth, it's at least a widely held perception, which must have a reason. (And I suspect that reason is because it's true ...)

> this is a valid email address apparently: #!$%&’*+-/=?^_`{}|[email protected]

If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that.

> If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that.

Actually, no. To the best of my knowledge (and I'd be delighted to be corrected!), that's merely a convention that lots of providers (including GMail) conform to, but it's not part of the RFC or standards.

Don't get me wrong - it irritates me when that very-common behaviour isn't supported (and, at the very least, `+` shouldn't be considered an illegal character). But it's also technically-not-wrong to consider `[email protected]` as different from `[email protected]`.

It's explicitly called out in RFC5233, at least: https://tools.ietf.org/html/rfc5233

TIL, thank you!

You are right. In fact, RFC 5321 specifically forbids you from interpreting the local part of an address in any way.

> the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

See your sibling comment for another perspective! (EDIT: which, to be clear, doesn't invalidate your point. Though it's worth considering, I guess, whether "only assigned semantics by the host specified in the domain" prevents user-tracking systems from calling "[email protected]" the same user as "[email protected]". After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC?)

It's not really a different perspective. Sieve, which the sibling comment's RFC extends, is a mail-filtering script language for end-user inboxes. So it's perfectly reasonable for a user on foo.com, who knows that foo.com supports the `+` syntax, to write a Sieve script directing mail to "[email protected]" to a particular inbox.

In fact, that RFC specifically calls out that interpreting the `+` on non-local addresses is likely wrong:

> NOTE: Because the encoding of detailed addresses are site and/or implementation specific, using the subaddress extension on foreign addresses (such as the envelope "from" address or originator header fields) may lead to inconsistent or incorrect results.

EDIT to address your second point:

> After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC?

Well, technically no, the RFC is about SMTP so if you're not writing an SMTP implementation, you're not breaching it.

But RFCs aren't the law, so whether you're technically breaching it isn't really what's relevant. What _is_ relevant is that a system that treats [email protected] the same as [email protected] is making assumptions about how email works that contradict the RFCs that define how email works. Whether that's a useful thing to do in practice is an engineering decision with tradeoffs. E.g., it's probably fine to assume it for a whitelisted set of domains where you know it to be true, like gmail.

This root period was mentioned on reddit a while ago because the domain "youtube.com." would fail to serve ads.

https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_...

> I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall.

For a long time I could access Bloomberg for free because they failed open when you did this

From doing agency/marketing work for numerous large corps, I can tell you that many have a straight up block on corpname on any email name or domain to prevent phishing.

Yes, I recently got a new chromecast, which now requires a google account to set up via the google home app. I knew I was never going to use this single-purpose account for anything real so I decided to make the name very descriptive and tried to put “googlehome” in the identifier but google would not let me get away with the string “google” anywhere in it. Ended up with “GewgleHome.”

I've never seen that and I have dozens of [email protected] emails signed up.

Be careful using illegitimate car rental codes. Sometimes they look so cheap because they cancel a lot of your insurances, because your employer carries those insurances itself. So if you crash or the car is damaged, the clerk says, “Don’t worry Hertz Corporate will pick that up” but of course when they discover you are not an employee they will not.

I'm sorry, did you reply to the wrong comment? I'm trying to understand where "illegitimate car rental codes" comes from here, as I never mentioned that or anything related to it.

I agree with you, just trying to understand how it's connected to what I wrote initially.

They are talking about this line:

> Me: sure, can you remind me of the employee discount again?

Which suggests that you would/did ask for (an employee) discount code when renting from that company.

If you use a discount code, say the Boeing discount code when you rent at Seattle Airport, Hertz will cancel any insurance off the price because Boeing covers those risks itself for its employees. But, if you’re not a Boeing employee and you crash, you’re not insured by Boeing and you’re not insured by Hertz.

They are referencing the line about the employee discount.

No one wants car rental insurance anyway.

Especially not Hertz, who doesn't honor claims anyway and is thankfully bankrupt.

I fucked up a truck and they covered it without questions, I guess their customer experience was highly variable.

On just meeting a girl in school whose last name was the first name of a lead actor in a popular TV show, I started blurting out “Are you related to X” and my brain was already sending X to my mouth before I realized no, stupid, that’s not how names work.

Turns out she’s a nice girl, and she answered happily, “no, but that would be cool”. I smiled back while I died a little inside.

It’s always possible the person figures out this is not right before they get to the juicy bit. But I’ve been wrong before.

My spouse got that a lot growing up, sadly she now sometimes gets another one since she took my last name. Thankfully the new actor is not very relevant anymore so it doesn't happen often.

Same experience, though I never tried to get a discount out of it.

In that case she tried to apply the discount via my email or something like that, but she said it failed. I blamed on it that I was a new employee and I'm a rush, so nevermind, let's proceed normally.

I'm not sure I would actually accept it if it went through, but I'm always curious to see if it works sometime.

I wrote libvldmail for that: https://github.com/dertuxmalwieder/libvldmail

Sadly, it is poorly adopted.

My favourite is when the validation rejects anything with the service name in the email. I wonder whether it's to prevent somebody registering <anything>@<service> as a joke, or a really bad attempt at preventing <service>@mailinator.

Well that would have caused me problems when Oracle started requiring registration for some form of Java downloads.

They haven't spammed that though, I don't think I've ever received any actual email to the "oracleblowsgoats" address. Probably keeps any sales droids from even bothering with me as well.

It's because it is a common spam action to use <site>@<free_email> when blasting out stuff. It's also common to try and use <something>@<site> in either/or the to/reply-to fields for spambots.

So, it is easier to blacklist it altogether.

I once owned "firstname.to" I figured it would be easy to tell people my email is [email protected] and have them use it, spell it right, and remember it.

Nope. It confused the hell out of people.

Aw man, this exact situation happened to me last time I rented a car with Sixt. I wish I had thought of this genius line of yours,

> Me: sure, can you remind me of the employee discount again?

Sooo… did it work?