Mail Station mit eigener Domain

Einleitung

Diese Anleitung beschreibt die nötigen Schritte und Einstellungen, um die Mail Station mit einer eigenen Domain zu betreiben. Hier wird nicht beschrieben, wie die Mail Station selbst einzurichten ist, da es dafür neben der Synology Anleitung (EN, DE) bereits genügend weitere Wiki- und Forumsbeiträge (Siehe auch) gibt. Stattdessen werden hier alle Einstellungen außerhalb der Mail Station (DNS, Router & Firewall, SSL) beschrieben, damit diese einwandfrei Mails mit anderen Mail-Servern im Internet austauschen kann.

Diese Anleitung erhebt kein Recht auf Vollständigkeit und absolute Richtigkeit. Sie resultiert aus den Recherchen und eigenen Erfahrungen des Autors. Der Autor lädt alle berufenen Leser ein, Fehler zu korrigieren und diese Anleitung weiter zu ergänzen.

Ausgangssituation

Angenommen über die eigene Domain (hier beispielhaft my-domain.de genannt) sollen E-Mails empfangen und versendet werden, wofür die Disk Station mit dem Mail Station Paket als eigener Mail-Server zum Einsatz kommen soll. Die Disk Station hängt am lokalen Netz (Intranet) und ein (DSL-)Router trennt und vermittelt (routet) zwischen dem Intranet und dem Internet. Der Router besitzt aus Sicht des Internets wahlweise ein statische oder, wie meist üblich, eine dynamische IP-Adresse. Es versteht sich von selbst, dass die Internet-Verbindung (z.B. per DSL-Flatrate) ständig aufgebaut sein muss, da ja die Mail Station sonst nicht ständig empfangsbereit für eingehende Mails wäre.

Schritte

Die folgende Liste zeigt die Schritte bis zur vollständigen Einrichtung. Jeder Schritt baut auf die vorhergehenden Schritt auf, womit die Reihenfolge eingehalten werden sollte.

1. Eigene Domain
2. Statische und Dynamische DNS (A-Record)
3. Router- und Firewall-Einstellungen
4. MX-Record Einstellungen
5. Sicherheit, Verschlüsselung und SSL-Zertifikat

Und die folgenden Abschnitte enthalten Optionen und weitergehende Informationen:

• Probleme mit dyn. DNS und Blacklists
• Zuverlässigkeitsbetrachtungen und Backup-Mail-Server
• Sender Policy Framework (SPF-Record)
• Mail-Client Einstellungen
• Schlussbetrachtungen und Vor-/Nachteile eines eigenen Mail-Servers
• Siehe auch
• Weblinks und Glossar

Eigene Domain

Der übliche Weg zum Betrieb eines eigenen Mail-Servers wie die Mail Station ist, sich dafür eine eigene Domain (z.B. my-domain.de) auf den eigenen Namen bei einem geeigneten Domain-Dienstleister (Registrar) registrieren zu lassen. Theoretisch ist es auch möglich, eine Subdomain unterhalb einer fremden Domain für die Mail Station zu nutzen, wie sie z.B. bei den kostenlosen DYNDNS-Anbietern üblich ist (z.B. my-subdomain.anbieter-domain.de). Aber davon ist abzuraten, weil man dann keine Rechte an der Subdomain hat und weil die nötigen DNS-Einstellungen nicht bei allen Anbietern im Detail möglich sind. Zudem wollen manche Anbieter einfach aus rechtlichen Gründen nicht, dass Mails über deren Domain quasi in deren Namen versendet werden.

Bei der Auswahl des Registrars ist darauf zu achten, dass dieser die volle Einstellbarkeit der DNS-Daten (A-Record, MX-Record, Subdomains) ermöglicht. Domain-Angebote, die nur eingeschränkte Funktionalität (nur Weiterleitung oder nur Webspace) bieten, sind unzureichend. Ebenso muss der Registrar den dynamischen DNS-Dienst (DynDNS) anbieten, wenn man mit einer dynamischen IP-Adresse arbeitet. Ggf. sollte auf den Hilfe-Seiten bzw. in den FAQs des Registrars nach Begriffen wie "DNS" und "MX" gesucht werden um da Klarheit zu bekommen.

Ein negativer Effekt in Zusammenhang mit einer eigenen Domain ist noch, dass sämtliche persönlichen Daten (Name, Anschrift, Mail-Adresse und Telefonnummer) per Whois abfragbar sind. Z.B. ist diese Abfrage für .de-domains bei der DENIC möglich. Wer es gerne anonym haben will, der kann seine Domain gegen Aufpreis bei manchen Registrars (z.B. GoDaddy) auch treuhänderisch registrieren lassen.

Ist nun die eigene Domain registriert, so sollte als nächstes überlegt werden, ob und wie Subdomains genutzt werden sollten. Speziell dann, wenn die Domain nur für den Mail-Dienst genutzt werden soll oder die Disk Station mit ihren Webdiensten (File Station, Photo Station, etc.) nicht einfach auch über das Internet sichtbar sein soll, dann empfiehlt es sich für die Disk Station eine eigene Subdomain (z.B. diskstation.my-domain.de) zu verwenden. Somit ist man frei darin, für z.B. my-domain.de, www.my-domain.de oder ftp.my-domain.de andere Ziele (z.B. IP-Adressen, Weiterleitungen oder Webspaces) als die der Disk Station einzutragen. Und ein Angreifer kann den Domain-Namen my-domain.de (herausgelesen aus der E-Mail-Adresse user@my-domain.de) nicht einfach in seinen Browser-, Telnet- oder FTP-Programm eintippen und damit auf der Disk Station landen.

Bei der Namenswahl für die Subdomain der Disk Station ist man frei (z.B. diskstation.my-domain.de oder osterei.my-domain.de). Eine spätere Änderung ist zwar möglich, aber ggf. mit Kosten verbunden, wenn dadurch auch ein neues SSL-Zertifikat nötig wird.

