Kategorie: E-Mail & Mailserver (Seite 7 von 8)

Zu beginn habe ich diese Seite nur mit dem Text: „Zeugs zu Postfix“ gefüllt!

Dieses erfüllt auch jetzt noch fast alles was es als Beschreibung zu sagen gibt. Aber auch nur fast! Postfix ist einer der besten und flexiebelsten MTAs die ich kenne. Hier werfe ich nun immer mal wieder Zeugs hin, welches vielleicht hilfreich sein könnte 🙂

Ich beobachte in der letzten Zeit immer mal wieder dass E-Mails im AMaViS lange hängen bleiben…. Viel Zeit scheint dabei für die Festplatte bzw. die Schreib-/Lesezugriffe drauf zu gehen. Die E-Mail wird von AMaViS angenommen, in dessen tmp Verzeichnis geschrieben. Dann noch ein paar mal gelesen um alle Tests zu machen, ausgepackt usw. usw… Um dieses etwas einzugrenzen habe ich mich gedacht, warum nicht eine RAM Disk für AMaViS oder besser für dessen Temp?

Auf einer gängigen Debian Kiste findet sich dieses Verzeichnis hier:

/var/lib/amavis/tmp

 Damit dieses Verzeichnis nicht mehr auf der Festplatte herum-gewürfelt wird, sondern sich nur noch im Arbeitsspeicher des Servers befinden (der ist ja viel schneller als so ne olle HDD) trägt man folgendes in seine /etc/fstab ein:

/dev/shm    /var/lib/amavis/tmp    tmpfs    defaults,size=256m,mode=750,uid=109,gid=113    0 0

 Man sollte nur darauf achten, dass uid und gid die des lokalen amavis sind. Sonst darf am Ende AMaViS nicht mehr in ein eigenes Temp schreiben 😛 Es soll bessere Wege die ID zu finden, ich mache es schnell und einfach mit:

$ cat /etc/passwd|grep amavis
amavis:x:109:113:AMaViS system user,,,:/var/lib/amavis:/bin/sh

109 ist dabei die User-ID
113 ist die Group-ID

 Das neue AMaViS-tmp ist damit 256MB gross. Für die Grösse gibt es eine „Faustformel“… Diese macht nicht für jeden Sinn! Man würde mit dieser Formel zwar _fast_ nie in die Gefahr eines zu kleinen AMaViS-temps laufen, nur verbrennt man so seinen RAM. Try and Error ist hier eher mein Vorschlag. Denn sollte AMaViS wirklich mal keinen Platz mehr haben, wird die E-Mail mit einem temporären Fehler abgewiesen. Der einliefernde Mailserver wird daher versuchen die E-Mail ein paar Minuten später noch einmal zuzustellen. Damit sollte keine E-Mail verloren gehen. Als Admin behält man nach so einer Änderung einfach seinen Server im Auge und erhöht bzw. reduziert den Wert/die Grösse… Fertig 🙂

Die RAM-Disk gibt AMaViS einen extremen Boost und steigert so dessen Performance enorm. Ich finde es kommt selten vor dass man so einfach ein so krasses Performance-Tuning hin bekommt. Nun laufen die E-Mails also schneller durch AMaViS und mein Postfix muss nicht mehr so lange auf die Filterung warten. WOOOOHOOOOO

Na also, nun hat die Telekom die Sicherheitsrichtlinien ihrer E-Mail Server so angepasst dass helo, hostname und R-DNS zusammenpassen müssen. Sonst gibt es diese Meldung:

A problem occurred. (Ask your postmaster for help or to contact tosa@rx.t-online.de to clarify.)

So gefällt mir das! Meine Kiste macht dieses ja schon länger so und ich bekomme immer mal wieder die Info, man könne mir keine E-Mail schicken. Mein Mailserver sei wohl kaputt, er sage immer:

550 5.7.1 Client host rejected: cannot find your hostname….

Wenn ich dann erkläre um was es geht bekomme ich immer mal wieder den Vorwurf da zu –genau- zu sein. Da jetzt noch ein weiteres großes Unternehmen genau so verfährt werden sich wohl noch mehr Mailserver „Administratoren“ um dieses Problem kümmern müssen. Lustig finde ich ja dass die Telekom direkt eine E-Mail Adresse angegeben hat tosa@rx.t-online.de, was da wohl abgehen muss 🙂

http://www.kernel-error.de/postfix-spam-und-virenabwehr-durch-helo

Debian Lenny, dovecot 1.2, quota 1.1, MySQL und Quota Warnings.

Ich habe vor kurzem vor dem Problem gestanden meinen dovecot mailboxen quotas aufzuerlegen. Die Anleitung von: http://wiki.dovecot.org/Quota/1.1 war sehr hilfreich, funktioniert aber leider mit meiner Konfiguration nicht sofort.

