Verwendung von DNSBLs (DNS-based Blackhole List)

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?

Weiterlesen

SMTP-Dienste am Mailserver absichern

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.

 

Weiterlesen

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

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?

 

Weiterlesen

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

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.

 

 

Weiterlesen

Mails vom Provider einliefern: SMTP-Weiterleitungen und IMAP-Weiterleitungen

Folgende Anforderung treffen wir auch heute noch relativ häufig an:

E-Mails liegen beim externen Provider und sollen auf einen lokalen Mailserver eingeliefert werden

Dies ist häufig bei kleinen Infrastrukturen der Fall, wenn man bspw. keine externe feste IP hat oder Spam-/Virenschutz dem Provider überlassen will. Oft wird dieses Szenario auch “Homeserver” genannt.

Erstrebenswert wäre dennoch, dass der eigene Mailserver alle Arbeiten selbst übernimmt. Selbst ohne feste IP ist es kein Problem mehr.

Geht es nicht anders oder ist es eine geziele Anforderung, benötigt man eine Lösung zur Einlieferung der Mails.

Prinzipiell muss man hierbei zwischen zwei Szenarien unterscheiden:

  • Jeder Benutzer hat sein eigenes Posfach beim Provider (Szenario 1)
  • Es gib ein zentrales Sammelpostfach (schlimmstenfalls sogar Catch-All). Mails aus diesem Postfach müssen dann in Einzelpostfächer verteilt werden. Dieses Szenario lassen wir außen vor, da es einen sehr hohen Konfigurationsaufwand erfordert und nur wenige Tools diese Verteilung korrek vornehmen. Kurz gesagt: Es geht, aber wie ist die Frage. Bei Interesse kontaktieren Sie uns.

Hat man diese Unterscheidung getroffen, hängt das Mittel der Wahl zusätzlich vom Mailserver und vom Betriebssystem ab.

AXIGEN RPOP

Unser Mailserver-System AXIGEN hat dafür das sogenannte RPOP-Feature eingebaut. Hier lassen sich im Webmail ganz einfach die POP3-Zugangsdaten eines oder mehrerer externer Mailkonten angeben und schon werden die Mails im Intervall in’s Postfach geholt.

Dies funktioniert tadellos.

Windows: P2S

Ein geeignetes Tool für Windows ist P2s. P2S holt Mails aus einem Postfach über POP3 oder IMAP ab und leitet die Mails dann über SMTP auf den eigenen Mailserver weiter.

Das Tool selbst ist kostenlos.

Eine kostenpflichtige Alternative, die vor allem im Exchange-Umfeld eingesetzt wird, ist Popcon.

Linux: Fetchmail

Unter Linux ist fetchmail das Mittel der Wahl. Ein Beispielaufruf sieht so aus:
poll axigenmailgate.de with proto POP3
user remoteuser there with password secret is axigenuser@axigenmailgate.de here options your_fetchmail_options

Plattformübergreifene Alternative: Einlieferung über IMAP

Neben den POP2SMTP und IMAP2SMTP Tools gibt es auch noch eine andere elegante Methode. Lassen Sie Ihre Mails vom Provider über POP3 abholen und liefern Sie diese über IMAP in ein lokales Postfach ein.

Dieses Tool heißt poptoimap und ist ein Perl-Script.

Der Vorteil dieses Verfahrens ist, dass sozusagen direkt von Postfach in ein anderes Postfach kopiert wird. Damit spart man sich den Umweg über SMTP und die damit verbundenen Probleme (wie SPF, MX-Check, etc.). Über poptoimap werden wir noch ausführlicher Berichten.

Weiterlesen

FREAK – SSL-Lücke bedroht Web- und Mailserver, Android und Apple betroffen

Inzwischen vergeht gefühlt kaum ein Monat, an dem nicht eine neue SSL-Sicherheitslücke bekannt wird. Die neueste Sicherheitslücke nennt sich FREAK und ist bereits seit vielen Jahren in den SSL-Bibliotheken enthalten – somit ein Relikt aus der Vergangenheit.

Betroffen sind viele Webseiten (OpenSSL vor 1.0.1k), der Android-Browser und Apples Browser Safari.
Weitere Details finden sich dazu bei Heise.

Aber auch viele Mailserver können betroffen sein. Daher sollten Sie Ihre Systeme dringend aktualisieren. Patches sind bereits teilweise verfügbar oder werden in Kürze verfügbar sein.

Mit AXIGEN 8.2.0+ sind Sie auf der sicheren Seite. Sollten Sie noch eine ältere Version haben, empfehlen wir dringend ein Upgrade.

Verwenden Sie zur Verschlüsselung folgenden Cipher:
ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

Weitere Details zu den möglichen Cipher-Optionen und Konfigurationen finden sich auch bei Mozilla:
https://wiki.mozilla.org/Security/Server_Side_TLS

für Webserver gibt es auch einen entsprechenden Cipher-Generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/

Um Ihren Server zu testen, bietet sich folgendes Test-Tool an:
https://www.ssllabs.com/ssltest/

Um Ihren Browser zu testen, verwenden Sie folgendes Test-Tool:
https://www.ssllabs.com/ssltest/viewMyClient.html

oder auch

https://freakattack.com/

Weiterlesen