Statische und Dynamische DNS (A-Record)

Jeder ans im Internet angeschlossene Host (in unserem Fall der Router) hat eine eigene einmalige IP-Adresse, über die er von überall her im Internet ansprechbar ist. Diese IP-Adresse kann konstant (statisch) sein, jedoch ändert sich diese bei privaten Internet-Zugängen (auch bei DSL-Flatrates) in der Regel laufend (dynamische DNS). D.h. der lokale Router bekommt regelmäßig (üblicherweise täglich) im Rahmen eines Reconnects eine neue IP-Adresse vom Internet-Service-Provider (ISP ) zugewiesen. Somit ist auch die IP-Adresse dynamisch, unter der die nachgeordnete Disk Station mit ihrer Mail Station aus dem Internet heraus erreichbar ist.

Eine statische IP-Adresse hat einige Vorteile im praktischen Betrieb (siehe auch Probleme mit dyn. DNS und Blacklists), aber diese ist als Option üblicherweise nur gegen Aufpreis oder häufig auch garnicht bei den ISPs für Privathaushalte erhältich.

Damit nun über den Nameserver des Registrars immer der richtige Bezug von der Subdomain diskstation.my-domain.de zu der aktuellen IP-Adresse hergestellt wird, muss der Nameserver laufend die aktuelle IP-Adresse vom Router mitgeteilt bekommen. Diesen Eintrag in der Datenbank der Nameservers nennt man übrigens A-Record.

Bei Verwendung einer dynamischen IP-Adresse sind zwei Einstellungen zu machen:

1. Beim Registrar muss die gewählte Subdomain (z.B. diskstation.my-domain.de) angelegt und mit einer dynamischen IP-Adresse vorgemerkt werden. Wie das genau geht, ist leider wieder bei jedem Registrar unterschiedlich und sollte dort auf den Hilfe- bzw. FAQ-Seiten nachgelesen werden. Als TTL-Wert sollte ein möglichst kleiner Wert (z.B. 20) eingestellt werden.
2. Beim Router zu Hause sind dann die entsprechenden Einstellungen wie vom Registrar vorgegeben zu übernehmen. Auch hier muss auf die Bedienungsanleitung des Routers verwiesen werden.

Bei Verwendung einer statischen IP-Adresse trägt man diese schlicht im A-Record der Subdomain ein. Der TTL-Wert kann hierbei auch recht groß sein (z.B. 86400 = 86400 Sekunden = 1 Tag), weil sich die IP-Adresse normalerweise nicht ändert, bis man vielleicht mal umzieht.

Der Erfolg dieser A-Record-Einstellungen kann folgendermaßen geprüft werden:

1. Bei Verwendung einer dynamischen IP-Adresse muss deren aktueller Wert erst herausgefunden und gemerkt werden z.B. mit Hilfe von der Website http://www.ip-adress.com. Aber auch bei statischer IP-Adresse schadet es nicht diese mal zu prüfen.
2. Mit Hilfe von z.B. http://www.dnswatch.info lässt sich herausfinden, ob der A-Record auf die zuvor ermittelte aktuelle dynamische IP-Adresse bzw. die statische IP-Adresse zeigt.

Wenn beide Abfragen die gleiche IP-Adresse liefern, dann ist soweit alles gut gelaufen und es kann mit dem nächsten Schritt fortgefahren werden. Wenn nicht, dann muss das noch nichts Schlimmes heißen und es wird folgende weitere Vorgehensweise empfohlen:

1. Die bei diesem Schritt gemachten Einstellungen nochmal zu prüfen. Manche Router und manche Registrars zeigen in ihren Statusmeldungen bzw. ihren Logs entsprechende Zustände und Fehler an. Meldet der Router, dass er die IP-Adresse an den Nameserver gesendet hat? Ist die neue IP-Adresse auf den Status-Seiten des Registrars sichtbar? Üblicherweise geht die Meldung der IP-Adresse vom Router an den Nameserver sehr flott, dass man bei korrekten Einstellungen sofort die IP-Adresse auf den Status-Seiten des Registrars sehen müsste.
2. Den Router neu starten lassen (im Zweifelsfall kurz Strom aus). Dann genügend Zeit (mehrere Minuten) warten, bis der Router sich komplett initialisiert, die Verbindung zum ISP aufgebaut und die neue IP-Adresse an den Nameserver gemeldet hat. Dann den Test wiederholen.
3. Einige Minuten (oder Stunden oder einen Tag) warten, und dann den Test wiederholen. Gerade bei Änderungen an den Domain-Einstellungen (speziell bei einem zuvor großen TTL-Wert), dauert die Übernahme der neuen IP-Adresse bei allen zwischengeschalteten Nameservern schon mal etwas länger...

Router- und Firewall-Einstellungen

Nachdem nun die Domain inklusive Subdomains richtig eingestellt ist und sämtliche Anfragen an diskstation.my-domain.de über die aktuelle IP-Adresse beim eigenen Router auflaufen, geht es nun daran den Router mit seiner Firewall so einzustellen, dass dieser die richtigen und nur die richtigen Datenpakete der verschiedenen Mail-Protokolle an die Disk Station weiterleitet. Jedes der Mail-Protokolle bzw. -Dienste (SMTP, POP3, IMAP) wird dabei mittels TCP durch ganz bestimmte Ports über das Internet übertragen. Im Router müssen nun die benötigten Ports freigegeben und übers Intranet zur Disk Station geroutet werden.

Hier muss leider wieder auf die Bedienungsanleitung des Routers verwiesen werden bezüglich der Beschreibung, wie die Port-Freigaben konkret im Router vorgenommen werden. Wie die Einstellungen bei der weit verbreiteten Fritz!Box durchgeführt werden, zeigt z.B. der Artikel Zugriff auf die Synology-Dienste über Internet.