Ich wollte folgendes erreichen:
–    Alle Mailboxen haben im Standard eine quota von maximal 512MB.
–    Jeder Mailbox kann ich dynamisch mehr oder weniger Platz zur Verfügung stellen.
–    Die Benutzer sowie der Admin sollen frühzeitig Warnmeldungen bekommen, wenn der Platz eng wird.

Als erstes musste eine etwas aktuellere Version vom dovecot (Taubenschlag) auf den Lenny Server. Glücklicherweise findet sich die Version 1.2 schon in den Backports. Diese waren schnell eingebunden!

echo "deb http://www.backports.org/debian lenny-backports main contrib non-free" >> /etc/apt/sources.list
apt-get update && apt-get install debian-backports-keyring && apt-get update
apt-get –t lenny-backports install dovecot-common

Nach der Installation erweiterte ich meine /etc/dovecot/dovecot.conf um die folgenden Einträge in den jeweiligen Sektionen.

protocol imap {
mail_plugins = quota imap_quota
}

 

protocol lda {
mail_plugins = sieve quota
quota_full_tempfail = yes
}

Hier ist zu beachten das in der neueren dovecot Version das sieve Plugin nicht mehr cumsieve heist! Damit E-Mais bei vollem Postfach nicht sofort zurückgewiesen werden, sondern mit einem temporären Fehler (so hat der Postfachbesitzer etwas mehr Zeit sein Postfach aufzuräumen), gibt es den 2. Eintrag.

plugin {
quota = dirsize:User quota
quota_rule = *:storage=512M
quota_warning = storage=80%% /usr/local/bin/quota-warning.sh 80 %u
quota_warning2 = storage=95%% /usr/local/bin/quota-warning.sh 95 %u
quota_warning3 = storage=99%% /usr/local/bin/quota-warning.sh 99 %u
}

Hier gebe ich nun an das ich als Backend, also über welche der möglichen Lösungen ich den Speicherplatz „berechnen“ möchte. Zudem gebe ich an, das jede Mailbox default 512MB Platz hat.
Quota_warning… Ruft jeweils bei 80%, 95% und 99% Mailboxauslastung das Script /usr/local/bin/quota-warning.sh auf.

Das Script muss man selbst anlegen. Das script im dovecot-wiki hat bei mir nicht so ganz funktioniert, es wurden keine quota_warnings generiert, versendet oder wie auch immer. Daher habe ich es etwas umgeschrieben und als weitere Übergabewert mir noch die betreffende E-Mailadresse des Postfaches mit übergeben lassen „%u“. Zusätzlich wollte bei mir (warum auch immer /usr/sbin/sendmail) nicht funktionier. Daber habe ich auf Heirloom Mailx zurückgegriffen (apt-get install heirloom-mailx). Mein script ist ausführbar (chmod +x /usr/local/bin/quota-warning.sh) und gehört dem Benutzer sowie der Gruppe vmail (chown vmail:vmail /usr/local/bin/quota-warning.sh). Es schaut nun so aus:

#!/bin/bash
PERCENT=$1
USER=$2
FROM=" <a href="mailto:%3Ca%20href=" mailto:sebastian="" vandemeer="" de="">sebastian@vandemeer.de"><a href="mailto:sebastian@vandemeer.de">sebastian@vandemeer.de<span style="display: none;">This e-mail address is being protected from spambots. You need JavaScript enabled to view it. "
qwf="/tmp/quota.warning.$"
echo "
(for English version please see below
Liebe(r) Mailsystem Benutzer(in
ihr E-Mail Postfach $USER ist jetzt zu  $PERCENT% voll.
Fuer Informationen senden Sie eine E-Mail an: sebastian@vandemeer.de">sebastian@vandemeer.de

Ab jetzt läuft das Thema Quota schon. Es lässt sich auch testen. Für alle jeweils 512MB.

Jetzt möchte ich natürlich in meiner mysql Datenbank den einzelnen Mailboxen mehr oder weniger Platz zuweisen können! Diesen Teil kann man für seine eigene Konfiguration aber nur dann so wie jetzt beschrieben übernehmen, wenn die Benutzerauthentifizierung wie bei mir funktioniert. Hier habe ich etwas länger gehangen bis ich eine funktionable Lösung hatte. Wer hier auch hängt: http://www.gidf.de/ vielleicht kann ich auch helfen (e-mail)!
Ich musste bei mir meine dovecot-sql.conf um die folgende Zeile erweitern:

>>Klick mich<<

Dann habe ich in der dovecot.conf den Teil auskommentiert:

#  userdb static {
#    # Template for the fields. Can return anything a userdb could normally
#    # return. For example:
#    #
#    args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes
#    #
#    #args =
# }

Und durch diesen hier „ersetzte“:

userdb prefetch {
}
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}

In meiner Datenbank habe ich dann ein neues view angelegt, und vorher meiner Tabelle virtual_users ein neues Feld quota_kb spendiert:

CREATE VIEW view_users_quota AS select concat(`virtual_users`.`user`,_latin1'@',`virtual_domains`.`name`) AS `email`,`virtual_users`.`quota_kb` AS `quota_kb`,`virtual_users`.`password` AS `password` from (`virtual_users` left join `virtual_domains` on((`virtual_users`.`domain_id` = `virtual_domains`.`id`)));

Dieses view sammelt sich aus meinen anderen Tabellen die passenden Informationen zusammen und erbricht bei einer Abfrage gleich auch die Quota infos:

>>klick mich<<

Jetzt klappt es auch mit den dynamisch zugeteilten quotas. Dafür habe ich aber etwas gebraucht *lach*!

Als Webmailser setzte ich roundcube ein. Dieser zeigt einem sogar in einer lustigen Statusleiste wieviel Platz gerade „verschwendet“ wird. Dieser Statusbalken hat mir (quick and dirty) beim Testen sehr geholfen :-P! Zudem kann roundcube mit sieves-filtern bessern umgehen als alle mir (derzeit) bekannten Mailclients!

*Update*

Da gibt es etwas neues. Man muss natürlich nicht unbedingt über den view gehen. Ich habe ein weiteres System neu aufgesetzt. Alles läuft nun über /var/vmail und die sql user query schaut nun so aus: >>klick mich<<

Ne ne ne… im Grunde müsste ich das alles noch einmal neu schreiben 😛 Wenn ich dafür nur die Zeit hätte!

Zu überprüfen ob die Angaben des Absenders, des Empfängers oder der Clients stimmen, ist für Postfix recht einfach. Es ermöglicht das schnelle „Ausfiltern“ von Spam- und Virenversendern.

Als Beispiel:

Wenn jemand versucht eine E-Mails an mich zu verschicken, und als Absender eine Domain angibt, die im DNS keinen A-Record oder keinen MX eingetragen hat, werde ich auf diesen Absender niemals antworten können. Eine solche E-Mail kommt fast ausschließlich von Viren- und Spamversendern, welche sich Absenderdomains ausdenken müssen. Ähnlich verhält es sich mit der Angabe des Clienthostnames. Ordentlich konfigurierte Mailserver melden sich mit ihrem FQDN und der Revers-DNS Eintrag passt zu diesem. Gekaperte Rechner eines Botnetzes melden sich maximal mit dem Namen, welcher vom Besitzer eingegeben wurde (Peters Wohnzimmerhobel)… Selbst wenn der FQDN passt, wird der Botnetzbetreiber kaum beim ISP des gekaperten Rechners einen passenden Reverse-DNS setzten lassen. Bei Verbindungen aus dynamischen IP-Netzten, sprich A-DSL T-COM 0815 Internetverbindungen, ist der Hostname meist nicht mal in einem gültigen Format. Warum auch? Dieses können wir uns zunutze machen, indem wir hier schon aussortieren. Fällt doch mal ein gewünschter Absender unter diese Restriktionen, hat dessen Admin meist nicht sauber gearbeitet. Der Admin und der Absender der E-Mail werden über passende Rückmeldungen und Logeinträge auf diesen Punkt aufmerksam gemacht!

Diese Filtermethode ist recht effektiv (30 – 55 Prozent Spam und Viren fliegen hier schon weg), einfach und sicher.

Eine erste grobe und einfache Konfiguration läuft so….

In der Datei /etc/postfix/main.cf müssen folgende beiden Zeilen ergänzt werden:

smtpd_helo_required = yes
smtpd_delay_reject = yes

smtpd_helo_required gibt vor, das unser Server immer und von jedem ein helo erwartet. Ist smtpd_delay_reject auf yes gesetzt führt Postfix die UCE-Filterung erst nach dem „RCPT TO:“ aus. Würde dieses nicht so sein, hätten einige SMTP Clients von z.B.: Microsoft damit arge Probleme.

Die einzelnen Beschränkungen legen wir passend unter den einzelnen Optionen an, was welche bewirkt erkläre ich unten….

Unter smtpd_recipient_restrictions:

        reject_unlisted_recipient,
        reject_non_fqdn_recipient,
        reject_non_fqdn_helo_hostname,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_unknown_recipient_domain,
        reject_unknown_client_hostname,
        reject_unknown_helo_hostname,
        reject_unknown_client,
        reject_unknown_recipient_domain,
        reject_unknown_sender_domain,
        reject_unauth_destination,
        reject_invalid_helo_hostname,
        reject_invalid_hostname,

Wichtig ist hier die Einrückung sowie Beachtung des Komma!

reject_non_fqdn_sender
Weist den Absender der E-Mail zurück, wenn dieser nicht in FQDN Form angegeben wurde.

reject_non_fqdn_recipient
Weist den Empfänger der E-Mail zurück, wenn dieser nicht in FQDN Form angegeben wurde.

reject_non_fqdn_hostname
Weist E-Mails zurück, wenn der Clientname nicht in FQDN Form angegeben wurde.

reject_invalid_hostname
Weist E-Mails zurück, wenn der Clientname nicht in einem gültigen Format angegeben wurde.

reject_unknown_recipient_domain
Weist die Anfrage zurück, wenn die angegebene Domain (RCPT TO) des Empfängers im DNS keinen Eintrag vom Typ A oder MX hat.

reject_unknown_sender_domain
Weist die Anfrage zurück, wenn die angegebene Domain (MAIL FROM) des Absenders im DNS keinen Eintrag vom Typ A oder MX hat.

reject_unlisted_recipient
Weist die E-Mail zurück, wenn der Empfänger nicht in der Liste der gültigen Empfängerdomains aufgeführt ist.

reject_unauth_destination
Weisst die E-Mail zurück:
  – wenn Postfix als relay Host arbeitet und die angegebene Empfängerdomain nicht in der Liste gültiger Weiterleitungsdomains steht.
  – wenn Postfix der Zielserver ist und die angegebene Empfängerdomain nicht in der Liste gültiger Empfänger steht.

reject_unknown_client_hostname
Weisst die E-Mail zurück, wenn Hostname und IP Adresse des einliefernden Mailservers nicht zueinander passen, oder nicht aufgelöst werden können.

reject_invalid_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname fehlerhaft ist. Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_non_fqdn_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname kein fqdn nach RFC ist.  Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_unknown_helo_hostname
Weisst die E-Mail zurück, wenn der im HELO oder EHLO angegebene Hostname keinen A oder MX Record hat. Damit Clients diesen Test nicht einfach umgehen können, indem sie kein HELO/EHLO senden sollte die Option smtpd_helo_required = yes gesetzt werden.

reject_unknown_client
Weisst die E-Mail zurück, wenn Host-IP Adresse und der Hostname des einliefernden Mailservers nicht zueinander passen, oder nicht aufgelöst werden können.

Nach einem Restart von Postfix kann man nun im Logfile schon die Wirkung der Beschränkungen bewundern:

tail -f -n 200 /var/log/mail.log

Hier versucht der Client „userpc“ mit der IP: 94.52.112.110 (GeoIP City Edition, Rev 1: RO, 10, Bucharest, (null), 44.433300, 26.100000, 0, 0) eine E-Mail einzuliefern. Da aber userpc kein FQDN ist, wird die Verbindung vom Server mit einem 504 zurückgewiesen. Der Vorteil von Errorcodes aus dem Bereich 5XX ist das wir (also der angesprochene Server) die Verbindung sofort beenden können, ohne auf den Client zu warten. Damit werden Verbindungen sofort wieder freigegeben und stehen anderen Verbindungen zur Verfügung.

Jun 7 17:50:35 smtp postfix/smtpd[22037]: NOQUEUE: reject: RCPT from unknown[94.52.112.110]: 504 5.5.2 <userpc>: Helo command rejected: need fully-qualified hostname; from=<MackenzieSaranzak@redvanilla.com> to=<spamemfaenger@spammdomain.de> proto=ESMTP helo=<userpc>
Jun 7 17:50:36 smtp postfix/smtpd[22037]: lost connection after DATA (0 bytes) from unknown[94.52.112.110]

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

*Update* 22.03.2012

Ich habe inzwischen ein paar Auswertungen gefahren. Dabei zeigte sich, das ich mit folgenden Optionen bereits knapp 96% aller Spam und Virenmails erschlagen kann:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_recipient_access hash:/etc/postfix/recipient-access,
        reject_rhsbl_sender rhsbl.ahbl.org,
        reject_rhsbl_sender cart00ney.surriel.com,
        reject_rhsbl_sender in.dnsbl.org,
        reject_rhsbl_sender rhsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rhsbl_client abuse.rhsbl.kernel-error.de,
        reject_rhsbl_client postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_client spam.rhsbl.kernel-error.de,
        reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
        reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_sender spam.rhsbl.kernel-error.de,
        reject_rbl_client spam.rbl.kernel-error.de,
        reject_rbl_client socks.dnsbl.sorbs.net,
        reject_rbl_client http.dnsbl.sorbs.net,
        reject_rbl_client misc.dnsbl.sorbs.net,
        reject_rbl_client web.dnsbl.sorbs.net,
        reject_rbl_client new.spam.dnsbl.sorbs.net,
        reject_unlisted_recipient,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_unknown_client_hostname,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_client,
        check_policy_service unix:private/tumgreyspf

smtpd_data_restrictions =
        reject_unauth_pipelining,
        permit

unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550

Wichtig:

Die Liste *.kernel-error.de ist meine ganz eigene private. Die nur für mich und meine eigenen Zwecke angedacht ist. Als einfachen Test könnt ihr sie natürlich gerne abfragen aber sie sollte niemals produktiv eingesetzt werden. Das wird bestimmt mal Probleme geben. Am besten einfach weg lassen!

Hier hätte ich dann noch die groben Auswertungen der Kiste, die sich um meine privaten Mails kümmert. Ist natürlich mit keinem großem Mailsystem zu vergleichen. Aber die Leute stehen ja so auf bunte Bilder 😛

Greylisting ist ein sehr einfacher und ebenso wirkungsvoller Kniff um sich gegen Spam und Viren zu schützen. 80 bis 90 Prozent der Spammails und fast schon alle Viren werden inzwischen von großen Botnetzen verschickt. Vor allem Betreiber größerer Mailserver bekommen schnell Probleme durch solche Botnetze. Die von großen Botnetzten ausgelösten Spam- und Virenfluten, verstopfen die Mailserver. Dadurch verzögern sich die Zustellungen einzelner E-Mails auf fast schon unbestimmte Zeit. Der bearbeitende Mailserver ist oft damit ausgelastet sich um Spam- und Virenmails zu kümmern.

Wie kann Greylisting hier nun helfen? Im Grunde ganz einfach….

Wenn ein Mailserver das erste Mal versucht einem Mailserver mit Greylisting eine E-Mail zuzustellen, wird diese mit der Bitte abgewiesen, es in ein paar Minuten noch einmal zu probieren. Im gleichen Moment speichert der Mailserver ein so genanntes Tripple. Dieses Tripple besteht aus der E-Mail Adresse des Empfängers, der E-Mail Adresse des Absenders und der IP-Adresse des Clients. Versucht nun der Mailserver nach ein paar Minuten eine erneute Zustellung, wird dieses von unserem greylistingfähigen Mailserver erkannt und die E-Mail wird ohne weitere Verzögerung zugestellt. Was das nun bringen soll? Nun ja, fast alle Botnetze arbeiten nach dem „fire and forget“ Prinzip. E-Mails werden also einfach abgeschickt und dann nicht weiter beachtet. Das liegt daran, dass die Botnetze sehr effektiv arbeiten sollen. In der Zeit, in welcher sich das Botnetz damit befasst eine E-Mail zu puffern und später noch einmal zuzustellen, sich darum kümmert das ein angesprochener Mailserver gerade nicht antwortet oder eine E-Mail Adresse nicht mehr existiert, in dieser Zeit hätte das Botnetz schon mehrere andere Empfänger anschreiben können. Zudem ist die Wahrscheinlichkeit, dass ein Server mit Greylisting auch sonst gut vor Spam geschützt ist und die E-Mail in einem nachgeschalteten Filter sowieso ausgefiltert wird, größer als bei einem anderen Server. Denn hier hat der Admin anscheinend seine Hausaufgaben gemacht. Aus diesen Gründen ist es für einen Botnetzbetreiber einfacher und besser von seinem vermeintlichen Opfer abzulassen und sich mit einem anderen zu beschäftigen!

Mit aktiviertem Greylisting wird nun jede erste Zustellung eines Mailservers verzögert zugestellt. Fast alle Greylistingsysteme sind selbstlernend, d.h.: nach kurzer Zeit landen bereits bekannte Mailserver auf einer whitelist und müssen ab diesem Moment keine Verzögerung mehr erdulden. Greylisting ist zwar in einigen Fällen nutzlos und sicher ist es kein Allheilmittel gegen Spam und Viren, es hält dem Mailserver denn noch sehr viel „Müll“ vom Hals, damit dieser sich um andere Dinge kümmern kann!

Zusammen mit Postfix benutze ich seit längerem schön das Tool postgrey von David Schweikert.

Eine Erste funktionsfähige Implementierung ist unter Debian schon in 5 – 7 Minuten zu realisieren.

Postgrey ist direkt aus dem Paketmanager heraus zu installieren:

apt-get install postgrey

Im Normalfall wird postgrey nach der Installation sofort ausgeführt. Dieses lässt sich recht schnell überprüfen, da es auf dem Port 60000 auf 127.0.0.1 lauscht.

netstat -anp | grep 60000

Sollte hier nun etwas wie:

tcp 0 0 127.0.0.1:60000 0.0.0.0:* LISTEN 2540/postgrey.pid -

zurückgeben….

Um Postfix nun die Nutzung von postgrey näher zu bringen, müssen in der Datei /etc/postfix/main.cf die „smtpd_recipient_restrictions“ um den Eintrag:

check_policy_service inet:127.0.0.1:60000

erweitert werden. Nach einem Postfixrestart sollte das Greylisting schon laufen. Genauer kann man es sich direkt im Logfile anschauen:

tail -f -n 200 /var/log/mail.log

Es wird das erste Mal versucht eine E-Mails einzuliefern. Porstgrey vergibt die action greylist. Postfix antwortet dem einlieferndem Server also mit:: „450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html“ Alle 4XX Fehler sind als temporäre Fehler deklariert, daher wird es der einliefernde Mailserver in kürze noch einmal probieren!

Jun 7 10:26:29 smtp postfix/smtpd[9268]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:26:40 smtp postgrey[1202]: action=greylist, reason=new, client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:26:40 smtp postfix/smtpd[9268]: NOQUEUE: reject: RCPT from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]: 450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html; from=<kernel-error@kernel-error.de> to=<Testadresse@testdomain.de> proto=ESMTP helo=<smtp.kernel-error.de>
Jun 7 10:26:40 smtp postfix/smtpd[9268]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Hier ist nun der zweite Einlieferungsversuch des Mailservers! Postgrey erkennt hier schon, den Server. Die Zeit, welche zwischen den Zustellversuchen vergehen muss (default 5 Minuten), ist noch nicht abgelaufen: „reason=early-retry (84s missing)“. Aus diesem Grund wird dem einliefernden Mailserver wieder ein: „450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html“ zurückgegeben.

