Child pages
  • SPAM filtern mit Greylisting
Skip to end of metadata
Go to start of metadata

Übersicht

Greylisting ist ein ziemlich wirkungsvolles Verfahren, um Spam-Emails abzuweisen. Es hat zwar auch einige Nachteile, nach einigen Wochen Praxiseinsatz haben wir uns jedoch dafür entschieden. Dieser Artikel enthält Infos sowie Konfigurationstipps.

Immer mehr SPAM

Die Spam-Flut auf meinem Server steigt immer weiter an: im Juni 2006 waren es noch etwa 500 - 1000 Spam-Emails pro Tag, inzwischen sind es schon 2000 bis 3000. Und das, obwohl dieser Server nur fünf  Homepages hostet (die allerdings schon ziemlich lange im Netz sind). Es sind zwar einige Gegenmaßnahmen wie DNS-Blacklists, SpamAssassin und Clamav installiert, aber immer mehr Spam-Emails werden an Benutzer weitergeleitet.

Das größte Problem beim Filtern der Emails ist die Gefahr, dass legitime Emails als Spam eingestuft und dann später übersehen werden. Man ist also gezwungen, sich von allen Spam-Emails wenigstens den Betreff anzusehen, bevor man sie löscht. Hinzu kommt, dass die Spammer ihre Emails immer mehr verfeinern, um sie durch SpamAssassin hindurchzuschleusen. Das führt dazu, dass ein immer höherer Anteil an Spam-Emails nicht mehr als Spam markiert wird, oder - wenn man den SpamAssassin Bewertungsfaktor herabsetzt - die Wahrscheinlichkeit ansteigt, dass auch legitime Emails fälschlicherweise als Spam klassifiziert werden. Beide Alternativen sind gleich unangenehm für den Email-Nutzer.

Seit kurzem nutze ich zusätzlich zu den angegebenen Verfahren noch zusätzlich das Greylisting. Der Erfolg ist umwerfend: von ca. 3000 Spam-Emails pro Tag werden durch die Kombination von Blacklisting und Greylisting praktisch alle bis auf ein paar geblockt. Und der kümmerliche Rest wird von SpamAssassin markiert und in den „Junk" Ordner einsortiert, den man sich einmal am Tag kurz durchsieht und dann manuell löscht. Früher waren das immerhin einige zehn Spam-Emails pro Tag, bei denen man den Betreff lesen musste.

Wie Greylisting funktioniert

Das Greylisting Verfahren macht sich zunutze, dass die meisten Spam-Versende-Programme jede Email-Adresse nur jeweils ein einziges Mal verwenden. Kann die Spam-Email nicht beim ersten Mal ausgeliefert werden, dann macht das Programm einfach mit der nächsten Adresse weiter. Ein normaler Mailserver wird dagegen den Zustellversuch mehrfach wiederholen, notfalls mehrere Tage lang.

Beim ersten Zustellversuch wird die Annahme verweigert und die IP-Adresse des versendenden Mailservers sowie die Email-Adresse des Absenders und des Empfängers in eine Datenbank eingetragen. Versucht es der Mailserver (nach Ablauf einer konfigurierbaren Mindestwartezeit) ein zweites Mal, wird die Email dagegen entgegengenommen. In fast allen Fällen handelt es sich dabei um eine legitime Email, die über einen regulären Mailserver versendet wird.

Wenn der Absender ein zweites Mal eine Email an den gleichen Empfänger versendet, dann wird sie sofort übermittelt, da Absender, Empfänger und Mailserver ja bereits bekannt sind.

Nachteile

In der Theorie sollte es also nur geringfügige Nachteile geben. Nur die erste Email jedes Absenders wird ein wenig verzögert, ansonsten fällt der Einsatz des Greylistings keinem Email-Nutzer auf. Leider sieht die Praxis etwas anders aus.