Neben den freizugebenen Ports ist üblicherweise im Router auch anzugeben, wohin die Datenpakete (also hier die Disk Station als Ziel) weitergeleitet werden sollen. Damit dieses Routing sicher funktioniert, empfiehlt es sich, dass die Disk Station eine feste IP-Adresse im Intranet bekommt, damit auch beim Router diese feste IP-Adresse als Routing-Ziel eingestellt werden kann. Dazu ist bei den Netzwerk Einstellungen der Disk Station das DHCP zu deaktivieren und die feste IP-Adresse vorzugeben.

Jetzt zur Frage, welche Ports mit welchen Mail-Protokollen nun konkret freigegeben werden müssen. Die Antwort hängt davon ab, auf welche Art und Weise Mails über die Mail Station empfangen und versendet werden sollen. Es stehen zur Auswahl:

1. Webmail-Oberfläche der Disk Station: Hierzu muss auf dem/den zugreifenden Rechner(n) keine spezielle Mail-Software installiert sein. Ein beliebiger Rechner mit einem Internet Browser reicht aus.
2. Mail-Client-Software (z.B. Outlook, Thunderbird, ...) und IMAP-Protokoll: Bei Nutzung des IMAP-Protokolls verbleiben die Mails üblicherweise auf dem Mail-Server und werden nicht auf dem jeweiligen Rechner mit dem Mail-Client gespeichert. Vorteil von IMAP ist, dass von beliebigen Rechnern auf das Mail-Postfach der Mail Station zugegriffen werden kann und man dabei Zugriff auf das gesamte Mail-Archiv hat. Nachteil von IMAP ist, dass bei Ordnern mit vielen Mails bzw. langsamer Verbindung merkliche Verzögerungen beim Zugriff entstehen können. Gerade hier wirkt sich die üblicherweise deutlich langsamere Upstream-Geschwindigkeit der DSL-Zugänge negativ aus, wenn man vom Internet heraus per IMAP auf die Mail Station zugreifen möchte. Auch bei den üblichen DSL-Anschlüssen mit 16 MBit/s Downstream ist die Upstream-Geschwindigkeit deutlich unter 1 MBit/s.
3. Mail-Client-Software und POP3-Protokoll: Bei Nutzung des POP3-Protokolls werden die Mails vom Mail-Client von der Mail Station auf den Rechner herunter geladen und dort gespeichert. Auf die lokal gespeicherten Mails kann dann zwar schnell und auch offline zugegriffen werden, aber die Mails sind dann auch nur auf dem einen Rechner vorhanden und lesbar.

Im Detail gibt es noch einige weitere Vor- und Nachteile eines jeden Verfahrens, aber eine weitere Ausführung würde den Rahmen dieses Artikels sprengen und es sei da auf vielen einschlägigen Vergleiche im Internet verwiesen.

Theoretisch ist es auch möglich, alle Möglichkeiten parallel zu nutzen. Dieses macht dann Sinn, wenn man auf Reisen ist und schnell mal per Webmail ins Postfach schauen möchte, während man zu Hause normalerweise vom Rechner aus per POP3 auf sein Postfach zugreift. Man muss nur halt aufpassen, dass man nicht durcheinander kommt, wo gerade welche Mails lagern.

Weiterhin ist entscheidend, ob und über welche Dienste (Webmail, POP3 und/oder IMAP) man auch vom Internet heraus Zugriff auf die Mail Station haben möchte. Oder ob man auschließlich nur übers eigene Intranet Zugriff auf sein Postfach haben möchte. Je nach gewünschten Diensten sind dann eben mehr oder weniger Ports freizugeben. Und hinsichtlich der Sicherheit gilt auch hier: Weniger (Freigabe) ist mehr (Sicherheit).

Zum Empfangen von Mails durch die Mail Station ist jedoch unumgänglich, dass der Port für das SMTP-Protokoll freigeschaltet ist. Per SMTP-Protokoll werden Mails im Internet übermittelt, egal wie der Mail-Client die Mails aus dem Posteingang abfragt (POP3/IMAP).

Und zu guter Letzt stellt sich die Frage der Verschlüsselung der Protokolle. Jedes dieser Protokolle (HTTP-Webmail, POP3, IMAP, SMTP) gibt es inzwischen auch in der jeweils verschlüsselten Variante (HTTPS-Webmail, POP3S, IMAPS, SMTPS), bei der die Mails auf dem Weg durchs Internet verschlüsselt übertragen werden. Weitere Erläuterungen siehe Sicherheit, Verschlüsselung und SSL-Zertifikat.

Die folgende Tabelle gibt nun endlich Aufschluss darüber, welche Ports für welche Dienste freizugeben sind:

Protokoll	Benötigt für	Port ohne Verschlüsselung	Port mit Verschlüsselung	Anmerkung
SMTP(S)	Mail-Versand	25/TCP	25/TCP (SSL/TLS) 465/TCP (SSL)	Mail Station verwendet SMTP mit SSL/TLS über Port 25 SSL/TLS über Port 25 ist auch beim Mail-Client vorzuziehen
POP3(S)	Mail-Download vom Mail-Client	110/TCP	995/TCP	Nur nötig bei Zugriff von Mail-Client über das Internet
IMAP(S)	Mail lesen und auf dem Server verwalten	143/TCP	993/TCP	Nur nötig bei Zugriff von Mail-Client über das Internet
HTTP(S)	Webmail	80/TCP	443/TCP	Nur nötig bei Zugriff auf Webmail über das Internet. Damit sind auch die anderen Webdienste der Disk Station sichtbar!

Um nun zu testen, ob die Ports im Router wirklich freigegeben und Datenpakete bei der Mail Station ankommen, empfiehlt sich der c't-Netzwerkcheck. Dort sind am besten gleich alle Ports zu testen, die die Mail-Protokolle betreffen. Es versteht sich, dass vor dem Test die zu verwendenen Protokolle der Mail Station in den Disk Station Management Einstellungen auch aktiviert wurden.

