You got a job and it seems you were pretty good at it too. Don't do the "my entire career is built on one amazing stroke of luck" thing, it's wrong. You had a stroke of luck at the start, but seeing how you got an offer from both teams, and kept the job for a decade, you obviously were good enough.

Maybe you would have passed that first test too without the preparation, who can tell. But even if you hadn't, would that have meant that your future wasn't in software development?

Correct, most decent mail administrators don't send out bounce messages anymore. In your case that would indeed mean that the sender wouldn't notice anything, but my setup is different. Because I reject while the connection is still open, the sender's MTA notices the failure and can report back to the sender. If an MTA doesn't even send bounce messages to local users, something's wrong.

I understand your concerns for false positives, but I have found that I hardly ever reject anything I shouldn't. If a novice admin hasn't configured SPF, DKIM or DMARC, I won't reject it just because of that: since there are no SPF or DMARC records to check and there is no DKIM key to validate, all those tests will simply pass.

Should someone have configured an incorrect IP in his SPF record, but states that it's up to the receiving MTA to decide what to do if the check fails (with "~all", which is very common), I will accept the message. But I also add a header to notice that SPF failed, and that header is used further up in the chain to calculate the score of the message, just like in your setup.

This setup has worked so well for me, that I didn't need a spamfilter until recently. Only a couple of years ago, when I built a new server, did I add all that to the mix. Amavis runs all those filters, and adds the header "X-Spam: YES" if the score is high enough, and if Sieve finds that header, it will deliver the message in the Junk folder and mark it read.

Well, strictly speaking they haven't transferred the message yet when it is rejected, only the headers. These are all checks that can be done before the data command arrives. That's what I do, and I'm not too concerned about the occasional false positive. At least the sender will notice something's wrong, maybe he can fix things (or have his sysadmin fix it).

If I understand correctly, you calculate a grand total score to decide whether or not a message is fishy, and you do that after the SMTP daemon has accepted, queued and processed the entire message. That works, and indeed gives more granularity.

I just hate the idea that someone's junk makes it to the queue, I hate the idea that my system has to run a whole circus for nothing. So if I'm sure enough ("spf says no", for example), I'll slam the door ;)

I use DANE for almost all my certificates, including smtp and imap. There are more things I haven't mentioned, including the use of TLS. But hey, that's so obvious I didn't think it needed mentioning.

But I don't really care about any legal request. What is my hoster going to do? Give the police a copy of my encrypted disk? Good luck with that.

The exact amount of suspicion needed to reject an incoming message is up to you, but here are a few suggestions:

• Failing SPF check
• Presence on blacklist
• Invalid PTR-record
• Any condition that DMARC says is wrong

People running their own servers will have to comply, that's simply today's world of e-mail.

Self-hosting isn't particularly difficult. I ran a mailserver at home behind a cable modem for about 15 years, I've recently moved it to a VPS.

Back in the days I used to run Postfix and Courier, and that was it. Nowadays it's Postfix, Dovecot, Sieve, SpamAssassin, PolicyD, ClamAV, Razor/Pyzor, OpenDKIM and OpenDMARC, so yes, it has become a lot more complex over the years. But it's still worth the effort, I think. The agressive spam filtering is recent, I ran without any spam filtering until recently. If you do the right checks on incoming mail, a lot of junk is rejected before it can even reach a filter.

I would just start with Postfix and Dovecot, make sure that works. Make sure that your server uses the correct FQDN in its HELO/EHLO and that you have a matching PTR-record for that, or most of your outgoing mail will be refused immediataly.

Then add what you think you need. You'll probably want Sieve, very nice to have the server deliver e-mail in the correct folder, but it can do a lot more than that. If you want webmail: Roundcube has a plugin that allows you to manage Sieve filters.

Adding PolicyD allows you to to check blacklists and SPF before you accept mail. Very useful, that filters out a lot of junk before it's even queued. Make an SPF-record in DNS, telling the world only to accept mail for this domain from your servers. That makes it less likely that someone can abuse your domain to send spam, possibly leaving you with a lot of bounce messages. Checking SPF-records (and a whole lot more) can be done here:

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fmxtoolbox.com

DKIM isn't particularly difficult to set up, and everybody loves a signed message. Create one keypair for all your domains, or a separate pair for every domain, whatever you want. Then publish the key in DNS and check if it works. A nice site to do that is this one:

http://www.appmaildev.com/en/dkim/

If you have SPF and DKIM (and why wouldn't you?), you might consider using DMARC too. You publish your policy in DNS, so that every receiving mailserver can check what to do with a message that fails, for example, the DKIM validation. OpenDMARC can check the policy for incoming mail, and can send status reports. Most of DMARC is configured in DNS, this document gives a good overview of how you should set up a machine that uses all of these techniques:

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.skelleton.net%2F2015%2F03%2F21%2Fhow-to-eliminate-spam-and-protect-your-name-with-dmarc%2F

And then there's spam and virusfiltering. I'm running a combination of SpamAssassin, Razor/Pyzor and ClamAV for that, which was basically one install of Amavis and then some tinkering to get it right. My next server will probably use Rspamd for that.

Is it still worth hosting your own e-mail? Hell yeah!

I'm not very well organised, so it won't come as a surprise that I embraced the "Inbox Infinity" right from the start. Every year or so, I "archive" stuff. Meaning: everything older than, say, a year, will go to a folder in my archive for that year. In a couple of months I'll create the folder 2018 and move everything of 2018 from both Inbox and Sent to it, and I'm done. Very easy to maintain, only takes a few minutes work every year. Very Zen indeed. Sure, at least 95% of all that "archive" is clutter, but who cares? I host my own e-mail and diskspace is cheap.

Why not legalise it indeed? It's unhealthy, absolutely. But so is alcohol, tobacco, unsafe sex and watching South Park and you can legally do that. Government will decide what's good for you, not you. Even here in the Netherlands it's officially illegal (although the world seems to think otherwise). Let's hope our next government will wake up to reality and finally legalise it.

Yup, "yet". But maybe this is the time where we actually do come up with something better. It doesn't make sense to slap a bracelet on a mentally deranged serial killer, tell him "watch it, cause we're watching you" and send him back onto the street. But doing the same with a shoplifter might actually be better than putting him behind bars for a while, having him loose contact with the real world. He may not be able to to any harm while in prison, but when he gets out, chances are he's not thinking "wow, that really taught me something. I'll never do it again."

To quote George Jung in Blow:

Well, I certainly won't use it. I don't use Google anyway, except their search engine. It took a bit of work, but even though I have an Android, they're not getting my address book or agenda. Yup, I might be paranoid (ok, I admit I am...) but Google knows far too much about its users.

As Eric Schmidt recently said: "At the moment we know roughly who you are, roughly what you care about, roughly who your friends are." And according to the article (and simple common sense), "Google would likely store more personal information about its users in the future." This new mailfiltering proves just that...

That doesn't spell much good for the future...