Postfix Antispam – Greylisting

Nach dem eine Mail also die ersten Hürden genommen hat, kommt Greylisting zu Einsatz. Dabei wird beim ersten Zustellversuch ein TEMPORARY ERROR als Antwort gesendet. Jeder vernünftige Mailserver versucht die Zustellung der Mail dann nochmals. Allgemein wird Greylisting so konfiguriert, dass der gegnerische Mailserver nur 1-2 Minuten warten muss vor dem erneuten Zustellversuch. Leider haben sich darauf viele Bots eingestellt. Hier wird mit 5 Minuten Wartezeit gearbeitet – sehr erfolgreich. Über eine Whitelist sind Mailserver von Partnern z.B. vom Greylisting befreit. Auch wenn bestimmte Mailserver-Absender-Kombinationen mehrfach erfolgreich das Greylisting überwunden haben, wird ein Eintrag in der Whitelist-Datenbank erzeugt.

Zum Einsatz kommt dabei Postgrey von David Schweikert. In der /usr/bin/postgrey sollte in der Zeile delay => $opt{delay} || 300, den Wert auf mindestens 300 setzen, das war hier elementar.

Postfix Antispam – Receiver

Grundlegend sollte ein MTA nur Mails für Domains annehmen, für die er auch zuständig ist und wenn es den entsprechenden Empfänger auch gibt.

In der main.cf des Postfix ist daher besonderes Augenmerk auf den Eintrag mydestination zu verwenden. Hier sollten wirklich nur die Domains aufgeführt werden, für die der MTA Mails akzeptieren soll.

mydestination = domain.de, anderedomain.de,...

Durch eine spezielles Regelset (rc_full) wird verhindert, dass Mails in das MTA-System gelangen, für die es keine Empfänger gibt. Dies ist elementar wichtig, wenn der Front-MX nur als Relay für dahinter liegende SMTP-Strukturen dient. In der rc_full werden für beteiligte Domains die validen Empfänger gelistet. Mails an andere als die definierten Empfänger werden mit einem USER UNKNOWN beantwortet. Im Detail gibt es dazu folgenden Eintrag in den smtpd_recipient_restrictions von /etc/postfix/main.cf: check_recipient_access hash:/etc/postfix/rc_full

Aber was enthält nun diese rc_full-Datei? Hier ein Auszug:

emaila@domain.de OK
emailb@domain.de OK
domain.de REJECT User unknown in domain.de
. OK

Mails an emaila und emailb werden über das OK akzeptiert. Alle anderen eMailempfänger für domain.de werden mit User unknown REJECTed. Der Eintrag mit dem Punkt sorgt dafür, dass Mails an nicht in der rc_full aufgeführte Domains akzeptiert werden – natürlich sind dafür nur die Domains in mydestination (siehe oben) gültig. Nach dem Editieren sorgt ein postmap rc_full für die Aktualisierung der Postfix-Datenbanken. Hier gibt es noch Optimierungsmöglichkeiten, in dem die Einträge zum Beispiel anhand der Nutzerdatenbank des nachgelagerten Exchange erstellt werden könnten.

Die ganze Zeile in der main.cf sieht so aus:

smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,reject_unauth_destination,check_recipient_access hash:/etc/postfix/rc_full

permit_mynetworks erlaubt allen Clients in den angeführten Netzwerken in mynetworks das Anliefern von Mails an den Mailserver zum Weiterversenden

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/8 192.168.1.0/24

reject_non_fqdn_recipient verhindert, dass Mails an Empfänger ohne qualifizierten Domainnamen gesendet werden können.

reject_unauth_destination verwirft Mails an Empfänger, für die wir laut Konfiguration gar nicht zuständig sind.

Postfix Antispam – Helo

 

In der HELO-Phase des SMTP-Dialogs Mails zu blocken hat sich als problematisch herausgestellt.

