I have been getting increasing number of errors in my Exim log related to GnuTLS Diffie-Hellman prime number. That prime number being too small causes Exim to abort the connection and initiate a new one to send the email over an unencrypted session.

The exact error message is: TLS error on connection to foobar.example.com [x.x.x.x] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

With a recent enough Exim installation, you can define the tls_dh_min_bits parameter to a value that you find acceptable.

To find the length of the DH prime number of a specific host, do the following:

$ gnutls-cli -s x.x.x.x -p 25
EHLO xentoo.info
STARTTLS
Hit <CTRL-D>

You should see something like this:

\# gnutls-cli -s x.x.x.x -p 25
Connecting to 'x.x.x.x:25'...
- Simple Client Mode:
220 foobar.example.com ESMTP Sendmail 8.14.3/8.14.3/SuSE Linux 0.8; Sat, 21 Jun 2014 03:29:34 -0400
EHLO xentoo.info
250-foobar.example.com Hello xentoo.info \[y.y.y.y\], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
STARTTLS
220 2.0.0 Ready to start TLS
\*\*\* Starting TLS handshake
- Successfully sent 0 certificate(s) to server.
- Ephemeral Diffie-Hellman parameters
 **\- Using prime: 512 bits**
 - Secret key: 507 bits
 - Peer's public key: 512 bits
- Server has requested a certificate.
... bunch of other stuff ...

If you want to get rid of the errors for that host (and all the others that us a “as-low-as” 512bits DH prime), you just set tls_dh_min_bits = 512 in the remote_smtp transport .

As far as I understand, such a low DH prime implies that the connection is vulnerable to attacks and that it will be easier to get the content of the connection. For me, it is not a problem. Moreover, if I don’t do this, the mail is sent unencrypted, which is even easier.

It works with Exim 4.82 in Ubuntu 14.04 (Trusty) but it doesn’t with Exim 4.72 from Debian 6 (Squeeze).

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676563