Re: [Exim] Final Peer Review Sought: "Spam Filtering for MXs…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Tor Slettnes
Datum:  
To: Sam Michaels
CC: Exim User's Mailing List
Betreff: Re: [Exim] Final Peer Review Sought: "Spam Filtering for MXs" HOWTO
On Fri, 2004-07-09 at 20:27, Sam Michaels wrote:
> In the generic exim conf you said to add:
> pipeline_advertise_hosts = :
> ...when it should be pipelining_advertise_hosts. I believe someone
> mentioned this on the list already.


Oh, I missed that. Thanks.


> I commented out all the DNS blacklists...I don't trust them.


Though they were used only to impose delays, not to reject.
A DNSbl listing is a good enough indicator of ratware senders that it's
worth trying to trip them up.

> I replaced your SPF code using spfquery with the exiscan-ACL built in SPF:
>
> # Sender Policy Framework
>    warn
>      spf = fail:neutral
>      set acl_m0 = $sender_host_address ($sender_helo_name) is not \
>                   authorized to deliver mail for <$sender_address>.
>      set acl_m1 = SPF check failed ($spf_result).


Actually I also included Exiscan-ACL's SPF in the latest version (0.08).
I haven't tested it, as it is not yet part of Debian's
"exim4-daemon-heavy".

In the snippet above, you will end up rejecting if SPF returns
"neutral"? That seems a bit harsh...


> Commented out the greylistd code


Don't like greylisting in general, or greylistd in particular? (The
section "Adding Greylisting" lists a couple of different
implementations, including an inline Exim/MySQL one).

> In the data ACL, I added the SPF header after you add a missing Message-ID:
>
> # Always add SPF-Received header
>    warn
>      message             = $spf_received


You can actually do that in the same ACL where the SPF check is
performed (presumably acl_mail_from). Even though the message data has
not been received yet, Exim will add the "message = " text later.

> I have a hardcoded system wide limit of 5.0 for SpamAssassin...so I
> commented out all the SA code and used my old one:
>
> # Reject spam messages with score over 5, using an extra condition.
>    deny
>      message = Message rejected as spam ($spam_score / 5.0)
>      spam = nobody:true
>      condition = ${if >{$spam_score_int}{50}{1}{0}}


Since you will be running as a particular user ('nobody'), any
SpamAssassin settings - including the threshold - are global. Thus, I
would rather set the threshold in SA's "local.cf" than in an explicit
"condition" here...


> Directly before the final accept I add my cryptographic header:
>
> # Add the cryptographic header.
>    warn
>      message = X-Scan-Signature: ${hmac{md5}\
>                  {SECRET}\
>              {$body_linecount}}


Rather than using cryptograhpic signatures, I would create a host list
defining backup MXes, and excempt these hosts from most/all ACL controls
(i.e. pretty high up in the list). For instance, you could add them to
+local_hosts or +relay_from_hosts.


> Seems to be working great so far. I see a ton of "unexpected
> disconnection while reading SMTP command..." from DSL and cable hosts.
> Thanks for a good doc.


Great!

Once you try greylisting, you will be impressed again.

-tor