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.
This article was updated, and the issue seems solved. Please look at the last paragraph before adding comments.
Exim has the habit of trying to find out about its host names and IP addresses when it starts up. This has, in the past, been an issue for the Debian packages, since a Debian system might be on a dial-on-demand modem line with expensive costs and thus should not do unnecessary DNS lookup when the MTA is started.
This article tries to describe the issue and which countermeasures debian took, and asks for tips how to solve this in the case of IPv6, where our past measures unfortunately do not directly apply.
I'd like to solicit opinions from people who are more experienced than me with Unix, the local resolver library including /etc/hosts and /etc/nsswitch.conf, DNS, and - especially - the customs that apply on a system running IPv6.
Judging from the long list of exim4 bugs, especially #446036, I find myself between a rock and a hard place, and having to choose between staying with GnuTLS and accepting a probably continuing flow of technical issues, or moving over to OpenSSL, setting an example against GNU software, and probably generating a new flow of license issues.
The DDs reading this might know the situation: You are subscribed to a gazillion of mailing lists, and spend quite some time answering questions of people using your packages. That's fine, service to your users. Occasionally, users take great pains in finding out a personal mail address (for example, by googling, and finding the webmasteridiot mail address on my personal web page) to ask their question in private e-mail. This prevents the answers from showing up in mail archives and deprives the public of a possibility to find a solution to this question themselves in the future.
I have uploaded exim4 4.67-2 to experimental. Lots of changes and improvements. Quite some changes have gone into the Debconf stuff (for example, the split/unsplit config question is not asked first any more), and into update-exim4.conf (including input sanitazion, transformation of input to lower case, and getting rid of the DEBCONFsomethingDEBCONF stuff in the configuration).
I'd like you to test the experimental package before I upload to unstable (probably on sunday). Please report your findings.
One thing I wish for exim is a patch for Exim Bugzilla Issue #66, which will incidentally fix Debian Bug #244724, which has become a recurring issue in various complex ISP configuration schemes.
A patch solving this would add an option to an SMTP transport which allows the transport to set the authentication credentials instead of the authenticator. The transport still knows the host name given to it and can look up the right authentication credentials, while the authenticator only knows the IP address that we are connected to and thus needs to rely on reverse DNS information to look up the credentials. Which leads to numerous kinds of confusion regarding CNAMEs and broken reverse DNS on the ISP side.
So, please dear Santa, give me a patch for that. It shouldn't be too hard to do.
Yesterday, Philip Hazel released exim 4.64. I have just uploaded the packages to Debian experimental. If you want to try the lastest and finest exim, please check out the packages.
Unfortunately, the release is too late for etch. Debian etch will release with exim 4.63. I mean, unless the release team decides to bend their rules very badly, which I really do not assume.
There is a HOWTO on the Internet which has the intention to help new users with creating their allround web-administrated exim mail server on Debian basis, using our pre-compiled packages. Unfortunately, this HOWTO starts with disabling all Debian magic in the exim4 configuration, which I personally think is WRONG to suggest to a newbie, and does not quite mention this in the documentation. The result is a big number of support requests in the Debian-specific and generic exim support mailing lists and IRC channels.
The makers of debianhowto.de do not seem to be quite interested in a peaceful co-existence.
My advice as a new exim4 / debian user myself is to read the documentation first. Then read the documentation. (There is a lot of it.) Read the documentation, or some people might point out that you have not read the documentation.
Thanks, Jeremiah Foster, this has just made my day.
exim4, sarge's default MTA, uses gnutls for the obvious license reasons. However, gnutls does seem to have issues of interoperability, which have manifested themselves in a list of bugs, most prominently being #297174, which we are at a loss to debug.
Neither Andreas nor me have the knowhow to debug gnutls, and Upstream uses openssl - the gnutls patch was contributed and the author of the original patch doesn't seem to be around any more.
