Schlagwort-Archiv: mailserver

10 Gratis-PDFs zum Thema Server von TecChannel.de

Einen verspäteten Rückblick der ganz besonderen Art liefert uns der das Online-Portal tecchannel.de. Die “besten Server-Artikel 2008” werden auf der Seite kostenlos zum Download als PDF angeboten (jeweils rechts in der Sidebar). Alternativ kann man sich auch den Beitrag online auf der Seite durchlesen.

Die Themen im Überblick:

Wie man sieht, nimmt es TecChannel mit dem Begriff “Server” nicht ganz so genau und streut die Themen sehr über alles, was mit Servern zu tun hat. Vielleicht ist ja trotzdem (oder gerade deswegen) für jemanden etwas Interessantes dabei.

Viel Spaß beim Stöbern.

Link: TecChannel.de: Top Server-Artikel 2008

Postfix: Absender bei Mailversand von der Konsole anpassen

Heute war ich mal wieder auf dem Optimierungstripp und wollte endlich mal erreichen, dass die von dem Inhouse-Linux-Server abgesendeten Mails (von Cronjobs usw.) nicht immer mit dem Namen des ausführenden Users erscheinen, sondern mit etwas aussagekräftigerem. Weiterhin werde ich der Vollständigkeit halber gleich auch noch erklären, wie man die Absenderadresse so umschreibt, dass man lokalen Usern mit lokaler Domain wie root@server3 (welche aus dem Internet nicht erreichbar wären) auch vernünftig antworten kann.

Weiterlesen

Anti-Spam-Blacklist ORDB ist am Ende

Wer Spam bekämpft findet in Realtime-Blacklists ein gutes Hilfsmittel zum Aussperren bekannter Spamserver. Leider ist die Wirksamkeit nur so gut wie die Blacklist selbst. Die schon länger inaktive ORDB (Open Relay Database) wird noch immer von vielen Mailservern abgefragt und das obwohl sie schon längere Zeit keine Einträge mehr enthält.

Um auch den letzten Mailserver-Admin davon zu überzeugen, dass die Liste nichts mehr bringt, haben sie die Betreiber dazu entschlossen, nun jede Anfrage als Hit zu beantworten. Die Folge: Mailserver, die keine Gewichtung in den Blacklists haben weisen jede Mail ab. Anwender von policyd und anderen erhalten zwar eine höhere Spamwahrscheinlichkeit, aber die Mails werden nicht grundsätzlich abgelehnt.

Die Bitte der Betreiber und auch die logische Schlussfolgerung: Entfernt ordb.org aus Euren Mailservern – es hat keinen Nutzen!

Die Standardconfig von policyd-weight enthält die ordb übrigens nicht.  Generell rate ich auch zu dem Einsatz eines gewichteten Blacklistings – mehr dazu in diesem älteren Beitrag.

Artikel: Anti-Spam-Blacklist ORDB listet alles @ heise online

Schneller DNS-Check

Gerade nach einer DNS-Umstellung oder einem Providerwechsel will man sicher sein, dass alles korrekt aufgelöst wird und vor allem die eMails dort ankommen, wo sie sollen. Dafür gibt es eine kleine Hilfe auf www.checkdns.net.

Gibt man im Formular einen Domainnamen ein, prüft der Schweizer Anbieter, ob die zur Domain gehörenden Nameserver online und synchronisiert sind, ob ein Webserver auf www.* läuft und ob die eingetragenen Mailserver zum Empfang bereit sind.

MailZu – Userbasierte Spameinschätzung

Über einen Hinweis in der Postfix-Maillingliste bin ich auf MailZu gestoßen.

Es soll, wie es aussieht, einem User ermöglichen, eingegangene Mails selbst nachträglich einzuschätzen und so die Spamerkennung zu verbessern. Weiterhin wird so eine Nicht-Zustellung wegen hohem Spamverdacht (Spam-Kill-Level) vermieden. Im großen und ganzen arbeitet die Websoftware damit wie Maia Mailguard.

Letzteres hatte ich bereits vor einiger Zeit ausprobiert, konnte es aber damals nicht fehlerfrei in meine Umgebung integrieren. Mit etwas Zeit werde ich die beiden Systeme nochmal genauer untersuchen und die Effizienzsteigerungen sowie Benutzerfreundlichkeit prüfen.

Insofern ist dieser Post eher eine Erinnung an mich selbst und ein Grund zu fragen: Hat jemand bereits Erfahrungen mit einem der Systeme? 

DNSBL database check

Auf der Suche nach einer doofen Blacklist, die meinen Server eventuell doch gelistet hat und daher die mir berichteten Spam-Einschätzungen von ausgehenden Kundenmails zu erklären, stieß ich u.a. auf die DB-Suche von relays.osirusoft.com. Aber ich musste dann doch schmunzeln, als ich die diese Meldung bekam. (Siehe vor allem den Fettdruck).

