Zugschlusbeobachtungen (Entries tagged as exim)

Geplusste und gedreifachtminuste Mailadressen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 23 Apr 2008 21:28:51 +0200

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.

Does Debian need the local host name in /etc/hosts for IPv6?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 31 Mar 2008 16:51:39 +0200

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.

To avoid the extra DNS lookups, the Exim packages have a Debconf option to configure exim for “minimal DNS usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This was necessary since - without this option - exim looks up its own host name in the DNS even when a completely local operation is invoked.

In some cases, exim still looks up its IP address when a listening daemon starts up. This is why the Debian installer configures 127.0.1.1 (not 127.0.0.1) for the local hostname on installation, yielding /etc/hosts files like

127.0.0.1       localhost
127.0.1.1       myfoo.localdomain   myfoo

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

However, in the last few weeks I have heard a few cases where exim does IPv6 AAAA lookups when a listening daemon starts up. An strace shows a gethostbyname2 call for AF_INET6, and if we want to continue the line we went in the past, we’d need an IPv6 address for myfoo.localdomain in /etc/hosts as well.

I am now wondering how this could be implemented. In IPv4, we have 127.0.0.0/8 available for the local host and could arbitrarily choose 127.0.1.1 to configure the local host name on. In IPv6, there is only ::1, which is a single address. Would it be possible to choose an arbitrary “link local” address on lo, the loopback interface? Or is there any better way?

This being said, I consider the entire 127.0.1.1 business a horrible hack which is one of the most ugly things I have ever seen. Do we have a chance to implement this in a more cleaner way, or is it still the way to go for the distribution, where we don’t know zilch about the environment where an installed system is going to be used?

This issue leads to people adding their local host name to ::1 in /etc/hosts, which might re-introduce other issues that we experienced in a phase when we did the same for 127.0.0.1, eventually ending up with 127.0.1.1, or to disabling IPv6 altogether, which is a bad thing in a time where IPv6 should be enabled, not disabled. So I’d like to find a clean solution which could then be implemented in whatever part of Debian might be responsible.

I tried asking this question in other places, including Usenet, before pestering my Blog to ask the Lazyweb, but obviously the people I asked before do not care for the special environment that a Linux distribution has to take care of. The only answers I got were like “that would be the local administrator’s task to fix” and “this should be taken care of in the local DNS server/setup (maybe even on the local box being installed)”. A quite frustrating experience.

Update 2008-04-15

