[ale] the _REAL_REASON_ for the admin change

[Michael H. Warfield]

Hey Jim,

On Wed, 2008-02-20 at 16:09 -0500, Jim Popovitch wrote:
> On Wed, Feb 20, 2008 at 3:46 PM, Randy Ramsdell
> <rramsdell at livedatagroup.com> wrote:
> >  I am not sure what is meant by something being a  third level of
> >  protection because each is equally important. It also appears that
> >  viruses anr't an issue here since I never get hits for viruses off this
> >  list.
> >  On thing to note is that Spamassassin will check these lists and it will
> >  check ALL mail relays within a message header whereas Sendmail is
> >  probably only checking the connected ip.

> You DON"T want spamassassin checking files that haven't been first
> cleared by a virus scanner.  SA does too much interaction, via perl,
> with emails that it's not worth the risk.   Always use this order:

	We could certainly have many many debates about what should go in what
order.  I'm generally in the camp that front-loads the checks with the
lightest loads and maximum yield to get rid of the easy stuff first
before you get to the processor intensive stuff.

	Protocol checking (and grey-listing if you are into that, it does give
some benefit over and above the greet_pause sendmail feature but would
be inappropriate for a mailing list such as this) would have to precede
all of this.

>    1) DNSBL checks
>    2) Virus checks
>    3) Spam checks

	Why would you put blacklists after the above.  Blacklists are the
easiest (lightest load on the system, next to protocol validation) and
why do any of the above checks if you are going to blacklist the sucker
anyways?

>    4) blacklists

	Why bother with a whitelist next to last?  If it passes the above
checks, why need a whitelist.  If it doesn't pass the above tests, it
won't get to the whitelist.  Either way, the whitelisting is irrelevant
at this spot, other than passing over the valid recipient check, but
it's irrelevant for that as well.

>    5) whitelists

	Some would also argue that you should do a valid recipient test very
VERY early on (like right after the protocol checks, in the MTA, and
before any scanning).  After all, why bother to scan the sucker if
there's no valid recipients to deliver it to?  You can also rejected it
at the SMTP protocol level and not have to worry about DSN's either.

>    6) valid recipient checks

	You also forgot to include "valid sender" checks such as SPF, DKIM, and
a variety of spoofed source checks, but I guess that could be considered
under "Spam checks" (which I generally consider content checks more than
anything else).

> -Jim P.

	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080220/6979d47b/attachment.bin