I have a unique email address for every single service that I sign up for, similar to this, though selfhosted. I've been doing this for years and it works wonderfully. If someone misuses my email address, or gets annoying, I can simply turn off the address. Bam!
It's the easiest Postfix config in the universe, essentially just:
I do a simplified version of this. I just use a catchall account with Fastmail and then pick email addresses in the domain randomly. If someone abuses the address, I block it. I specifically do not use addresses that make it obvious what my strategy is. I end up just using a name and number that would look right at home on gmail.
I'm also not trying to stop tracking, so much as I'm trying to have my own semi-permanent equivalent to mailinator that nobody will recognize as such, that I can use to cut back on the amount of spam I get.
I've been happily using fastmail for years and I think I'm going to be forced to stop. My outbound emails are constantly getting caught in spam and it recently cost me a job offer.
if you're having this issue I would reach out to Fastmail support. A real human will dig through the smtp logs and find out what the issue is. Based on my experience... Fastmail is very on top of spam, blacklists and other deliverability issues.
In my case, it costed me two offers. One from Google and one from GitHub. Come to think of it, yeah I will begin migrating everything away from FastMail and stop using it completely.
One event that pissed me off with them: Instead of forwarding an email to SPAM, they simply throw it away instead. Turns out the email was not SPAM (2FA) and I had to go through weeks of support to find out what happened (thank god that you get a human for support but still).
Also I think they are still based in Australia? Would be happy to hear about alternatives.
I use an @fastmail domain. The issue was how they handle RSVPs when your default calendar is an external one. RSVPing from within Fastmail attempted to Accept as my old Gmail address, who wasn't invited to the interview. On the interviewers end it looked like I didn't respond.
In some contexts, fastmail is viewed as a "throwaway" email provider. I ran into this when I was trying to provision a couple of VMs at a hosting provider. My fastmail email address was rejected. After contacting their support, they said they did not accept "throwaway" email addresses. I had to use a gmail acccount. The irony did not seem apparent to them.
My only scare with not using gmail and outlook calendars. However I moved to Zoho for mails and nextcloud self hosted for calendars. For mail delivery I make sure to verify again n again my SPF DKIM is valid or not but it’s a scare still :(
Isn’t it so bad that it’s overly hard to move away :(
With your own domain? Make sure you’ve got an the SPF, DKIM set up correctly, and register your domain with gmail’s postmaster tools. I moved my domain recently, and had completely forgotten about all that stuff I’d set up years ago. Started losing mails, redid the setup
I wonder if you can provide more context. I've only had issues when I tried to use external domains, e.g. gmail, as my reply-to when sending in fastmail.
I have tried this approach. Unfortunately, some services will not accept plus sign in the username no matter what RFC says. On top of that, some services seem to not like seeing the service name in the username. I.e. foo.tld will refuse sending email to mailbox+foo@mydomain.tld.
Shopify also flags orders (even if they are fully paid) when the customer's email contains the shop's name. I'm sure their logic is that it helps cut down on fraud.
I prefer the system of using a basic abbreviation in the email address to avoid these types of filters but still make the email easily traceable later. Say your name is joe smith and you're buying from Sports Online. Something like Joe_spo_smith@yourdomain.com works well for later confirming whom you gave the address to.
I like this approach because one doesn't have to track all of the catch-all emails made on the fly, since finding out who you originally gave that email to is just a matter of searching your past email and noticing that "spo" looks more like those old Sports Online emails and not the new spam from discounted wholesale fancy rugs.
Apart from seeing who a company has on-sold your information to (or more rarely had a staff member steal their database), it's also an easy way to see who has been hacked.
One other reason not to use something like SportsOnline@yourdomain.com is that some websites exist merely as credential honeypots and those types are usually aware of this approach and will then typically exploit the catch-all for spamming. The shady All on MP3 service was known for doing this. (I'm pretty sure that site existed solely to exploit the fact that most people used the same password for everthing.)
Some mail providers support receiving mail on arbitrary hostnames, so you can set up a wildcard MX record and then use mailbox@foo.example.com instead. This avoids email validation issues with plus addresses, spammers don’t try removing any parts of the hostname, and I think in the many years I have been using it I’ve only run into a problem with including the service name once or possibly twice.
AFAIK the only provider that supports that is Fastmail and it kinda defeats the purpose of using your own domain because if you are forced to migrate you are toast.
I do this with ProtonMail. I have it set on a subdomain, though: my regular email is email@example.com, while my account email is hackernews@email.example.com. This avoids the spam sent to asdf@everydomain.
Some MTAs (Postfix at least) allows other characters. I use an underscore, which seems universally accepted. For the second problem, there's usually some alternative mangling that would still be unique-enough, or just flee because they seem too aggressive on the data harvesting.
not only can you not sign up to many services, customer support can often get confused when you need to email reply to them and you cannot email from your aliased email. they see you as a separate user not in their system, or the wrong person replied to the support ticket, etc.
On Fastmail, at least, this isn't a big issue. For a catchall account, if I reply to an email[0] it automatically addresses the reply as from the alias. It is editable in place, too, in case I want to give it some other name.
But why would you not be able to reply with the aliased email? I do this regularly. Of course your mail client needs to support this, but using Mutt this is absolutely no problem (just change the FROM header) and I have heard from other users who use Thunderbird that they can also create new identities (just not as easy on the fly). In fact I wrote a small script for Mutt that would automatically set the correct sender if I reply to an email that contained a wildcard. Works pretty well.
Can you not reply from a user+foo@example.com alias? I use the catchall approach (so just foo@example.com when signing up for foo), but if I need to email customer support I'll just send the email from foo@example.com. I've never tried that with a + in the account though to see if my client supports it.
There is nothing secure about email. It's less secure than Telnet.
You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
Email is sent over cleartext, it is not encrypted. Anyone can read email if they can inspect packets.
>You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
That might be true for some systems, but for most services out there, having missing/invalid anti-spoofing measures will result in your mail ending up in spam or not delivered at all.
> but for most services out there, having missing/invalid anti-spoofing measures will result in your mail ending up in spam or not delivered at all.
You would think so.. but its remarkable how easy it still is to forge email.
My mum was recently the target of such a campaign. She's in the executive team at an international NGO. An attacker found her email address and a bunch of her contacts via the NGO's webpage. Then they forged emails from her email address, with a gmail address set up in the reply-to field. The emails all said it was an emergency, and asked for her colleages to transfer money.
As far as we can tell, most of the emails were delivered and lots of people were fooled - at least for awhile.
Her email address has DKIM and SPF set up, but (like most email providers) it has a lax DMARC policy. It turns out thats all it takes to be vulnerable to this sort of attack.
Are you being serious right now? You understand that that'll never happen in our current technology landscape, right?
Outside of a few niche hardcore technologists, nobody knows what PGP is or how to use it. It would be hard enough getting my mum set up to PGP sign her own emails in Outlook, on the desktop and from her phone. (Is that even possible?). Let alone require anyone emailing her PGP sign their email too? Thats never going to happen for so many reasons, both technical and social.
I'm a software engineer and I tried setting up PGP years ago in thunderbird and it only worked for a few weeks, then it somehow broke. And then later I lost my PGP key. Oh, and then I started using webmail and PGP didn't work there at all.
And then later still I realised my public PGP key (signed by my web of trust) leaked details on the identity of my social network; which bothers me a lot more than any problems I've personally ever had with a forged identity.
> That's obviously false if you bothered to do a bit of searching
Technically correct, best kind of correct.
Sure, it is not plaintext, but anyone with the access to the wire could MITM the connections. Maaaaybe something changed in the last ten years, but I never seen someone not accepting a connection with a self-issued certificate and any warnings (to the end user) if the receiver uses self-issued cert. Which makes the whole point quite moot.
For this attack to be mitigated everyone should implement it. Gmail and Live.com has MTA-STS records, Fastmail doesn't, one regional provider with millions of accounts doesn't have it too.
And finally your MTA should support it and be configured to deny the delivery if MTA-STS validation fails (and adversary, who is happily MITMing your traffic, shouldn't fiddle with DNS and HTTPS and of course blocking HTTP/S from the MX would be considered cheating!).
All in all, SMTP traffic is encrypted, but it is not secured.
TLS is unaffected by any government laws. What I assume OP is referencing is a law that makes end to end encryption problematic in Australia but Fastmail has never offered end to end encryption. Neither do most email providers so it doesn't matter.
If you get a PGP browser extension they all do. It’s pretty inconvenient to use though, sending encrypted attachments and giving the password offline is probably the only thing most people are up to.
The location of the fastmail office has zero impacts on this. If the complaint was that the PGP extension was developed in Australia then that would be a valid complaint. But email hosts themselves are not private against government requests.
Nice! I do something similar, but using an automatic aliasing scheme so that I don't have to manually configure an email address for each service and other users can use this without me knowing their aliases. In my setup, aliases can contain wildcards, represented as percent signs. If an alias phil.%@domain1.com is set up, all your examples will be sent to the respective aliased address. I use Postfix Admin with a MySQL database. Hence the Postfix setup looks like this:
The first file is just regular aliases, and is basically a simpler version of the second file (no SQL selections/filters) and could also be merged into a single query with the second file:
user = mail
password = <password>
hosts = 127.0.0.1
dbname = maildb_postfix
query = SELECT a1.goto FROM alias a1
LEFT JOIN alias a2 on (a2.address = '%s')
WHERE '%s' LIKE a1.address
AND a1.active = '1' AND a2.address IS NULL
This works, because the percent sign in the alias is picked up by the LIKE keyword. A setup like this allows me to configure many aliases through Postfix Admin's web admin page, including optional wildcard aliases (depending on which users wants that). It has been working very well for me over the past 15+ years. Also, I haven't looked at that SQL query since then and would likely write it in a nicer way today.
Note: with the above code SQL injection could be possible through an alias name, but given that in this setup I am the only one managing the mail accounts, I was willing to take this risk. :-) Postfix Admin might do some cleaning/validation, but I haven't checked on it.
Because it's not as effective if the goal is to catch spam. Spammers are already wise to the meaning of + and will strip it automatically when selling data in bulk. Plus, some services block creating accounts with the + or with their name in the address.
How do you mean? This is exactly what I can do with my setup. If you are referring to the use of Gmail: I prefer to run my own infrastructure as long as this is possible.
> It's not as shiny as Apple's thing, but it's 100% selfhosted and I own the domain.
Apple's system is "shiny" because it provides near total anonymity, whereas your setup has all the deliverabilty issues of a self-hosted domain and rather uniquely identifies you...at the domain level?
I'm not sure why you are maintaining a hundreds-of-lines virtual table and a web UI, instead of just using a regex or two to capture phil.*@domain2.com or something along those lines (maybe you want to do one including a year or something to cut down on spam), or blacklisting as needed by having postfix reject during the SMTP session so the email is marked as invalid and is removed from the spammer's database.
Or, I dunno, just use VERP? I don't think I've yet run across anyone smart enough to drop VERP from email addresses.
Apple's system will only work until they decide to shut you out or shut down this service for whatever reason. Anonymity is not really a concern for most uses, privacy, longetivity and reliability of reception is though.
I still want to use random unique addresses even for important and trusted services, not just for throwaway uses. So third party domain is not an option.
I use self-hosted unique addresses mostly for registering to services, so forwarding those messages in both directions through Apple's service would expose all those services to a silent takeover via password reset by Apple's employees in control of this service. So this service is exactly as useful as those random throwaway email inboxes available on the web. More polished maybe.
I imagine Apple would come down on them pretty hard in the App Store if they did that so for most applications it's enough of a deterrent that most places would not do it. I also think that because Apple can mostly control which addresses and how many of them there are it can control the spam issues enough to avoid that problem. If not... then yea that's gonna happen in a few years. Would be short sighted for Apple to not do it though.
I'm doing the exact same thing. Built a small web app that lets me manage all my email aliases for the domain. Unfortunately there are a couple of websites that do only allow a select list of whitelisted domains meaning I cannot use my own, but for the other 99% it works wonders.
I wish I had had this idea ten years ago, it would have saved me so many headaches.
The most recent incident I remember was with a debrid service. I opened a ticket with their support and was told that the point of the policy was to combat abuse of their service. Not entirely sure why a paid service that accepts cryptocurrencies would care about email addresses.
Not as of right now, but I could put it on GitHub. It's essentially just a front end for the Gandi.net email management API. Manually editing the alias list gets cumbersome really quickly.
I use 33mail.com (33m.co) which does the same thing (it has a link on the email to disable the address). You can use a subdomain or custom domain. It has a generous free tier, and ridiculously cheap paid tier. (Paid is required if you want to be able to reply to inbound emails though.)
It's worth a lot of money for the ad-tech (consumer tracking) industry to understand.
If a domain only occurs once in a user database, it's likely to be a personal domain. A data broker that sees the same domain in a few different datasets (once in each) can be quite confident that the domain is an individual's.
I used to do this too, but it's a considerable amount of effort, and doesn't really prevent much: many domain hoarders/resellers know the trick, so they'll try to match other data they get from you, and sometimes build a fuller "profile" on you than they would if you only had gmail/other generic domain (eg if they have your name, which often leaks along email, they'll try your first name, first name + last name, initial + last name, first name + last initial, etc).
I'm doing it the other way around, which is slightly less work because you don't have to create new email addresses explicitly: Catch-all by default, with a recipient blocklist as part of smtpd_relay_restrictions that I update whenever some service gets breached.
For those who do not wish to interact with their webserver config (or can't) there is AnonAddy, which can be self-hosted (https://github.com/anonaddy/anonaddy) or paid for (https://anonaddy.com/). It's really convenient, with the added benefit (for the paid version) of having a domain, that is used by many people, which makes it easier to hide behind an email address.
I've just started doing this and it's so nice. "Gee who signed me up for a newsletter... why, it's that hotel chain I stayed at 3 months ago! Naughty, naughty." Makes the management much nicer, and I can maintain my fun username for silly projects and a slightly more professional one for business inquiries and such. Highly recommended! Domains are cheap and Fastmail makes the process absolutely painless.
I wrote a simple script[0] which generates a new address for each site I register. Then a simple script to look up what the generated address was later. It is written for OpenBSD, but should be easy to adapt.
I've set up a catch-all SMTP server for my domain and now I make up unique addresses on the fly. It simply forwards everything to gmail. Was too lazy to set up sending.
Thanks to this setup, I've already encountered one instance of a company either leaking or selling their customer information.
I did this too for many years. I recently reversed the filter logic from whitelist to blacklist since spam filters nowadays seem efficient enough that passing through `name*@domain.tld` by default and only blocking those few addresses that leak and start sending spam is less work.
I did this with my own domain. Then sold the domain, and it was an absolute nightmare to go change my email registration everywhere because asking the buyer to forward a bajillion emails to me was overbearing. Never again!
And, if the email service is also self-hosted, it prevents Apple from collecting more data about your interests and purchases through your email, which it uses to profile you (to determine how to extract more money from you).
I tried to do this but my dentist’s receptionist got confused and cancelled an appointment because “I used their email address”.
Square also makes this incredibly difficult because if you enter a merchant specific email they permanently tie it to your card. So now any time I ask for an email receipt I get an email to my hairdrstylist’s “unique” email.
> I tried to do this but my dentist’s receptionist got confused and cancelled an appointment because “I used their email address”.
Never had it go that far but I definitely had some odd reactions e.g. a support agent thinking I was a colleague.
On the other hand, if you have a relatively common name it avoids people giving your email address then behaving aggressively when you tell them to stop. I’ve had a few friends hit this issue.
> On the other hand, if you have a relatively common name it avoids people giving your email address then behaving aggressively when you tell them to stop. I’ve had a few friends hit this issue.
I’m sorry, I can’t parse this. Can you try again?
I used <dentistbusinessname>@<mydomain>. My name was never involved in the address.
> I used <dentistbusinessname>@<mydomain>. My name was never involved in the address.
That's the point, if you don't use your name in your address, you can't be <genericname>@<genericdomain>, which third parties will provide as their email,
Because I use the same scheme you do I've never had that issue, but several friends with common names have hit the issue having registered to more "normal" hosts, often as somewhat early adopters and thus having gotten their pick.
I have a very uncommon name (though not unique) and I've had people mistakenly signing up for services with my firstname.lastname@gmail.com (which I don't usually sign up to services with).
The annoying thing is the number of services these days that don't seem to require you to verify your email. Examples of the above included eBay and Spotify. On both occasions I had to contact support to ask them to delete the account.
> That's the point, if you don't use your name in your address, you can't be <genericname>@<genericdomain>, which third parties will provide as their email,
I’m still not following. Who is this third party and what does it have to do with a confused receptionist?
Also, not as granular, but instead of the + suffix, add a dot in a weird place. So
n.ame@gmail.com or nam.e@gmail.com . Many SMTP servers respect periods as differentiating emails, so services can't delete them. It doesn't help you stop spam, but you can add a gmail filter that n.ame@gmail.com is put in a separate label. And it's very fast to type, easy for non tech-y people
It’s almost as trivial with this format too, at least to guess what address is used for other services, though it has a strong advantage over using ‘+’ in GMail in that nothing will try this automatically. It’s hard to believe anyone would intentionally try to guess a different service’s email to spam to it, but even so in my setup I prefer to eliminate this possibility completely by adding a random number to the service name: experian12322@example.com, and so on, with no catchall for invalid addresses.
So far the most spam I’ve gotten has been to the address I used for Amazon (probably leaked by a third‐party seller there).
I mean you can pick any format you want before the "@", but yeah my format is trivial. Nobody has tried to do it automatically yet though, as far as I can tell.
Though I had originally made this because with the "+" approach, you can easily get the original address by simply removing everything after the "+", while with mine you cannot. On top of that, sometimes "+" does not work in services that do "strict email validation".
It's the easiest Postfix config in the universe, essentially just:
And then /etc/postfix/virtual looks like this: I also made a super simple web UI for myself to edit this file quickly.Gmail seems to be fine with this, emails do not usually end up in spam. Every full moon maybe, but usually it's alright.
It's not as shiny as Apple's thing, but it's 100% selfhosted and I own the domain.