≡ Menü

Bye, bye, Cloud – Teil 4 – Meine Mails, meine Kommunikation

My Cloud 4

In diesem Teil der „Bye, bye, Cloud“-Serie geht es um ein etwas komplizierteres Thema: Das Aufsetzen eines eigenen Mailservers für den Empfang und den Versand von Emails. Dabei bediene ich gleichzeitig verschiedene Mail-Provider aus nur noch einem einzigen Postfach.

Ziele

Tatsächlich hat diese Aktion gleich mehrere Dinge zum Ziel:

  1. GoogleMail soll als bisheriges (Web-)Hauptpostfach abgelöst und alle Mails von den Google-Servern auf meinen eigenen Server verschoben werden.
  2. Ich möchte die „Lagerzeit“ meiner Mails auf fremden Servern so gering wie möglich halten, um der Datensammel- und Indizierungswut der Anbieter zumindest ein klein wenig entgegen zu treten.
  3. Der Umgang mit meinen mannigfaltigen Email-Accounts soll so einfach wie möglich werden. D.h. ich erhalte alle meine Mails in einem Postfach, ohne dass diese ihre „Identität“ verlieren.
  4. Mein neuer Haupt-Mailaccount wird künftig der meiner eigenen Domain (karsubke.de) sein und über meinen WebHoster als Mail-Relay abgewickelt.

Vorbemerkung

Ich werde hier nicht alle Aspekte der Einrichtug bis ins Kleinste ansprechen können. Auch sind sicher nicht alle Punkte optimal gelöst. Vor Allem das Thema Sicherheit, SSL-Verschlüsselung, Kryptographie wäre deutlich weiter ausbaubar. Auch Spam- und Virenschutz wird hier etwas zu kurz kommen.

Ich möchte aber nochmal drauf hinweisen, dass mein Server innerhalb meines Heimnetzwerkes steht und keine direkte Verbindung von Außen möglich ist. Jedenfalls nicht so einfach. Innerhalb meines Netzes kann ich mit gutem Gewissen auch mit simplem User/Password authentifizieren. Immerhin ist das ganze aber auch für mich immer noch ein stetiges Build/Lern/Change und ich freue mich über jeden Verbesserungsvorschlag.

Begrifflichkeiten

Es wird im folgenden sicher eine Menge Abkürzungen geben, die ich verwenden werde. Ich hoffe, alles soweit zu erklären, dass am Ende klar ist, was ich meine. Ein paar Dinge möchte ich aber kurz an den Anfang stellen:

Ein Mailserver besteht aus mehreren Komponenten. Auf meinem Linuxsystem sind das

  • Fetchmail, ein MRA (Mail Retrieval Agent), der sämtliche Email-Konten bei allen Providern regelmäßig abfragt und die Mails abholt, beim Provider löscht und dann an
  • Postfix, meinen MTA (Mail Transfer Agent) gibt, der jede Mail, eingehende, wie ausgehende, als SMTPD (Simple Mail Transfer Protocol Daemon) entgegen nimmt, anguckt und per SMTP entweder nach draußen an einen Provider weiterleitet, oder nach innen an
  • meinen MDA (Mail Delivery Agent, auch LDA, Local Delivery Agent) gibt, der letztlich dafür sorgt, dass Mail an einen lokalen Empfänger, also mich, oder (noch in Planung) meine Freundin, bzw. das jeweilige lokale Postfach des Benutzers gelangt. Das macht bei mir nicht Postfix, sondern das macht auch schon
  • Dovecot, der auch einen LDA mitbringt, der aber hauptsächlich als IMAP-Server dafür verantwortlich ist, dass man sich mit einem Mail-Client an ihm anmeldet und Emails anschauen, lesen, beantworten kann.

Fetchmail – Mails einsammeln

Ich gestehe, ich bin Messi. Ein Email-Adressen-, bzw. Email-Konten-Messi. Nachdem die ersten Zeiten mit einem T-Online Zugang und zughöriger Email-Adresse überstanden waren, habe ich irgendwann Ende der 90er meine erste GMX-Adresse registriert. Die habe ich immer noch. Und eine web.de-Adresse; und eine – zwischenzeitlich – outlook.com Adresse. Und natürlich auch die Email-Adressen zu meinen Domains.

Und auch, wenn ich nicht mehr all diese Adressen aktiv nutze, frage ich sie ab, damit mir nicht irgendwas durch die Lappen geht. Würde ich all dies von Hand und nacheinander machen, wäre ich eine Weile beschäftigt. Deshalb besteht meine Lösung aus folgendem Szenario:

  • Ich habe auf meinem Linux-Server genau ein Postfach, auf das ich per IMAP Zugreife.
  • Fetchmail holt Mails von all meinen Email-Konton automatisiert ab und liefert sie letztlich an dieses Postfach.

