"Run Your Own Mail Server" by M.W.Lucas

I started sending through Amazon SES around a year ago. That got the blocklisting down to practically zero and my volume is low enough to be free. Running a mail server itself is not *THAT* hard really, I consider that a pernicious myth. It's the babysitting of users and the rest of the outside world misbehaving that takes most of the time. My stack: FreeBSD obviously, Postfix, Dovecot, OpenDKIM, OpenDMARC, SpamAssassin (I know, old but works), clamav-milter, and a few plugins for Dovecot like Sieve.

Running through SES botched the test above quite a bit. It takes it down from 9 to 6 for me, which is worth a complaint against AWS (which is interesting and I'm going to route through the big fat enterprise support agreement at $work for added effect) . The test at internet.nl is less comprehensive but good enough for my purposes. Mail works and has worked for me for years with my current setup, which is practically maintenance-free. I can't help the DANE situation unfortunately as AWS Route53 doesn't let me add that. which is another open case with AWS posted with my work hat on.
 
Install a mail server, follow the documentation. Learn the basic protocol – it helps a lot when debugging and looking for vulnerabilities. It also clarifies a number of idiotic myths that have accumulated over the years.

Spamhaus is tolerable among free blacklists while all others are complete junk. You shouldn't expect miracles though: I checked my today's spam feed at Spamhaus: 3 IPs were indeed listed, 1 was clean, and 1 IPv6 was also clean.

Much of spam used to come from big tech free mail, and vast majority of that was GMail. This has been rapidly improving in recent years. However I haven't administered a busy mail server for some time now, so I might not have the full picture.

Graylisting and fake MX records with higher priority work just fine on stupid botnets. SPF does not because it's trivial to circumvent. The idea was good, but the actual protocol that they cooked was a conceptual disaster.

DKIM, DMARC, DNSSEC, S/MIME, and some other fancy abbreviations are waste of your time.

PGP is vastly underutilized.
 
Umm... Matlib.. Nowadays you're not going to get much of anything delivered from your box if you do not have DKIM, DMARC, SPF and reverse DNS properly in place. DNSSEC is not as hard a requirement but doesn't hurt if you know how to manage it properly. You may be factually correct in that these protocols/additions to the mail worklfow are flawed, but that's the world we have to work with. If you choose not to implement any of them, I wish you the best of luck with your mail sending endeavours because you will need it.
 
Of course SPF works, you just have to keep your records correct and clean for every domain you are sending mail from...

DKIM is pretty much mandatory today and it also works; same as DMARC (yes, you have to actually *look* at the reports you get...), DNSSEC (not only for mail delivery) and S/MIME.

It's fascinating how much FUD about mailservers still seems to be general folklore. Especially from people who doesn't seem to have ever ran a mailserver.

I've been running maliservers for almost 20 years now, ranging from my own, personal (and my former business) ones, to medium sized corporate servers. And yes, the landscape has become a major shitshow, especially thanks to RFC-ignorant monopolists like microsoft and google which constantly come up with random crap to break communication and a protocol that even has "simple" in its name. Especially the former are by large the most incompetent, elitist idiots in the field, constantly "bending" the rules (or simply too dumb to follow them), rejecting legitimate mail while sending massive amounts of spam themselves (#1 spamhoster for *years*; by orders of magnitude larger than anyone else on the top 10 list). And no, you can't just mail their postmaster@ or abuse@ to sort things out, because they simply don't accept mail to those *strictly required* addresses...
Yes, at some point you have to deal with those idiots. Yes, it's tedious. Yes, you can just block them altogether with a meaningful error message on your private mailserver, telling everyone still using them to get a proper mailprovider (that's what I'm doing - and it actually works). For a corporate server however, you can't really do that, so you again have to deal with those idiots...
So if you have the choice and don't want to waste your precious time with idiots - don't run a mailserver. Not because it's *technically* very hard, complicated or tedious - the RFCs are pretty clear and simple - but because you have to deal with idiots that aren't able/willing to follow even the most simple rules...
 
bvdw78 said:
You may be factually correct in that these protocols/additions to the mail worklfow are flawed, but that's the world we have to work with. If you choose not to implement any of them, I wish you the best of luck with your mail sending endeavours because you will need it.
Click to expand...
No, it is not only that it fights spam by making life difficult to spammers (and anyone).

DNSsec makes sure that the domain is in possession of the domain owner.

SPF allows the domain owner to specify the host names and IPs that he allows to send mails with addresses
in his domain.

DKIM allows the domain owner to sign certain parts of the mail, among them the From header,
and if the From has this domain, as required by DMARK, then it is a sign of authenticity.

SMTP allows any IP to send mails with any "from header" and any "envelope from". Mechanisms to prove
authenticity are necessary, and the above bind these data to the DNS.
 
You must log in or register to reply here.
Back
Top