Bug 4503 - trusted_networks fails with IPv6 Received header
Summary: trusted_networks fails with IPv6 Received header
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: 3.0.4
Hardware: Other other
: P5 normal
Target Milestone: 3.3.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 4964
Blocks:
  Show dependency tree
 
Reported: 2005-07-26 00:14 UTC by Mike Klinkert
Modified: 2008-03-14 07:55 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Klinkert 2005-07-26 00:14:51 UTC 
Hi,

I've discovered a new misfiring of ALL_TRUSTED (-3.30). Previously ALL_TRUSTED 
fired when obscure Received: headers were detected. This is fixed in 
SpamAssassin 3.0.4. However, I'm currently testing some mail servers which are 
connected to the Internet via IPv6 (currently IPv6 tunnels over IPv4). 
Whenever two such mail servers exchange messages, SpamAssassin adds a score of 
ALL_TRUSTED -3.30.

I'm using MailScanner-4.43.8 with SpamAssassin 3.0.4. I've added several 
combinations of the IPv6 address (with and without the "IPv6:" prefix) 
to "trusted_networks" and "internal_networks", but all to no avail.

Below is such a Received: header (some info obscured). Note that the IDENT:... 
is not at fault here. A secure identd is used, which works flawlessly on 
messages received via IPv4.

*******************************************************
Received: from mx1.<srcdomain>.<tld> (IDENT:5vY5WszBDM9k0/i471qw4anH+ocuXZb4@
[IPv6:2002:<byte12>:<byte34>::1])
	by mx1.<destdomain>.<tld> (8.13.4/8.13.4) with ESMTP id j6Q3Grve025177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <<email>@<dstdomain>.<tld>>; Tue, 26 Jul 2005 05:16:59 +0200
*******************************************************
Comment 1 Justin Mason 2006-06-23 15:10:36 UTC 
does this still occur with 3.1.x?
Comment 2 Mark Martinec 2006-08-30 18:49:48 UTC 
See also bug 4965.
Comment 3 Justin Mason 2007-04-16 05:32:30 UTC 
needs checking in 3.2.x
Comment 4 Justin Mason 2007-04-17 13:07:40 UTC 
reading into this -- basically, SA doesn't yet support IPv6 trusted_networks
(bug 4964, as Mark noted).  This didn't make 3.2.0, either, and is probably
going to be too big for 3.2.x in general :(
Comment 5 Justin Mason 2008-03-14 07:55:57 UTC 
fixed by bug 4964