Alle ungenutzten und nicht freigegebenen Ports werden dort dunkelgrün als "gefiltert" angezeigt. Rot und mit Status "offen" werden alle freigegeben und von der Mail Station bedienten Ports angezeigt. Hellgrün und "geschlossen" werden Ports angezeigt, die zwar der Router zur Mail Station hin geöffnet hat, aber von der Mail Station nicht bedient werden. Hier wurde entweder das Protokoll in den Mail Station Einstellungen der Disk Station noch nicht aktiviert oder beim Router wurden zu viele Ports freigegeben. Letztendlich dürfen nur die Ports als offen gemeldet werden, über die die zu nutzenden Mail-Protokolle laufen.

Gesperrte IMAP- bzw. POP3-Ports führen dazu, dass man mit einen Mail-Client vom Internet aus keine Mails lesen kann, weil der Router den Zugriff blockiert. Ein gesperrter SMTP-Port führt zu dem berühmten Fehlerbild, dass die Mail Station zwar Mails verschicken, aber nicht von anderen Mail-Servern im Internet empfangen kann, weil der Router von außen kommende Mails abblockt.

Das umgekehrte Fehlerbild (Mail Station empfängt zwar Mails aus dem Internet, aber verschickt keine Mails zu Mail-Servern im Internet) gibt es übrigens auch. Siehe Probleme mit dyn. DNS und Blacklists und Sender Policy Framework (SPF-Record).

Wenn nun alle benötigten Ports freigegeben und zur Mail Station hin geroutet sind, kann mit dem nächsten Schritt weitergemacht werden.

MX-Record Einstellungen

Neben dem bereits angesprochenen A-Record können zu einer Domain weitere sogenannte MX-Records in der Datenbank der Nameservers abgelegt werden. Die MX-Records enthalten notwendige Informationen über den Mail-Server (Mail Station) und werden von den anderen Mail-Servern im Internet abfragt, wenn diese eine Mail zur Mail Station senden wollen. Konkret enthalten die MX-Records Informationen über den bzw. die Mail-Server, die für den Mail-Empfang der jeweiligen Domain zuständig sind. In unserem Beispiel würde der MX-Record sinngemäß die Information enthalten, dass Mails an Empfänger der domain my-domain.de bei den SMTP-Server diskstation.my-domain.de (also bei der Mail Station) abzuliefern sind.

Eine Besonderheit der MX-Records ist, dass eine Domain davon mehrere haben kann. Dieses wird dafür verwendet, dass man noch weitere sekundäre Mail-Server neben dem primären Mail-Server angeben kann, die dann einspringen und die Mails empfangen sollen, wenn der primäre Mail-Server ausgefallen ist. Siehe weitere Betrachtungen dazu im Abschnitt Zuverlässigkeitsbetrachtungen und Backup-Mail-Server. Sekundäre Mail-Server müssen zwar nicht vorgehalten und mittels MX-Records eingetragen werden, aber sie können.

Um die Reihenfolge bei mehreren MX-Records / Mail-Servern festzulegen, enthält jedes MX-Records eine Priorität (Preference-Wert). Der MX-Record mit der höchsten Priorität gibt den primären Mail-Server und die MX-Records mit den niedrigeren Prioritäten entsprechend der Reihenfolge die sekundären Mail-Server an. Je kleiner der Preference-Wert, desto höher die Priorität.

Und auch der MX-Record hat wie der A-Record einen TTL-Wert. Da sich der MX-Record im allgemeinen nicht ständig ändert, kann hier ein recht großer Wert eingetragen werden. Gängig ist da z.B. ein TTL-Wert von 86400 (Sekunden), was umgerechnet der Zeit von einem Tag entspricht. Nur während der Experimentierphase empfiehlt es sich, vorerst einen ganz kleinen TTL-Wert zu nehmen, wenn man die MX-Records noch mehrfach ändern möchte. Ansonsten würde es entsprechend lange dauern, bis sich alle Anfrager im Internet (Mail-Server) den neuen aktuellen MX-Record-Eintrag beim Nameserver des Registrars wieder abgeholt haben.

Wie nun die MX-Records bei jedem Registrar eingestellt werden, ist wieder unterschiedlich und sollte dort auf den Hilfe- bzw. FAQ-Seiten nachgelesen werden.

Zum Testen der MX-Record Einstellungen wird die MXToolBox empfohlen. Man kann dort im ersten Schritt die MX-Records der eigenen Domain my-domain.de abfragen und auf Richtigkeit prüfen. Im zweiten Schritt lässt sich durch Klicken auf "SMTP Test" der SMTP-Dienst des Mail-Servers testen. Die dortige Warnmeldung "Warning - Reverse DNS does not match SMTP Banner" ist übrigens normal, wenn man eine dynamische IP-Adresse besitzt.

Wenn die Abfrage der MX-Records nicht die erwarteten Werte liefert, dann empfiehlt sich die folgende weitere Vorgehensweise:

1. Die bei diesem Schritt gemachten Einstellungen beim Registrar nochmal prüfen.
2. Einige Minuten (oder Stunden oder einen Tag) warten, und dann den Test wiederholen.

Wie bereits geschrieben benötigen auch die Änderungen an den MX-Records (speziell bei einem zuvor großen TTL-Wert) lange, bis alle Stellen im Internet (DNS- und Mail-Server) wieder die aktuellen Werte abgefragt haben. Manchmal ergibt sich da auch das Fehlerbild, dass während der TTL-Zeit manche Abfrager schon mit dem aktualisierten MX-Record arbeiten, während andere Abfrager noch mit dem alten Wert arbeiten. Also einfach die TTL-Zeit abwarten und Tee trinken...

Sicherheit, Verschlüsselung und SSL-Zertifikat

