Known Bugs in the exim4 sarge packages
At the time of writing, sarge and sid packages have not diverted too far. There are some documentation issues, which we have improved. Besides that, the following issues are known:
A bug in exim's DNS code causes problems on hosts which think that they have ipv6, but don't actually have ipv6. This is connected with DNS additional sections and different TTL values in zone data (#342619). This bug has been fixed in 4.50-8sarge1, available from stable-proposed-updates, which will be included in Debian 3.0r2).
The default login_saslauth_server contains a duplicated server_advertise_condition clauses, which makes the configuration syntactically invalid. This is trivially and obviously fixable. (#311906)
The default example for authentication against courier authdaemon is broken and succeeds in authentication with bad passwords as long as a valid user name is given. This is fixed in 4.54-2 with fix also applying to 4.50-8. (#336979, fixed file)
There are some entropy issues (#338319, #343085) with exim4 at the moment. exim4 uses GnuTLS, and needs entropy to initialize TLS sessions and to build the Diffie-Hellman parameters anew every 24 hours. When no sufficient amount of entropy is available, these operations will block. If you see SMTP connections stalling after STARTTLS has been issued, you most probably are out of entropy. This happens regardless of the SMTP connection being incoming or outgoing. To see whether you're bitten by that problem, look at the contents of /proc/sys/kernel/random/entropy_avail. If that number is well below 1000, you're in trouble. There are rumours that later 2.6 kernels generate significant less entropy now since some mistrusted entropy sources have been removed. If this is true, this is severly harming TLS deployment around the world. It might also be possible that GnuTLS requires more entropy than necessary to initialize a TLS session, thus draining the entropy pool quickly. We are not in a position to debug this for lack of GnuTLS know-how and would appreciate external know-how. There is a workaround, though it isn't the prettiest. A cron job can be run that checks available entropy, and does something to generate a lot of interrupts when it gets too low. I've had success with something like this:
entropy=`cat /proc/sys/kernel/random/entropy_avail` if [ $entropy -lt 1000 ] then find /var/mail -type f -print0 | rl -0 -c 5000 | xargs -0 cat > /dev/null fiIt uses randomize-lines to read 5000 random emails off the mail spool. This was experimentally determined to be enough disk activity to refill the entropy pool on this system. (The spool in question uses maildir, so there is one email per file. A different technique would be required for an mbox spool).
Another technique that has been suggested is simply to make /dev/random a symlink to /dev/urandom (or give it the same major/minor numbers, which will have the same effect). This is a bad idea if you care about security, because it will affect everything that wants cryptographically secure randomness, not just GnuTLS as used by exim4.
A way to watch how much entropy is used (and regenerate it on the fly):
while true
do
entropy=$(< /proc/sys/kernel/random/entropy_avail)
echo -n "$(date --iso=m) ent=$entropy act="
if [ $entropy -lt 1000 ]
then
echo find
find / /usr /var/ /home -xdev -type f -print0 | rl -0 -c 1000 | xargs -0 cat > /dev/null
else
echo sleep
sleep 10
fi
done
You need to look at both lists!