Nach dem gescheiterten DKIM-Experiment nehme ich die Verbindungssicherheit in den Blick. Bislang baut mein Server TLS-Verbindungen mit den von Postfix bereitgestellten und selbstsignierten Zertifikaten auf. Das genügt zwar für die verschlüsselte Kommunikation mit anderen Mailservern, aber Mailclients erwarten von einer vertrauenswürdigen Stelle ausgestellte Zertifikate. Passenderweise kann ich die für meine Domain verwendeten Zertifikate auch an dieser Stelle einsetzen. Die Postfix-Dokumentation empfiehlt die Kombination von privatem und öffentlichem Schlüssel in einer Datei (cat private.key public.cer intermediate.cer > chain.pem), das Ergebnis kann wie folgt referenziert werden:
# /etc/postfix/main.cf smtpd_tls_chain_files = /etc/ssl/private/chain.pem
Der logische nächste Schritt nach der Inbetriebnahme von Postfix vor einigen Jahren ist die Emanzipation von Posteo durch den SASL-authentifizierten Versand von E-Mails über meinen Server. Postfix unterstützt zwei SASL-Bibliotheken (Cyrus und Dovecot), lässt aber eine innere Distanz zu Cyrus erkennen:
People who go to the trouble of installing Postfix may have the expectation that Postfix is more secure than some other mailers. The Cyrus SASL library contains a lot of code. With this, Postfix becomes as secure as other mail systems that use the Cyrus SASL library. Dovecot provides an alternative that may be worth considering.
Ich entscheide mich trotzdem für Cyrus, weil dessen SASL-Bibliothek ohne den zugehörigen IMAP-Server verfügbar ist und – trotz der spürbaren Geringschätzung seitens der Postfix-Maintainer – weiterhin als Regelfall gilt (was die Konfiguration erheblich vereinfacht). Nach der Installation (apt-get install libsasl2-2 sasl2-bin libsasl2-modules) müssen lediglich drei Parameter angepasst werden:
# /etc/default/saslauthd START=yes MECHANISMS="sasldb" OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
Der Postfix-Nutzer muss Zugriff auf das genannte Socket-Verzeichnis haben (chown root:sasl /var/spool/postfix/var/run/saslauthd; adduser postfix sasl), und in /etc/postfix/master.cf müssen die spezifischen Parameter für die Kontaktaufnahme zwischen Client und Server (submission, Port 587) aktiviert werden. Außerdem wird /etc/postfix/sasl/smtpd.conf als zusätzliche Konfigurationsdatei benötigt (mit der Anweisung smtpd_sasl_path lässt sich deren Speicherort bei Bedarf anpassen):
# /etc/postfix/master.cf submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_relay_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING # /etc/postfix/sasl/smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN
Nach dem Start/Neustart (service saslauthd start; service postfix restart) kann ich eine SASL-Nutzerin anlegen und lokal authentifizieren:
saslpasswd2 -c -u eden.one user1 testsaslauthd -u user1 -r eden.one -p password
Dass die Postfix-Dokumentation die obligatorische Angabe des Parameters -r verschweigt und stattdessen zur Syntax testsaslauthd -u user1@eden.one -p password rät, beschert mir eine Stunde Debugging bis zum erlösenden 0: OK "Success.".
Für die erste Verbindung zwischen dem lokalen msmtp und dem Mailserver benötige ich nur noch den Fingerabdruck meines Zertifikates (openssl x509 -fingerprint -in /etc/ssl/private/chains.pem), um .msmtprc zu ergänzen:
# ~/.msmtprc account mailserver host mail.eden.one tls_fingerprint 0B:01:B0:59:42:53:C6:57:47:1C:69:C3:16:E1:1B:A6:77:5E:1A:06 from email.address@eden.one auth on user user1@eden.one password password
Es funktioniert. Um trotz reject_sender_login_mismatch verschiedene E-Mail-Adressen mit einer SASL-Nutzerin verwenden zu können, sind nur noch kleine Anpassungen erforderlich:
# /etc/postfix/main.cf smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders # /etc/postfix/controlled_envelope_senders email.address@eden.one user1@eden.one listmaster@eden.one user1@eden.one
Bidirektional verwendete Adressen müssen in /etc/postfix/controlled_envelope_senders und /etc/postfix/virtual eingetragen werden, unidirektionale nur in eine der beiden Dateien (noreply@eden.one → /etc/postfix/controlled_envelope_senders – sendmeeverything.butdontexpectareply@eden.one → /etc/postfix/virtual). Um spamartige Diskrepanzen zwischen Briefumschlag- und Absenderadresse zu vermeiden, muss msmtp mit dem Parameter --read-envelope-from aufgerufen (und die Anweisung from aus .msmtprc entfernt) werden:
# ~/.muttrc set sendmail = "/usr/local/bin/msmtp -a mailserver --read-envelope-from"
Nach postmap /etc/postfix/controlled_envelope_senders; service postfix reload habe ich einen vollwertigen SMTP-Server, der auch im Vergleich zu Posteo eine gute Figur macht. Während SpamAssassin beim Versand über Posteo gleich zwei Spam-Kriterien (FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN) erkennt, hat er gegen die lokal eingereichten E-Mails kaum Einwände:
Jan 26 08:09:35 eden postfix/submission/smtpd[565032]: 95DE07F92F: client=xxxx.nc.de[xx.xx.xxx.x], sasl_method=PLAIN, sasl_username=user1@eden.one Jan 26 08:09:35 eden postfix/cleanup[565034]: 95DE07F92F: message-id=<Yf+CP148PWSGkKM/@eden.one> Jan 26 08:09:35 eden spamd[500789]: spamd: connection from 127.0.0.1 [127.0.0.1]:44112 to port 783, fd 6 Jan 26 08:09:35 eden spamd[500789]: spamd: processing message <Yf+CP148PWSGkKM/@eden.one> for spamass-milter:111 Jan 26 08:09:35 eden spamd[500789]: spamd: clean message (0.4/6.0) for spamass-milter:111 in 0.1 seconds, 641 bytes. Jan 26 08:09:35 eden spamd[500789]: spamd: result: . 0 - NO_DNS_FOR_FROM,UNPARSEABLE_RELAY scantime=0.1,size=641,user=spamass-milter,uid=111,required_score=6.0,rhost=127.0.0.1,raddr=127.0.0.1,rport=44112,mid=<Yf+CP148PWSGkKM/@eden.one>,autolearn=no autolearn_force=no