Wie schon im Abschnitt Router- und Firewall-Einstellungen erläutert, können die Mail-Daten auch verschlüsselt über HTTPS, SMTPS, IMAPS und POP3S von bzw. zur Mail Station übertragen werden. Es versteht sich von alleine, dass es ratsam ist die Verschlüsselung zu verwenden.

Damit die Daten verschlüsselt werden, ist ein sogenanntes SSL/TLS-Zertifikat nötig, dass auf der Disk Station abgelegt wird. Es gibt verschiedene Arten von Zertifikaten, je nachdem, was zertifiziert werden soll (Personen, E-Mail-Adressen, Domains, ...). Herausgegeben werden Zertifikate von sogenannten Zertifizierungsstellen, bei denen die Zertifikate käuflich erworben werden können. Der geplante elektronische Personalausweis soll wohl später auch ein persönliches Zertifikat besitzen.

In diesem Fall wird ein Zertifikat benötigt, dass auf die Domain my-domain.de oder gar nur auf die Subdomain diskstation.my-domain.de ausgestellt ist. Jeder beliebige Anfrager aus dem Internet kann sich das Zertifikat der Disk Station herunterladen und ansehen um zu prüfen, dass die sich meldende Disk Station authorisiert (zertifiziert) ist, für die jeweilige Domain bzw. Subdomain ihre Dienste anzubieten und die Daten zu ver- und entschlüsseln.

Da die Disk Station im Neuzustand nur ein Zertifikat von Synology vorweisen kann, kommt regelmäßig die bekannte Sicherheits-Warnmeldung beim Browser oder Mail-Client, wenn man auf eine der HTTPS-Webseiten bzw. über IMAPS, POP3S oder SMTPS auf die Mail Station der Disk Station zugreift. Man kann zwar üblicherweise beim Browser oder Mail-Client Ausnahmen zulassen und trotzdem Verbindung mit der Disk Station aufnehmen. Aber es ist davon auszugehen, dass andere Mail-Server, die bei der Mail Station per SMTPS Mails abliefern wollen, über das nicht zur Domain passende Synology-Zertifikat stolpern und den Vorgang abbrechen (Anmerkung Autor: noch zu verifizieren).

Also wird für den Betrieb der Mail Station ein SSL-Zertifikat benötigt, das auf die eigene Domain bzw. Subdomain ausgestellt ist. Praktischerweise wird das gleiche Zertifikat auch für die HTTPS-Seiten der Disk Station verwendet, womit auch alle Webseiten der Disk Station verschlüsselt werden und z.B. die Betrachter des Photo Albums ebenfalls keine Warnmeldung mehr bekommen.

Auf dem Markt gibt es verschiedenste Zertifizierungsstellen, die verschiedenste Typen und Sicherheitsstufen von Zertifikaten anbieten. Sie unterscheiden sich z.B. darin, ob das Zertifikat für die Domain inklusive aller Subdomains ausgestellt ist (teuer) oder nur auf eine Subdomain (günstig). Ebenso wird unterschieden, ob vor Ausstellung der Zertifikats die Identität des Domain-Inhabers mit hohen Aufwand z.B. per Personalausweis-Kopie oder Postident-Verfahren geprüft wird (teuer) oder mit einfacheren und nicht so sicheren Mechanismen (günstig).

Weitere Ausführungen darüber, welche Zertifikate es gibt und wie sie beschafft werden, würde den Rahmen dieses Artikels sprengen. Hinsichtlich der Zertifizierungsstellen sei eine Google-Recherche empfohlen. Hinsichtlich der Frage, wie das Zertifikat erstellt und auf die Disk Station installiert wird, sei auf das Manual der Disk Station, als auch auf die vielen Wiki- und Forums-Beiträge verwiesen.

Probleme mit dyn. DNS und Blacklists

Wie bereits ausgeführt, besitzt der Router aus Sicht des Internet entweder eine statische oder eine dynamische IP-Adresse. Üblich bei privaten Internetzugängen sind sogenannte Dial-UP-Verbinungen per ISDN oder DSL mit dynamischen IP-Adressen. Das heisst, dass bei jeder Einwahl ins Internet der Router eine neue IP-Adresse vom Internet-Service-Provider (ISP) zugewiesen bekommt. Auch bei DSL-Flatrates wird vom ISP regelmäßig (täglich) die Verbindung kurz unterbrochen.

Falls man nun (leider) eine dynamische IP-Adresse hat, so ergeben sich im praktischen Betrieb einer Mail Station mehrere Probleme bzw. Nachteile:

1. Manche Internet-Provider verbieten in ihren AGB den Betrieb von Servern über private Internet-Zugänge mit dynamischen IP-Adressen
2. Einige Mail-Server nehmen Mails von Mail-Server mit dynamischen IP-Adressen nicht an. Bekannt dafür ist z.B. GMX, die sich dadurch gegen Spam-Mails schützen wollen. Spam-Mail-Versender missbrauchen auch gerne gekaperte Privat-Rechner (mit dynamischer IP-Adresse) zum Versenden der Spam- oder Massen-Mails. Die professionellen Mail-Dienstleister betreiben ihre Mail-Server durchweg mit statischen IP-Adressen.
3. Während der Wiedereinwahl (Reconnect) aufgrund der täglichen Unterbrechung der Internet-Verbindung entsteht ein kleines zeitliches Loch, in der die Mail Station nicht erreichbar ist. Diese Zeitspanne reicht von der Unterbrechung, über die Wiedereinwahl, die Zuweisung der neuen IP-Adresse, der Mitteilung der neuen IP-Adresse an den Nameserver, bis hin zum Ablauf der TTL-Zeit und Neuabfrage der IP-Adresse durch alle Abfrager im Internet. Theoretisch können während dieser Zeit Mails verloren oder an falsche Mail-Server gehen, wenn die alte IP-Adresse gerade einem anderen Internet-Anschluss zugewiesen wird. Die Zeitspanne ist zwar mit rund einer Minute recht klein, aber nicht null.