Manche Emails werden erheblich verzögert, und zwar aus folgenden Gründen:

  • Die meisten Mailserver verwenden ein Retry-Intervall von 30 Minuten, einige aber auch ein Intervall von 12 oder noch mehr Stunden.
  • Große Unternehmen oder Webhoster verwenden meistens mehrere Mailserver. Es passiert häufig, dass erneute Zustellversuche dann von einem anderen Mailserver vorgenommen werden. Die Greylisting-Software sieht eine neue IP-Adresse, verweigert erneut die Annahme und startet erneut die Mindestwartezeit. Dies wiederholt sich solange, bis die Email von einem bekannten Mailserver versendet wird, der dann inzwischen freigeschaltet wurde.
    Da Unternehmen wie eBay oder Google dutzende von Mailservern einsetzen, kann sich das über viele Stunden hinziehen.
  • Manchmal enthält die Absender-Email-Adresse einen Time Stamp oder irgendeinen Code. Dies ist oft bei automatisch generierten Emails wie Versandbestätigungen, Webanfragen oder dergleichen der Fall. Aus Sicht des Greylisting-Systems sind das natürlich jedesmal neue Absender, die dann wieder verzögert werden.

Man kann also nicht eben mal am Telefon seinen Gesprächspartner bitten, eine Datei zuzusenden und hat sie dann zwei Minuten später vorliegen. Auch die Bestätigungsmails bei Registrierung in Diskussionsforen, Shops usw. werden mehr oder weniger lang verzögert.

Es kommt sogar vor, dass manche legitimen Emails nicht zugestellt werden. Das passiert immer dann, wenn der versendende Mailserver den Response Code des empfangenden Mailservers falsch interpretiert und als endgültige Fehlermeldung auffasst und keinen weiteren Sendeversuch unternimmt. Unter anderem ist mir dies bei manchen (nicht allen) Emails von eBay passiert.

Wenn der versendende Mailserver korrekt konfiguriert ist, erhält der Absender der Email wenigstens eine Fehlermeldung.

Installation und Konfiguration

Auf einem Debian System ist lediglich das Paket "greylistd" zu installieren.

Danach müssen neue ACL Regeln in exim (vexim-acl-check-rcpt.conf) eingetragen werden, damit das alles funktioniert. Die Regel, die auf der greylistd Installationsanleitung empfohlen wird, enthält zusätzlich zur Abfrage des greylistd - Status noch eine Abfrage der Whitelist. Es ist jedoch sinnvoller, die Abfrage der Whitelist separat am Anfang der ACL Regeln durchzuführen, so wird auch die Abfrage der DNS Blacklists vermieden, falls ein Mailserver in der Whitelist aufgeführt ist. Sonst kann es passieren, dass zwar ein Mailserver in der Whitelist drinsteht, aber die Email trotzdem abgelehnt wird, weil der Mailserver auch in einer der Blacklists steht. Das passiert gelegentlich bei kostenlosen Webmail-Diensten.

# accept all email from authenticated hosts

  accept    authenticated = *

# accept all email from whitelist

  accept
    hosts          = : +relay_from_hosts : \
                     ${if exists {/etc/greylistd/whitelist-hosts}\
                                 {/etc/greylistd/whitelist-hosts}{}} : \
                     ${if exists {/var/lib/greylistd/whitelist-hosts}\
                                 {/var/lib/greylistd/whitelist-hosts}{}}

# deny emails from any host in these blacklists
# note: check the policy of each blacklist provider to see wether it matches
# your requirements. uceprotect.net and bl.spamcop.net may be too aggressive

  deny
    message        = DNSBL listed at $dnslist_domain\n$dnslist_text
    dnslists       = sbl-xbl.spamhaus.org:combined.njabl.org:list.dsbl.org:dnsbl-2.uceprotect.net:dnsbl-1.uceprotect.net:bl.spamcop.net

# handle greylisting

  defer
    message        = $sender_host_address is not yet authorized to deliver \
                     mail from <$sender_address> to <$local_part@$domain>. \
                     Please try later.
    log_message    = greylisted.
    !senders       = :
    domains        = +local_domains : +relay_to_domains
    condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--grey \
                                  $sender_host_address \
                                  $sender_address \
                                  $local_part@$domain}\
                                 {5s}{}{false}}

Und hier meine /etc/greylistd/config Konfigurationsdatei mit einigen wichtigen Änderungen:

########################################################################
### FILE:       /etc/greylistd/config
### PURPOSE:    Configuration settings for the "greylistd(8)" daemon
########################################################################

[timeouts]
# Initial delay before previously unknown triplets are allowed to pass
# Default is 1 hour = 3600 seconds
retryMin     = 300

