Monat: März 2015

Verwendung von DNSBLs (DNS-based Blackhole List)

mailserverblogde Schreib einen Kommentar

Als einfache, kostengünstige Möglichkeit Spam von Ihrem Mailserver fernzuhalten, bieten sich DNSBLs an.

Eine DNS-based Blackhole List ist eine Blacklist, auf der sich IP-Adressen (und damit E-Mailadressen) befinden, die Spam versenden. Dies List wird in Echtzeit vom Mailserver abgefragt. Es handelt sich dabei um eine DNS-Abfrage.

Diese Abfrage ist zumeist direkt zu Beginn der SMTP-Kommunikation implementiert (nämlich sobald die Absender-IP bekannt ist). Dies hat den Vorteil, dass eine Mail direkt abgewiesen werden kann und so gar nicht das System erreicht.

Der entscheidene Vorteil von DNSBLs ist, dass sie sich mit nur minimalem technischen Aufwand einbinden lassen. Sie werden von den Anbietern in Echtzeit vorgehalten und sorgen daher für wenige falsche Ergebnisse. Sie belasten das Mailsystem kaum und durch die direkte Abweisung werden Bounces oder die Einlieferung in Spam-Ordner verhindert.

Der größte Nachteil der Verwendung von DNSBLs ist, dass eine IP oder ein IP-Bereich geblockt wird. Es wird somit der gesamte gegnerische Mailserver geblockt, auch wenn z.B. nur ein Konto zum Spamversand missbraucht wird (wobei darunter ggf. auch legitime E-Mails, gesichert durch Opt-In fallen können).

Von daher sollte man DNSBLs sehr sparsam einsetzen und sich auf wenige, zuverlässige Listen verlassen. Das Einbinden einer großen Anzahl von Listen hat oftmals einen negativen Effekt.

Folgende Listen sind empfehlenswert (bitte die jeweiligen Nutzungsbedingungen des Anbieters beachten):

dnsbls

Es gibt auch einige schwarze Schafe in den Blacklisten, hier wird z.B. Geld für ein De-Listing (also das Entfernen-Lassen der IP von der Liste) verlangt. Dies halten wir für nicht seriös.

Welche DNSBLs nutzen Sie?

SMTP-Dienste am Mailserver absichern

mailserverblogde Schreib einen Kommentar

Es gibt derzeit viele Anfragen zum Thema Verschlüsselung, Compliance, MandatoryTLS, “E-Mail Made in Germany” (das ist übrigens eine Partnerschaft und kein technisches Konzept).

Aus diesem Grund möchten wir Ihnen mit dem heutigen Artikel zeigen, wie Sie Ihre SMTP-Dienste am Mailserver (im Beispiel AXIGEN) korrekt absichern.

Aufgaben

Folgende Aufgaben gilt es zu erledigen:

  • Zwei SMTP-Listener einrichten (Einer auf Port 25 und einer auf Port 587)
  • Optional: Weiteren Listener für Port 465
  • STARTTLS auf den Listeners aktivieren
  • Plain-Authentifizierung ausschalten
  • Authentifizerung bei sicheren Verbindungen aktivieren (nach TLS)

Grundlagen der SMTP-Listener / Ports

Im SMTP-Verkehr sind folgende drei Ports im Standard beschrieben:

  •  25 – SMTP – dieser wird zur Kommunikation von MTA zu MTA (also Mailserver zu Mailserver) verwendet. Dieser Port kann auch zur Kommunikation mit Mailclients verwendet werden. Jedoch gibt es deutlich bessere Optionen.
  • 465 – SMTPS – SSL wird auf diesem Port erzwungen und wird vor jeder weiteren Kommunikation zwingend vorausgesetzt. Kein SSL, keine weitere Verbindung.
  • 587 – MSA – dieser Port ist ähnlich zum Standard-Port. SSL kann auf diesem Port verwendet werden. Da sehr viele ISPs den Versand von SMTP-Nachrichten auf Port 25 unterbunden haben (viele Schadprogramme verwenden diesen Port), sollten sie diesen Port einrichten, damit Ihre Benutzer auch E-Mails einliefern können. Das betrifft vor allem Benutzer, die in Mobilfunktnetzen oder öffentlichen WLANs unterwegs sind.

STARTTLS erlauben

Im ersten Schritt sollten Sie prüfen, ob STARTTLS für eingehende Verbindungen erlaubt ist:

  • WebAdmin => Security and Filtering
  • Dort auf Acceptance and Routing klicken
  • Im Bereich Acceptace Basic Settings prüfen Sie den Bereich Allowed ESMTP Comands
  • Stellen Sie sicher, dass Allow StartTLS angehakt ist.