Selbst viele professionelle IT-Abteilungen sind anscheindend nicht in der Lage, ihre abgehenden MTAs sauber zu konfigurieren. Daher habe ich alle Checks bezüglich des HELOs deaktiviert und akzeptiere auch Hostnamen wie exchange.local und Ähnliches.

Aus eigenen Tests heraus kann ich vor der Verwendung der Postfix-Optionen reject_unknown_hostname und reject_non_fqdn_hostname nur warnen. So verlockend die Verwendung dieser Optionen auch scheint: es werden zuviel erwünschte eMails abgelehnt. Eventuell sind diese Optionen in Zukunft einmal sinnvoll verwendbar.

Postfix Antispam – Connect

Der mit Abstand meiste Müll lässt sich durch eine Prüfung des gegnerischen SMTP-Partners aussondern.

Das Ablehnen von Mail in dieser Phase ist auch rechtlich gesehen eine gute Idee, weil auf diese Art und Weise abgelehnte Mails wohl nicht als zugestellt gelten nach derzeitiger Rechtsauffassung.

So prüfe ich auf vorhandene DNS-Einträge für die Absender-IP-Adresse. Die gegnerische IP-Adresse wird auch durch zwei Blacklisten geprüft. So fallen schon mal viele Mails aus Bot-Netzen etc. raus, weil die befallenen PCs entweder nur über eine IP-Adresse ohne zugehörigen DNS-Eintrag verfügen bzw. weil die IP-Adressen meist sehr schnell auf einer Blacklist erscheinen, wenn sie denn mal missbraucht wurden.
Wenn Hosts auf Grund dieser Rules auffällig werden, werden sie zudem durch das kleine Script smtpblock für eine Weile daran gehindert, erneute Zustellversuche zu unternehmen. Diese Maßnahme allein senkt die Last des MTA erheblich.

In meiner main.cf steht dazu:


smtpd_client_restrictions = permit_mynetworks,check_client_access hash:/etc/postfix/client_is_good,reject_unknown_client,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net

Die beiden Einträge reject_rbl_client zen.spamhaus.org und reject_rbl_client bl.spamcop.net prüfen, ob die absendende IP-Adresse schon mal negativ aufgefallen ist oder ob diese Adresse zum dynamischen Einwahlpool von Internetprovidern gehört – von beiden Gruppen nehmen wir hier keine Mails an.

Der Eintrag reject_unknown_client entsorgt Verbindungsversuche von „Mailservern“ ohne DNS-Eintrag – meist verbergen sich hinter diesen Hosts verseuchte PCs von arglosen Anwendern, auf denen ein Bot sein Unwesen treibt.

Das permit_mynetworks sorgt dafür, dass die anderen Prüfungen auf Verbindungen aus dem internen Netz nicht geprüft werden.

Der Eintrag check_client_access hash:/etc/postfix/client_is_good ist eine Whitelist, die dafür sorgt, dass auch falsch konfigurierte MX von Partnern und Kunden nch Mails abladen können. Dazu gibt es die Datei /etc/postfix/client_is_good mit etwa folgendem Inhalt:


1.2.3.4 OK

Diese Zeile sorgt nach einem postmap sender_is_good dafür, dass Mails von 1.2.3.4 angenommen werden ohne erst eine Prüfung im DNS zu machen bzw. eine Blacklist dafür zu befragen.

Häufig sieht man in den Logfiles, dass ein MX versucht dutzende oder hunderte Verbindungen gleichzeitig aufzumachen. Diese bleiben dann offen bis zum Timeout. Da der Postfix so konfiguriert ist, dass ein Timeout erst sehr spät erfolgt und da die gleichzeitig möglichen Verbindungen limitiert sind, kann dies zu einem Denial of Service führen. Dies kann man ändern, indem man in der main.cf die Timeouts ändert. Folgende Werte haben sich bei mir bewährt:


smtp_connection_reuse_time_limit = 40s
smtpd_timeout = 20s
smtpd_idle_timeout = 20s

