Sie sind hier


Exim4 and TLS with GMX/

Due to the unveiling of the NSA surveillance by Edward Snowden, some German mail providers decided last week to use TLS when sending mails out. For example GMX and Usually there shouldn't be a problem with that, but it seems as if the Debian package of Exim4 (exim4-daemon-heavy) doesn't support any TLS ciphers that those providers will accept. The Debian package uses GnuTLS for TLS and there is Bug #446036 that asks for compilation against OpenSSL instead.

Anyway,  maybe it's something in my config as I don't use the Debian config but my own /etc/exim4/exim4.conf. Here are the TLS related parts: 

tls_advertise_hosts = *
tls_certificate = /etc/exim4/ssl.crt/webmail-ssl.crt
tls_privatekey = /etc/exim4/ssl.key/webmail-server.key

That's my basic setup. After discovering that GMX and cannot send mails anymore, I added some more, following the Exim docs (it's commented out, because I don't use GnuTLS anymore):

#tls_dhparam = /etc/exim4/gnutls-params-2236
#tls_require_ciphers = ${if =={$received_port}{25}\
# {SECURE128}}

But still I got this kind of errors:

2013-08-14 22:49:27 TLS error on connection from [] (gnutls_handshake): Could not negotiate a supported cipher suite.

As this didn't help either, I recompiled exim4-daemon-heavy against OpenSSL and et voila, it worked again. So, the question is if there's any way to get it working with GnuTLS ? Does the default Debian config work and if so, why? And if not, can a decision be made to use OpenSSL instead of GnuTLS? Reading the bug report it seems as if there are exemptions for linking against OpenSSL , so GPL wouldn't be violated.

UPDATE 16.08.2013:
I reinstalled the GnuTLS version of exim4-daemon-heavy to test the recommendation in the comments with explicit tls_require_chiphers settings, but with no luck: 

#tls_require_ciphers = SECURE256
#tls_require_ciphers = SECURE128
#tls_require_ciphers = NORMAL

These all resulted in the usual "(gnutls_handshake): Could not negotiate a supported cipher suite." error when trying one by one cipher setting.

UPDATE 2 16.08.2013:
There was a different report about recent GnuTLS problem on the debian-user-german mailing list. It's not the same cause, but might be related.


Getting hit by a spammer with Exim

Yesterday I was warned by Nagios that something is going on with my server. The number of processes has been gone beyond the limit. The reason for this were a bunch of Exim processes trying to deliver a lot of mails. Apparently a spammer made it happen to send spams via my server. How could this happen?

I was seeing a lot of those log entries: 

2010-06-28 16:29:25 1OTFKt-0004cZ-1R <= H=( [] P=esmtpa A=cram_md5:inna S=1455 id=0ec5ff00b06c43369e2582fc4269839e@e12c17c51ec546bf9e7a23e6f9875941
2010-06-28 16:29:27 1OTFKw-0004cZ-KZ <= H=( [] P=esmtpa A=cram_md5:inna S=1520 id=58913c34bde64e908310db7e1280eff5@2dc8ed5998b64e8485c472cae5ef98c3
2010-06-28 16:29:28 1OTFKy-0004cZ-1p <= H=( [] P=esmtpa A=cram_md5:inna S=1436 id=814a7bdcbe85447a9283d4a0a074830b@0ada3cde4a4c41c38c65bc912639afb6

Apparently the spammer has successfully found a way to bypass the authenticators in Exim. By default only authenticated users can send mails via my mailserver, of course. But this spammer found a way around that problem. A user "inna" is not known, so the spammer shouldn't be able to send mails at all. But he can. Something is broken apparently.

The spammer sent an empty password ('') and the database didn't find an user by this name and returned an empty resultset (''). Both sides of the comparison matches and the mail is allowed in. Let's have a look at my Exim config: 

  server_debug_print = "running smtp auth $1 $2"
  driver = cram_md5
  public_name = CRAM-MD5
  server_secret = ${lookup pgsql{select clear from passwd where passwd.usr='$1' limit 1}{$value}}
  server_set_id = $1

On #exim@freenode there was just another user with the very same problem with exactly the same spammer. Apparently the lookup is true for empty passwords or users. The solution is to add a "fail" in the lookup statement: 

server_secret = ${lookup pgsql{select clear from passwd where passwd.usr='$1' limit 1}{$value}fail}

That's pretty all to do to prevent the spamming. But how could this happen at all? Back then when I was configuring my mailserver (around 2003 or so) I can remember that I tried a "fail" statement in the server_secret as it is described in the Exim documentation, but it didn't work as expected. So I ended up with no "fail". This worked fairly well over the years and I remember that I tested this lookup by trying to send with user/password combinations of all different sorts. So it went into "production".

Apparently it doesn't work anymore today. The other guy on the #exim channel said that he found no database lookup example with "fail" at all. Even the example in one of his books was without "fail". So I believe that something changed either in Exim or in PostgreSQL to make submitting an empty password string a positive match for bypassing authentication nowadays.

For the records: the spammer send approx. >10.000 mails. Another bunch of 8000 mails were rejected, but this is just slightly over the daily average.


Spamassassins spamds memory usage

Da ich ja durchaus schon früher über meine tollen Erlebnisse mit Alice-DSL berichtet habe, möchte ich das nun fortführen. Der Grund für das neuerliche Alice-DSL ist übrigens die Zweitwohnung in Berlin aufgrund des neuen Jobs in Berlin.

Naja, wie auch immer. Nach der Online-Bestellung gestern, bekam ich nun heute eine Email von Alice, daß noch die Daten des Vormieters fehlen würde, also Name und Telefonnummer und daß ich die fehlenden Daten im Kundenbereich im Web nachtragen könnte:

Das lustige dabei ist, daß oben steht, Name und Telefonnummer solle man nur eintragen, wenn man sie sicher kennt. Ansonsten solle nichts eintragen. Da ich weder Namen noch Telefonnummer vom Vormieter kenne, hab ich also brav nichts eingetragen und auf Weiter geklickt. Daraufhin kam dann der Hinweis hinzu, daß Name und Telefonnummer Pflichtfelder seien, also ausgefüllt werden müssen.

Testet Alice ihr Webinterface auch irgendwie mal?


Exim4 & Entropy

Nachdem ich ja schon letztens mein Unmut über die unsäglichen TetraPak-Verschlüsse geäußert hatte, ereilte mich das Schicksal erneut und ich wurde mit deren Unzulänglichkeiten belästigt...

Hier wie sich die Packung in etwa vor meinem Versuch des Öffnens präsentiert hat:

TetraPak vor dem Versuch des Öffnens

Nachdem ich aber den Verschluß nur gaaaanz leicht berührt hatte, war schon klar, daß das nichts mehr werden würde. Letztendlich sah es dann so aus:

TetraPak nach dem Versuch

So blieb mir mal wieder nichts anderes übrig, als die Verpackung an der hochgeklappten Lasche aufzuschneiden. Immer noch die beste, einfachste und sauberste Variante, eine TetraPak-Verpackung zu öffnen! :-)



Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer