Quoting Bill Broadley (b...@broadley.org): > I hear this line of thought, and am always puzzled by it. My recipe is: > 1) run a current OS with a current spam assassin, like the newest ubuntu LTS > or > newest debian stable. > 2) run postfix and whatever glue you like (mail filter, amavis, and amavis-ng > are popular) > 3) use greylisting [...]
I'm puzzled that you're puzzled. What I said was that a distro's out-of-the-box MTA configuration has basically zero spam-rejection, which must be created by local administrative effort. The meritorious configuration you describe is not provided by any Linux distribution's out-of-the-box MTA configuration, but must be created by local administrative effort. So, you agree with, and restate slightly differently, what I said -- yet you claim to be puzzled by what I said? > Your IP reputation (that causes non-delivery of email) can take a REAL > hit if you forward a malicious attachment. Is it really worth having > attachments if major mail services stop accepting email from you? This is solving the wrong problem. If an SMTP host ceases to use alias redirectors (/etc/aliases and ~/.forward) for cross-domain purposes, then the problem of 'forwarding a malicious attachment' to a remote SMTP host basically goes away without the collateral damage of neutering the file-attachment mechanism. (The other type of mail reflector, MLM software such as Mailman and Sympa, makes it easy to avoid being a malware reflector for reasons I won't spend time covering here. It should suffice to note that LUG mailing lists are not a vector for same.) > Heh, well using current software is much easier than engineering it from > scratch. I'll note in passing that implementing some or all of the ideas in Boggis's toolkit entails using current software, and not engineering any from scratch. I would guess that you did not bother looking at Boggis's work before commenting. > Not sure what you get by throwing everything away and using some > ancient guide. It's not an 'ancient guide', but I agree that you aren't sure. That's because, I gather, you didn't look. > Mail servers these days are nearly turnkey. And devoid of spam-rejection upon initial installation of just an MTA from a distro package. So we agree -- and yet you are arguing anyway. Well, I guess that's what I get for being on the Internet. > I'd start recommend with something updated in 2018 instead of 2011 though. The ideas Boggis collected in one place that were excellent in 2011 are sill excellent in 2019. FYI, Michael Paoli recently used Boggis's tarball and docs to create a new MTA configuration for Bay Area Linux User Group, and the only problem he found IIRC was the Perl SPF package reference being outdated. > Greylisting + current SA works wonders + sane postfix checks works > wonders. Keep in mind you can't just update the SA rules, you have to > update SA itself for the best protection. There are a number of things that need to be done with SA, including avoiding using all of the default weightings, for the simple reason that any halfway competent spamhaus tests spamicity against a default spamd configuration before sending. (Competent spammers are relatively rare, but there are enough of them to be a problem.) [problems with use of /etc/aliases or ~/.forward redirection for interdomain reflection:] > There are technical work around that are a pain in the ass. You're probably thinking of software to implement Sender Rewriting Scheme, as invented by Meng Wong in 2003, in the form of a wrapper Perl script intended to rewrite SMTP envelopes, semi-mimicking the way MLM software does that, using a variable envelope return path (VERP). I found this to be not only a pain in the ass but also that the results are downright peculiar, and that it's far more practical to simply cease using /etc/aliases and ~/.forward entries for cross-domain mail reflection. (As I said.) I'm also skittish about trusting pipes to Perl scripts in /etc/aliases (etc.) entries. There's a good (security) reason why the processing of those is now disabled by default in modern distros. > Sieve can do things like: > > if header :contains "To" "r...@lugod.com" { > fileinto "admin.root"; > redirect :copy "poor.s...@randomdomain.com"; > } If I understand this bit of Postfix plumbing correctly, this is functionally exactly the same as having /etc/aliases entry root: poor.s...@randomdomain.com ...except I guess this would make Postfix write a new outbound SMTP envelope, making this a tiny improvement over the /etc/aliases equivalent -- but leaving in place the huge problem that lugod.org would mindlessly reflect any received spam (including as a subcatetory spam with attached MS-Windows malware) that passes MTA checking, and putting lugod.org at war with the receiving MTA's spam defences. That's exactly the problem LUGOD should want to avoid having. Hence my recommendation to dispose of the 'role' reflectors as sadly impractical. But, hey, if y'all would prefer to learn that the hard way, keep using non-MLM mail reflectors, and good luck to you. > Wow, I'd think that would be pretty unpopular and unnecessary. Good luck with that. I gave my advice and said why. Now, if people want to keep being caught in the middle of the spam war, cool, good luck. > I can see a man week to build it from scratch. I recommend a week _with entirely standard packaged software_ (as you would understand if you'd bothered to look at what I recommended) so that the admin fully understands what he/she is setting up and can run it properly. > Which leads to one of my favorite stories: > > http://web.mit.edu/jemorris/humor/500-miles Yeah, my friend Trey Harris wrote that when we both were at VA Linux Systems. He has a related FAQ. https://www.ibiblio.org/harris/500milemail-faq.html _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech