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