Für ausgehende Verbindungen sollten Sie prüfen, ob STARTTLS ESMTP korrekt eingerichtet it:

  • WebAdmin => Security and Filtering
  • Dort auf Acceptance and Routing klicken
  • Im Bereich Routing Basic Settings prüfen Sie die Einstellungen für Outgoing Delivery
  • Prüfen Sie dort, ob die Checkbox bei Use StartTLS if available angehakt ist.

 SMTP-Listener einrichten

Ports 25 und 587:

Diese beiden Ports sollten auch Verbindungen ohne SSL erlauben, jedoch STARTTLS unterstützen.

smtp_rec

Die SSL-Einstellungen sollten auf beiden Ports so aussehen:

listeners

 

Folgende zusätzliche Hinweise sind zu beachten:

  • Die Checkbox “Enable SSL for this listener” sollte nicht aktiviert werden. Diese beiden Listener sollen primär nicht-SSL Verbindungen akzeptieren. Erst wenn der Client den Befehl für STARTTLS sendet, wird AXIGEN automatisch SSL aktivieren.
  • SSLv2 und SSLv3 sind deaktiviert. Diese beiden veralteten SSL-Protokolle sind angreifbar.
  • Wenn Sie DHE Cipher verwenden möchten, wie z.B. DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA dann müssen Sie den Pfad für das DH (Diffie-Hellman) Parameter-File setzen.

SMTP Port 465:

Der Port 465 sollte nur SSL-Verbindungen akzeptieren. Hierzu müssen Sie die Checkbox bei “Enable SSL for this Listener” aktivieren.

Regeln für die Authentifzierung

Im nächsten Schritt sollten zwei Regeln auf dem AXIGEN angelegt werden:

  • Authentifizierung für Plan-Text Verbindungen deaktivieren
  • Aktivierung der Authentifizierung für sichere Verbindungen (nach StartTLS)

Dies wird in AXIGEN über zwei Routing-Regeln erreicht. Diese müssen im Webadmin -> Security and Filtering -> Acceptance and Routing -> Advanced Settings angelegt werden.

Nachfolgend erklären wir Ihnen diese beiden anzulegenden Regeln

  • disableAUTH_on_non_SSL
  • enableAUTH_on_SSL

Authentifizierung für Plain-Text-Verbindungen deaktivieren:

  • Klicken Sie auf “+ Add Acceptance/Routing Rule“.
  • Als Name geben Sie ein “disableAUTH_on_non_SSL“
  • Conditions lassen Sie leer. Dies bedeutet, dass diese Regel für alle Verbindungen gilt.
  • Bei Actions wählen Sie “Plain connections authentication” und setzen Sie “Not authenticated“
  • Klicken Sie auf Save Configuration

rule1

Authentifizierung für sichere Verbindungen zulassen (jedoch erst nach StartTLS):

  • Klicken Sie auf “+ Add Acceptance/Routing Rule“.
  • Als Name verwenden Sie “enableAUTH_on_SSL“
  • Conditions lassen Sie leer. Dies bedeutet, dass diese Regel für alle Verbindungen gilt.
  • Bei Actions wählen Sie “SSL connections authentication” und setzen “Authenticated”.
  • Wählen Sie die gewünschten Authentifizierungarten
  • Da diese Regel nur für sichere Verbindungen gilt, könnten Sie Plain und Login weglassen
  • Klicken Sie auf “Save Configuration“

rule2

Reihenfolge der beiden Regeln:

In der Übersicht unter Advanced Acceptance / Routing Rules stellen Sie bitte sicher, dass disableAUTH_on_non_SSL rule vor der Regel enableAUTH_on_SSL in der Reihenfolge kommt:

order

STARTTLS für eingehende und ausgehende SMTP Verbindungen bei einer bestimmten Domain erzwingen

Damit Sie STARTTLS für eingehende und ausgehende SMTP-Verbindungen zwingend voraussetzen, benötigen Sie eine Routing Regel.

Das ist dann sinnvoll, wenn Sie

  1. Wenn Sie Mails nur annehmen wollen, wenn der gegnerische Server STARTTLS unterstützt.
  2. Sie Mails an einen gegnerischen Mailserver nur mit STARTTLS ausliefern wollen.

Hinweis: Dies kann dazu führen, dass Sie keine Mails von Servern erhalten, die dieses Verfahren nicht unterstützen)

Hierzu muss die folgende Regel angelegt werden:

 

  • Klicken Sie auf “+ Add Acceptance/Routing Rule“.
  • Als Name verwenden Sie “allow_only_tls_for_mydomain_com” (bitte entsprechend anpassen)
  • Bei Conditions wählen Sie Connection -> isSSL und lassen die Checkbox unangehakt
  • Bei Conditions wählen Sie danach Recipient->Domain is “mydomain.com” (Domain Namen bitte anpassen)
  • In der oberen Combobox (“For incomig messages that match”) wählen Sie ALL aus.
  • Bei Actions fügen Sie Folgendes hinzu SMTP -> Action. Danach wählen Sie Reject aus der Dropdown aus und hinterlassen eine Erklärung für den gegnerischen Mailserver, wie z.B. “Accepting only secure delivery (STARTTLS) for mydomain.com“
  • Klicken Sie auf Speichern

