-
Notifications
You must be signed in to change notification settings - Fork 0
/
whitelist_ip.dist
165 lines (152 loc) · 7.45 KB
/
whitelist_ip.dist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
#############################################################################
#
# This whitelist is copied from
# http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt
#
# Couriergrey should fully support the format used there, but has some
# extensions to the format, to support class-less routing and IPv6 addresses.
#
# Due to the extensions, the following entries can be written as well:
#
# 192.168.0.0/16 # for all addresses from 192.168.0.0 to 192.168.255.255
# 172.16.0.0/12 # for addresses in the class B private network addresses
# 2001:abcd::/32 # for an IPv6 network
# ::ffff:192.168.0.0/112 # it is also valid to use mapped IPv4 addresses
#
#############################################################################
# This is a list of manual whitelist entries that have been discovered
# so far for various reasons.
# This is not meant to be a comprehensive list of all servers that should be
# considered legitimate, merely a list of servers that for one reason or
# another may either have some type of problem with the Greylisting method,
# or because of a recognized need to avoid the delay that it may cause.
# These are common entries that most people using greylisting will probably
# want to have. If you happen to discover ones that aren't in this list,
# or that the IP's in this list have changed, please let me know at
# [email protected], after reading the next paragraph carefully.
# PLEASE NOTE - PLEASE NOTE - PLEASE NOTE - PLEASE NOTE - PLEASE NOTE
# Any submission for inclusion to this list should be accompanied by
# the IP's or address range of the mailservers that have a problem sending
# to Greylisting servers, the name/url of the organization running these
# problem servers, and a detail of the specific reason(s) why their systems
# have a problem with Greylisting, and also the type of mail server softare
# they are running (if known).
# Valid reasons for inclusion on this list are:
# 1. They have a pool of round-robin outbound mail servers that spans more
# than one /24 netblock.
# 2. They have software that considers a 4xx temporary mail failure to be
# a permanent bounce.
# 3. Their mail servers retry delivery for 4xx failures continually with
# no delay.
# 4. Their mail servers either don't retry at all, or have a very long
# retry delay (more than 5 hours).
# 5. The mail servers use a unique sender address for each delivery
# attempt, even for the same piece of mail. (also known as VERP).
# 6. The mail servers host high volume mailing lists with a general appeal
# that try to track bounces by using a unique sender address for each
# mail (also known as VERP).
# Generally, submissions of servers that do not meet at least one of the
# above criteria will not be accepted for inclusion in this list. This
# includes servers that handle Greylisting ok, but that you consider
# "legitimate", and don't want their mail delayed. Since "legitimate" is a
# subjective distinction, I believe that those types of whitelist entries
# are better left for individual administrators to decide.
# ****** IF YOU ARE USING A DIFFERENT IMPLEMENTATION THAN RELAYDELAY ******
# Before submitting a potential entry, please check that your implementation
# uses the 451 error code (not 450 or another 4xx code). Some problems have
# been reported for sites like MSN/Hotmail, Prodigy, and various other
# senders that appear to be having "weird" retry patterns (sometimes
# resulting in bounces) when using code 450 or others.
# Because error code 450 is most commonly used for a mailbox lock failure,
# many sites seem to treat it as a very short duration failure, and will
# retry several times within seconds, and then bounce the mail, while they
# handle a code 451 more "normally".
# Here's an example command to use in a mysql shell to insert
# a whitelist entry (assumes defaults from dbdef.sql):
# INSERT INTO relaytofrom (relay_ip, record_expires, create_time)
# VALUES ('127.0.0.1', '9999-12-31 23:59:59', NOW());
127.0.0.1 # Of course we don't want to delay ourselves or local users
192.168 # Don't delay our private networks either
10 # Private net (class A)
172.16 # Another private net (inidividual entries, since can't
172.17 # do a /12 netmask easily
172.18
172.19
172.20
172.21
172.22
172.23
172.24
172.25
172.26
172.27
172.28
172.29
172.30
172.31
# Public Servers
12.5.136.141 # Southwest Airlines (unique sender, no retry)
12.5.136.142 # Southwest Airlines (unique sender, no retry)
12.5.136.143 # Southwest Airlines (unique sender, no retry)
12.5.136.144 # Southwest Airlines (unique sender, no retry)
12.107.209.244 # kernel.org mailing lists (high traffic, unique sender per mail)
63.82.37.110 # SLmail
63.169.44.143 # Southwest Airlines (unique sender, no retry)
63.169.44.144 # Southwest Airlines (unique sender, no retry)
64.7.153.18 # sentex.ca (common pool)
64.12.137 # AOL (common pool) - http://postmaster.aol.com/servers/imo.html
64.12.138 # AOL (common pool)
64.124.204.39 # moveon.org (unique sender per attempt)
64.125.132.254 # collab.net (unique sender per attempt)
#64.233.162 # zproxy.gmail.com (common server pool, bad 451 handling?)
#64.233.170 # rproxy.gmail.com (common server pool, bad 451 handling?)
#64.233.182 # nproxy.gmail.com (common server pool, bad 451 handling?)
#64.233.184 # wproxy.gmail.com (common server pool, bad 451 handling?)
#65.82.241.160 # Groupwise?
66.94.237 # Yahoo Groups servers (common pool, no retry)
66.100.210.82 # Groupwise?
66.135.209 # Ebay (for time critical alerts)
66.135.197 # Ebay (common pool)
66.162.216.166 # Groupwise?
66.206.22.82 # PLEXOR
66.206.22.83 # PLEXOR
66.206.22.84 # PLEXOR
66.206.22.85 # PLEXOR
66.218.66 # Yahoo Groups servers (common pool, no retry)
66.218.67 # Yahoo Groups servers (common pool, no retry)
66.218.69 # Yahoo Groups servers (common pool, no retry)
#66.249.82 # gmail (common server pool, bad 451 handling)
66.27.51.218 # ljbtc.com (Groupwise)
#66.89.73.101 # Groupwise?
#68.15.115.88 # Groupwise?
#72.14.204 # qproxy.gmail.com (common server pool, bad 451 handling?)
152.163.225 # AOL (common pool)
194.245.101.88 # Joker.com (email forwarding server)
195.235.39.19 # Tid InfoMail Exchanger v2.20
195.238.2 # skynet.be (wierd retry pattern, common pool)
195.238.3 # skynet.be (wierd retry pattern, common pool)
#204.60.8.162 # Groupwise?
204.107.120.10 # Ameritrade (no retry)
205.188.139.136 # AOL (common pool)
205.188.139.137 # AOL (common pool)
205.188.144.207 # AOL (common pool)
205.188.144.208 # AOL (common pool)
205.188.156.66 # AOL (common pool)
205.188.157 # AOL (common pool)
205.188.159.7 # AOL (common pool)
205.206.231 # SecurityFocus.com (unique sender per attempt)
205.211.164.50 # sentex.ca (common pool)
207.115.63 # Prodigy (broken software that retries continually with no delay)
207.171.168 # Amazon.com (common pool)
207.171.180 # Amazon.com (common pool)
207.171.187 # Amazon.com (common pool)
207.171.188 # Amazon.com (common pool)
207.171.190 # Amazon.com (common pool)
#209.104.63 # Ticketmaster (poor retry config)
209.132.176.174 # sourceware.org mailing lists (high traffic, unique sender per mail)
211.29.132 # optusnet.com.au (wierd retry pattern and more than 48hrs)
213.136.52.31 # Mysql.com (unique sender)
#216.136.226.0 # Yahoo Mail?
#216.157.204.5 # Groupwise?
#216.239.56 # proxy.gmail.com (common server pool, bad 451 handling?)
217.158.50.178 # AXKit mailing list (unique sender per attempt)