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