# Lifetime of triplets that have not been retried after initial delay
# Default is 8 hours = 28800 seconds
retryMax     = 259200

# Lifetime of auto-whitelisted triplets that have allowed mail to pass
# Default is 60 days = 5,184,000 seconds
expire       = 5184000


[socket]
# Path to the UNIX domain socket on which greylistd will listen.
# The parent directory must be writable by the user running 'greylistd'.
# Default path is "/var/run/greylistd/socket".
path         = /var/run/greylistd/socket

# UNIX filemode of that socket.  See "chmod(1)" for the meaning of this.
# Default mode is 0660.
mode         = 0660


[data]
# Update interval -- save data to the filesystem if if has been more
# than this many seconds (default 600) since the last save.
update       = 600

# Path to the file containing the current state of each data item (triplet),
# along with some general statistics.
# Default is "/var/lib/greylistd/states".
statefile    = /var/lib/greylistd/states

# Path to the file that will contain the original, unhashed data for the
# "list" command.  Default is "/var/lib/greylistd/triplets".
tripletfile  = /var/lib/greylistd/triplets

# Whether or not to retain unhashed triplets, for the "list" command.
# Default is "true"
savetriplets = true

Anpassungen

retryMin ist die Zeitspanne, die mindestens verstreichen muss, damit eine Email akzeptiert wird. Eine Zeitspanne von 300 Sekunden scheint gut zu funktionieren. Die Idee hinter der längeren Zeitspanne von 1 Stunde ist, dass Spam-Emails nach dieser Zeitspanne evtl. schon in die bekannten DNS-Blacklists eingetragen sind. Nutzt der Server diese Blacklists, dann würde die Zustellung verhindert werden, auch wenn der Spammer die Zustellversuche mehrfach wiederholt.

retryMax ist die Zeitspanne, in der Einträge in der greylist gehalten werden. Es empfielt sich, den Defaultwert von 1 Tag deutlich zu vergrößern. Erstens gibt es Server, die ein sehr langes Retry-Intervall haben, zweitens sollte man sich gelegentlich die Einträge mal durchsehen, um problematische Emails (siehe Abschnitt Nachteile) ausfindig machen zu können und evtl. Anpassungen machen zu können. 

expire ist die Zeitspanne, in der Einträge in der whitelist gehalten werden. Der Default ist 60 Tage, wesentlich längere Einträge schaden sicher auch nicht. Man will nur vermeiden, dass die whitelist ins Unendliche wächst.

Die Whitelist

Wie schon erwähnt, gibt es verschiedene Unternehmen, die entweder sehr viele oder falsch konfigurierte Mailserver haben. Die IP-Adressen dieser Server sollte man in die /etc/greylistd/whitelist-hosts Datei aufnehmen. Es gibt noch eine zweite Whitelist unter /var/lib/greylistd/whitelist-hosts, die mit einigen vordefinierten Einträgen versehen ist, daher kommen die eigenen Einträge in die /etc/greylistd/whitelist-hosts, damit diese bei einem eventuellen Update nicht überschrieben werden.

Diese whitelists werden nicht vom greylistd ausgewertet, sondern von der jeweiligen Mailsoftware, in diesem Falle von exim. Die Syntax richtet sich daher nach dem jeweiligen Programm.

Hier ein paar Beispiele, wie man an die Adressen der Mailserver kommt. Man durchkämmt gelegentlich die "greylist" nach problematischen Einträgen. Hier beispielsweise einige Emails von eBay, die nicht oft genug wiederholt wurden und folglich nie angekommen sind. Man sieht auch, dass immer andere IP-Adressen verwendet wurden.

$ greylist list --grey | grep arne@schirmacher.de | grep ebay
  2006-11-09 13:58:43      1  66.135.197.13 emailconfirm@ebay.com arne@schirmacher.de
  2006-11-09 17:47:14      1  66.135.209.207 endofitem@ebay.de arne@schirmacher.de
  2006-11-09 17:47:18      1  66.135.209.215 endofitem@ebay.de arne@schirmacher.de
  2006-11-10 10:28:49      1  66.135.197.23 checkout@ebay.de arne@schirmacher.de
  2006-11-10 10:41:21      1  66.135.197.28 bidconfirm@ebay.de arne@schirmacher.de

 Man sollte also die eBay-Mailserver in die Whitelist aufnehmen. Viele Unternehmen teilen die IP-Adressen oder Adressbereiche ihrer Mailserver in einem sogenannten SPF-Record mit. Diesen SPF-Record bekommt man mit folgendem Befehl:

