[vox-tech] Test/Upgrade

[Rick Moen]

Quoting Bill Broadley (bill at 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" "root at lugod.com" {
>   fileinto "admin.root";
>   redirect :copy "poor.soul at randomdomain.com";
> }

If I understand this bit of Postfix plumbing correctly, this is
functionally exactly the same as having /etc/aliases entry
root: poor.soul at 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