Spamfilter an der TU Graz

für alle Subdomains verwenden wir Nolisting (oder auch „Poor Man's Greylisting“ genannt) - eine Methode, die keinerlei Aufwand verlangt und trotzdem einen hohen Wirkungsgrad hat:
Alle E-Mails, die an die TU Graz geschickt werden, landen zuerst bei einem Server, der keine E-Mails annimmt (mx0.tugraz.at), der zustellende Server bemerkt das (wenn er richtig konfiguriert ist) und schickt die E-Mail nun zu unserem echten Mailgate. E-Mails, die über sogenannte „Botnets“ versandt werden, werden dadurch sehr wirkungsvoll blockiert.

Erst danach beginnen die eigentlichen Filter zu arbeiten:
Um die nachgeschalteten (Instituts-)E-Mail-Server zu entlasten (DoS-Attacken, dictionary Spam, Bounces auf solche Attacken) und einen möglichen Mißbrauch abzuwenden, wird jede E-Mail zuerst nach bestimmten Kriterien, die sich nicht auf den Inhalt beziehen, untersucht. Wenn ein E-Mail-Server mit unserem Server eine Verbindung aufzubauen versucht, wird ein ident-Request auf Port 113 zurück gesandt (das sollte eine Firewall 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!)


Formale Tests

Bevor der Inhalt untersucht wird, müssen einige formale Kriterien erfüllt sein.

top

Inhaltliche Tests

Erst danach wird die E-Mail auf Malware und auf Spam untersucht.

top

Häufigste Probleme

  1. Greylisting bereitet falsch konfigurierten Servern manchmal Probleme, was aber eigentlich nicht passieren dürfte, da Greylisting mit temporären Fehlern arbeitet, die ein E-Mail-Server auf jeden Fall bearbeiten muß, da temporäre Fehler (wie z. B. eine kurzfristige Überlastung, durch die vorübergehend keine E-Mails angenommen werden können) jederzeit auftreten können.
    Der zustellende Server sollte eigentlich die Fehlermeldung auswerten und kurz nach Ablauf der „Greylisting-Zeit“ die E-Mail nochmals zu(zu)stellen (versuchen).
    Manche Server ignorieren jedoch die Fehlermeldung total, andere senden die E-Mail erst nach einer fixen Zeit (eventuell auch erst nach Stunden oder Tagen) nochmals, beides können wir nicht beeinflussen!
  2. Ein häufiges Problem ist, daß sich einige (Exchange-)Server statt mit ihrem FQDN mit irgendetwas.local (oder .lan) melden, unsere Fehlermeldung lautet dann sinngemäß

    550 5.7.1 HELO irgendetwas.local from RFC 2606 reserved domains blocked

    Das scheint eine Default-Einstellung bei Exchange zu sein, bzw. wird das anscheinend bei Updates bei vielen (nicht wirklich gewarteten?) Exchange-Servern so eingestellt.
    Durch das Deaktivieren der Spamfilter über TUGRAZonline (s. u.) wird auch dieser Filter inaktiv, besser wäre es aber, wenn der Server des Absenders richtig konfiguriert würde (Exchange System Manager\Dein Exchange\Protokolle\SMTP\Virtueller Standardserver für SMTP\Eigenschaften\Übermiittlung\Erweitert → "Vollständig qualifizierter Domänenname" = der richtige FQDN).

  3. Viele moderne E-Mail-Clients haben auch selbst Spam-Filter eingebaut - manche müssen dabei erst trainiert werden (z. B. Thunderbird) und erreichen bei entsprechendem Training eine sehr gute Trefferrate, andere (z. B. Outlook) kommen mit einem festen Junk-Filter, der aber leider in unserem Umfeld oft „false positives“ liefert und daher abgedreht werden sollte!

top

Problembehebung

Generell sollten die Fehlermeldungen, die wir an den zustellenden Server - nicht dem (vermeintlichen) Absender! - retournieren, ausgewertet (Achtung z. B. bei Exchange-Servern: diese melden meistens nur ein Sicherheitsproblem und eventuell nicht den echten Grund an den Absender retour!) und das Problem auf der Seite des Senders behoben werden.
Bei Exchange-Servern und .local muß in den erweiterten SMTP-Einstellungen der FQDN des Servers angegeben werden!

Wenn Sie mit uns in Kontakt treten, brauchen wir daher i. Allg. die Adresse des zustellenden SMTP-Servers, die From-Adresse hilft zumeist nicht, da viele E-Mails ja schon in einem frühen Stadium des Verbindungsaufbaus abgelehnt werden und die (vermeintliche) Absenderadresse uns noch gar nicht bekannt ist.

Greylisting

Im Fall von Greylisting sollte es als schnelles Workaround genügen, die E-Mail händisch nach 10 Minuten ein 2. Mal anzufordern - das behebt aber das Problem nicht wirklich und funktioniert nicht, wenn die Adresse des Absenders (z. B. bei Amazon) dynamisch ist!

OSR & Greylisting

Bedienstete können in Ihrer Visitenkarte in TUGRAZonline festlegen, ob Sie für Ihre Exchange-Adresse E-Mails von mehrfach in OSRs gelisteten Servern erhalten wollen oder nicht (die Voreinstellung lehnt E-Mails von solchen Servern ab) und ob Greylisting außer Kraft gesetzt werden soll (eine Änderung der Einstellung wird nach spätestens 15 Minuten - :00, :15, :30 und :45 - von den Mailgates übernommen). -->

Eine andere Möglichkeit um E-Mails zu bekommen, die nicht unseren Kriterien genügen, stellt das Webinterface Bigmail dar. Sonst gibt es noch die Möglichkeit, daß Sie sich eine externe (temporäre) E-Mail-Adresse zulegen, mailcatch.com können Sie dazu z. B. direkt in den Firefox einbinden.

top

Warum macht es die TU Graz so kompliziert?

Wir hören immer wieder das „Argument“, daß man ja andere Empfänger auch erreicht und daß es nur bei der TU Graz Probleme mit der Zustellung von E-Mails gibt - nun ja:

Es gibt Leute, die öffnen die Haustüre, wenn ihnen über die Gegensprechanlage jemand sagt, daß er Post abzugeben hat und andere überprüfen das, bevor sie öffnen - keine der beiden Varianten ist richtiger, aber eine der beiden Varianten ist sicherer.

top