Resisting the centralization of network infrastructure
Resisting the centralization of network infrastructure
Posted Aug 19, 2016 7:36 UTC (Fri) by guus (subscriber, #41608)In reply to: Resisting the centralization of network infrastructure by bronson
Parent article: Resisting the centralization of network infrastructure
> If you run your own mail server, pray tell your setup?
I am running Postfix, with Postgrey to do greylisting. Postgrey is already doing 50% of the spam filtering. I used to use RBLs, which were even more effective, but unfortunately the most useful ones shut down. The rest of the spam filtering is done with Spamassassin, but that is started by individual user's mail filters. Spamassassin is also quite effective, and when it lets something true it is a single press of a button in mutt to let Spamassassin learn that an email is spam.
> I just couldn't keep up with the ongoing changes to SPF, DKIM, DNSSEC, RBLs,
Apart from some useful RBLs disappearing, and having to set SPF records on my mail domain names once, I don't seem to need to keep up with anything, at least not more than once in half a year or so. I also don't have to monitor the logs. The few times I do it's mostly because something is stuck in the greylist and that normally solves itself by being more patient.
> And I don't even bother with webmail! Providing a more complete experience with server-side contacts, mobile clients, custom filters, 2factor, automatic expiry, a proper Sent Mail folder, reactive spam filtering, etc...
Hm, maybe this is the difference? I have the mail delivered to a Maildir, and use mutt to read it directly from there. I'm not running an IMAP or webmail server to access it. If I want to access my email remotely, I just SSH into the server.
Posted Aug 19, 2016 8:03 UTC (Fri)
by mbunkus (subscriber, #87248)
[Link]
There are several ways to deal with this, e.g. the mailing list manager can send from "Your Name via Mailing List <mailing-list-manager-address@domain>" instead of your address. But a lot of mailing lists don't support such a feature or aren't configured for it.
Another way would be for you to include the outgoing mail servers used by those mailing lists in your own SPF record.
The problems don't stop with mailing lists which you might not even use. Even worse are cases you cannot do anything about such as when a receiver has set up forwarding on the mail server level.
Think of Postfix' virtual alias maps. For example, on the main mail server for $customer the $customer has set up a forwarding to a private account with something like "jdoe@custom.er jdoe@custom.er,john.doe@googlemail.com". What now happens when you send to jdoe@custom.er is: 1. $customer's mail server may check your SPF record and see that it's good. 2. $customer's mail server stores one copy and forwards a second copy to Google Mail. 3. Google Mail checks your SPF record (because the sender of said email is still you) and see that the server the mail originates from ($customer's server) is not listed in your SPF record.
That second mail is now silently stored in Google's spam folder, and there's nothing you can do about it. You're at the mercy of everyone else setting up their forwardings in a way that's SPF compliant.
The error reporting is pretty bad, too. For the example above you might only note there's something wrong when $customer comes to you and says "hey, your mails are all marked as spam!"
The situation gets even more complicated when you add DKIM to the mix. Similar problems arise. Basically both schemes rely on everyone having their systems set up correctly, which is a practical impossibility.
Resisting the centralization of network infrastructure