Der unterhaltsame Thread mit dem ursprünglichen Schwerpunkt auf Zeilenumbrüchen entwickelt sich stetig weiter, und ist mittlerweile bei einer Diskussion um die Vor- und Nachteile eigener Mailserver angekommen. Radikale Listenmitglieder verbinden mit dem self hosting die Möglichkeit, allen Kommunikationspartnerinnen E-Mail-Accounts zur Verfügung zu stellen, andere beklagen die Mithaftung durch die Blockade ganzer Subnetze durch Google, Microsoft et al und wittern Verschwörungen.
Ich nutze die Gelegenheit, um meinen Mailserver mit allen verlinkten Werkzeugen zu überprüfen, werde mit der Fehlermeldung Reverse DNS is not a valid Hostname
der MXToolBox konfrontiert und muss mich von der Illusion einer perfekten PTR-Konfiguration verabschieden. Im Affekt ändere ich aber nicht etwa den PTR-Eintrag für meine IP-Adresse, sondern den MX-Eintrag für meine Domain (eden.one statt mail.eden.one) in Verbindung mit Anpassungen der Dovecot- und Postfix-Konfiguration (SSL-Zertifikate und Hostnames), obwohl sich die inkriminierte PTR-Situation dadurch ganz offensichtlich nicht verbessert. Außerdem gelingt es mir, versehentlich eine Todsünde zu begehen (NEVER list a virtual MAILBOX domain name as a mydestination domain!
) und zeitweilig die Zustellung von E-Mails an meine Dovecot-Nutzerinnen zu unterbinden (<user@eden.one> (expanded from <address@eden.one>): unknown user: "user"):
# DO NOT DO THIS in /etc/postfix/main.cf myhostname = eden.one mydestination = $myhostname, localhost.localdomain, localhost virtual_mailbox_domains = eden.one
Auch nach der Korrektur dieses Fehlers setzt sich langsam die Erkenntnis durch, dass eine Domain als Hostname keine sehr gute Idee (und eben kein valid hostname) ist. Zugleich wird mir klar, dass ein PTR-Eintrag im Wesentlichen für Mailserver relevant ist und es keinen Grund gibt, den PTR-Eintrag nicht entsprechend zu gestalten:
id 44025, opcode QUERY, rcode NOERROR, flags QR RD RA ;QUESTION 138.240.160.217.in-addr.arpa. IN PTR ;ANSWER 138.240.160.217.in-addr.arpa. 21600 IN PTR mail.eden.one. ;AUTHORITY ;ADDITIONAL
Alle Änderungen an main.cf, 10-ssl.conf und 15-lda.conf werden daher zurückgenommen und auch der MX-Eintrag verweist wieder auf den FQDN mail.eden.one. Mit dieser Konfiguration ist die MXToolbox zufrieden:
Status Ok SMTP Reverse DNS Mismatch OK - 217.160.240.138 resolves to mail.eden.one
Status Ok SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
Status Ok SMTP Banner Check OK - Reverse DNS matches SMTP Banner
Status Ok SMTP TLS OK - Supports TLS.
Status Ok SMTP Connection Time 0.363 seconds - Good on Connection time
Status Ok SMTP Open Relay OK - Not an open relay.
Status Ok SMTP Transaction Time 1.100 seconds - Good on Transaction Time
Lediglich einige Testwerkzeuge für Newsletter haben noch Einwände. Mail-Tester vergibt zwar die Wertung 10/10, weist aber auf einen fehlenden List-unsubscribe-Header hin sowie auf die unzureichende Gestaltung meiner Testnachricht:
Unspam.email hat denselben Humor, mäkelt aber darüber hinaus an meiner TLD herum –Your message could be improved: There is no html version of your message.
Test failed. Your email is missing the List-Unsubscribe header.
Test failed. Your domain uses are [sic!] not trustworthy suffix!
Test failed. Your message body is not using HTML best practices! The HTML body is not composed of standard and supported HTML elements.
– und zieht dafür allen Ernstes 11 Punkte ab (89/100). Mailgenius ist ebenfalls weder mit .one noch mit dem fehlenden Listen-Header einverstanden, hat aber eine sympathische Einstellung zum fehlenden HTML-Body (97/100):
Warning -2 – Domain Suffix – Although your domain is not using a common spammer suffix, it is not using one of the most trustworthy suffixes.
Warning -1 – List-Unsubscribe Header – Your email is missing the List-Unsubscribe header.
Passing – HTML Body Best Practices – Your message body is using HTML best practices!
Mit so unqualifizierten Einwänden können mein Mailserver und ich leben.