The World's Longest Alphabetical Email Address (2004)
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com
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@
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
providersWithSuffixSupport = ["icloud.com", "gmail.com", "googlemail.com", ...];
if email.endsWithAnyOf(providersWithSuffixSupport) {
email = email.trimBetweenFirstOccurrence("+", "@");
}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)
"John Smith"@example.com
In fact, the local part is a set of elements separated by dots, each of which can be quoted. The following is valid: "John Smith@example.com".foo."John Smith".!$%^&*/@example.com
Of course, barely anything supports this. Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
https://tools.ietf.org/html/rfc5322#appendix-A.5Generally 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.
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.
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. 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,'@');
}(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.
> 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.
People 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.
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.
Yet another side-effect of a super long domain name!
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...
;; ANSWER SECTION:
wikipedia.org. 599 IN A 208.80.154.224
Lets try this in decimal:Sort of cool, but what happens if we overflow it by adding 232?
>>> 3494943456 + 2**32
http://7789910752/I mean that's cool, but how far can we go?
>>> 3494943456 + (2**32) ** 2
http://18446744077204495072/So that still works, what about going further?
>>> 3494943456 + (2**32) ** 100
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).
http://bigtittyjapanesewomenthatlooklikecutecatsandipromisen...
Safari - iOS
amazonsupport@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com