(127.0.0.2) 85.214.85.117 is DNSbl listed. by relays.osirusoft.com
Relays.osirusoft.com has not had valid data in years
Anyone using relays.osirusoft.com to stop spam must be intellectually challenged
Please stop using relays.osirusoft.com

Ich finde es recht mühseelig, die Infos den Datenbanken manuell zu entlocken. Habt ihr noch weitere Checks? Immer her damit!

Link: DNSBL database check

Neues Hobby: SPAM or NOT

Nachdem ich noch einmal etwas in einem älteren Artikel auf adminlife.net nachsehen wollte, habe ich etwas gefunden, was ich beim ersten Lesen wohl übersehen hatte: SPAM or NOT

Das Spiel ist ganz einfach: Man bekommt immer wieder Grafiken angezeigt und muss entscheiden, ob diese Spam oder Ham sind. Wenn man sich nicht sicher ist, kann man auch neutral entscheiden.

Die gesammelten Userwertungen fließen dann in die Entscheidungen von MSRBL ein.

Neben der Tat für die Allgemeinheit (bessere Spamerkennung) hat man persönlich den Vorteil, den Spam auch mal zu sehen, der sonst Dank policyd-weight und spamassasssin (hoffentlich) gar nicht erst beim Mailprogramm ankommt. So bleibt man trotzdem auf dem laufenden, wo es gerade die günstigsten Viagra-Pillen gibt. ;)

Bye Bye Greylisting?

Matthias von adminlife.net hat seit neuestem Greylisting wieder ausgeschaltet, da er die Erfahrung gemacht hat, dass die Spammer sich bereits angepasst haben.

Bye Bye Greylisting! @ adminlife.net

Dies könnte bei mir ja theoretisch auch der Fall sein. Zudem sollte seit der Einrichtung von policyd-weight, die Anforderungen an das eingerichtete sqlgrey nicht mehr so hoch sein. Daher werde ich mal eine intensive Logfile-Analyse bereiben und sehen, wieviel Spam wirklich noch durch sqlgrey abgefangen wird und was durch die Tests von policyd-weight abgefangen wird.

Das Abschaffen von sqlgrey hätte natürlich den Vorteil der unverzögerten Mailzustellung, die man aber – ehrlich gesagt – vielleicht einmal im Monat wirklich braucht.

Meine Erkenntnisse werde ich dann hier posten.

Wie sieht es bei euch aus? Habt ihr sqlgrey/postgrey in Aktion? Hat sich die “Abfangrate” verschlechtert? Welche Kombination von Spamtools setzt ihr ein?

Postfix: optimierte Konfiguration gegen Spam und Missbrauch

In einem früheren Artikel versprach ich, eine Postfix-Konfiguration zu posten, die nach (meinen) neuen Erkentnissen eingerichet ist.

So sah meine Konfiguration nach der Einrichtung von sqlgrey aus:

[...]
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit
[...]

Mehrere Hinweise aus der Postfix-Mailgruppe brachten mich jedoch auf folgende Konfiguration, die weiter unten noch genauer erläutere:


#
# restrictions
#
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes

#
# Recipient Restrictions
#

smtpd_recipient_restrictions =
    reject_unlisted_sender
    reject_unlisted_recipient
    reject_unknown_sender_domain
    reject_unknown_recipient_domain
    permit_sasl_authenticated
    permit_mynetworks
    reject_invalid_hostname
    reject_non_fqdn_sender
    reject_non_fqdn_recipient
    reject_unauth_destination
    #policyd-weight
    check_policy_service inet:127.0.0.1:60001
    #sqlgrey
    check_policy_service inet:127.0.0.1:60000
    reject_unknown_client
    reject_unknown_hostname
    permit

Es handelt sich hier natürlich nur um einen Ausschnitt aus der main.cf, diese Parameter sind sehr wichtig, wenn es darum geht, welche Mails von Postfix zur Zustellung angenommen werden.

Weiterlesen

policyd-weight: Score-basierte Spamabwehr für Postfix

Es ist immer wieder das gleiche: Sobald man denkt, dass man das System perfekt eingerichtet hat, bekommt/ findet man gleich mehrere Hinweise, die einen daran zweifeln lässt.

Ausgangslage

Bei vielen, die sich halbwegs um einen spamgeschützten Postfix-Mailserver kümmern, wird die Konfiguration ungefähr so aussehen:


