[ale] the _REAL_REASON_ for the admin change

[Jim Popovitch]

2008/2/20 Michael H. Warfield <mhw at wittsend.com>:
>         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.

I think that generally is a good path to follow.  However, with email
you want to do body checks only after you know you have a clean body
(same for sports physicals too I would presume).  ;-)

>         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

Blacklists would be for some headers not parsed out by the MTA.  Most
(if not all) MTAs initially, during the connect phase, look at To:,
From:, HELO, and connecting host.  HOWEVER Sender:, Reply-To: and
other headers aren't yet known and can't be known until the email
itself (body included) is parsed apart.

>         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

Whitelists would by-pass further checks, specifically spam checks.
This would be important for mailinglists (such as ALE or SPAM-L) that
periodically have folks submit emails with spammy content inline.

>         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.

Recipient checks should only be done AFTER DNSBLs and blacklists
because if not it would be very easy to hammer a server to determine
accepted accounts.

>  >    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).

Spamassasin does SPF DK/IM and a variety of spoofed checks ;-)

-Jim P.