Diese Nachteile besitzen dynamische IP-Adressen grundsätzlich und müssen in Kauf genommen werden. Abhilfe schafft nur die Verwendung einer statischen IP-Adresse und die Zusage des ISP keine täglichen Unterbrechungen vorzunehmen. Nähere Informationen sind hier beim eigenen ISP einzuholen bezüglich Angebot und Kosten einer statischen IP-Adresse. Es steht jedem frei zu entscheiden, ob für ihm dieser Makel der dynamischen IP-Adressen ein Problem darstellt oder nicht.

Es gibt zumindest Möglichkeiten das Problem der dynamischen Adressen abzumildern:

1. Manche Router (z.B. Fritz!Box) bieten in ihren Einstellungen die Möglichkeit an, dass sie von sich aus zu einer wählbaren täglichen Uhrzeit die Wiedereinwahl vornehmen. Wenn man diese Uhrzeit auf z.B. 3:27 Uhr nachts schiebt, so ist die Wahrscheinlichkeit ziemlich gering, dass gerade dann eine Mail bei der Mail Station eintreffen will, sofern man nicht gerade viele Bekanntschaften in Australien hat. Höchstens automatisch verschickte Mails dürften zu der Schlafenszeit noch eintreffen.
2. Bei Verwendung eines zusätzlichen Backup-Mail-Servers kann dieser bei Nicht-Erreichbarkeit der Mail Station einspringen und die Mails annehmen (siehe Zuverlässigkeitsbetrachtungen und Backup-Mail-Server).

Zum Schutz gegen Spam benutzen die großen Mail-Dienstleiter (GMX, Web.de, Freenet usw.) noch weitere Mechanismen. Dazu gehören sogenannte Blacklists, die von verschiedenen Betreibern geführt werden. Auf der Blacklists landen z.B. IP-Adressen (gerade die dynamischen), sowie Domains und E-Mail-Adressen, die bislang negativ durch Spam- oder Phishing-Mail-Versand aufgefallen sind. Auch andere Tests werden noch vorgenommen (z.B. Prüfung der reverse DNS). Mails von deklassierten Absendern bzw. Mail-Servern werden dann nicht angenommen.

Auch hier ist die MXToolBox wieder recht hilfreich, weil man dort nach der Abfrage der MX-Records gleich noch über Klicken von "BLACKLIST" prüfen kann, ob sich die eigene IP-Adresse bzw. Domain auf einer Blacklist befindet.

Zuverlässigkeitsbetrachtungen und Backup-Mail-Server

Die Zuverlässigkeit eines technischen Produkts ist eine Eigenschaft (Verhaltensmerkmal), die angibt, wie verlässlich eine dem Produkt zugewiesene Funktion in einem Zeitintervall erfüllt wird. Übertragen auf den eigenen Mail-Server mit der Mail Station stellt sich die Frage, wie hoch die Wahrscheinlichkeit ist, dass dieser jederzeit verfügbar ist und einwandfrei funktioniert. Oder anders gefragt: Wie groß ist das Risiko, dass die Mail Station aufgrund Stromausfall, Störungen beim ISP, Ausfall des Routers, Defekt der Disk Station usw. ausfällt und keine Mails annehmen kann?

Versendende Mail-Server geben mitunter schnell auf eine Mail der Mail Station zuzustellen, wenn diese aufgrund Störung nicht erreichbar ist. Wenn die Mail von einem Menschen abgeschickt wurde, dann kann dieser noch entsprechend reagieren, weil er üblicherweise eine Fehlermeldung zurück bekommt. Viele Mails werden heute aber vom Computer automatisch generiert und verschickt (z.B. Rechnungen & Versandmitteilungen von Shops, eBay, Newsletter, Banking, ...), wo sich wohl kein Mensch mehr darum kümmert, ob da der eigene Mail-Server eine Fehlermeldung beim Versand der Mail generiert hat.

Zweifelsohne haben die professionellen Mail-Dienstleiter eine wesentlich bessere Zuverlässigkeit zu bieten, da deren Rechenzentren etliche Mechamismen gegen Ausfall vorhalten (z.B. Notstrom-Versorgung, Redundanz, Daten-Backups, ...). Es ist nun jedem angehenden Betreiber einer Mail Station selbst überlassen zu beurteilen, wie hoch er mit entsprechenden Aufwand die Zuverlässigkeit treiben möchte, damit möglichst keine zu empfangene oder archivierte Mail verloren geht. Die folgenden Ausführungen sollen einige praktische Tipps geben, welche Strategien man zur Erhöhung der Zuverlässigkeit verfolgen kann.

Ein Ansatz zur Erhöhung der Zuverlässigkeit wäre, den Router und die Disk Station mit einer Notstrom-Versorgung (USV) zu versehen. Hierbei ist aber nachteilig, dass Störungen beim ISP oder Defekte des Routers oder der Disk Station weiterhin zum Ausfall führen können, abgesehen davon, dass USVs nicht gerade preiswert sind.

In professionellen Anlagen wird vor allen Dingen der Ansatz mit redundanten Systemen verfolgt. Das heißt in unserem Fall, dass als Ersatz ein zweiter (sekundärer) Backup-Mail-Server vorzuhalten ist, der beim Ausfall der Mail Station deren Arbeit übernimmt. Wie bereits bei den MX-Record Einstellungen beschrieben, bieten die MX-Records bereits die Einstellmöglichkeit von sekundären Mail-Servern. Absendende Mail-Server versuchen schon von sich aus, eine Mail, die sie ohne Erfolg beim primären Mail-Server abliefern konnten, hilfsweise bei dem (den) sekundären Mail-Server(n) zuzustellen.

