You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2005/12/09 23:52:54 UTC

Re: false positive in RCVD_IN_SORBS_DUL test

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Matt Kettler writes:
> Daryl C. W. O'Shea wrote:
> 
> > Mail to internal users (from roaming users) isn't the problem though.
> > It's mail to external sites that see that my smart host is the second
> > "public IP hop" and look it up in DUL.  Since my telco continues to
> > refuse to change my generic rDNS, my static IP has been listed in
> > SORBS-DUL and any of our mail not sent from the internal network gets
> > hit by SpamAssassin.
> 
> Yeah, that falls under the "multi-hop behind a dynamic IP with legitimate
> relaying through a non-dynamic server" case.
> 
> Really I think the use of notfirsthop in DUL testing is just plain broken. SA
> should only be checking the host that drops off to your MX against the DULs. It
> shouldn't be backtracking further.

To be honest, I'm inclined to agree -- I thought we *had* fixed that. :(

Is there a bug open about that?

> The current "external, nonprivate, notfirsthop" deals with most common FP cases,
> such as The "no private" fixes the "NATed co-op" case of:
>  private IP -> public (dyn) -> ISP -> Recipient MX -> SA.
> 
> but it is still broken for the case of:
> 
>  public IP -> public (dyn) -> ISP -> Recipient MX -> SA.
> 
> Which is rare, but does exist.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFDmgrGMJF5cimLx9ARArDpAJ4/bKDO9nRe+kKiHS9SdeVhMGWVkgCfQsqO
ioW9WcgbauLUY2KBOdWG1xk=
=KL8o
-----END PGP SIGNATURE-----


Re: false positive in RCVD_IN_SORBS_DUL test

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 09/12/2005 5:52 PM, Justin Mason wrote:

> Matt Kettler writes:
> 
>>Really I think the use of notfirsthop in DUL testing is just plain broken. SA
>>should only be checking the host that drops off to your MX against the DULs. It
>>shouldn't be backtracking further.
> 
> 
> To be honest, I'm inclined to agree -- I thought we *had* fixed that. :(
> 
> Is there a bug open about that?

http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4728