Re: negative score from ALL_TRUSTED

[Arvinn Løkkebakken <ar...@whitebird.no>]

Matt Kettler wrote:

> At 09:07 AM 3/31/2005, Arvinn Løkkebakken wrote:
>
>>> You have a broken trust path. ALL_TRUSTED should *never* match email
>>> from outside your network.
>>>
>> But it does anyway, even when trust path is set correctly:
>>
>> http://bugzilla.spamassassin.org/attachment.cgi?id=2508
>
>
> Hmm. Well, that happens if and only if SA can't parse your received 
> headers: Ususaly broken AV appliances that insert a "by" clause in 
> front of the "from" clause cause this.
>
Just like I did mention myself.

To me it looks like Qmail servers tend to produce Received headers like 
this:

Received: from rai93-1-82-231-188-165.fbx.proxad.net (@82.231.188.165)
  by a.trusted.qmail.server.eample.com with SMTP; 1 Apr 2005 02:02:17 -0000

I'm not sure if this always is the reason the times I've had problems 
with ALL_TRUSTED misfire. Nor am I sure when and why Qmail produces a 
Received header like this. Maybe because the string in front of @ only 
contained unwritable characters? Nevertheless, SA fails to parse it.

> One of Roy's headers does look strange to me, and might be unparseable 
> because the from and by are in separate headers. I've never seen a 
> working mailserver do that before, but that doesn't mean it's not 
> parsable by SA.
>
> However, looking at Roy's headers, it looks like he might have a NATed 
> mailserver too, which would definitely cause a broken trust path.
>
> However, you might want to suspect that problem after trying to set 
> trust path. Setting a trust path may or may not fix the problem, but 
> at least it's quick and easy.
>
I aggree, and this is probably the reason most of the times. I just felt 
it was necessary to comment on your *never*. It_is_likely that 
ALL_TRUSTED will misfire as long as it trusts unparseable headers 
containing whatever IP-addresses. Generally we should acknowledge the 
fact that this bug exists in 3.0.2 and not categorically blame it on the 
frequently TrustPath misunderstanding.

> The patch is also not a sure-fire fix, as it will NOT help anyone 
> suffering from the broken-trust-path problem. It will ONLY help those 
> suffering from a broken mailserver.

True, the patch doesn't have anything to do with the trust-path problem. 
However, claiming it will ONLY help those suffering from a broken 
mailserver is very daring. Does this mean you are 100% sure that SA will 
succeed in parsing every Received header (that is not produced by a 
broken appliance) in the world?

Arvinn

Re: negative score from ALL_TRUSTED

[Matt Kettler <mk...@evi-inc.com>]

Arvinn Løkkebakken wrote:

> I aggree, and this is probably the reason most of the times. I just
> felt it was necessary to comment on your *never*. It_is_likely that
> ALL_TRUSTED will misfire as long as it trusts unparseable headers
> containing whatever IP-addresses. Generally we should acknowledge the
> fact that this bug exists in 3.0.2 and not categorically blame it on
> the frequently TrustPath misunderstanding.
>
I think you misunderstood my use of *never*. I didn't mean to imply the
rule never failed except due to broken trust path.

To requote myself:
"You have a broken trust path. ALL_TRUSTED should *never* match email
from outside your network."

I suppose I should have re-phrased the first part "you probably have a broken trust path". 

However, the "ALL_TRUSTED should *never* match email from outside your network" is 100% correct. It SHOULD never hit mail from outside, if it was working correctly. 

I suppose I'm just so used to seeing NATed mail headers and equating it to the trust path configuration issue because I see it several orders of magnitude more frequently than the mis-parsing bug. NATed MXes are now as common as dirt in new networks. There's just rarely any reason to ever have a non-NATed one other than not understanding how to use the Cisco PIX "static" command, or equivalent commands in your firewall of choice.

Broken AV appliances and weird MTAs are not too uncommon, but not nearly as common as NATed servers.

However, you are correct, I should acknowledge both.