Jun 7 10:30:11 smtp postfix/smtpd[9268]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:30:16 smtp postgrey[1202]: action=greylist, reason=early-retry (84s missing), client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:30:16 smtp postfix/smtpd[9268]: NOQUEUE: reject: RCPT static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]: 450 4.2.0 <Testadresse@testdomain.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/testdomain.de.html; from=<kernel-error@kernel-error.de> to=<Testadresse@testdomain.de> proto=ESMTP helo=<smtp.kernel-error.de>
Jun 7 10:30:16 smtp postfix/smtpd[9268]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Jetzt kommen wir zum dritten Einlieferungsversuch. Postgrey findet das Tripple und die minimale Zeit zwischen den Zustellversuchen ist inzwischen vergangen. Daher bekommen wir die action pass, welche Postfix zur Annahme der E-Mail bringt! Die E-Mail wurde zugestellt! Postgrey wird sich diesen Vorgang nun für (default) 35 Tage speichern. Aus dieser Merkliste wird postgrey nun lernen und das Greylisting wird Stück für Stück, bei bekannten Kombinationen, verschwinden!

Jun 7 10:32:34 smtp postfix/smtpd[9827]: connect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:32:35 smtp postgrey[1202]: action=pass, reason=triplet found, delay=355, client_name=static-xxxxxxxxxxxx.de, client_address=xxxxxxxxxxxxx, sender=kernel-error@kernel-error.de, recipient=Testadresse@testdomain.de
Jun 7 10:32:35 smtp postfix/smtpd[9827]: 6B271904DA4C: client=static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]
Jun 7 10:32:35 smtp postfix/cleanup[10999]: 6B271904DA4C: message-id=<584E00FCBBB4684XXXXXXD0119300F37D4@smtp.kernel-error.de>
Jun 7 10:32:35 smtp postfix/qmgr[1637]: 6B271904DA4C: from=<kernel-error@kernel-error.de>, size=5104, nrcpt=1 (queue active)
Jun 7 10:32:36 smtp postfix/smtpd[9827]: disconnect from static-xxxxxxxxxxxx.de[xxxxxxxxxxxxx]

