Hetzner - DokuWiki

Mailserver Greylisting/en

Inhaltsverzeichnis

Greylisting

Greylisting is often touted as the "newest weapon" against spammers. The effectiveness is currently not bad, even if the spammers will adapt sooner or later.

Therefore, the combination of greylisting and public blacklists offers greylisting for the rapidly-changing sender and blacklisting for permanent senders.

Operation

With greylisting, a basic principle of many spammers — but also many viruses — gets broken: in the shortest possible time, send as many mass emails as possible.

Greylisting uses the fact that emails, when they cannot be delivered, are not immediately returned with an "undeliverable" error, but the transfer is attempted several times.

Many senders of bulk mail on the other hand only try the delivery once. If the first delivery is artificially blocked by a temporary 400-type error, then the delivery is immediately canceled. Regular emails from legitimate senders, as well as newsletters and the like, are delivered successfully via a second try.

This method offers many advantages:

  • Less spam that needs to be processed by subsequent filters
  • Blocks only junk email, viruses, worms and trojans
  • No "false positives" by the greylisting filter
  • Normal emails are not blocked and are not lost

Three parameters are technically stored in a database by the greylisting filter:

  • Sender address
  • Recipient address or the recipient domain
  • IP address of the sending mail server

In addition, more information about the validity of each entry is stored in the database, because with unlimited validity of each entry, the database would be very crowded quickly.

Therefore, the following restrictions are recommended:

  • Entries should always only be valid for a short time (for example 35 days), but they must be extended for each new "hit" again. This ensures that stale entries are eliminated from the database, but regular contacts remain permanently in the database.
  • If a re-delivery is not attempted within 12 hours, the entry should also be removed from the database again.
  • The re-delivery attempt should be permitted only after at least 3–5 minutes, so that a "rapid-fire" of spam emails can not overcome the greylisting barrier.

Problems

A small downside should not be ignored: the first email from an unknown address will have an extra delay whose length typcially includes 5 minutes due to greylisting, plus the extra time until the server makes its second communication attempt (this has been observed to be as much as 1 hour). Subsequent emails from sender addresses that are know as being "serious" are recognized but not re-examined, so that the regular email traffic occurs without delays or other adverse effects.

With non-RFC-compliant mail servers, there could also be a problem: these mail servers could possibly react to the temporary errors during transmission (as provoked by the greylisting) with the cancellation of the transfer and the immediate return of the mail as "undeliverable" to the sender. In such cases, it is advisable to maintain a whitelist for such a problematic server — even though actually the operator of the sending email server should resolve the misconfiguration.

For outgoing mail, the greylisting filter must not be used: the sending email program in the workplace would annoy the user with their own error messages. Clever greylisting filters enter the sender-receiver combination as "authorized" to the filter database, so that answers to your own emails are delivered immediately without delay. The fact that the IP address of the email server returning the email is not yet known must be taken into account by the filter.

Practical Experience

Some spammers try to bombard email servers in 3-second intervals with mass emails until they are finally allowed to pass. Here, we recommend a kind of automatic blacklist for the sender such as completely blocking them through the firewall for some time. Rejecting this sender with an error 500 is not recommended because some services, such as mailing lists, try to empty their queues with considerable aggressiveness (e.g., after a downtime of your own email server).

In addition, one should also take into account what a failure of the greylisting filter or the database would lead to: if no contact can be made with the database, the greylisting filter will reject all incoming emails, blocking the entire data transfer.

Whitelist

The following is an attempt to create a list of servers/IP address ranges that are known to cause problems with greylisting. Please expand this list if you have additional information. Please adhere to the predetermined shape!

  • Specify IP address or range
  • Name of the service or server
  • Reason for whitelisting

This list is intended as a guideline and shall be free for everyone to be used, so please ensure that no irrelevant (for the masses) entries appear on it.

  • 192.43.244 # openbsd mailinglist (unique sender per attempt)
  • 66.249.92 # Google Mail Server Pool (bad error handling)
  • 12.5.136.141 # Southwest Airlines (unique sender, no retry)
  • 12.5.136.142 # Southwest Airlines (unique sender, noretry)
  • 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.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?)
  • 66.94.237 # Yahoo Groups servers (common pool, no retry)
  • 66.135.209 # Ebay (for time critical alerts)
  • 66.135.197 # Ebay (common pool)
  • 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.94.237 # Yahoo Groups servers (common pool, no retry)
  • 66.135.209 # Ebay (for time critical alerts)
  • 66.135.197 # Ebay (common pool)
  • 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)
  • 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.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.239.56 # proxy.gmail.com (common server pool, bad 451 handling?)
  • 217.158.50.178 # AXKit mailing list (unique sender per attempt)


© 2018. Hetzner Online GmbH. Alle Rechte vorbehalten.