$ dig ebay.com txt

...

;; ANSWER SECTION:
ebay.com.               3292    IN      TXT     "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com
                                                 include:p._spf.ebay.com include:c._spf.ebay.com ~all"
ebay.com.               3292    IN      TXT     "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com
                                                 include:p._sid.ebay.com include:c._sid.ebay.com ~all"

...

Entscheidend ist die ANSWER SECTION. Hier stehen entweder die IP-Adressen oder Adressbereiche direkt drin, oder sind indirekt mit einer include-Direktive angegeben. In letzterem Fall muss man noch einmal dig für die angegebenen Domains aufrufen:

$ dig s._spf.ebay.com txt

...

;; ANSWER SECTION:
s._spf.ebay.com.        2790    IN      TXT     "v=spf1 ip4:66.135.209.192/27 ip4:66.135.197.0/27
                                                 ip4:64.4.240.64/27 ip4:64.4.244.64/27 ~all"

...

Diese IP-Adressen-Ranges kann man nun in die Whitelist eintragen (jedoch ohne den ip4: Prefix). Dies ist für alle Einträge zu wiederholen, evtl. auch rekursiv.

Hat ein Unternehmen keinen SPF-Eintrag, kann man zumindest die in den MX-Records gelisteten Mailserver in die Whitelist aufnehmen. Diese Server bekommt man mit "dig ebay.com mx" angezeigt.

Anbei meine Whitelist, die einige wichtige Server enthält (eBay, Google Mail, 1&1 Domains, GMX, web.de): 

12.155.144.75 # ebay.com according to their SPF records
62.22.61.131
63.104.149.126
63.80.14.17
64.127.115.252
64.4.240.64/27
64.4.244.64/27
64.68.79.253
64.94.204.222
65.110.161.77
66.135.195.180
66.135.195.181
66.135.197.0/27
66.135.209.192/27
66.135.215.134
66.135.215.224/27
67.72.12.29
67.72.12.30
67.72.99.26
80.66.137.58
80.93.9.10
194.64.234.129/27
195.234.136.12
203.49.69.114
204.13.11.49
204.13.11.51
206.165.246.83
206.165.246.84
206.165.246.85
206.165.246.86
209.63.28.11
210.80.80.136
212.110.10.2
212.147.136.123
212.208.64.34
213.219.8.227
216.113.168.128
216.113.175.128
216.113.188.112
216.113.188.96
216.177.178.3
216.33.244.6
216.33.244.7
216.33.244.84
216.33.244.96/27
217.149.33.234
220.248.6.124

207.171.160.0/19 # amazon.com according to their SPF records
87.238.80.0/21
72.21.196.0/24
72.21.208.0/24

64.233.160.0/19 # gmail.com according to their SPF records
66.249.80.0/20
72.14.192.0/18
216.239.56.0/23

209.85.146.0/23 # googlemail.com

212.227.126.128/25 # moutng.kundenserver.de (1&1) according to their SPF records

81.169.144.0/20 # Strato AG (this range is too large)

213.165.64.0/23 # gmx.net

217.72.192.221 # web.de (fmmailgate01.web.de - fmmailgate09.web.de)
217.72.192.227
217.72.192.234
217.72.192.242
217.72.192.243
217.72.192.247
217.72.192.248
217.72.192.249
217.72.192.184

194.25.134.80 # t-online.de
194.25.134.17
194.25.134.81
194.25.134.18
194.25.134.82
194.25.134.19
194.25.134.83
194.25.134.20
194.25.134.84
194.25.134.21
194.25.134.85 152.163.225.0/24 # aol.com according to their SPF records
205.188.139.0/24
205.188.144.0/24
205.188.156.0/23
205.188.159.0/24
64.12.136.0/23
64.12.138.0/24
205.188.158.121
64.12.137.184
64.12.137.249
205.188.156.185
205.188.157.25
64.12.137.168
64.12.138.185
205.188.155.89
205.188.157.217
205.188.159.57
64.12.138.57
64.12.138.120
64.12.138.152
205.188.156.249
205.188.159.217
64.12.138.89

