Re: negative score from ALL_TRUSTED
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.
RE: negative score from ALL_TRUSTED
The server is NATed. I'll try setting a trust path and see what happens. > -Original Message- > From: Matt Kettler [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 31, 2005 10:09 AM > To: Arvinn Løkkebakken; Matt Kettler > Cc: ROY,RHETT G; 'users@spamassassin.apache.org' > Subject: Re: negative score from ALL_TRUSTED > > 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. > > 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. > > 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. >
Re: negative score from ALL_TRUSTED
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 - 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
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. 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. 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.
Re: negative score from ALL_TRUSTED
Matt Kettler 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 Happens when spamassassin fails to parse the Received header(s) comtaining the untrusted host(s). Arvinn
Re: negative score from ALL_TRUSTED
ROY,RHETT G wrote: > I just had a spam get through with a negative score from ALL_TRUSTED. > > # The message was never sent via an untrustworthy host. > header ALL_TRUSTED eval:check_all_trusted() > describe ALL_TRUSTEDDid not pass through any untrusted hosts > tflags ALL_TRUSTED nice > > Can someone tell me what that rule does? Original message is attached. > You have a broken trust path. ALL_TRUSTED should *never* match email from outside your network. Please see the Wiki: http://wiki.apache.org/spamassassin/TrustPath/ and look up trusted_networks in man Mail::SpamAssassin::Conf