Hier ist nun ein Beispiel für einen Vorgang, bei welchem der Client schon eingelernt wurde.

Jun 18 11:43:40 smtp postfix/smtpd[17392]: connect from www.XXX.nrw.de[193.xxx.xxx.xxx]
Jun 18 11:43:55 smtp postgrey[1203]: action=pass, reason=client AWL, client_name=www.XXX.nrw.de, client_address=193.xxx.xxx.xxx, sender=xxxxxxxxxxxxx@uni-wuppertal.de, recipient=kernel-error@kernle-error.de
Jun 18 11:43:55 smtp postfix/smtpd[16425]: B1613904DA46: client=www.XXX.nrw.de[193.xxx.xxx.xxx]
Jun 18 11:43:55 smtp postfix/cleanup[18052]: B1613904DA46: message-id=<2A15E2XXXXXXXXXX9A17CF771D007BDC@men>
Jun 18 11:43:55 smtp postfix/qmgr[1643]: B1613904DA46: from=<xxxxxxxxxx@uni-wuppertal.de>, size=79646, nrcpt=1 (queue active)
Jun 18 11:43:55 smtp postfix/smtpd[16425]: disconnect from www.XXX.nrw.de[193.xxx.xxx.xxx]

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) als Spam- und Virenabwehr für Postfix? Diese Frage habe ich mir des öfteren gestellt. Ich sehe hier sehr klare Vorteile genauso wie Nachteile.