Dieser Backup-Mail-Server sollte möglichst unabhängig vom primären Mail-Server (Mail Station) arbeiten. Höchste Unabhängigkeit erreicht man, wenn der Backup-Mail-Server ein eigenes Gerät mit einer eigenen Stromversorgung und einem eigenen Internet-Zugang an einem örtlich getrennten Standort ist. Für den privaten Gebrauch dürfte aber die Anschaffung einer zweiten Disk Station nebst deren Installation bei der Verwandschaft im anderen Erdteil nicht gerade ein kostengünstiger und praktikabler Ansatz sein.

Vielmehr ist es überlegenswert nun doch einen professionellen Mail-Dienstleister mit ins Boot zu holen, bei dem man ein Mail-Konto als Backup-Postfach nutzt. Dieser Weg widerspricht zwar dem Grund, warum man überhapt einen eigenen Mail-Server nutzen möchte. Aber der Fall, dass die Mail Station ausfällt und dann die Mails beim Backup-Mail-Server des Mail-Dienstleisters landen, ist ja nur die Ausnahme. Und viele Registrars liefern neben der Domain-Registrierung gleich ein kleines Einsteiger-Mail-Konto mit wenigen Postfächern und mit geringer (aber meist ausreichender) Speichergröße als kostenlose Dreingabe mit (z.B. GoDaddy, Selfhost).

Hier nun die Einstellungen bezüglich des Backup-Mail-Servers:

1. Beim Mail-Dienstleister ist das Backup-Mail-Konto entsprechend einzustellen und zu aktivieren. Anleitung dazu siehe dort.
2. Der SMTP-Server des Backup-Mail-Kontos ist als sekundärer Mail-Server in den MX-Records einzutragen. Der Mail-Dienstleister muss hier entsprechende Angaben machen, was in den MX-Records einzutragen ist. Dieser Posteingangs-SMTP-Mail-Server ist nicht immer der gleiche, den man als SMTP-Server beim Mail-Client einzustellen hat. Siehe auch MX-Record Einstellungen.
3. Beim Backup-Mail-Konto ist es (erstmal) ausreichend eine E-Mail-Adresse (z.B. postmaster@my-domain.de) einzurichten, bei der das Catch-All aktiviert ist. Beim Catch-All landen alle Mails an unbekannte Adressaten im Postfach des postmasters. Damit spart man sich die Arbeit alle E-Mail-Adressen beim Backup-Mail-Konto identisch einzurichten wie bei der Mail Station.
4. Bei der Mail-Client-Software wird als weiteres Konto das des Postmasters beim Backup-Mail-Server eingerichtet. Damit holt der Mail-Client nacheinander die Mails von der Mail Station und von dem Backup-Mail-Konto ab. Die Aufgabe des Postmasters ist es nun, Mails, die bei einem Ausfall der Mail Station auf dem Backup-Mail-Konto gelandet sind, an den eigentlichen Empfänger weiterzuleiten.

Getestet werden kann dieser Backup-Mail-Server auf folgende Weise:

1. Beim Router wird temporär der SMTP-Port 25 geschlossen, womit die Mail Station als primärer Mail-Server nicht erreichbar ist.
2. Eine Test-Mail wird von einem anderen Mail-Konto aus (z.B. von einem Freund oder Bekannten) an eine ausgedachte Mail-Adresse (z.B. backup-test@my-domain.de) geschickt. Nicht selber die Mail über die eigene Mail Station verschicken!
3. Diese Test-Mail muss nun im Posteingang des Postmasters des Backup-Mail-Kontos gelandet sein. Durch Ansicht des Mail-Headers (Quelltext-Anzeige der Mail im Mail-Client) lässt sich noch prüfen, ob wirklich der Backup-Mail-Server die Mail angenommen hat.
4. Nach dem Test nicht vergessen, den SMTP-Port 25 wieder freizugeben.

Ein weiterer Vorteil bei Nutzung eines Backup-Mail-Kontos wäre, dass man dessen Postausgangs-Mail-Server auch zum Versenden der Mails verwenden kann, um das Problem mit der dynamischen IP-Adresse zu lösen. Beim Mail-Client ist dann nicht die Mail Station, sondern der SMTP-Mail-Server vom Backup-Mail-Konto des Mail-Dienstleisters anzugeben. Der SMTP-Mail-Server des Mail-Dienstleisters dient somit als sogenannter SMTP-Relay-Server, d.h. er versendet anstelle der Mail Station die Mails für die eigene Domain. Zu beachten dabei ist, dass auch die SPF-Records entsprechend einzustellen sind (siehe Abschnitt Sender Policy Framework (SPF-Record)).

Ein weiterer Aspekt bezüglich der Zuverlässigkeit ist die Notwendigkeit regelmäßiger Daten-Backups der Mail-Daten auf der Disk Station. Da das Backup-Thema nicht Schwerpunkt dieses Artikels ist, soll hier auf die vielen Wiki- und Forumsbeiträge verwiesen werden. Hier soll nur daran erinnert werden, dass auch beim Betrieb der Mail Station an regelmäßige Backups gedacht werden sollte, und gerade dann, wenn bei IMAP-Verwendung das ganze Mail-Archiv auf der Disk Station lagert.

Sender Policy Framework (SPF-Record)

Um den immer größer werdenden Problem mit Spam-Mails, Phishing-Mails und mit Mails mit gefälschten Absendern zu entgegnen, wurde die Technik des Sender Policy Frameworks (SPF) eingeführt. Ohne SPF kann theoretisch jeder beliebiger Mail-Server so eingestellt werden, dass er Mails im Namen einer anderen frenden Domain versendet, womit die Manipulationen möglich sind.

Kern des SPF ist es, in der Datenbank des Nameservers weitere sogenannte SPF-Records aufzunehmen, die aussagen, welche Mail-Server authorisiert sind, für die jeweilige Domain Mails zu versenden. Anhand dieses SPF-Records können andere empfangende (Posteingangs-)Mail-Server prüfen, ob der absendende (Postausgangs-)Mail-Server authorisiert ist, Mails für die in der Absender-Adresse enthaltene Domain zu versenden. SPF-Records (Postausgang-Mail-Server) sind sozusagen das Pendant zu den MX-Records (Posteingang-Mail-Server).

