Hacker News Reader

Comment by NikolaNovak | Hacker News Reader

Frustratingly, in the opposite realm, I setup a really short address on my domain I wanted to use for business correspondence (b@mydomain.com), and it's astonishing how many websites/forms reject it due to being "invalid" :<

View on HN

Some years ago I realized that the last two letters of my first name is the same as a country TLD.

So I registered the domain [letters 2 to (n-2)].[TLD], giving me an email address of [first letter]@letters 2 to (n-2)].[TLD] - i.e. something in the vein of r@ebec.ca.

I thought that would be a great time saver, but to my chagrin it turns out that both computers and humans tend to have difficulty understanding such an unusual scheme.

I tried to use the @ as an A in an email address once and found it nearly impossible to relay to other humans.

I wish there were a reference set of validated C routines that corresponded to the [most important] RFCs and that everybody could be persuaded to use them.

We pretty much have this for crypto, but for everything else on the internet it still seems like the wild west.

I have such a routine for e-mail addresses:

    int is_valid_email(const char* email) {
        return strlen(email) > 0;
    }

You're welcome. Coincidentally it also works for validating people's names and addresses too.

That isn't very good. I would think better would be:

    int is_valid_email(const char*email) {
        return !!*email;
    }

But, either way, it isn't good enough, because it is considered valid even if there is no at sign. With some applications, such as email on a local system, you don't need to worry about that, but on internet, you will need to check that there is a at sign in the email address. So, better would be to check if there is a at sign, and if so, then it is considered to be valid.

Therefore, probably the best way is:

    int is_valid_email(const char*email) {
        return !!strchr(email,'@');
    }

I don't see the difference between the one that was linked and the first one you posted, other than the other one invoking undefined behavior if not passed a null-terminated string.

The difference is that it is potentially more efficient (depending what the optimizer does).

(At least, it is how I do C programming.)

I think you could reasonably go a step further and require that there be at least one character before and after the at sign. And you could probably ban ASCII control characters from appearing anywhere in the address. Depending on your needs, you might even want to try resolving the hostname or connecting to the SMTP server.

In a real-world application, you don't just want to check if an address meets an RFC; you want an address you can use throughout your application. Email addresses such as `h\@x0rz@!!!` or `\n@\0` or `@` might be RFC-compliant, but they are plainly ridiculous and would never be used by a real user. Any time/effort you spend writing tests or fixing bugs caused by permitting these esoteric addresses would be better spent on anything else.

Any time/effort you spend writing tests or fixing bugs caused by permitting whitespaces in filenames would be better spent on anything else.

Any time/effort you spend writing tests or fixing bugs caused by permitting Unicode characters in domain names would be better spent on anything else.

Any time/effort you spend writing tests or fixing bugs caused by permitting leap seconds in timestamps would be better spent on anything else.

Etc.

My favorite `""@example.com`.

The semantically empty local part ;=)

Oh and `""@[Ipv6:someipv6addres]` because who says that the domain system needs to be used.

(Disclaimer: I don't remember if it was Ipv6 or ip-v6, I would have to look that up).

I usually try a@b.com for forms I don't care about, but often have to resort to the more verbose nobody@nowhere.com when the validator complains about the former being too short...

webmaster@$whateverdomainyouresurfing is the right thing to do. Stomping on other people's domains is rude.

or just me@example.com

This sometimes gives you special/admin access. Good if you are security testing something, bad if you accidentally hack a site.

example.com and example.org were specifically reserved for testing: https://www.iana.org/domains/reserved

I've seen sites that specifically deny @example.com email addresses.

Which is perfectly reasonable. They're looking for an email address that they can reasonably expect to deliver mail to, not just an address that is technically valid.

I bet the guy who owns test.com gets a lot of interesting junk.

The domain nowhere.com is real and has MX records pointing to email-hosting.net.au, which appears to have an Exim SMTP server running. Is nobody@nowhere.com meant for public use as a fake email address, or is it just something of yours, or what?

When I need an email address for something that should not need my email address and for which I have no interest whatsoever in receiving any emails sent to, I use something @mouse-potato.com.

Mouse-potato.com was registered in 1997 by, if I remember correctly, the owner of the Seattle ISP Northwest Nexus. Northwest Nexus is long gone, but he or someone has kept mouse-potato.com alive ever since.

The MX record for mouse-potato.com points to mail.mouse-potato.com. The A record for that, www.mouse-potato.com, and mouse-potato.com all give 127.0.0.1.

Give some spammer an @mouse-potato.com address, and hopefully they send the spam from the same machine their own SMTP server is on, and so end up just trying to send it to themselves.

After he registered it, he stated publicly that it was specifically registered for Northwest Nexus customers, and anyone else who wanted to use it, for making fake email addresses.

> The domain nowhere.com is real and has MX records pointing to email-hosting.net.au, which appears to have an Exim SMTP server running. Is nobody@nowhere.com meant for public use as a fake email address, or is it just something of yours, or what?

It's just my own go-to (not-) fake e-mail. I probably tried it the first time when I was 12, and it worked, so whoever actually owns nobody@nowhere.com must be getting a lot of junk... At some point I realized the e-mail actually exists, but oh well... I figure with an e-mail like that they never expected it to be exactly private

Who knows what they intended? It's probably not very nice to load them up with extra spam just because you're lazy (? I mean really, what are you gaining here?)

I own a domain that is similar (in a "1337" way) to the domain of a CRM SaaS operation. At least once a week one of their customers signs up using my domain in a throwaway fake email address. I find it extremely frustrating. Because of their architecture and mine there is no easy way for me to filter these messages so I am often stuck with the spam in my inbox. I don't hold a grudge or anything, but I wish people would think before they fill in someone else's perfectly valid info into a form they don't want to give their own info to.

I've been rejected because i use an .link domain, so it has 4 characters and they theft emails without 3 TLD characters! Luckily I also have an .com in that case.

Reply on news.ycombinator.com