Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
166 lines (152 sloc) 7.45 KB
#############################################################################
#
# 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
# eharris@puremagic.com, 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)
You can’t perform that action at this time.