Da in der Mail die Empfängeradresse, also das Email-Konto, an die sie ursprünglich gerichtet war, erhalten bleibt, kann ich bei Bedarf durchaus differinzieren, wenn ich das möchte.

Die Einrichtung von Fetchmail gestaltet sich relativ simpel über aptitude. Der Daemon muss in der /etc/default/fetchmail aktiviert werden. Konfiguriert wird Fetchmail über die Datei /etc/fetchmailrc. Meine enthält hierbei alle Einträge für die auf dem System abzurufenden Mailkonten. Exemplarisch möchte ich zwei, für web.de und für meine Postfach bei Uberspace angeben:

poll pop3.web.de with proto POP3 interval 15
    user 'karsubke' there with password 'm3inGeh31m3sPa55wort' is karsubke here options fetchall
    sslproto ssl3
    sslfingerprint "48:FC:ED:0A:EB:4F:DF:A3:F3:4A:C5:DB:8B:E4:D6:6A"
    sslcertck
    sslcertpath /etc/ssl/certs

poll triangulum.uberspace.de with service imap2
    user 'geiststreicher@geiststreicher.org' there with password 'm3inGeh31m3sPa55wort' is karsubke here options fetchall
    sslfingerprint "13:68:87:BE:97:44:BE:E8:93:56:F7:8F:A3:DE:F3:FD"
    sslcertck
    sslcertpath /etc/ssl/certs

Wie man sieht, nutze ich hier einmal POP3 und einmal IMAP, jeweils über eine SSL gesicherte Verbindung.

Die benötigten Zertifikate bekommt man über den Befehl

 echo "quit" | openssl s_client -connect triangulum.uberspace.de:143 -starttls imap -showcerts |sed -n /BEGIN/,/END/p

Diese packt man in ein File und kopiert sie in nach /etc/ssl/certs. Für das Verzeichnis muss man bei Änderungen noch ein c_rehash ausführen.

Die Fingerprints bekommt man mit der gleichen CommandLine, nur mit noch einem Zusatz, der den Fingerprint aus den Zertifikaten extrahiert:

 echo "quit" | openssl s_client -connect triangulum.uberspace.de:143 -starttls imap -showcerts |sed -n /BEGIN/,/END/p | openssl x509 -dates -fingerprint -md5  -noout

Etwas ausführlicher habe ich das in meinem Artikel „Fetchmail Abruf per SSL von GMX und web.de“ beschrieben.

Postfix – Der Alleskönner unter den Mailverteilern

Ich befürchte, hier keine Umfassende Anleitung zur Einrichtung von Postfix geben zu können. Deshalb werde ich nur kurz ein paar Punkte meiner Konfiguration ansprechen und anschließend meine Konfigurationsdateien zum Download zur Verfügung stellen. Vielleicht hilft es dem ein oder anderen mit seiner Konfiguration voran zu kommen.

Die am Anfang definierten Ziele möchte ich hier noch einmal kurz aufgreifen, da sie wesentlich für die Konfiguration von Postfix mitverantwortlich sind.

  • Vereinfacht gesagt, möchte ich alle Email-Konten abrufen und hier zu einem zusammen führen.
  • Ich möchte auf jede Mail mit der Email-Adresse als Absender antworten können, an die sie ursprünglich gerichtet war. Also möchte ich sie auch über den jeweiligen Provider wieder raus schicken, wenn ich antworte.

Diese Vorgaben führen zu folgender Konfiguration:

  • master.cf (Gist Link)
    • Definiert die Services des Postfix MTA. Hier ist zum Beispiel auch festgelegt, wie der Aufruf von Spamassassin von statten geht (Stichwort: conten_filter=spamfilter).
  • main.cf (Gist Link)
    • Das Hauptkonfigurationsfile des Postfix MTA.
  • relayhosts (Gist Link)
    • In dieser Datei ist definiert, welche Email-Adresse über welchen Provider, bzw. über welchen Email-Server verschickt wird – das eine impliziert das andere.
  • sasl_passwd (Gist Link)
    • Alles Zugangsdaten werden hier pro SMTP-Relay und/oder pro Absender-Email-Adresse definiert. Es können also auch unterschiedliche Angaben für zwei unterschiedliche Mailadressen beim gleichen Provider angegeben werden.