Der wirklich große Vorteil ist, dass wenn ein Client auf einer Blacklist steht, dieser sofort abgewiesen wird. Der Mailserver muss also erst überhaupt keine E-Mail annehmen, sich lange mit dem Client unterhalten, irgendwas filtern, auf das Beenden der Verbindung vom Client aus warten usw. usw…
Als Admin großer Mailserver wünscht man sich so etwas.

• Denn hält ein Client die Verbindung bis zum Timeout offen, ist dieser Prozess für andere eingehende Verbindungen nicht zu gebrauchen. Einem läuft also die Tabelle voll.
• Jede Spam- oder Virenemail die eingeliefert wird, verschwendet Traffic und Serverzeit.
• Jede Spam- oder Virenemail im System beschäftigt dieses auch. Die E-Mail wird zwischengelagert, verschoben, gefiltert, überprüft, verglichen usw.. Sie nimmt echten E-Mails den Platz weg, diese müssen auf die Verarbeitung von Müll warten, alles verschleppt sich. Es entstehen Mailstaus, die Zustellung gewünschter E-Mails wird bis auf ungewisse Zeit verzögert!

Der für mich große Nachteil ist, dass man sich auf andere ~blind~ verlässt.

• Ich kann die Blacklisten nicht wirklich überprüfen, es ist für mich zudem nicht wirklich transparent.
• Hin und wieder landet auch mal ein System „versehentlich“ auf einer solchen Liste.
• Ob und wie dieses System wieder von einer solchen Blackliste herunter kommt, kann ich nicht wirklich beeinflussen.

