You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2004/09/15 21:50:21 UTC

[Bug 3530] ALL_TRUSTED false positive

http://bugzilla.spamassassin.org/show_bug.cgi?id=3530





------- Additional Comments From ajs+spamassassin@aeschi.ch.eu.org  2004-09-15 12:50 -------
With 3.0.0-rc5, I'm still seeing ALL_TRUSTED coming up when
it's clear that this isn't the case. Mostly, what happens is
that SA fails to detect _any_ relays, so num_relays_trusted ==
num_relays_untrusted == 0.

Anyhow, the current logic says that ALL_TRUSTED is set unless
num_untrusted > 0. I believe that this is flawed and that we
should count the total received lines and not flag ALL_TRUSTED
unless we can definitely say that we have recognised all the
received headers? i.e. that num_relays_received ==
num_relays_trusted and num_relays_untrusted == 0?

What do you think?

Example spam attached that flags ALL_TRUSTED (IMHO) incorrectly.

Cheers,
Al.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 3530] ALL_TRUSTED false positive

Posted by Loren Wilton <lw...@earthlink.net>.
> Are there any MTAs that don't put a "Received:
> ... from ... by" header with the incoming host details ?

Well, in your own posting, the first Received line is

Received: (qmail 98292 invoked by uid 500); 17 Sep 2004 23:00:01 -0000


        Loren


Re: [Bug 3530] ALL_TRUSTED false positive

Posted by Nick Leverton <nj...@leverton.org>.
So an unrecognised handover should count as untrusted rather than being
ignored ?  Maybe with some check for only bracketed terms as opposed to
completely unrecognised.  Are there any MTAs that don't put a "Received:
... from ... by" header with the incoming host details ?

Nick