Migration von E-Mail Konten und Accounts, Mailserver Migration

Immer wieder erhalten wir Kundenanfragen, wie sie ihren Mailserver oder auch einzelne Konten davon auf AXIGEN migrieren können.

Eine Mailbox-Migration sollte bevorzugt über IMAP erfolgen. IMAP ist ein standardisiertes Protokoll. Somit kann sichergestellt werden, dass E-Mails identisch migriert werden und nicht inhaltlich verändert werden.

Für eine generelle Migration bieten sich folgende Möglichkeiten an:

IMAPSize

IMAPSize ist ein Tool mit dem man ein Backup einer Mailbox vom alten Server über IMAP ziehen kannn und dieses wieder auf dem neuen Server zurückspielen.

Natürlich sollte während der Migration sichergestellt werden, dass keine Mails mehr am alten Server ankommen.

Dieses Tool ist Freeware.

Weitere Informationen finden Sie hier: http://www.broobles.com/imapsize/screenshots.php

ss01_Mailbox

Fazit: Manueller Aufwand, für wenige Mailboxen empfehlenswert. Man benötigt alle Login-Daten und Passwörter.

MigrationWiz

Wer es komfortabler möchte und keine Angst vor einem Cloudanbieter hat, der kann MigrationWiz verwenden. Dieser Service ist kostenpflichtig und die Migration kostet ca. 10 USD pro Mailbox.

Hierbei muss lediglich ein IMAP-Connector zum Altsystem eingerichtet werden und ein Connector zum Neusystem, ebenfalls über IMAP. Dieser Dienst gleicht dann die Mailbox Schritt für Schritt ab und kopiert sie vom Altsystem zum Neusystem.

Dieser Vorgang kann später wiederholt werden, neue Mails werden erneut abgeglichen, bestehende Übersprungen.

projekt

URL: https://www.bittitan.com/products/migrationwiz

Fazit: Es werden auch hier alle Login-Daten benötigt, Daten laufen jedoch über einen Cloudanbieter, sehr komfortabel.

Migration über MailClient

Natürlich können Sie auch Mails über Ihren Mailclient migrieren. Z.B. über Drag&Drop in Thunderbird. Dies ist jedoch sehr aufwendig und fehleranfällig und nur für sehr wenige E-Mails zu empfehlen.

In jedem Fall sollte man niemals eine Mail-Migration über einen .pst Import oder Drag&Drop über Outlook vornehmen. Der Grund ist, dass das .pst Format nicht standardisiert wird. Die Mails innerhalb eines .pst Files haben Outlook-Spezifische Flags, die das Neusystem ggf. nicht versteht.

Mühelose, automatische Migration mit AXIGEN

Die oben genannten Schritte sind nicht besonders komfortabel. Das haben wir erkannt und in AXIGEN schon vor vielen Jahren einen Mechanismus zur automatischen Migration eingebaut.

AXIGEN bietet eine sogenannte AutoMigration an. Hierbei kann AXIGEN so konfiguriert werden, dass bei der ersten Anmeldung am Neusystem (=AXIGEN) alle Mails über IMAP vom Altsystem kopiert werden.

Wie funktioniert die Automigration?

Die AutoMigration kann pro Domain aktiviert werden. Sobald sich ein Benutzer am Neusystem anmeldet (egal ob WebMail, POP3 oder IMAP), prüft AXIGEN ob dieses Konto bereit lokal existiert.

Falls ja, wird nichts weiter unternommen und die lokale Mailbox geöffnet.

Falls das Konto noch nicht lokal existiert, versucht AXIGEN sich mit den angegebenen Zugangsdaten sich am Altsystem über IMAP anzumelden. Gelingt dies, so wird das Konto wird automatisch mit dem identischen Passwort in AXIGEN angelegt.

Zeitgleich beginnt im Hintergrund die Mailbox-Migration über IMAP aus dem Altsystem. So werden alle Mails Schritt für Schritt auf das Neusystem migriert. Automatisch und ohne weitere Interaktion.

Der Clou ist, dass das auch auf SMTP-Seite berücksichtigt wird. Existiert der Account lokal auf AXIGEN noch nicht (da sich der Benutzer noch nicht angemeldet hat), wird die Mail über SMTP noch an den alten Server ausgeliefert. Somit kann der Benutzer seine Mails noch am Altsystem erhalten, sobald er sich am Neusystem anmeldet, wird seine Mailbox automatisch migriert.

Wenn viele Mailboxen migriert werden müssen (z.B. bei ISPs), ist dies sehr komfortabel, da so eine weiche Migration vorgenommen werden kann. Konten werden umgezogen, sobald sich ein Benutzer anmeldet. Somit muss keine Downtime in Kauf genommen werden. Darüber hinaus kann somit der neue Server direkt in Betrieb genommen werden.

Wir haben schon zahlreiche Plattformen nach AXIGEN migriert. Exchange, Kerio, Zarafa, Zimbra, IpSwitch Mail, Dovecot, etc.

Es gibt auch komplizierte Migrationsszenarien, bei dem z.B. Formate konvertiert werden müssen, Benutzernamen umformatiert, etc. Sofern Sie Hilfe bei einer Migration benötigen (auch außerhalb von AXIGEN), kontaktieren Sie uns!

Weiterlesen