/etc/couriergrey/whitelist_ip is in couriergrey 0.3.2-5build2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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
# 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)
|