Im SPF-Record lassen sich auf verschiedenste Arten die Postausgangs-Mail-Server angeben (siehe OpenSPF). Man kann deren IP-Adressen oder auch deren FQDN (diskstation.my-domain.de) angeben, als auch auf die MX-Records der Domain verweisen. Und man kann nur einen oder auch mehrere Mail-Server angeben.

Wenn man für die Mail Station eine Subdomain angelegt hat, so sollte am besten auf deren A-Record verwiesen werden und der Eintrag lautet "a:diskstation.my-domain.de". Wenn man die Mail Station mit einer eigenen statischen IP-Adresse betreibt, so kann diese direkt im SPF-Record mit "ip4:x.x.x.x/32" (CIDR-Notation) angegeben werden.

Bei Verwendung des Mail-Servers vom Backup-Mail-Konto des Mail-Dienstleisters als SMTP-Relay-Mail-Server wird die Sache etwas schwieriger. Bei großen Mail-Dienstleistern ist häufig der Postausgangs-Mail-Server ein anderer als der Posteingangs-Mail-Server und zur Verteilung der Arbeitslast werden häufig mehrere Postausgangs-Mail-Server verwendet. Wie nun alle diese Mail-Server heißen, darüber schweigen sich die Mail-Dienstleister meist aus. Wenn deren Hilfe- und FAQ-Seiten (Suchbegriff "SPF") nicht weiterhelfen, kann man versuchen die Namen per Support-Anfrage zu erfragen. Im Zweifelsfall kann man mit dem SPF-Record-Eintrag "include:mail-isp-domain.de" die Domain mit allen Subdomain zur Mail-Versendung authorisieren.

Zur Erstellung des SPF-Records bietet sich der Wizard der OpenSPF-Website an.

Je nach Registrar lassen sich SPF-Records unterschiedlich angeben, entweder direkt als SPF-Record, als TXT-Record oder mit Hilfe eines Webformulars (siehe dort). Als TTL-Wert sollte bei Verwendung einer dynamischen IP-Adresse wieder ein kleiner Wert (z.B. 20), ansonsten ein großer Wert (86400 = 1 Tag) angegeben werden.

Zum Testen der SPF hält die OpenSPF-Website einige Tools bereit. Bei falsch eingestellten SPF-Records zeigt sich auch hier das Fehlerbild, dass man zwar Mails empfangen, aber (teilweise) nicht versenden kann.

Mail-Client Einstellungen

Dieser Abschnitt beschreibt welche Einstellungen bei der Mail-Client-Software vorgenommen werden müssen. Die entscheidende Frage ist dabei, ob man mit dem Mail-Client auch vom Internet aus (z.B. wenn man mit dem Notebook auf Reisen ist) auf die Mail Station zugreifen möchte oder nur von zu Hause aus.

Wenn der Zugriff ausschließlich von zu Hause über das Intranet erfolgt, so sind als IMAP-, POP3 und SMTP-Server der lokale Netzwerk-Name oder die lokale IP-Adresse der Disk Station einzutragen.

Erfolgt der Zugriff auch nur gelegentlich aus dem Internet heraus, dann muss als IMAP-, POP3 und SMTP-Server die FQDN der Disk Station (diskstation.my-domain.de) eingetragen werden. Dieser Weg hat aber zum Nachteil, dass der Datenstrom immer über den Router (und das Internet?) geht, auch wenn man zu Hause am Intranet hängt, was mit geringerer Geschwindigkeit einhergeht.

Bei Verwendung des Mail-Servers vom Backup-Mail-Konto des Mail-Dienstleisters als SMTP-Relay ist natürlich dieser aus Postausgangs-SMTP-Mail-Server anzugeben.

Schlussbetrachtungen und Vor-/Nachteile eines eigenen Mail-Servers

Anhand dieser Beschreibung ist wohl ersichtlich geworden, dass das Betreiben eines eigenen Mail-Servers zu Hause nicht gerade eine einfache Angelegenheit ist. Wie einfach sind da im Vergleich dazu die Dienste der etablierten Mail-Dienstleister wie z.B. GMX, Freenet, Web.de, Arcor, MSN, etc. Diese bieten das komplette Paket mit eigener Domain ohne viel administrativen Aufwand an. Aber diese Angebote haben auch ihre Beschränkungen.

Siehe Artikel "Vor- und Nachteile der Mail Station"

Siehe auch

• Nutzung der Mail Station
• Deutsche Übersetzung der Mail Station Anleitung
• Externe Accounts mit getmail abrufen
• Client Restriktionen im Postfix Server
• Vor- und Nachteile der Mail Station

Weblinks und Glossar

• Deutsches Synology-Forum Mail Station
• Englisches Synology-Forum Mail Station
• DENIC
• http://www.ip-adress.com
• http://www.dnswatch.info
• c't-Netzwerkcheck
• MXToolBox
• OpenSPF

• A-Record
• Backup
• Backup-Mail-Server
• Blacklists
• Catch-All
• CIDR
• Domain
• DNS
• dynamische DNS
• DYNDNS
• FQDN
• IMAP
• Intranet
• ISP
• IP-Adresse
• Mail-Client
• Mail-Header
• MX-Record
• Nameserver
• Notstrom-Versorgung
• Phishing
• POP3
• Port
• Preference
• Reconnect
• Registrar
• reverse DNS
• Redundanz
• Router
• SMTP
• SMTP-Relay-Server
• Spam
• SPF
• SSL/TLS
• TCP
• TTL
• Upstream-Geschwindigkeit
• USV
• Webmail
• Whois
• Zertifizierungsstelle
• Zuverlässigkeit