Ein weitere Aufgabe besteht darin, einmal negativ aufgefallene Clients von der Verbindungsaufnahme zu unserem Mailsystem abzuhalten, dazu dient mir ein kleines Perlscript mit dem Namen smtblock. Dieses Script parst das Maillog nach abgelehnten Mails aus oben genannten Regeln und erstellt eine Firewallregel für auffällige IP-Adressen. Aller einer Stunde werden diese Blockeinträge wieder gelöscht. Es gibt sicher Optimierungsmöglichkeiten dafür, so werden derzeit auch doppelte Einträge erzeugt. Ausserdem ist das Script ein Resourcenfresser, da es mehrfach pro Minute durch das Maillog auf Suche geht. Bei MTAs an der Lastgrenze ist das sicher keine gute Idee – für mich funktioniert das prima. Für Fehlerfreiheit garantiere ich nicht – für Schäden durch den Einsatz dieses Scripts hafte ich nicht!

Piwigo und PHP7, Teil 2 – der RSS Feed

Code

Der RSS Feed von Piwigo ist in Version 2.8.6 immer noch nicht PHP7 kompatibel. Wir müssen also erneut Hand anlegen, wie schon im Artikel Piwigo Umstellung auf PHP7. Wie man das selbst ändern kann, steht in diesem Artikel!

Wie äußert sich der Fehler?

Beim Abonieren des Fehlers wird ein malformed XML Fehler angezeigt. Eine Recherche im Quelltext des Feeds ergibt „Piwigo und PHP7, Teil 2 – der RSS Feed“ weiterlesen

Die Google Bildersuche – wie der Suchmaschinenriese Fotografen um den Traffic bringt

Google Bildersuche und robots.txt mit Piwigo

Die Google Bildersuche ist seit Anfang Februar 2017 nun auch in Deutschland so verfügbar, wie sie es schon vorher im Rest der Welt war…wie auch Bing seine Bildersuche präsentiert! Für uns Piwigo Bildergalerie-Betreiber ist das vielleicht ein Problem.

Wo ist das Problem mit der Google Bildersuche?

„Die Google Bildersuche – wie der Suchmaschinenriese Fotografen um den Traffic bringt“ weiterlesen

TLS – Transport Layer Security für eingehende und abgehende Emails

TLS aka Transport Layer Security – Verschlüsselung

Wir wollen dafür sorgen, dass unsere Mails auf verschlüsselten Wegen gesendet und empfangen werden. Immer mehr Provider warnen, wenn Emails über SMTP ohne TLS (ohne Verschlüsselung) empfangen wurden. GMail sagt dann z.B.:

Ohne Verschlüsselung bzw TLS
Ohne Verschlüsselung bzw TLS

 

Wir wollen aber lieber das hier sehen

Mit Verschlüsselung bzw TLS
Mit Verschlüsselung bzw TLS

„TLS – Transport Layer Security für eingehende und abgehende Emails“ weiterlesen

SPF aka Sender Policy Framework für abgehende Mails nutzen mit Postfix

SPF aka Sender Policy Framework

SPF besteht aus einem Eintrag im für unsere Domain zuständigen DNS-Server. Dieser Eintrag enthält Regeln. Anhand dieser Regeln kann ein empfangender Mailserver prüfen, ob die Quelle der Mail für die Domain von deren Verwalter zugelassen wurde. Anlaufstelle für die Dokumentation ist http://www.openspf.org/, es gibt aber gute deutsche Seiten und sogar Generatoren für SPF-Einträge. Man muss sich einfach nur Gedanken machen, welche Server im eigenen Namen Mails versenden dürfen, und was passieren soll, wenn der absendende Server nicht im SPF-Record enthalten ist.

Ein sehr einfacher Eintrag: „SPF aka Sender Policy Framework für abgehende Mails nutzen mit Postfix“ weiterlesen