[...]
smtpd_recipient_restrictions =
permit_sasl_authenticated
permit_mynetworks
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unauth_destination
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_rbl_client dnsbl.ahbl.org
reject_rbl_client cbl.abuseat.org
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
check_policy_service inet:127.0.0.1:60000
reject_unknown_client
warn_if_reject reject_unknown_hostname
permit
[...]

Anmerkung: Diese Konfiguration hatte ich bereits hier gepostet, wurde von mir nun aber mehrfach verfeinert (siehe weiter unten).

Wie man sehen kann, sind mehrere RBL-Checks (Realtime-Blackhole-List) in der Konfiguration, welche bei jedem SMTP-Connect von anderen Mailservern überprüft werden und bei einem positiven Treffer sofort zum REJECT führen. Dies hat zwar funktioniert, birgt aber die Gefahr, dass man einen legitimen Mailserver ablehnt, weil er durch einen Fehler in einer der RBL landete.

Besser wäre es also doch, wenn man nachschauen könnte, ob der Mailserver in mehr als einer dieser RBLs steht. Mit Boardmitteln von Postfix ist dies vorerst nicht möglich.

Einführung in policyd-weight

Hier kommt policyd-weight als policy-Server ins Spiel und bietet folgende Zusatzfunktionen in der Standardkonfiguration an (Auszug von der Website):

  • Score-basierte Auswertung von RBL/RHSBL
  • Score-basierte Auswertung der Beziehung und Korrektheit von DNS-Einträgen, HELO und MAIL-FROM
  • Caching von a) DNS-Request und b) Score-Ergebnissen (= Beschleunigung und weniger Traffic)
  • eigene, schnelle DNS-Lookup.Routine
  • frei konfigurierbare Scores und RBLs (sinnvolle Standardwerte bereits enthalten)
  • keine Datenbank-Abhängigkeit
  • Einrichtung auch nur für eine Teilmenge von Mails/Mailservern nutzbar (via postfix restriction classes)

Policyd-weight arbeitet als Policy-Server mit Postfix zusammen und entgegen z.B. AMAViS noch auf der Ebene des SMTP-Connects und ist daher in der Lage, Postfix einen REJECT der Verbindung zu empfehlen und die Mail erst gar nicht anzunehmen zu lassen. (Dies ist auch im Hinblick auf die Rechtslage ein wichtiger Unterschied.)

Diese Vorteile sprechen ja deutlich für den Einsatz von policyd-weight und daher nahm ich mir auch gleich die Installation vor, welche im Folgenden beschreiben werde.

Weiterlesen

rechtliche Fallstricke beim Filtern von Spam

Mit dem wachsenden Aufkommen von Spam und den dazu eingeleiteten Gegenmaßnahmen müssen auch rechtliche Aspekte in den Fokus eines Admins bzw. eines beauftragenden Geschäftsführers kommen.

Der hier verlinkte Artikel der c’t ist bereits älteren Datums, aber jedoch nichtsdestotrotz aktuell.

Hier geht’s zum c’t-Artikel (26/2003, S. 186)

Die einzige Möglichkeit des Spamhandlings ohne eine dieser Betriebsvereinbarungen und/oder Servicevereinbarungen zur Einwilligung der Spamfilterung ist imho die Ablehnung einer Mail (keine Annahmen = keine Zustellpflicht) oder – nach der Annahme – die unbedingte Zustellung der Mail, ggf. unter Hinzufügung von Spamtags.

Meine Frage an Euch, geschätzte Leser, ist, ob Ihr Vorlagen für solcher Art Vereinbarungen habt und wenn ja, ob ihr mir bzw. den anderen Lesern eventuell diese zur Verfügung könntet?!

Mail-Logs im Auge behalten

Ich habe mir, nachdem ich der Postfix-Mailgruppe mehrere Hinweise las, die diversen Tools zur Logfile-Analyse angesehen und mich danach entschieden, ein paar auf regelmäßiger Basis einzusetzen.

Folgende Tools sind nun bei mir im Einsatz:

  • pflogsumm: Postfix-Logs analysieren und zusammengefasst ausgeben (englische Version / deutsche Version)
    Es läuft nächtlich als cron, analysiert den vorherigen Tag und wird mir via Mail zugesendet.
  • mailgraph: Postfix-Logs graphisch darstellen (z.B. ACCEPTs, REJECTs, BOUNCEs usw.) (Beispielausgabe)
  • queuegraph: Postfix-Queue-Belastung wird graphisch aufbereitet
  • couriergraph: Courier-Logs graphisch darstellen (z.B. LOGINs)
    Die *graph-Tools sind jeweils eine Kombination aus Perl-Script (laufen als cron (queuegraph) oder daemon (mailgraph/couriergraph)) und Web-CGI für die Ausgabe im Web.

