If it was about being able to spam, they'd just silently strip the + part. I think it's just ignorance ... in my own mailserver I have a custom separator that usually doesn't trip validation functions.
This assumes the “+” is not a trick to see if they are stripping the “+” from the username of the email address; which then is automatically flagged as SPAM. Of course this assumes you’re creating a new email per contact, not just using a feature that was never intended as a anti-spam tool.
This is intentional. It's because the people who own the site know the gmail <realemail>+thisisspam@gmail.com trick and they prevent people using that trick.
I have only a handful of addresses on my machine so implemented the letter ‘f’ as the selector (none of the usernames nor various full name aliases have that letter in them). I really doubt any spammer could screen that out :-)
DNS label name limit is 63 characters, and total length limit 255 (or thereabouts). Maybe newer implementations allow longer names, you'd have to test though.
Going further actually breaks some browsers (Firefox can handle longer than Internet Explorer for example), breaks web servers because they log the full version before it is transformed, and even acts as a fingerprinting vector. The limit is usually in the several hundred kilobyte range, and depending on the way that the underlying operating system handles it, things get seriously broken very quickly.
In Firefox, when I hover over http://3494943456/ it displays as http://208.80.154.224 in the lower left, as does 1844... and 197690..., BUThttp://7789910752/ displays as exactly that string. It likewise navigates to the first, third, and fourth links but breaks on your second.
Way back in high school I used to use decimal ip addresses to bypass the network content filter. It doesn't work as well these days as so many sites are virtual hosted.
The continuous discussion about "thereabouts" is because the 255 bytes limit applies to encoded name fields (in DNS messages), not domain names as we usually write them in dotted format.
Since the encoded format is that each label is preceded by its length and the whole domain ends by 'root' (i.e. 0x00) this means that domains names as we usually write them are limited to 253 bytes, including the dots (we don't write the 'root' label and label lengths are replaced by dots except the first one, that's 2 bytes to subtract from 255).
> Each FREE mailbox account comes with 25MB of storage capacity, which is a lot more than what is offered by most free email providers. This can allow you to store over 250,000 email messages.
This has not aged well since 2003. The amount of bloat in emails now is quite high since everybody who sends emails wants to use HTML with embeds while also inserting tracking pixels, images, links, etc.
1. Using a link like in a normal website => might not load.
2. Using a data uri => increases mail size, there is no rfc as far as I know which states that this even had to be supported.
3. Using a cid , link as specified by the mail rfc => increased size and more complex (you basically put a link in the http body which refers to another body in the multiparty/mixed body it's in by the unique cid. Which is supposed to be works unique but quite to often is not.
Gmail blew our collective minds when they started with, what, 1 GB free? And the gimmicky counter on the login page showing increasing storage free forever at some rate of a few more kilobytes per second.
As I recall, it was common to have 10 MB inbox storage for free email accounts around that time.
Note that comments are only valid in mail headers, but not smtp.
Generally even besides CFWS related differences there are some differences in between which email addresses SMTP allows and which are allowed in mail headers....
Lastly given that quoting in the local part as well as some special forms of the domain part are not supported by most programs it's often sensible to reject them, i.e. treat them as invalid even through technically they are not. (But you really should support internationalized mails!)
No more, no less. Although "server" here also includes anything in-between that may barf on a local part or (sometimes) even a domain name it doesn't like. For example, some forms don't like emails to top level domains.
In the email addressing standard (RFC 5321), the brackets means it's an IP address literal. If you add in an IPv6 tag (e.g., [IPv6:1::1]), you get IPv6 support as well.
Ah yes, you can use an IP address instead of a domain! I'd completely forgotten about that because nowadays it's so very unlikely to work with anything.
Yahoo! Mail always has supported a space in the local part because David Filo wanted to ensure it was supported. His @yahoo.com email address had a space in it to ensure that he’d know if it was ever broken.
And for good reason. Were I in charge of the project budget, I wouldn't be blowing good dev money on implementing some RFC circle-jerk that no real user will ever use except in a geek pissing contest. Our collective Venn diagrams of what an email address "ought to look like" have a big enough intersection that we can probably do without such silliness.
I have my own e-mail addresses at rhabarberbarbarabarbarbarenbartbarbierbierbar.com that I use for fun and testing form validation. It is surprisingly rare that I find sites that break over it.
Hah! I was just showing that video to a friend last night.
I used to have myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com and I used it for quite a bit of testing too. Broke all sorts of things, either because of length or multiple levels of subdomain or who knows what.
I'd love a service that gives you all sorts of peculiar-but-valid addresses for testing... hmm. Is there a market here?
I've seriously considered getting some long and meaningless domain (although not that long) for some serious use. I'd probably go with something like a prefix of 'm' (for "mail") followed by 64 random bits in hex, so something like m95aaa5aea09bdc67.com.
Addresses there would only be used as the recovery addresses for vital services such as bank and brokerage accounts, domain registrar accounts, telephone company accounts, and mail hosting accounts, and that's probably all.
By "recovery address" I mean the address that the service provider will use if someone initiates an "I forgot my password and lost my 2FA device!" password reset. It's any address that if someone takes control of they can take over your account at that service starting from at most your user name on that service.
Why a meaningless name like m95aaa5aea09bdc67.com? To minimize the risk of someone coming in and trying to take it over via a trademark dispute. For this I want domain name that I can be very sure I can keep as long as the current domain system is still in place.
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" :<
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...
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.
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 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.
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.
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.
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'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.
I solve the spam problem by having my own domain with an infinite number of email addresses. Whenever I sign up for something I use $PERMUTE@mydomain.com, where PERMUTE is some easily-reversible permutation of the vendor's own name.
This has two benefits: I can easily route/filter incoming email from that vendor, and if I ever receive spam at that address I know which vendor sold my info.
Fastmail also has a catch all / wildcard option which I am using. You don't need to create aliases for every email; instead any email to *@mydomain.com goes to my single email inbox. And similarly I can send from anything@mydomain.com.
I use a subdomain for it. Anything to that subdomain is marked as read and filed in the "spam-adjacent" folder. I'll look in there for transactional stuff and marketing bs never increments my unread counter. Only real people appear in my actual inbox and it's basically email nirvana.
The way I do it is I use a subdomain for any aliased email, e.g. vendor.com@account.mydomain.com and then I just have rules to move anything sent to account.mydomain.com to a separate folder, then it never shows up in the main mailbox unless I put it there myself. Works fine!
I do it with the free email address that comes with my domain name. In this case I'm using gandi.net but I'm sure most domain name providers have a similar deal.
Fastmail supports "subdomain addressing" out of the box. So if the email address is ... user@domain.com ... then you can use ... <anything>@user.domain.com ... without setting up any extra aliases, Fastmail will just handle it as if it's for user@domain.com.
And you can also reply from such addresses without extra configuration. On the desktop I use MailMate as my email client, which works great with dynamic aliases. The win is that you don't have to configure anything extra when signing up for some online service.
You can do this in Google Suite btw, as you can configure a forwarding rule. The problem with Google Suite, last time I tried, is that they no longer want to sign emails with DKIM for such dynamic aliases, so you can receive emails just fine, but sending emails from such addresses is a problem if you have SPF/DKIM domain rules.
One Fastmail alias can be "(asterisk)@domain.tld", by the way, so you can send and receive emails to every address possible. When you send an email from the (asterisk) alias, you can type whatever you want in the from address box. I use their DNS as my primary DNS for all my domains so I can email to/from all of them easily like this.
(asterisk) means the character itself, I can't figure out how to type one on this site though.
Edit: this wasn't a feature 3 years ago, I only discovered this 4 months ago when I added a few domains to my account and they added the (asterisk) aliases for those automatically.
You could do subdomain aliasing instead (with Fastmail, or with Google Suite if you try hard enough) and there's no way to detect and strip that, since it looks and feels like a normal address.
myemail.youtube@gmail.com would go to myemailyoutube@gmail.com (or my.email.you.tube@gmail.com). Gmail's email normalization is like: sed -e s/[+].*//g -e s/[.]//g
Not exactly so, dot in address is just ignored by gmail, so “myemail.youtube“ is equivalent to “myemailyoutube“, not to “myemail“. Plus sign works as you described.
The nonstandard dot behavior turned out to be a really bad idea. I've had numerous instances of people signing up for other services (e.g. Amazon) with my gmail address, adding various dot combinations. Whenever I have contacted Amazon (or others) to report a security issue--that I have access to someone else's account because "their" email address is routed to me, I just end up having a really unproductive conversation.
Yes. easyDNS offers this service. They call it a "catch all mailmap." You also need your "real" mail server ISP to be okay with getting unlimited addresses forwarded to them. Some ISPs don't like it because it makes SPF more difficult.
I've seen a lot of people doing this. Maybe we should have a public database of what company sold emails to who that everyone who did this can contribute to, with some kind of proof required.
Difficulty there is that many vendors are victims of data breaches, so they perhaps don't deserve to be demonized quite as much as if they'd outright sold the data. Could be difficult to prove which side of Hanlon's Razor they fall on.
That should depend on whether they informed the affected customers that their data was leaked in a breach or (if they weren't yet aware of the breach) how they react to the news that they have been breached.
If a company has a data breach, they most likely still have a security problem. While they may actually be victims if any 3d party software is exploited, it still comes down to system misconfiguration inany cases. And that would still be their fault.
That's a great idea. I do the same thing as the parent poster, and I've seen lots of email addresses compromised. If it's one that I care about, I will contact the company. (Last time it was Tektronix, before that it was Roku.) They usually deny that it could have been on their end, which is BS because nobody besides them ever had the email address (assuming I wasn't hacked locally). The most common scenario is the insider threat. Some low-paid IT person with access to their database sells the list for a few tens of dollars.
I do the same and in addition to reselling of personal information, it also shows when there was a data breach, as a whole bunch of spam starts pouring in the ones that are breached. Sometimes before an official announcement is made as the case was with Adobe.
I used to do this, and recall one particularly irate call from someone asking "why is my company name in your e-mail address!?!" They seemed to be concerned that I was impersonating them.
That's why I permute it, so it's not so blatantly obvious. OTOH most email signup handlers are robots nowadays and no real human ever pays much attention to them, so it hasn't really been a problem for me.
I do this as well using a not so well know trick that exists on most major email providers including gmail and iCloud: myemail+permute@icloud.com. Those emails will arrive at myemail@icloud.com
I have a site with users, and while we have no interest in selling their addresses, it still strikes me as futile when people add "+mysite" to their address. It would take me 2 seconds in excel to zap all those appendages.
Not everybody uses the scheme for some futile security purpose, some sites are just a bit annoying with their outgoing addresses with their non-nefarious communication and the + scheme can be a nice way for rules.
I do it too. I've found some vendors that will not allow their company name in the email address. For example, samsung@mydomain.com cannot be used to register with any Samsung-operated service.
I will answer, since I have been following this strategy for almost 20 years.
In my experience, very, very few companies sell email addresses. Maybe 1% or fewer. The vast majority of spam tied to company-specific addresses is the result of data breaches. I get spam to my (old) linkedin, dropbox, equifax addresses - all starting after they were hacked.
I do this too, and this is also my experience. In fact, at first I expected my ad-hoc email addresses to be the target of a good amount of spam, but I was surprised to find this almost never happens.
I have to concur. The spam I'm getting only comes to aliases I published on some public-facing site. So I get a lot of spam for fb@, and hn_work@ (used in "Who wants to be hired?" posts), but surprisingly not hn@ (which is in my profile) or hello@ (used on my website). I don't think I got spam for any alias I used only to register an account with some vendor.
I did this for a while. I gave up because it just wasn't worth the effort. I would run into exceptions to my permutation rule maybe. Or I signed up for an account and forgot which email I used so couldn't reset the password. Things like that.
> This has two benefits: I can easily route/filter incoming email from that vendor, and if I ever receive spam at that address I know which vendor sold my info.
There's just nothing actionable to do with this information. OK, so I caught badcompany.com giving my email address to marketingfirm.com. But the damage is already done. Sure, I can send them a nasty email, but it'll just get ignored or whatever.
I just started generating random addresses and putting them in password manager. The actionable bit is permanently black-holing all incoming mail to that address if/when I no longer need the service, or the "spam" rate gets too high.
I use gmail, so I just use the "Report as spam" option. I'm assuming Google uses that information in some way when calculating spam scores. So if enough people do the same, those emails will just start getting sent to spam automatically for huge amounts of people, and therefore punishing those folks for doing it in the first place. That seems more effective to me.
And I just never really had that big of an issue with spam where I needed to black-hole a specific email address. So for me it just wasn't worth the effort.
People using "report as spam" is what made gmail such a great spam filter. Is also the reason google has such high market share of public email addresses. It's also why people running their own mail servers are afraid of being blacklisted by google.
Yesterday I used the report as spam feature on an email from Microsoft.
The footer had no unsubscribe option and the "manage communication preferences" requires a login/password combo that I couldn't be bothered to reset for my new geolocation.
I doubt this'll make a dent in Microsoft.com's spam score.
More than 3 years ago I moved from a single gmail address that had a ton of spam, to a Fastmail wildcard domain with a rule for each individual/company that emails me. I use a randomly generated, 7-character username created from a-z and 0-9 for each address, stored in my password manager. eg. The email address for my Reddit account might be rkd64id@example.com.
While I think this scheme is perfection in terms of privacy and security in knowing which company sells or breaches my email address... the fact is I haven't gotten a single unsolicited email in the entire 3+ years. Not a single message that hit a spam/junk filter, and not one email that wasn't expected based on whitelisted rules. The closest exception is Amazon who shares your email address with their shippers for delivery notifications; while I do receive 3rd party mail regarding legitimate Amazon deliveries, I've never received any spam to that Amazon address.
I have come to a conclusion as to why I have never received a single spam email since switching to this scheme. When I transitioned my GitHub account away from the old gmail address, I used the privacy option to not publish my REAL email address in Git logs pushed to GitHub. I deleted my old repos, and re-imported using the GitHub-wrapped email address. Thus I surmise that for those of us who are developers pushing code to public Git repositories, the vast majority of the spam you receive is because your email address can be very easily scraped from those Git logs.
I expect to migrate back to a single email address in the future, for a singular reason: as I get older I cannot imagine managing these email filters and password manager entries. Eventually I will need to simplify things.
I don't think it's quite that simple. Ignoring the fact that I'm not in the EU, the company would also have to have some sort of presence in the EU for that to have any effect. And then which company do I send it to? The original one? Or the one they shared my address with and is now spamming me? Presumably the latter, since they are the one sending the spam. But if the initial company shared my email address with that company, they probably shared it with a lot of others, too. And what are the chances someone who has resorted to these sorts of tactics is going to care anyway?
> he company would also have to have some sort of presence in the EU
If you were in the EU, they wouldn't have to have presence in the EU to fall under GDPR.
> And then which company do I send it to?
Both! One shared your data with a third party without your explicit consent, for non-essential reasons, the other one is processing it without your explicit consent.
> And what are the chances someone who has resorted to these sorts of tactics is going to care anyway?
Depends. A lot of business do awful stuff for as long as nobody cares enough to start raising fuss about it.
Speaking of that, for extra effect, complain about it on Twitter and Facebook, linking relevant companies' public profiles/pages. In general, it seems a lot of companies (particularly non-tech ones) are extremely sensitive about social media posts.
> There's just nothing actionable to do with this information.
Of course there is. When it happens I add an entry to my procmailrc that routes those emails directly to my spam folder, and I never see them again. And I never do business with that company again.
I do this using a catchall account with Fastmail, but I don't even bother obfuscating the vendor name. Occasionally they don't let you use an email with their name in it, which which case I add 'isdumb' to their domain and then use it.
It happens occasionally that they get confused, but so far I haven't run into any issues.
I do agree in principal that it would be better to have some sort of hash that maps their domain to the e-mail in a way that is easy for me to know but hard for someone else to figure out. Ideally in a way that is still reasonably easy to pronounce over the phone.
What would be really slick is to have such functionality integrated into a password manager.
2. Just use the domain or in some cases company name
3. Use a sub-domain
The sub-domain is essential for catch-all, otherwise you get a crazy amount of spam. I forward it all to a single Gmail address, have a rule to move it to a specific folder (based on "to" address), and otherwise let Gmail spam filtering do it's thing.
I've been doing this since early 2000's, and had very few issues with using domain/company. One or two that dis-allowed it, a couple confused humans.
> The sub-domain is essential for catch-all, otherwise you get a crazy amount of spam.
Seconding this. I get a larger portion of targeted spam (addresses that I gave out in the past) with a sub-domain catch-all. At a normal second-level domain catch-all, I get more random spam addressed to common addresses like accounts@, billing@, and sales@.
Yahoo mail has a feature under Mailboxes, called "Disposable email address" that allows you to pretty much do the same. You choose a "base" name, and then you can create upto 500 disposable addresses of the form basename-keyword@yahoo.com - you can choose the "keyword" based on the site you're signing up for, the basename stays constant. All mails to the disposable address get delivered to your normal mailbox, but you can go and delete a disposable address or filter it to spam. Also, both the basename and keyword remain untraceable to your actual address (unlike gmail's + format that has your base email id embedded in it).
I used to use this earlier, but then I couldn't find the setting easily on their mobile web interface and got tired of either switching to the desktop version or waiting to get to a desktop to complete a signup. Nowadays, I just report spam if there's no unsubscribe option.
This is the easiest and most widely available solution imo. I use ProtonMail which allows for plus addressing. Gmail also offers this feature if I recall correctly.
All of my web apps limit email addresses to 128 characters. This domain alone is 67. If you exceed the 128 character limit then I'm not sure I want you to sign up anyway...
Fun fact: having this article on the front page made my iphone render all the front page text smaller so it could fit the full URL. When I hid the listing, text sizing went back to normal.
Yet another side-effect of a super long domain name!
175 comments
[ 4.6 ms ] story [ 239 ms ] threadPeople seem to spam me, but gmail is pretty good at filtering all that stuff into the "Promotions" folder, which is nice.
I'm confused at how this allows spammers to self-identity.
Edit: RFC 1035 section 2.3.4 says 255 octets. Could be shorter here, though. https://tools.ietf.org/html/rfc1035
https://stackoverflow.com/questions/32290167/what-is-the-max...
http://3494943456/
Sort of cool, but what happens if we overflow it by adding 232?
http://7789910752/I mean that's cool, but how far can we go?
http://18446744077204495072/So that still works, what about going further?
http://19769064789825639936542264398379633403153906826257738...Going further actually breaks some browsers (Firefox can handle longer than Internet Explorer for example), breaks web servers because they log the full version before it is transformed, and even acts as a fingerprinting vector. The limit is usually in the several hundred kilobyte range, and depending on the way that the underlying operating system handles it, things get seriously broken very quickly.
You should probably include the OS+browser combo you used, as it does not seem to be universal.
The continuous discussion about "thereabouts" is because the 255 bytes limit applies to encoded name fields (in DNS messages), not domain names as we usually write them in dotted format.
Since the encoded format is that each label is preceded by its length and the whole domain ends by 'root' (i.e. 0x00) this means that domains names as we usually write them are limited to 253 bytes, including the dots (we don't write the 'root' label and label lengths are replaced by dots except the first one, that's 2 bytes to subtract from 255).
> Each FREE mailbox account comes with 25MB of storage capacity, which is a lot more than what is offered by most free email providers. This can allow you to store over 250,000 email messages.
This has not aged well since 2003. The amount of bloat in emails now is quite high since everybody who sends emails wants to use HTML with embeds while also inserting tracking pixels, images, links, etc.
1. Using a link like in a normal website => might not load.
2. Using a data uri => increases mail size, there is no rfc as far as I know which states that this even had to be supported.
3. Using a cid , link as specified by the mail rfc => increased size and more complex (you basically put a link in the http body which refers to another body in the multiparty/mixed body it's in by the unique cid. Which is supposed to be works unique but quite to often is not.
As I recall, it was common to have 10 MB inbox storage for free email accounts around that time.
Generally even besides CFWS related differences there are some differences in between which email addresses SMTP allows and which are allowed in mail headers....
Lastly given that quoting in the local part as well as some special forms of the domain part are not supported by most programs it's often sensible to reject them, i.e. treat them as invalid even through technically they are not. (But you really should support internationalized mails!)
[whatever the server accepts]@[valid domain name]
No more, no less. Although "server" here also includes anything in-between that may barf on a local part or (sometimes) even a domain name it doesn't like. For example, some forms don't like emails to top level domains.
[::ffff:127.0.0.1]
[64:ff9b::127.0.0.1]
https://en.wikipedia.org/wiki/IPv6_address#Special_addresses
Yahoo! Mail always has supported a space in the local part because David Filo wanted to ensure it was supported. His @yahoo.com email address had a space in it to ensure that he’d know if it was ever broken.
And for good reason. Were I in charge of the project budget, I wouldn't be blowing good dev money on implementing some RFC circle-jerk that no real user will ever use except in a geek pissing contest. Our collective Venn diagrams of what an email address "ought to look like" have a big enough intersection that we can probably do without such silliness.
I used to have myself@iwenttodefcon7.andalligotwas.thislousyemailaddress.com and I used it for quite a bit of testing too. Broke all sorts of things, either because of length or multiple levels of subdomain or who knows what.
I'd love a service that gives you all sorts of peculiar-but-valid addresses for testing... hmm. Is there a market here?
Addresses there would only be used as the recovery addresses for vital services such as bank and brokerage accounts, domain registrar accounts, telephone company accounts, and mail hosting accounts, and that's probably all.
By "recovery address" I mean the address that the service provider will use if someone initiates an "I forgot my password and lost my 2FA device!" password reset. It's any address that if someone takes control of they can take over your account at that service starting from at most your user name on that service.
Why a meaningless name like m95aaa5aea09bdc67.com? To minimize the risk of someone coming in and trying to take it over via a trademark dispute. For this I want domain name that I can be very sure I can keep as long as the current domain system is still in place.
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.
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
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.
We pretty much have this for crypto, but for everything else on the internet it still seems like the wild west.
Therefore, probably the best way is:
(At least, it is how I do C programming.)
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 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.
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).
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.
amazonsupport@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
This has two benefits: I can easily route/filter incoming email from that vendor, and if I ever receive spam at that address I know which vendor sold my info.
But really you could just set up a 'catch all' and have everything routed to one inbox, then use filters to filter the emails to separate folders.
So emails to $PERMUTE1@domain.com could be filtered to a $PERMUTE1 folder, and so on.
And you can also reply from such addresses without extra configuration. On the desktop I use MailMate as my email client, which works great with dynamic aliases. The win is that you don't have to configure anything extra when signing up for some online service.
https://www.fastmail.com/help/receive/addressing.html
You can do this in Google Suite btw, as you can configure a forwarding rule. The problem with Google Suite, last time I tried, is that they no longer want to sign emails with DKIM for such dynamic aliases, so you can receive emails just fine, but sending emails from such addresses is a problem if you have SPF/DKIM domain rules.
I had them handle my DNS for that domain so I'm assuming this won't require any extra setup.
(asterisk) means the character itself, I can't figure out how to type one on this site though.
Edit: this wasn't a feature 3 years ago, I only discovered this 4 months ago when I added a few domains to my account and they added the (asterisk) aliases for those automatically.
For example: myemail+twitter@example.com or myemail.youtube@example.com both go to myemail@example.com
exampl.e@protonmail.com == example@protonmail.com == e.xample@protonmail.com
This is a good guide on how you can leverage this technique to identify which website you signed up for, and who sold your email to third parties.
https://www.reddit.com/r/ProtonMail/comments/7425v7/protonma...
Last I remember, dots aren’t a separator like plus is, they just don’t count as part of the name.
So Gmail treats my.email@ and m.y.e.m.a.i.l@ as aliases of myemail@
https://kb.easydns.com/knowledge/mailmaps/
It would be important to stress it out on the page that it may be due to security negligence/failure rather that just data sale.
I’m working on something I call “datapoint tax”
Make this hoarding of data a (tax) liability. A policy like this will solve most problems.
Obligatory mention: https://haveibeenpwned.com
I thought it was an interesting blend of technical literacy both to notice and be bothered by that!
In my experience, very, very few companies sell email addresses. Maybe 1% or fewer. The vast majority of spam tied to company-specific addresses is the result of data breaches. I get spam to my (old) linkedin, dropbox, equifax addresses - all starting after they were hacked.
> This has two benefits: I can easily route/filter incoming email from that vendor, and if I ever receive spam at that address I know which vendor sold my info.
There's just nothing actionable to do with this information. OK, so I caught badcompany.com giving my email address to marketingfirm.com. But the damage is already done. Sure, I can send them a nasty email, but it'll just get ignored or whatever.
And I just never really had that big of an issue with spam where I needed to black-hole a specific email address. So for me it just wasn't worth the effort.
The footer had no unsubscribe option and the "manage communication preferences" requires a login/password combo that I couldn't be bothered to reset for my new geolocation.
I doubt this'll make a dent in Microsoft.com's spam score.
While I think this scheme is perfection in terms of privacy and security in knowing which company sells or breaches my email address... the fact is I haven't gotten a single unsolicited email in the entire 3+ years. Not a single message that hit a spam/junk filter, and not one email that wasn't expected based on whitelisted rules. The closest exception is Amazon who shares your email address with their shippers for delivery notifications; while I do receive 3rd party mail regarding legitimate Amazon deliveries, I've never received any spam to that Amazon address.
I have come to a conclusion as to why I have never received a single spam email since switching to this scheme. When I transitioned my GitHub account away from the old gmail address, I used the privacy option to not publish my REAL email address in Git logs pushed to GitHub. I deleted my old repos, and re-imported using the GitHub-wrapped email address. Thus I surmise that for those of us who are developers pushing code to public Git repositories, the vast majority of the spam you receive is because your email address can be very easily scraped from those Git logs.
I expect to migrate back to a single email address in the future, for a singular reason: as I get older I cannot imagine managing these email filters and password manager entries. Eventually I will need to simplify things.
If you're in the EU, then send it to their DPO instead, and CC the national data protection authorities.
If you were in the EU, they wouldn't have to have presence in the EU to fall under GDPR.
> And then which company do I send it to?
Both! One shared your data with a third party without your explicit consent, for non-essential reasons, the other one is processing it without your explicit consent.
> And what are the chances someone who has resorted to these sorts of tactics is going to care anyway?
Depends. A lot of business do awful stuff for as long as nobody cares enough to start raising fuss about it.
Speaking of that, for extra effect, complain about it on Twitter and Facebook, linking relevant companies' public profiles/pages. In general, it seems a lot of companies (particularly non-tech ones) are extremely sensitive about social media posts.
https://www.enforcementtracker.com/
(And the rules here: https://gdpr.eu/fines/)
The action one can take is that if the address is distributed and you start receiving unwanted mail, you can filter out messages to that address.
Of course there is. When it happens I add an entry to my procmailrc that routes those emails directly to my spam folder, and I never see them again. And I never do business with that company again.
It happens occasionally that they get confused, but so far I haven't run into any issues.
I do agree in principal that it would be better to have some sort of hash that maps their domain to the e-mail in a way that is easy for me to know but hard for someone else to figure out. Ideally in a way that is still reasonably easy to pronounce over the phone.
What would be really slick is to have such functionality integrated into a password manager.
1. Use a catch all alias (zero-effort)
2. Just use the domain or in some cases company name
3. Use a sub-domain
The sub-domain is essential for catch-all, otherwise you get a crazy amount of spam. I forward it all to a single Gmail address, have a rule to move it to a specific folder (based on "to" address), and otherwise let Gmail spam filtering do it's thing.
I've been doing this since early 2000's, and had very few issues with using domain/company. One or two that dis-allowed it, a couple confused humans.
Seconding this. I get a larger portion of targeted spam (addresses that I gave out in the past) with a sub-domain catch-all. At a normal second-level domain catch-all, I get more random spam addressed to common addresses like accounts@, billing@, and sales@.
I used to use this earlier, but then I couldn't find the setting easily on their mobile web interface and got tired of either switching to the desktop version or waiting to get to a desktop to complete a signup. Nowadays, I just report spam if there's no unsubscribe option.
I got two mails telling me I cannot use the company name in my e-mail, they'd file for fraud if I would.
(got resolved by explaining how e-mail works, but still)
https://your.mom/
Safari - iOS
http://bigtittyjapanesewomenthatlooklikecutecatsandipromisen...
Yet another side-effect of a super long domain name!