Eine besonderheit ergab sich für den Versand über Microsofts Server live.com. Dieser sprich, oder sparch zumindest zum Zeitpunkt der Konfiguration nicht alle „SSL-Dialekte“. Also musste ich für diesen Server extra angeben, welche Protokolle nicht verwendet werden können. Das habe ich in der Datei tls_policy getan:

[smtp.live.com]:587     may protocols=!SSLv2:!TLSv1.1:!TLSv1.2

Wie man an den Konfigurationen sieht, ist, da es sich um meinen Server handelt alles sehr zentralistisch. Auch Passwörter setze ich nicht über die einzelnen User.

Auch für große Last ist die Konfiguration nicht ausgelegt. Speziell der Aufruf von Spamassassin über ein Script kostet ziemlich viel. Das geht auch anders, benötigt aber eine kompliziertere Konfiguration. Um das ganze für mich so verständlich wie möglich zu halten, habe ich mich für den einfachereren Ansatz entschieden.

Dovecot – IMAP-Server und Sortierzentrale

Dovecot soll eigentlich nichts anderes tun, als Mails per IMAP über einen Mailclient, z.B. Thunderbird, abrufbar zu machen.

Können kann er aber noch mehr. In meiner Konfiguration dient Dovecot als LDA, der die von Postfix übergebenen Mails den einzelnen, lokalen Userkonten zuordnet und auch als Postsortierstation mit Hilfe von sog. Sieve-Scripten. Aber eins nach dem anderen…

Die Einrichtung gestaltet sich unter Debian relativ einfach:

  1. Man installiert den eigentlichen IMAP-Server per aptitude install dovecot-imapd
  2. Die Konfiguration des Zusammenspiels von Dovecot und Postfix erledigt ein aptitude install dovecot-postfix
  3. Die Sieve-Komponente bekommt man mit aptitude install dovecot-sieve dovecot--managesieved

Anschließend folgt noch ein wenig Konfiguration:

  • Ich bin Maildir-Format-Fan, also in die /etc/dovecot/conf.d/10-mail.conf
    mail-location = maildir: ~/Maildir
    eintragen.
  • Die SSL-Konfiguration ist im Dovecot-Wiki sehr gut erklärt.

Im Großen und Ganzen war’s das schon. Es stellt sich allerdings noch die Frage der Datenübernahme aus den bisherigen Systemen. Dazu werde ich aber irgendwann – und je nach Nachfrage – mal einen eigenen, kurzen Artikel schreiben.

Stand der Dinge

Mein Mailserver läuft, ruft Mails von allen Konten ab, prüft auf Spam und liefert mir alles in mein Postfach. Dort greife ich mit Thunderbird, vom iPhone und vom iPad mit dem Standardmailclient und auch „über’s Web“, natürlich per VPN, mit Roundcube als Frontend zu. Letzteres kann übrigens auch mit Adressbüchern und Kalendern umgehen. Nicht ganz out-of-the-box, aber es geht. Auch dazu schreibe ich gerne noch einen Artikel, wenn es gewünscht wird.

Von den genannten Clients kann ich alle Email-Identitäten über dieses eine Postfach bedienen und Mails über meinen Server verschicken. Erst die Linuxkiste entscheidet anhand der Absender-Adresse über welchen Mailprovider (gmx, web.de, googlemail, outlook.com, eigene Domains bei Uberspace) eine Mail ausgeliefert wird.

Fazit

Sicher ist die Einrichtung und der Betrieb eines eigenen Mailsservers nichts für Jedermann. Der Aufwand und die Einarbeitung in die mannigfaltigen Themen ist relativ hoch und man muss das schon wollen. Es ist aber auch eine tolle Gelegenheit, selbst besser zu verstehen, wie dieses Email-Zeugs im Netz so funktioniert.

Ich bin gespannt, ob und was für Fragen ihr habt. War das verständlich, was ich hier zu schildern versuchte? Würdet ihr euch nach diesem Artikel zutrauen, selbst einen kleinen Mailserver aufzusetzen? Oder was fehlt an dringend benötigter Info noch, bzw. welche Seiten sollte ich noch verlinken?

Bisherige Artikel

Die bisheringe Teile der Serie findet ihr hier:

  1. Bye, bye, #Cloud – Meine Daten, mein Server
  2. Bye, bye, #Cloud – Teil 2 – Mein Server, meine Infrastruktur
  3. Bye, bye, Cloud – Teil 3 – Meine Kontakte , mein Kalender
{ 0 Kommentare… add one }

Trackbacks

Hinterlasse einen Kommentar

*