Sämtliche Tools sind zwar als Debian-Pakete erhältlich, aber die deutsche Pflogsumm-Version kann man derzeit nur über den o.g. Download installiert werden.

Fragen? Probleme? Immer her damit, denn dafür sind die Comments da…

sqlgrey: einfaches und robustes Greylisting

Spam nervt und stiehlt jedem Nutzer täglich Zeit. Um zu vermeiden, dass wir eines Tages nur noch mit dem Löschung von dubiosen Angeboten beschäftigt sind, müssen wir uns immer wieder mit Gegenmaßnahmen befassen. Eine dieser Gegenmaßnahmen ist Greylisting.

Was ist Greylisting?

Das Wort Greylisting entstand aus den Wörtern Blacklisting (in diesem Kontext: permanentes Verbot einer E-Mailadresse) und Whitelisting (permanente Erlaubnis für eine E-Mailadresse) und bezieht sich auf die Mischung dieser beiden Verfahren. Das Verfahren funktioniert vereinfacht wie folgt:

  1. Ein dem Mailserver unbekannter Absender (freund@absender.tld) möchte gern ein Mail an person1@mailserver.tld senden.
  2. Der Mailserver (mit installiertem Greylisting) aber lehnt die Übermittlung nach Erhalt der Absender und Zieladresse unter Angabe eines temporären Fehlers ab (meist mit einer Greylisting-Erklärung für das Logfile).
  3. Der Mailserver trägt die IP des Absendermailserver ( absender.tld, 123.123.123.123 ) zusammen mit dem Absender (freund@absender.tld) und der Zieladresse (person1@mailserver.tld) in seine Datenbank ein.
  4. Ein vernüftig konfigurierter Mailserver wird innerhalb der nächsten 10 bis 60 Minuten eine erneute Zustellung versuchen. So ist es auch und so versucht der Mailserver von freund@absender.tld erneut, die Mail an person1@mailserver.tld zu übergeben.
  5. Der Zielmailserver schaut nun wiederum in seine Datenbank, ob ihm diese Kombination aus Quell-IP (wahlweise auch Quell-Subnetz), Absender und Adressat bereits bekannt ist. Da dem in diesem Fall so ist, nimmt er die Mail an und bestätigt die Annahme.

Die Idee hinter dieser “Verkomplizierung” der Mailzustellung ist, dass die Spammaschinen entweder das Handling von temporären Fehlern ausgeschaltet oder dieses in Ihren Mailprogrammen/ -servern gar nicht implementiert haben, um den Durchsatz zu erhöhen.

Wie kann ich Greylisting einsetzen?

Da Greylisting wie oben erläutert noch vor der Annahme der Mail geschehen muss, kann man dieses entweder direkt im Mailserver integrieren (z.B. Plugin) oder alternativ dem Mailserver als Proxy vorschalten.
Weiterlesen

note to myself: RFCs lesen

Ich hatte heute wieder mal eine Erkenntnis: RFCs lesen hilft, dass alles so funktioniert wie es soll.

Szenario: Ein Kunde teilt mir mit, dass eine bestimmte Person ihm keine Mails senden kann. Die mir bekannte Person habe ich nach einem Fehlerbericht des Mailservers gefragt und war erstaunt zu lesen:

domain name system error:
host mail.kundendomain.tld:
mail exchanger has no ip addresses

WTF? Als wenn ich für den Mailserver keine IP eintragen würde, klar!

Eine Quick-Google-Search brachte die Erklärung:

Da ich gerade mit meinem Server umgezogen bin und bei allen Domains die IP einzeln ändern musste (btw: Danke NicDirect!), hatte ich es gleich so eingerichtet, dass ich beim nächsten Mal, so wenig wie möglich ändern muss. Daher machte ich folgende Eintragungen im DNS:

kundendomain.tld in MX 10 mail.kundendomain.tld
mail.kundendomain.tld in CNAME mail.mydomain.tld

Also steht in dem DNS-Eintrag des MX des Kunden ein CNAME für eine andere Domain. Laut RFC1912 soll man aber keine CNAMEs in den MX eintragen.

Meine schöne Erleichterung war also dahin…. naja, nicht ganz. Ich habe es dann eben wie alle großen Hoster (warning: GRÖßENWAHN) gemacht und nicht den MX-Eintrag der Domain auf die Kundendomain sondern gleich auf mail.mydomain.tld zeigen lassen. Ist zwar nicht so schick, aber RFCs sind da nun einmal eindeutig.

PS: Ach ja, der Mailserver, der das Problem gemeldet hat und die Zustellung daher verweigerte von übrigens von Schlund bzw. 1&1. Wie ich lesen konnte, war ich nicht der Einzige, der auf dieses Problem gestoßen bin.