Quoting Bill Broadley (b...@broadley.org):
> Do you really think lugod's new mail server should be some weird
> conglomoration of upstream source,
> and out of tree patches?
>
> That's batshit insane in my book.
Fortunately, I nowhere suggested that. Not intending to complain, and I
gladly acknoledge that we have the best of intentions in this
conversation and both have a sincere desire to help LUGOD, but this is
the second time consecutively that I've pointed out that Boggis's ideas
in his EximConfig tarball can and should be implemented with packaged
software only and standard sysadmin work on conffiles, etc., for
purposes of integration.
> More details below.
Apologies, good sir, but it's late, I've had a very long day and am
tired, and therefore will merely attempt in all benevolence to cut to te
chase.
Boggis's tarball (and I'll speak from memory, here, so pardon a small
amount of vagueness) is targeted primarily at Debian sysadmins and
provides directions for which Debian binary packages to installto
construct a highly effective MTA + antispam system built around the
exim4-daemon-heavy package, the sa-exim package originally written by
Marc Merlin, the spamassassin package, one or two packages related to
SPF, and optional binary-packaged components that can be included to
carry out greylisting, teergrubing (keeping records in MySQL), and
probably a couple of other optional angles I'm not quite recalling. It
also provides a set of Exim4 conffile snippets that unpack directly into
the /etc/exim4 tree and integrate into the Debian-style many-fragments
configuration structure that Debian package devs seem to like so much
(viz. /etc/apache2/* and all its pieces), where the intent is to ensure
smooth future upgrades of the distro packages (in this case,
exim4-daemon-heavy and sa-exim) without anything breaking, segregating
out local configuration as separate from what is replaced during
upgrade. Likewise provided as working examples are controls exposed
for tweaking all of this. (See tarball contents.)
Part of what is distinctively good about the architecture Boggis
describes with the cited packages as an example is that it does most of
the heavy antispam lifting using MTA rulesets, a working Exim4 set of
which are provided. This is critical to limiting RAM and CPU splurging,
because MTA rules are typically implemented using C code (hence small
and fast), so there's a huge amount of benefit in rejecting 95+% of
arriving spam using MTA rules before handing off the SMTP bitstream to a
ponderous, slow Perl daemon (spamd) to measure the spamicity of the
remaining 5%. Boggis provides some truly clever MTA rules such as te
'callout' ones that test whether the delivering remote MTA is operating
in an RFC-compliant manner _prior_ to accepting the mail with 250
Accept.
The role of sa-exim is also key in Boggis's example, in that Marc
Merlin's code enables (likewise) a consultation by the MTA to spamd to
measure spamicity prior to the MTA deciding whether to say 250 Accept or
550 Die spammer die or 450 Please stick around while I greylist you.
Among several advantages is that this decision-making _during_ the
ongoing SMTP conversation prevents any possibility of creating
backscatter spam.
Now, the working files drop straight into Debian's _exim4_ setup,
whereas many sysadmins would prefer to use Postfix, or Courier-MTA, or
(God help you) qmail. Fine. This doesn't permit the drop-in
functionality the way you can just unpack the stuff Boggis intends for
the /etc/exim4 tree and have it Just Work{tm} effortlessly, _but_ all of
Boggis's excellent ideas are right there to study and implement as you
desire in whatever packaged MTA the sysadmin prefers.
More can be easily learned by having a look at Boggis's documentation
and his tarball. (I will mention once again that the tarball is _not_
a tarball of software, but rather of MTA rules and conffile snippets,
etc.) Or, of course, if readers already think they have the whole thing
covered and have nothing to learn from Boggis and Merlin's work, they
can bag it and do something else.
OK, then?
I'm sorry, and intend no offence, but I'm going to assume (so I can
hurry up and get to sleep) that the above covers what needs to be said,
ergo I'm not going to read the rest of your post at this time. If
there's something significant you think I really ought to read, I would
welcome your telling me so.
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