forcetls

Ausgehenden SMTP-Verkehr mit STARTTLS in Kombination TLS1.1 und TLS1.2 erzwingen

Hinweis: Dies kann dazu führen, dass Mails nicht ausgeliefert werden können, wenn der gegnerische Mailserver kein STARTTLS mit TLS1.1/1.2 unterstützt.

Falls Sie erzwingen wollen, dass AXIGEN nur E-Mails an Server liefert, die STARTTLS mit TLS1.1 oder TLS1.2  unterstützen, müssen Sie folgende Regel anlegen:

 

  • Klicken Sie auf “+ Add Acceptance/Routing Rule“.
  • Als Name verwenden Sie “use_only_tls11_and_12_when_relaying”
  • Bei Conditions wählen Sie Delivery->Relaying mail 
  • Bei Action fügen Sie folgendes hinzu -> SSL Encryption und stellen Sie sicher, dass die Checkbox angehakt ist
  • Bei Actions fügen Sie weiterhin hinzu -> SSL Versions und stellen Sie sicher, dass nur TLS1.1 und TLS1.2 angehakt sind
  • Klicken Sie auf Speichern

relaying tls

Den englischen Originalartikel finden Sie hier.

 

Private und geschäftliche E-Mails in einem Account – am Beispiel Hillary Clinton

mailserverblogde Schreib einen Kommentar

Hillary Clinton wird derzeit öffentlich für ihre E-Mail Praxis kritisiert. Denn sie nutzte nur einen Account für geschäftliche und private Mails.

Das sorgt jetzt für Probleme hinsichtlich der Archivierung und Aufbewahrungsfristen. Da sie auf einem privaten Server liegen, ist die Archivierung schwierig.

Wie archivieren Sie Ihre E-Mails revisionssicher und trennen private und geschäftliche Mails?

 

Bilder in E-Mail-Signaturen: Verlinken, einbetten oder verzichten?

mailserverblogde Schreib einen Kommentar

Oft finden sich in E-Mail Signaturen im geschäftlichen Umfeld Bilder. Dies kann das Unternehmenslogo, das Bild des Ansprechpartners oder eine Unterschrift sein.

Wenn Bilder verwendet werden, kommt es oftmals zu Problemen, das sich im berühmten “X” äußert. Nicht schön.

missing

Das HTML-Format ist in E-Mails oftmals Standard. HTML bietet zwei Arten Bilder einzufügen: Verlinken oder Einbetten.

Nachfolgend möchten wir Ihnen beide Möglichkeiten vorstellen und bewerten:

Eingebettete Bilder

Diese Option ist sehr beliebt, insbesondere bei Outlook-Benutzern. Hierbei wird das Bild intern als Anhang mitgesendet und innerhalb der Nachricht über eine ID verlinkt.

<IMG src=”cid:unique content id”>

Vor- und Nachteile:

+ Wird automatisch angezeigt, wenn die E-Mail geöffnet wird
+ Wird auch angezeigt, wenn der Client offline ist
+ Keine externe Ahängigen
– Wird oft von Antivirus/Antispam-Lösungen blockiert
– Bläht die E-Mail auf (Bild jedesmal als Anhang)
– Belastet die Server-Infrastrukturen (Signaturbild muss durch den Virenscanner geprüft werden und belegt Speicherplatz)

Verlinkte Bilder

Hierbei wird das Bild nicht als Anhang an der Mail versendet, sondern es wird auf ein externes Bild verwiesen, das auf einem Webserver liegt:

<IMG src=”http://www.axigenmailgate.de/signatur-huestel.jpg”>

Vor- und Nachteile:

+ Wird nicht von Antivirensofware geblockt
+ Entlastet die Mailserver Infrastruktur
+ Spart Speicherplatz
– Wird oft nicht automatisch im Client angezeigt und muss explizit freigegeben werden (Bilder herunterladen)
– Empfänger muss Online sein, um Bilder anzuzeigen
– Externe Abhängigkeiten vom Webserver (URL, Erreichbarkeit)

Fazit:

Braucht man Bilder in der Signatur wirklich?

Wir selbst verwenden keine Bilder, reiner Text tut es auch. Man muss auch bedenken, dass diese Bilder auf Smartphones geladen werden müssen und dort auch unnötig Traffic erzeugen. Mobiler Traffic ist teuer.

Wie ist Ihre Meinung?

Wenn es unbedingt Bilder in der Mailsignatur sein müssen, würden wir zur Verlinkungsvariante tendieren. Eine große Menge an Speicherplatz in Mailservern wird sicherlich durch Signaturbilder belegt. Das könnte man sich sparen und so die eigene und fremde Serverinfrastrukturen entlasten.