The issue seems solved. To avoid the extra DNS lookups, the Debian Exim packages have a Debconf option to configure exim for “minimal DNS usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This - silently - doesn’t happen if hostname --fqdn does not return a fully qualified name (#476249).

I am inclined to solve this issue by having update-exim4.conf print a warning if hostname --fqdn does only return a single-component name and leave the rest to the local admin.

exim4 vs. OpenSSL vs. GnuTLS

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 04 Nov 2007 17:06:27 +0100

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.

GnuTLS is the “clearer” solution from a license point of view: The client library is LGPL, and it can thus be safely linked to everything that is part of Debian main. This is the main reason why we decided to use GnuTLS for exim4 years ago, so that we do not need to worry about licensing issues when some other library is linked to by exim some time in the future.

On the other hand, my impression gets stronger and stronger that GnuTLS is not ready for prime-time. There is a truckload of interoperability problems with a number of “remote sides”. The most prominent issues are TLS aborts when exim4 is SMTP server for some clients, most notably Incredimail and some mobile Phones from Nokia and other vendors. Most of them can be nailed down to misnegotiation of certain ciphers, but exim does currently not allow disabling of some ciphers at run-time, and - even worse - one would need to disable them completely since one cannot judge in advance whether we are facing a client with issues or one without.

The GnuTLS maintainers of both Debian and upstream try being helpful, but I do not see a long-term solution here.

Additionally, nobody upstream knows its way around the GnuTLS related code in exim, which was contributed by Nikos Mavroyanopoulos years ago. So, there is little chance to get GnuTLS-related bugs ironed out from exim.

OpenSSL, on the other hand, does not have these interoperability issues. At least, I haven’t heard of any, and the recommended fix for the reporters of GnuTLS related bugs, “recompile exim with OpenSSL” (which the packaging has been supporting for nearly two years now), usually fixes their problems. I am not in a position to judge whether this is caused by people actually testing against OpenSSL, or OpenSSL generally being more tolerant towards strange implementations, or GnuTLS being buggy or poorly written.

However, building exim4 again OpenSSL may post the license issues that convinced us to use GnuTLS in the first place. Exim itself has an OpenSSL exception, and from what I have been told, the MySQL FLOSS License Exception allows linkage to OpenSSL as well. At least, it does now, since historical evidence in the exim4 package either shows that it used to be a license violation to link MySQL and OpenSSL in the past, or that we (the Debian exim4 team) wrongly thought so. On the other hand, if it is illegal to have OpenSSL and “really” GPLled code in the same execution space, we already have that license violation today, brought to us by PostgreSQL, which links against OpenSSL.

ftpmaster has already indicated that they won’t consider an exim4 linked against OpenSSL a license violation and that the packages would go through, the packaging can handle the change by virtue of flipping a switch and rebuilding, but I am still not fully convinced that doing so is the right thing from a political and license point of view. I might still need that final nudge by feedback to this blog article, or have my reluctance fed. Please comment.

No, I do not plan to take this to debian-legal; I’d prefer exim4 staying in Debian main.

From the personal Inbox of the exim4 maintainer

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 17 Jul 2007 18:08:41 +0200

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 web~~master~~idiot 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.

Today, I had this happen to me twice. In the morning, I received a question about exim4 in private e-mail. In German. I investigated the user’s problem (which looked interesting enough), found two minor issues in the Debian exim4 packages and upstream exim behaving not as expected. I fixed the two issues in the package and reported the unexpected behavior of exim to the upstream mailing list. I then reported this - in German - back to the person who asked the question. Time from incoming message to outgoing report was like 80 minutes, most of which I spent with this user’s issue. On my personal time.

A short while afterwards, I found out that this person has waited a mere eleven minutes before asking the same question on pkg-exim4-users, this time in English. Had I known before, I would have drafted my answer in English as well, to have the answer publicly visible. By doing this double post, the user has deprived the public of my answer.

I’m probably going to stop answering questions asked in private mail. I might draft a boilerplate answer along the lines of “I don’t answer questions asked in private mail unless I am being paid to do so. You might be better off by asking one of the numerous mailing lists that are available on the Internet. I read a lot of them, might see your question, and you might get an answer from me. But otoh, there are many more knowledgeable people on these lists, and you’d want them to see your question as well.” Or I just might hit Delete on questions in my private inbox.

The “Delete” approach has become more attractive this afternoon after I pulled the following (anonymized) from my personal Inbox:

Great job breaking exim4 on my system with no easy way to fix it.

$ /etc/init.d/exim4 start
Starting MTA:DEBCONFsomethingDEBCONF found in exim configuration. This
is most probably
caused by you upgrading to exim4 4.67-3 or later without accepting the
suggested conffile changes. Please read
/usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4
2007-07-17 11:31:57 Exim configuration error in line 25 of
/var/lib/exim4/config.autogenerated.tmp:
  malformed macro definition
Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not
installing
/var/lib/exim4/config.autogenerated.tmp to
/var/lib/exim4/config.autogenerated

I’ve been running exim4 v4.63 for awhile now and only have you bugger
exim4-config it doesn’t work.

I mean, this user has

Not read NEWS.Debian.gz before updating
Declined the configuration file updates that were offered by dpkg during the update.
Received a clear-text error message explaining the issue and pointing to the docs.
Vulgarly insulted the maintainer

Sorry, but: How stupid can people be?

I think I’m going to stop being responsive to users. They’re not worth the blood pressure.

Please test exim4 from experimental

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 14 Jun 2007 15:30:26 +0200

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.

exim4 (4.67-2) experimental; urgency=low

  - update-exim4.conf:
    - finally get rid of the DEBCONFfooDEBCONF stuff. That information
      is now passed to the configuration by ue4c by directly setting exim
      macros in the configuration. This has caused both the configuration
      and ue4c to be much shorter.
    - run with -e, -C and -u.
    - convert input read from update-exim4.conf.conf to lower case
    - barf if strange characters are found in ue4cc. Closes: #400294
  - Remove superfluous "x$foo" = "xbar" constructs from scripts
  - Add routers to reject mail to accounts with low UID.
    Closes: #400790.
  - Make daily cron job barf if /usr/bin/mail is not found. Have
    exim4-base recommend mailx. Closes: #427960
  - Have all -daemon packages provide exim4-localscanapi-1.0 and
    exim4-localscanapi-1.1 as requested by Magnus Holmgren while fixing
    #426425. Also include exim4-localscan-plugin-config script with
    exim4-dev. Thanks to Magnus for helping with this. Closes: #428274
  - remove /etc/exim4/email-addresses symlink and document this.
    Thanks to Josip Rodin. Closes: #420578
  - introduce conf.d/250_exim4-config_lowuid which optionally allows
    to reject (or alias away) mail to low-uid accounts that are not
    listed in an exception list. Thanks to Dominic Hargreaves,
    Marc Sherman and Ross Boylan. Closes: #400790, #307768, #331716
  - remove versioned depends on cron, since the version we need is
    well before sarge.
  - Add cron | fcron dependency. Fcron is going to be removed again
    at the first sign of trouble. Closes: #381806
  - remove move_exim3_spool debconf template. Closes: #391762
  - replace openssl gendh with openssl dhparam. Closes: #413235
  - adapt docs, README and manpages
  - have Hilko fix the lynx-dump postprocessing to repair generating
    README.Debian text version. Thanks!
  - increase README.Debian generation robustness. Thanks to Hilko.
  - debconf:
    - Partly apply Christian Perrier's patch for reviewed
      templates and control file. Closes: #426980
    - Other minor template changes.
    - get rid of "mails" in debconf templates, use "messages" instead.
      Re-word local_interface debconf template. Other minor changes.
      Thanks to Jens Seidel and Christian Perrrier. Closes: #394976
    - re-work exim4-config.config logic to have split/non-split config
      asked last instead of first. This partly addresses #410756.
    - Add exim4-daemon-heavy.templates, exim4-daemon-light.templates
      and exim4.templates to POTFILES.in
    - Re-Word dc_other_hostnames debconf template.
      Thanks to Hans G. Ehrbar. Closes: #421860
    - translation updates:
      - French
      - Ukrainian. Closes: #427793
      - Bulgarian.
      - Thai.
      - Galician.
      - Swedish.
      - Punjabi.
      - Indonesian.
      - Italian.
      - Khmer.
      - Traditional Chinese. Closes: #428072, #428069.
      - Portuguese.
      - Simplified Chinese. Closes: #428072, #428069.
      - Marathi

 -- Marc Haber <mh+debian-packages@zugschlus.de>  Wed, 13 Jun 2007 14:00:38 +020
0

A christmas wish for exim

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 24 Dec 2006 12:21:25 +0100

Dear Lazyweb, dear Santa Claus,

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.

exim 4.64 in Debian

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 21 Dec 2006 14:18:54 +0100

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.

Personally dropping support for users of debianhowto.de exim configuration

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 29 Nov 2005 13:56:27 +0100

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.

Mailing List Message

In the last weeks, I have been bombarded with a lot of newbie-level support questions. In most cases, I found out that the people asking these questions have used the directions listed in the debianhowto.de HOWTO for using exim, vexim, courier and a lot of other complex mail-related packages which basically say “disable the Debian magic and use our exim4.conf”.

This morning, I asked the makers of Debianhowto.de to clarify that their directions take the “Debian” from exim4 and that the Debian exim4 maintainers cannot do any support on the configuration generated by users of this HOWTO, and that this HOWTO generates quite an amount of support burden for us.

The message, in German

I received an answer (unreadable in the archive), which I had to quote back to the archive to get it in the archive in a human-readable way (also in German). It basically says “you suck, get lost, we have backing of the community”, which is quite easy to say if you unload your support burden on other people.

I am therefore tempted to drop any support for vexim-based configurations and to send all people asking for support towards the debianhowto.de people who have quite clearly demonstrated that they do not care about the work load of the people providing Debian’s exim.

If nobody from the Debian exim4 community objects, I’m going to place warnings regarding this in our documentation, on Debian’s exim4 web pages and on the list description for pkg-exim4-users.

Did you read the documentation?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 16 Sep 2005 16:41:00 +0200

Found on exim-users:

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 needs gnutls expertise

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 15 Aug 2005 22:45:35 +0200

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.

Can anybody help?