Es gibt zwar Wege, sich selbst eine solche Liste anzufertigen!
Einer ist, eine E-Mail Adresse überall dort zu veröffentlichen, wo sie vermeintliche Spammer einsammeln können. Jeder der dann an diese Adresse eine E-Mail sendet landet auf der Blackliste. So würde sich diese Liste selbst pflegen lassen. Es wird aber lange dauern bis sie wirklich effektiv arbeitet und der Spammer muss natürlich zuerst die „Sammeladresse“ anschreiben. Hier sind die großen Listen von spamhaus.org oder die Listen mit den dynamischen IP-Netzten schon viel viel viel weiter, wenn man sich auf diese verlassen möchte!

Ich habe es erst an einem Testsystem probiert und später Stück für Stück auf die echten Systeme ausgebreitet. Dieses mit überwältigendem Erfolg! ca. 80 – 90 Prozent aller Viren- und Spammails werden schon beim Einlieferungsversuch abgewiesen. Die Belastung der Server ist stark zurück gegangen. Bisher hat sich noch kein Kunde beschwert und mir ist kein Problem aufgefallen, wie Mailverlust, Falschabweisung oder ähnliches…. Diese Lösung ersetzt ganz klar keine nachgeschalteten Filter und man sollte alles im Auge behalten, hält einem denn noch extrem viel Müll vom Hals!

Die erste grobe Konfiguration ist schnell und einfach gemacht….

Die zu befragenden Server trägt man in die passenden Sektionen der Konfigurationsdatei /etc/postfix/main.cf ein.

Unter smtpd_recipient_restrictions

        reject_rhsbl_sender rhsbl.ahbl.org,
        reject_rhsbl_sender cart00ney.surriel.com,
        reject_rhsbl_sender in.dnsbl.org,
        reject_rhsbl_sender rhsbl.sorbs.net,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client ix.dnsbl.manitu.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rhsbl_client abuse.rhsbl.kernel-error.de,
        reject_rhsbl_client postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_client spam.rhsbl.kernel-error.de,
        reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
        reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
        reject_rhsbl_sender spam.rhsbl.kernel-error.de,
        reject_rbl_client spam.rbl.kernel-error.de,
        reject_rbl_client socks.dnsbl.sorbs.net,
        reject_rbl_client http.dnsbl.sorbs.net,
        reject_rbl_client misc.dnsbl.sorbs.net,
        reject_rbl_client web.dnsbl.sorbs.net,
        reject_rbl_client new.spam.dnsbl.sorbs.net,

Wichtig:

Die Liste *.kernel-error.de ist meine ganz eigene private. Die nur für mich und meine eigenen Zwecke angedacht ist. Als einfachen Test könnt ihr sie natürlich gerne abfragen aber sie sollte niemals produktiv eingesetzt werden. Das wird bestimmt mal Probleme geben. Am besten einfach weg lassen!

Beim Eintragen muss auf das Komma geachtet werden und darauf dass die Einträge eingerückt werden. Sonst wertet Postfix diese als eigenständigen Eintrag, welcher zu Fehlern führen wird!

