Bug 3968 - IP_IN_RESERVED_RANGE should go
Summary: IP_IN_RESERVED_RANGE should go
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: unspecified
Hardware: Other other
: P5 normal
Target Milestone: 3.1.0
Assignee: Daniel Quinlan
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-15 10:14 UTC by davidoc
Modified: 2005-01-10 03:11 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
suggested patch patch None Theo Van Dinter [HasCLA]
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 davidoc 2004-11-15 10:14:17 UTC 
IP_IN_RESERVED_RANGE, in Constants.pm, is out of date. Specifically, 71/8 and 72/8 are no longer reserved, according to http://www.iana.org/assignments/ipv4-address-space.
Comment 1 Theo Van Dinter 2004-11-16 12:32:01 UTC 
whois agrees with this, so I'll get up a patch in a minute.
Comment 2 Theo Van Dinter 2004-11-16 12:33:52 UTC 
Created attachment 2517 [details]
suggested patch
Comment 3 Michael Parker 2004-11-16 12:59:00 UTC 
+1
Comment 4 Daryl C. W. O'Shea 2004-11-16 14:06:37 UTC 
According to http://www.cymru.com/Documents/bogon-bn-nonagg.txt (linked to from
http://www.cymru.com/Documents/bogon-list.html), the following /8s are all IANA
reserved.  I've checked them by hand via ws.arin.net.

[0125]|		# 000/8, 001/8, 002/8, 005/8
2[37]|		# 023/8, 027/8
3[1679]|	# 031/8, 036/8, 037/8, 039/8
4[129]|		# 041/8, 042/8, 049/8
50|		# 050/8
7[3-9]		# 073-079/8
89|		# 089/8
9[0-9]|		# 090-099/8
1[01][0-9]|	# 100-119/8
12[0-6]|	# 120-126/8
17[3-9]|	# 173-179/8
18[012345679]	# 180-187/8, 189/8
19[07]|		# 190/8, 197/8
223|		# 223/8

-Daryl
Comment 5 Justin Mason 2004-11-16 16:55:43 UTC 
+1
Comment 6 Theo Van Dinter 2004-11-16 16:57:55 UTC 
committed.
Comment 7 Andrew Daviel 2005-01-10 00:59:39 UTC 
Just spent a couple of hours trying to understand why SA 3.0.0 was giving -2.8
to some spam from a 72/8 network (not being overly familiar with the inner
workings), and realized it was the trusted/untrusted algorithm in
Received.pm:parse_received_headers acting up.

Why is SA trusting these reserved addresses anyway ? People should not be using
random reserved blocks for NAT (which I assume is the reason for the auto-trust
algorithm), they should be using the RFC 1918 blocks 10/8, 172.16/12,
192.168/16. We certainly should not be trusting mail from reserved blocks;
rather the reverse I would think.
Comment 8 Daniel Quinlan 2005-01-10 02:03:22 UTC 
reopening
Comment 9 Daniel Quinlan 2005-01-10 02:04:48 UTC 
working on this and testing patch

Andrew, can you attach your bug ("Create a New Attachment" link on this page)?
Comment 10 Daniel Quinlan 2005-01-10 12:11:48 UTC 
Done.  IP_IS_IN_RESERVED is no longer used in trunk.  A new variable, IP_PRIVATE
describes address spaces that are not publicly routeable and is used in its
place.

I tested this out and the results are definitively better for all code that was
previously using the IP_IS_IN_RESERVED.