Die gute alte Dame SMTP, das Simple Mail Transfer Protocol, hätte sich
zu Zeiten seiner Definition 1982 kaum vorstellen können, wie häufig es
in den 35 Jahren erweitert und für neue Anwendungen missbraucht
werden würde.
In diesem Artikel geht es darum, SMTP dazu zu benutzen, um von einem
Mailclient ohne eigene Serverfunktionalität Mail bei einem Smarthost
einzuliefern. Eigentlich ein gelöstes und alltägliches Problem, möchte
man meinen.
Dadurch, dass mein Mailsystem in seiner Eigenschaft als Nichtwindows nicht besonders anfällig gegen Malware ist und ich auch nicht blind auf jeden Anhang klicke, leiste ich mir seit einigen Jahren den Luxus, dass der Clamav auf meinem Mailserver nur die Malware ablehnt, die ich explizit konfiguriert habe. So werde ich die lästigsten Störer automatisch los und habe trotzdem einen Überblick darüber, was im Moment so an Malware unterwegs ist, weil der Clamav natürlich auch Malware, die nicht auf der Reject-Liste steht, markiert.
Es gab zwischendrin eine Zeit, da kam ungefähr gar nichts. So wenig jedenfalls, dass ich ernsthaft darüber nachgedacht habe, die CPU-Zyklen für den Scan eingehender Mail auf Malware einzusparen und den Mailvirenscanner abzuschalten.
Gut, dass ich das nicht gemacht habe, denn in den letzten zwei bis drei Wochen kommt durchaus wieder Malware per Mail in signifikanter Menge (also mehr als zwanzig pro Tag). So hat der Clamav wieder ein wenig mehr zu tun, und ich werde in Zukunft nicht mehr so schnell darüber nachdenken, einen nicht störenden Sicherheitsmechanismus wegen "irrelevant, braucht man heutzutage nicht mehr" abzuschalten.
Wie schon vor fast einem Jahr geschrieben, verwende ich normalerweise konsequent geplusste Mailadressen, um die Möglichkeit zu haben, der Wanderung meiner Mailadressen durch die verschiedenen Datenbanken nachvollziehen zu können. Dies birgt einige Fallstricke, die sich hauptsächlich daraus ergeben, dass sich manche Webentwickler ihre Arbeit verhältnismäßig einfach machen und diese weitgehend unbeeinflusst von den technischen Standards verrichten.
Heute ist mir aber ein Punkt über den Weg gelaufen, bei dem Pluszeichen im Localpart einer Mailadresse wirklich nicht erlaubt sind: Das zweite Feld im SOA-Record einer DNS-Zone soll laut RFC1035 einen Domainnamen enthalten, der die Mailbox der für die Zone verantwortlichen Person spezifiziert. Und im Wort "Domainnamen" steht der Schlüssel: Denn ein Domainname darf weder Klammeraffe noch Plus enthalten: Es sind nur Punkte, Buchstaben, Ziffern und Bindstriche erlaubt (und die nichtmal in beliebiger Reihenfolge). Das ist auch der Grund dafür, warum man den Klammeraffen im SOA-Record durch einen Punkt ersetzen und alle davor vorkommenden Punkte Backslash-Escapen muss.
Damit ich nicht jede SOA-Mailadresse einzeln manuell anlegen muss, nimmt mein Mailserver seit heute nicht nur mh+blog-zugschlus-de@zugschlus.de, sondern auch mh---blog-zugschlus-de@zugschlus.de an. Das sind zwei getrennte Suffixe, die in Filtern unterschiedlich behandelt werden können. In Exim ist das einfach zu konfigurieren: Man schreibt einfach local_part_suffix = "+* : ---*" in die Konfiguration, wo zuvor nur "+*" stand.
Damit dürfte ich mich in Zukunft auch etwas weniger über hirntote Webprogrammierer ärgern müssen, weil der Weg zur nicht mehr geplussten Mailadresse jetzt nicht mehr so weit ist.
Meine INBOX ist groß. So groß, dass sie eigentlich nur noch mit einer schnellen, textbasierten, direkt auf dem Filesystem operierenden Software verwendbar ist: Mit mutt. Und sie hat in den letzten Wochen die 150.000-Mails-Grenze überschritten, das ist zu viel.
Das Script, das die Mailinglistenmails und die automatischen Mails der verschiedenen Systeme nachträglich aus der Mailbox in verschiedene Untermailboxen verteilt, hat eine Linderung auf knapp 60.000 Mails gebracht. Das ist immer noch zu viel, so dass ich eine Radikalkur verordnete: Alle Mails von 2006 und früher werden in eine Ablagemailbox verschoben.
Jetzt sind es noch knapp 20.000 Mails in der Inbox ab Januar 2007. Das sind knapp über 40 Mails pro Tag und gar nicht mehr so viel wie es auf den ersten Blick erscheint - denn da sind auch noch alle Mails dabei, die hier rausgegangen sind.
Wer in Beantwortung einer Mail von vor 2007 noch auf eine Reaktion von mir wartet: Bitte nicht den Atem anhalten, da wird wohl nix mehr kommen. Sorry.
Bei vielen Firmen, besonders im Handwerk, findet man die Kombination aus "Web: http://www.firmenname.example/", aber eine Mailadresse @t-online.de oder unterhalb der Domain eines anderen Internet-Zugangs-Providers (ob das nun AOL, Freenet, T-Online, Arcor, Alice, Debitel oder noch andere sind).
Oft frage ich mich, wie sowas entsteht. Wissen diese Leute (oder ihre Berater) es einfach nicht besser, wird da fleissig vom ISP gesponsort oder ziert man sich nur, die Mailadresse zu ändern? Ich meine, dank Forwards und Mail-Pickup-Diensten ist eine über mehrere Jahre hergezogene Migration von einer Mailadresse auf eine andere doch prima möglich.
Ich meine, gerade der Mailservice bei T-Online hat doch eigentlich nur Nachteile: Man kann sie ohne Zusatzkosten in Form eines komischen E-Mail-Pakets nur über den T-Online-Zugang abfragen (was zum Beispiel die mobile Nutzung drastisch erschwert), und man ist langfristig an den Anbieter gebunden, weil mit Kündigung des Zugangsvertrags nicht nur dieser, sondern auch gleich die Mailadresse mit weg ist. Und da es bei T-Online keinen kostenlosen Account mehr gibt, fängt man sich auf diese Weise auch noch Grundgebühren beim Wechsel ein.
Liebe Kleinunternehmer: Wenn Ihr eine eigene Domain habt, habt ihr mit sehr großer Wahrscheinlichkeit auch bereits Mailadressen unterhalb dieser Domain, von Eurem Webspaceanbieter. Es spricht gar nichts dagegen, diese Mailadressen auch zu nutzen. Das gibt Euch Flexibilität im Einkauf, und weniger unprofessionell sieht es ganz nebenbei auch noch aus.
Wie viele meiner Leser wissen, benutze ich konsequent geplusste Mailadressen und falle damit regelmäßig auf die Nase, weil so genannte "Webentwickler" die technischen Grundlagen ihres Kerngeschäfts bestenfalls mal gestreift, nie aber in der Tiefe gelesen haben. So sind viele Webanwendungen der Meinung, dass das Pluszeichen in Mailadressen nicht auftauchen darf.
"So ein Unsinn!" denke ich dann oft und schreibe, wenn ich zu viel Zeit habe, eine nette Mail und weise darauf hin, dass zum Beispiel mh+vxrn@zugschlus.de eine gültige und funktionierende Mailadresse ist, die ich gerne für die Kommunikaton mit dem Unternehmen vxrn verwenden möchte.
Manchmal antworten die Firmen sogar, weisen mich auf RFC822 oder wahlweise RFC2822 hin und behaupten, dass dort drin stünde, dass keine Pluszeichen in Localparts vorkommen dürfen. Auf meine Antwort, die den betreffenden RFC dahingehend interpretiert, dass das eben doch erlaubt ist, kommt dann typischerweise nichts mehr.
Aber das, was mir mit VXRN passiert ist, ist dann doch einen Blogeintrag wert.
Mailadressen mit Plus im Local Part sind ein immer währender Quell der Freude. Sie helfen dem lokalen Mailserver bei der Sortierung eingehender Mail, und sind ein ausgezeichneter Spamfilter - Spammer wissen nicht wirklich, dass Pluszeichen in Local Parts von Mailadressen erlaubt sind, und schneiden die von der Webseite gefischte Mailadresse per Skript kaputt.
Dass auch die meisten Entwickler von dynamischen Webseiten nicht wissen, dass Pluszeichen in Local Parts von Mailadressen erlaubt sind, ist bedauerlicher Nebeneffekt. So kann man sich bei gut der Hälfte aller Webapplikationen mit einer solchen Mailadresse nicht anmelden.
Die neueste Masche der Snowboarder ist allerdings noch etwas perverser: Man akzeptiert die Mailadresse für die Anmeldung. Dann setzt man den Kunden ungefragt auf einen Newsletterverteiler (was man ja, da Kunde, ungestraft tun darf). Und dann lässt man die Abmeldung vom Newsletter nur dann durchgehen, wenn die Mailadresse kein Plus enthält. Wunderbar.
Diesen Scherz haben sich alleine in den letzten sieben Tagen sowohl Tchibo als auch Netgear erlaubt. Wie schön, dass ich geplusste Mailadressen dafür einsetze, dass ich Mailadressen nur einmal verwende. Somit haben sich jetzt sowohl Tchibo als auch Netgear ein 550 mit passendem Kommentar im Ablehnungstext eingehandelt. Schade, dass das niemals jemand lesen wird. Denn Bounces auswerten tut ja auch kein professioneller Newsletterversender.
Viele Webapplikationen haben recht eigenwillige Vorstellungen davon, wie eine Mailadresse aussehen darf. Wenn man als Kunde nun etwas ausgefallenere Features des Mediums E-Mail verwendet, fällt man oftmals in die Falle, dass eine Webapplikation eine völlig korrekte Mailadresse nicht akzeptieren mag.
