I sort do this a different way. I have a custom domain and use that with Google's G Suite. I set the catch-all email to my email. Then everything I sign up with gets a different email address, like amazon@<mydomain>. I use a password manager to track all the different emails/passwds. This has helped me catch the water company giving out my email. I got junk mail asking me to sign up with my email utilities-water@<mydomain>. If a particular email starts getting spam, I just blacklist the To: address.
People have been mentioning this technique for a long time on HN. I finally started doing it a few years ago (my email is through Fastmail), and it has worked pretty well. It turns out most customer support staff are surprised to find the name of their company in your email address (“is that your real email address?”).
I've set up traditional email aliases for years. It was Andrew Lewman's blog article https://lewman.blog/2019/09/02/why-i-have-over-one-thousand-... that goaded me into writing this. I've been doing stuff with email since before there was InterSLIP, I finally concluded nobody was going to work on the problem for me.
I do a variant of this, login+company@domain.com (or more often login-company@domain.com as + is often rejected at html forms).
In my experience, catch-all email (*@domain.com) increased number of spam as spambots send out emails to randomly generated adresses (john@domain.com, stephen@domain.com, anne@domain.com).
Why require a patched Postfix merely to use a localhost address and port as a lookup table? I would assume that a unix domain socket should be acceptable?
I want to thank HN and the HN community for the awesome free exposure. It means a tremendous amount to a niche open source project. I'm sure I can attribute 6 clones and 20 GitHub stars to this, hopefully some of those turn into users and possibly even contributors. Thanks again...
You can point alias_maps to a SQL table too. So adding and removing alias can be done on the fly. No patching.
One can also use UAE, the '+' symbol after the user portion in postfix - don't need new alias. Then use a dedicated UAE base address "spam+VENDOR@example.com".
I've never written a general purpose parser in SQL, I'll be curious to see what you come up with. Might be easier to retrofit your SQL engine so that it will run Python functions.
Regarding stemming addresses, you can combine the two approaches. See the procmail example.
This is quite clever. I have avoided wildcards because I have not wanted to deal with the increased spam sent by bots to random (jane@ eve@) or not so random addresses (webmaster@).
Thank you. Some people view wildcarding the domain as basically turning it into a honeypot (and using the spam to train the spam filter). I wanted to be able to provide feedback, not blowback, and rejecting at SMTP transfer time is the distinguishing factor. Yes I do eat my own dogfood, and I'm finding that I'm almost using aliases as cookies now.
Note: Using port 465 for SMTPS is deprecated; one should use STARTTLS on normal SMTP on port 25 or client e-mail submissions on port 587 instead. Port 465 has even been officially reassigned to the “URL Rendezvous Directory” service.
If you’re worried about man-in-the-middle protocol downgrade attacks, check the DANE DNS record for the mail server (and verify the DNSSEC signature); if the DANE record says to use TLS, but the SMTP connection doesn’t accept STARTTLS, raise the shenanigans alert.
How many serious SMTP servers in the entire industry have DANE records with DNSSEC signatures? Didn't the major mail providers just push SMTP-STS specifically so people wouldn't have to bother with DANE?
MTA-STS was made by, and for, the big providers, and it shows. MTA-STS is not a practical standard for small players, and is unlikely to be widely adopted except by Big Email.
Given that, by definition, the majority of end users are on “Big Email”, if all of them adopt it, it will already have vastly more practical benefits than DANE has had thus far.
That said, I’ve looked around a bit and it doesn’t seem like it’s actually impractical to set up MTA-STS for your own server, unless I’m missing something? (For reference, I’ve been skimming https://roll.urown.net/server/mail/mta-sts.html ). Can you elaborate on why it’s not practical for small players?
Maybe because he doesn't like serving https? Many people object to that, while they're fine with the DNS only part (you need to be able to curl https://mta-sts.DOMAIN/.well-known/mta-sts.txt )
This is factually wrong. Your information is deprecated.
Historically, yes 465 has been deprecated several years ago. But as many ISP and the largest email services kept using it, the IANA had to change its tune and 'resurrected' port 465 in this RFC.
It is funny: the RFC itself describes that as a wart, but reality is a harsh mistress.
Please read the outlined section 3-3 of RFC 8314 from 2018 that explain just that if you don't believe me.
Of course, this still doesn’t mean that using 465 is a good idea; ports 25 and 587 with STARTTLS (using DANE for downgrade protection) should still be preferred to using 465, which the RFC does clarify.
(sorry if I insisted. A lot of people still believe 465 is deprecated. I wanted to correct that)
For preference, the RFC also mentions implicit SSL is the goal.
Given how far it has come, with 465 now being resurrected, I will not be surprised when in the future STARTTLS becomes deprecated - and maybe other ports besides 465.
All it takes is a few large email providers to stop accepting port 587 ... and 25. Just look at how everybody has jumped into using DKIM and MTA-STS which are way more complicated and ugly, but almost required if you want your email delivered.
