Formelle Kriterien

Um die nachgeschalteten Instituts-E-Mail-Server z. B. vor DoS-Attacken, Dictionary Attack Spam und Bounces (automatische Antworten auf solche Attacken) zu entlasten und einen möglichen Mißbrauch abzuwenden, wird jede E-Mail zuerst nach bestimmten formalen Kriterien, die sich nicht auf den Inhalt beziehen, untersucht.

Nolisting (oder auch „Poor Man's Greylisting” genannt) blockiert E-Mails, die von Bot-Nets versandt werden: Der MX-Record mit höchster Priorität zeigt dabei auf einen Server, der keine E-Mails annimmt (mx0.tugraz.at). Ein richtig konfigurierter E-Mail-Server erkennt das aber und versucht dann unseren Server mit der nächstniedrigeren Priorität zu erreichen, Bot-Netze versenden die E-Mails zumeist nicht über richtig konfigurierte SMTP-Server und damit wird man einen großen Teil der Spam-E-Mails los. Wir haben aber keinen Einfluß auf die Konfiguration externer Server, also ob diese das Verfahren beherrschen und wie lange es dauert, bis sie die E-Mail an den 2. (den richtigen) Server senden - kaum ein Vorteil ohne (möglichen) Nachteil.

Wenn der E-Mail-Server nun mit unseren „richtigen“ Servern eine Verbindung aufzubauen versucht, wird ein ident-Request auf Port 113 zurück gesandt, dieser muß nicht beantwortet werden (eine Firewall sollte das aber auf keinen Fall mit einer Blockade unserer IP beantworten, da sonst die gesamte weitere Kommunikation behindert wird und somit auch keine Fehlermeldungen versandt werden können).

Kommt eine Kommunikation zustande, werden untenstehende Tests der Reihe nach durchgegangen:


Ist die Empfängeradresse eine gültige E-Mail-Adresse der TU Graz?

  • Alle gültigen E-Mail-Adressen sind (im Wege der EDV-Beauftragten) über TUGRAZonline zu erfassen (Applikation „Mail Routing“; Adressen auf den zentralen Servern sind automatisch bekannt!)
  • Alle E-Mail-Server sind (vom EDV-Beauftragten) dem Postmaster der TU Graz zu melden!

Damit ersparen sich die Mailgates das Scannen von vielen E-Mails, für die es dann am Institutsserver gar keinen Abnehmer gibt, außerdem verhindert das, daß das Mailgate zum Backscatter-Server wird.

top

Greylisting

Bei Greylisting wird für einen neuen Absender (genauer: wenn das Tripel Absender - Absender-IP-Adresse - Empfänger nicht in der dynamischen Whitelist steht) ein temporärer Fehlercode erzeugt, dieser kann je nach Ursache folgendermassen aussehen:

DNS-Blacklist-Hit:
reject=451 4.7.1 delaying messages from [ip-address] - listed at [dnsbl] - try again in nn seconds

Reverse DNS-Fehler:
reject=451 4.7.1 delaying messages from [ip-address] - fix your reverse DNS entry - try again in nn seconds

D. h.: der zustellende Server wird darüber informiert, daß der Empfänger von diesem Absender nn Sekunden keine E-Mails annimmt (=„Greylisting-Zeit“), die Mailbox aber aktiv ist:

451: 4xx = temporär, x5x = Mail, 451 = Requested action aborted: error in processing
4.7.1: 4.x.x = Persistent Transient Failure, x.7.1 = der Absender hat nicht die Erlaubnis dem Empfänger etwas zu senden

Falls nach der Greylisting-Zeit wieder ein Zustellungsversuch mit dem gleichen Absender-IP-Empfänger-Tripel erfolgt, wird die E-Mail angenommen und der Absender wird als verifiziert angesehen und für 5 Tage im Cache gehalten (d. h. es kommt in diesem Zeitraum zu keiner weiteren Überprüfung und damit Verzögerung).

Wir haben keinen Einfluß darauf, ob der neue Zustellversuch wirklich nach nn Sekunden oder erst nach Stunden erfolgt, das ist eine Konfigurationseinstellung des zustellenden Server!

Greylisting kann - zusammen mit den anderen formalen Tests - über die E-Mail-Applikation in Ihrer TUGRAZonline-Visitenkarte deaktiviert werden - Sie werden dann aber eventuell deutlich mehr Spam bekommen.

Einige Domains haben mit Greylisting Probleme, weil sie entweder dynamische Absender-Adressen für automatisch versandte E-Mails verwenden oder weil sich die IP-Adresse des absendenden Servers ändert, weil hier ein Server-Pool für das Versenden zuständig ist. Für einige bekannte große Domains gibt es daher eine permanente Whitelist.

top

Anti-Spam-SMTP-Schema

  • Nolisting
  • helo checks → sendmail
  • lokale Black-/Whitelist
  • Greylisting
    • 129.27.0.0 (also das TUGnet) ist „whitelisted“
    • Hosts auf der ISPA-Whitelist sind whitelisted
    • Yahoo Groups, eBay, amazon, Google sind whitelisted
    • Empfänger, die Greylisting im „Accountstatus“ abdrehen, werden whitelisted
    • Hosts mit falschem HELO (localhost, *tugraz.at, *tu-graz.ac.at, *.local, *.lan) → reject
    • Hosts mit ungültigem rDNS-Eintrag → 1h greylisting time
    • DNS-Blacklists
      • blacklist.rbl.ispa.at → reject
      • ix.dnsbl.manitu.net → 3h Greylisting-Zeit
      • cbl.abuseat.org → 1h Greylisting-Zeit
      • dnsbl.sorbs.net → 1h Greylisting-Zeit
      • bl.spamcop.net → 1h Greylisting-Zeit
      • sbl.spamhaus → 1h Greylisting-Zeit
      • Hosts, die in mindestens 3 DNS-BLs geführt sind, werden abgelehnt (→ reject)
      • default Greylisting-Zeit: 3min
  • Hosts, die es durch Greylisting geschafft haben, werden für 5 Tage in die Whitelist eingetragen
  • Dann geht es zu den inhaltlichen Tests (Antivirus, Spamassassin)

Bei Rejects aufgrund von mehrfachen Blacklist-Hits wird fogender Fehlercode erzeugt:

reject=551 5.7.1 Bad reputation - [ip-address] listed on too many DNS blacklists: […] Bei Rejects aufgrund von HELO-Fehlern wird je nach Ursache einer der folgenden Fehlercodes erzeugt: reject=551 5.7.1 [heloname] invalid HELO name from RFC 2606 reserved domains blocked reject=551 5.7.1 [heloname] invalid HELO name [hostname] claims to be us but connection is from [ip-address] Diese Liste ist nicht vollständig, es gibt auch noch andere SMTP-Error-Codes.

top

Maximale E-Mail-Größe

Falls die E-Mail-Größe die maximal erlaubte Größe überschreitet, wird die E-Mail mit folgender Fehlermeldung abgewiesen:

stat=Message exceeds maximum fixed size ([maxsize])

top