http://de.wikipedia.org/wiki/Greylisting

http://en.wikipedia.org/wiki/Greylisting

http://www.greylisting.org/

http://projects.puremagic.com/greylisting/whitepaper.html

Eure Erfahrungen?

Falls ihr Greylisting ebenfalls einsetzt, Fragen oder weitere Vorschläge für die Whitelist habt, hinterlasst bitte einen Kommentar oder schickt mir eine Email.

13 Comments

  1. Anonymous

    Ist es auch möglich das Greylisting per vexim zu steuern, damit nicht jeder Benutzer/Account automatisch dazu gezwungen wird Greylisting zu verwenden?

    1. Darüber habe ich auch schon nachgedacht. Der greylistd verwendet Dateien, um seine Daten zu speichern, währen vexim das über MySQL macht. Man müsste also greylistd entsprechend modifizieren, oder eine andere Greylisting Implementation (es gibt eine ganze Reihe) einsetzen, die auf MySQL zurückgreift.

      Vexim hat bereits Dialoge für Blacklists, die allerdings z.Zt. nicht funktionieren.

      Habe leider nicht so viel Zeit, vielleicht können wir das zu zweit machen?

      1. Anonymous

        Ich habe mir eigentlich gedacht, dass man von den ACL aus einfach das Ausführen des Greylisting-Scans unterbinden/gestatten kann. Bin nämlich auch auf der Suche nach einer Lösung lokal bzw. authentifiziert versendete E-Mails nicht scannen zu lassen. Aber so wie es aussieht werde ich da nichts finden.

        Ich kenn mich auf dem ganzen Gebiet leider zu wenig aus um selbst tätig zu werden bzw. jemanden dabei unterstützen zu können.

        1. Lokal authentifiziert emails sollte eigentlich nicht gescannt werden, wegen der Zeile

          accept    authenticated = *
          

          (siehe oben). Analog könnte man weitere Regeln einbauen, um für bestimmte Emails/Server keine weiteren Prüfungen auszuführen.

  2. Anonymous

    hi,

    ich würde die whitelist condition anpassen.

    accept
        hosts          = : +relay_from_hosts : \
                         ${if exists {/etc/greylistd/whitelist-hosts}\
                                     {/etc/greylistd/whitelist-hosts}{}} : \
                         ${if exists {/var/lib/greylistd/whitelist-hosts}\
                                     {/var/lib/greylistd/whitelist-hosts}{}}
    

    so sagt es aus, dass du für jeden host auf der whitelist zum relay wirst, und das ist ja auch nicht gewollt. also vorschlag wäre:

    accept
        hosts          = : +relay_from_hosts
    
    accept:	domains = : +local_domains : +relay_to_domains 	hosts=    ${if exists {/etc/greylistd/whitelist-hosts}\
                           {/etc/greylistd/whitelist-hosts}{}} : \
                         ${if exists {/var/lib/greylistd/whitelist-hosts}\
                                     {/var/lib/greylistd/whitelist-hosts}{}}
    

    ------
    also die realayer zulassen, und von der whitelist auch nur annehmen, wenns an dich selbst geht.

     mfg ingmar mohring

    ingmar @mohring.net

    PS: ich setzte greylisting mit MYSQL ein, also ohne den greylistd deamon.  

  3. Anonymous

    Die meisten Mailserver mit Greylisting geben "450: Greylisted" oder so zurück.

    Ist das nicht unsinnig? So weiss ja der Spammer gleich, dass er es nochmals versuchen soll und kann das mit einer entsprechenden Router abfangen. Vielleicht wäre etwas wie "Server temporarily buisy. Try again later." sinnvoller

    1. Eigentlich sagt schon der Result Code 450, dass der Mailserver es nochmal versuchen soll. Die meisten Spammer reagieren nicht einmal darauf. Durch Ändern des Textes könnte man verhindern, dass jemand eine Statistik macht, wieviel Server Greylisting verwenden.

    2. Anonymous

      Keine Ahnung, welche bescheidenen Mailserver ein "Greylisted" zurückgeben. Welche sollen das sein? Die Meldung, die eigentlich durch Greylisting am Anfang erzeugt wird, simuliert nämlich genau die von Dir geforderte "busy - try again later"-message. Für den einliefernden Server ist somit nicht zu unterscheiden, ob der Server wirklich busy ist, oder ob er gegrylisted wurde. Nur so macht es ja auch Sinn.

  4. Anonymous

    Macht es eigentlich einen wesentlichen Unterschied, ob ein 450 oder ein 451 zurückgeliefert wird?

    Gruß
    Jörg Detlefs <technik[at]khd-art.de>

  5. Anonymous

    Hallo Arne,
    Unverständlich für mich, daß Du Dir offenbar Gedanken zu Spam machst und extra ein Verfahren zum automatischen Aussortieren implementierst, aber andererseits nicht mal die geringste Sorge dafür trägst, daß Deine e-Mail Adresse auf dieser Webseite (und wahrscheinlich auf all Deinen Seiten) NICHT im Klartext erscheint.

    Meinst Du nicht, Du solltest mal mit gutem Beispiel vorangehen, und einen e-Mail Obfuscator verwenden? Das ist doch heutzutage wirklich kein Problem und verhindert schon mal die erste Welle von Spambot Spam! Kein Wunder, daß Du täglich so viel Spam bekommst – oder hast Du das extra so eingerichtet, damit Du Dich über die viele Spam beschweren kannst??

    Schon komisch, was Leute so veranstalten. Da verbarrikadieren sie die Haustür und installieren im Garten Flutlicht, damit auch alle den Hintereingang schön finden. <kopfschüttel>

    (Ich hätt Dir das ganze auch nicht-anonym zugeschickt, aber ich werde bestimmt nicht bei jemandem einen User-Account starten, der noch nicht mal seine eigene Adresse verstecken kann.)

    1. Du unterstellst, dass Deine eigene Lösung, nämlich Email-Adressen nicht im Klartext anzuzeigen, die einzig brauchbare Lösung ist. Das ist - vorsichtig formuliert - doch ein sehr naives Weltverständnis.

      Erstens habe ich meine Email-Adresse schon aus der Anfangszeit des Internet, wo es noch kein Spam-Problem gab. Inzwischen ist sie in praktisch jeder Spammer-Datenbank drin, es würde also gar nichts mehr nützen, sie zu verstecken.

      Zweitens verhindert ein Email-Obfuscator nur, dass Email-Adressen automatisch ausgelesen werden. Es gibt aber noch etliche andere Wege, wie Spammer an Email-Adressen kommen. Außerdem kann man als Betreiber eines Email Servers nicht alle seine User zwingen, dieses Verfahren einzusetzen.

    2. Anonymous

      Ich verstehe deine Antwort zu diesem meines Erachtens wirklich guten Artikel zu greylisting nicht. Anstatt zu meckern könntest du ja selbst einen Artikel zur Spamvermeidung schreiben??

      Es ist mir unverständlich wie man irgendwo einen Kommentar hinterlässt in dem man nur meckert.....

      Von hier aus Daumen hoch, der Artikel war echt informativ.

      Danke Arne (:

  6. Anonymous

    Ich selbst nutze auch Greylisting und bin sehr zufrieden damit. Die Probleme mit ebay und Co habe ich bisher nicht festgestellt.

    Ab und zu kommt es mal vor, dass man ein wenig auf die Bestätigungsmail nach Registrierungen/Anmeldungen warten muss. Aber nach meiner Erfahrung hält sich das doch sehr in Grenzen. Grob geschätzt kommen 90%  innerhalb von 10 Minuten bei mir an, weitere 5% innerhalb weiterer 20 Minuten, und nur 5% brauchen mehrere Stunden. So ungefähr empfinde ich das zumindest.

    Das Whitelisting find ich doch n bisschen heavy - das muss man ja ständig kontrollieren und korrigieren - das wär mir dann doch n bisschen zu aufwändig.

    Ich finde es ist die Aufgabe der Admins von den einsendenden Mailservern ihre Server vernünftig einzustellen. Denn temporäre Nicht-Erreichbarkeit eines Empfängers kommt durchaus mal vor - nicht immer nur wegen Greylisting. Der annehmende Server kann ja auch wirklich mal überlastet sein o.ä.

Write a comment…