Ist ein Mailserver „versehentlich“ auf einer Blacklist gelandet wird sich der Administrator des Mailserver natürlich irgendwann wundern, warum sein Mailserver kaum noch E-Mails ausliefern kann. Diesem Administrator wollen wir natürlich die Arbeit etwas erleichtern und sorgen für klare Logeinträge in seinem System. Zudem sollten die Absender auch etwas sinniges bekommen. Daher setzten wir eine Standardrückmeldung für alle Systeme, welche aufgrund der Blackliste abgelehnt werden! Es muss in der Konfigurationsdatei /etc/postfix/main.cf etwas in dieser Art ergänzt werden:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@$recipient_domain; So long.....

Wird die Annahme der E-Mail nun verweigert, bekommt der Absender eine sinnige E-Mail. In dieser steht nun der Grund und dass er die Nachricht bitte an seinen Administrator weiterleiten soll (dieser sollte in der Lage sein sie auch zu verstehen). Zusätzlich wird noch angegeben unter welcher E-Mail Adresse man den Postmaster des Empfängers erreichen kann.

Nach einem Restart von Postfix sollte RBL schon laufen.

tail -f -n 200 /var/log/mail.log

Wie gut zu erkennen ist, baut ein Clientsystem mit der IP: 66.220.155.147 (GeoIP City Edition, Rev 1: CA, ON, Petrolia, (null), 42.883301, -82.150002, 0, 0) eine Verbindung zu unserem Mailserver auf. Dieses System befindet sich nun auf eine Blacklist oder kommt aus einem dynamischen Adressbereich, welche auf einer Blacklist steht. Es wird daher sofort ein 554 gesendet. Alle Fehlercodes aus dem Bereich 5XX sind als dauerhafte/fatale Fehlercodes deklariert. Bei allen Fehlern aus dem Bereich 5XX baut unser Server direkt die Verbindung ab und wartet nicht auf ein Beenden der Verbindung vom Client. Diese Verbindung wird somit sofort freigegeben und steht anderen Prozessen zur Verfügung.

Oct 31 16:19:16 postfix/smtpd[7308]: connect from outmail013.ash2.facebook.com[66.220.155.147]
Oct 31 16:19:18 postfix/smtpd[7308]: NOQUEUE: reject: RCPT from outmail013.ash2.facebook.com[66.220.155.147]: 554 5.7.1 Service unavailable; Client host [66.220.155.147] blocked using ix.dnsbl.manitu.net; Your e-mail service was detected by mx.selfip.biz (NiX Spam) as spamming at Wed, 31 Oct 2012 04:20:15 +0100. Your admin should visit http://www.dnsbl.manitu.net/lookup.php?value=66.220.155.147; !!!! Forward this EMail to -YOUR- System Administrator !!!!; You can reach -OUR- System Administrator by postmaster@user.de; So long.....; from=<notification+kr4mss2q24wx@facebookmail.com>; to=<user@user.de>; proto=ESMTP helo=<mx-out.facebook.com>

Ich hoffe dieser Beitrag hilft dem einen oder anderen, sich etwas mehr Müll vom Hals zu halten!

Fragen oder Anregungen sehe ich wie immer gerne!

Ein kleines „Problem“ ist mir bei dieser Technik untergekommen. Einer der RBL Server, welchen ich abgefragt habe, hat (für mich) plötzlich seinen Dienst eingestellt. Dieses ist mir aber erst spät aufgefallen.
Im Postfixlogfile unter: /var/log/mail.log werden dazu Warnmeldungen angezeigt. Nach dem Timeout der Abfrage wurde einfach der nächste Server in der Liste abgefragt. Alles kein Problem, sollte man meinen 😀 Leider ist das Mailaufkommen auf diesem Server doch sehr hoch. Die ständigen Anfragen bis in die Timeouts führten leider in seltenen Fällen zu einer unvollständigen Rückmeldung anderer DNS-Abfragen. Einige E-Mails konnten so nicht richtig zugestellt werden. Die Rückmeldung war folgende:

<kernel-error@kernel-error.de>: Host or domain name not found. Name service error for name=mailserver.maildomain.de type=A: Host found but no data record of requested type

Nachdem ich den toten Server entfernt hatte und die DNS Abfragen nicht mehr in die Timeouts liefen, war dieses Problem weg! Ich habe nur leider in den ersten Minuten keinen Zusammenhang zwischen dem toten RBL-Server und einer gescheiterten „Weiterleitung“, wegen einer nicht vollständig aufgelösten DNS-Abfrage, gesehen.

Funktionsweise

Dazu wird in der DNS-Zone einer Domäne ein sog. Resource Record vom Typ TXT oder SPF mit Informationen darüber hinterlegt, welche Computer E-Mails für diese Domäne versenden dürfen. Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die „MAIL FROM“-Identität als auch die „HELO“-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.

Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an

test@example.org

Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden. Mit dieser Technik lässt sich die Fälschung von Absenderadressen effektiv verhindern.

SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

SPF muss nur vom Empfängersystem unterstützt werden – am SMTP-Protokoll der Mailübertragung ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt