Ping for primary MX

[Kenneth Porter <sh...@sewingwitch.com>]

Has anyone written a plugin for SA3 that pings the higher-priority MX peers 
for a domain and boosts the spam score if they're up?

Re: Ping for primary MX

[Daniel Quinlan <qu...@pathname.com>]

Daniel Quinlan <qu...@pathname.com> writes:

> No, but by my quick test here it would help a bit.  0.22% of my spam and
> 9% of my missed spam was sent via my secondary MX.

Oops, that 0.22% is the number of _missed_ spam messages that hit the
rule out of all of my spam.  It's about 8% of my spam overall.

Still definitely worth writing a plug-in, I think.

I think the best way is to do look at the time delay, if it's low, then
do call-back to your higher priority MXes until you get a positive
result (or not).  If I recall correctly, someone wrote an eval test that
did call backs using a Perl SMTP module.  I think it's somewhere in
bugzilla.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: Ping for primary MX

[Daniel Quinlan <qu...@pathname.com>]

>> Perhaps something like:
>>
>>  - a higher priority MX is up
>>  - the mail was delivered from a secondary MX with little or no delay

Kenneth Porter <sh...@sewingwitch.com> writes:

> My concern was primarily for the secondary, where you don't know the delay 
> until you forward. Are you saying that the first rule runs on the 
> secondaries, and the second rule runs on all but the lowest-priorty MX?

No, it's a logical "and" rule.  Both need to match for it to be
spamsign.  If the filter is actually run *on* the secondary, it still
works since the delay will be just about zero.  However, a lot of places
just run the spam filter on the primary and have secondaries forward it
to, or on an internal host to which all MXes deliver their mail.  You
can't assume every MX is running SpamAssassin independently.
 
> I've got a secondary which receives very little traffic for itself, and 
> virtually all of the remaining traffic is spam destined for a primary 
> elsewhere. It's running SA from MIMEDefang, configured to reject anything 
> scoring 10 or more. Giving it a rule like the one proposed here would allow 
> it to reject more instead of queuing it to the primary.

The rule should work regardless of where it's run.  It also should
ideally work for forwarded email (assuming trusted_networks is set up, I
don't expect it to check every relay hop, just the untrusted->trusted
one.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: Ping for primary MX

[Kenneth Porter <sh...@sewingwitch.com>]

--On Sunday, September 05, 2004 2:15 PM -0700 Daniel Quinlan 
<qu...@pathname.com> wrote:

> It's also not just enough to ping the higher priority MX peers because
> the spam checker might be running on the primary MX only so it would
> only receive delayed mail from the backup MXes once it was back up.
>
> Perhaps something like:
>
>  - a higher priority MX is up
>  - the mail was delivered from a secondary MX with little or no delay

My concern was primarily for the secondary, where you don't know the delay 
until you forward. Are you saying that the first rule runs on the 
secondaries, and the second rule runs on all but the lowest-priorty MX?

I've got a secondary which receives very little traffic for itself, and 
virtually all of the remaining traffic is spam destined for a primary 
elsewhere. It's running SA from MIMEDefang, configured to reject anything 
scoring 10 or more. Giving it a rule like the one proposed here would allow 
it to reject more instead of queuing it to the primary.

Re: Ping for primary MX

[Daniel Quinlan <qu...@pathname.com>]

Kenneth Porter <sh...@sewingwitch.com> writes:

> Has anyone written a plugin for SA3 that pings the higher-priority MX
> peers for a domain and boosts the spam score if they're up?

No, but by my quick test here it would help a bit.  0.22% of my spam and
9% of my missed spam was sent via my secondary MX.  It's just never been
a high enough of a priority to actually write a rule.

It's also not just enough to ping the higher priority MX peers because
the spam checker might be running on the primary MX only so it would
only receive delayed mail from the backup MXes once it was back up.

Perhaps something like:

 - a higher priority MX is up
 - the mail was delivered from a secondary MX with little or no delay

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/