[gnutls-dev]Re: exim + gnutls

Philip Hazel ph10 at cus.cam.ac.uk
Fri Oct 25 11:53:01 CEST 2002

On Wed, 9 Oct 2002, Nikos Mavroyanopoulos wrote:

>   I attach you, in case you are interested, a very preliminary patch
> to exim, to use gnutls instead of openssl. I treat it as unstable
> because I'm not familiar with exim's source code, and I didn't understand
> many things.

Hello Nikos,

I have now managed to find time to look at your patch, but I'm having a
problem making it work. I had to re-organize it so that I could
conditionally compile Exim either for OpenSSL or for GnuTLS, but I don't
think I actually changed any of your code significantly. I have a number
of comments:

1. One of the things you haven't realized is the way Exim works. It does
not run as a continuously running process, except for the listening
daemon. Outgoing messages arrive and are delivered in separate processes
that do not have a common ancestor process. Thus, calling a global
initialization function once near the start of Exim is not a good idea.
Also, there are calls to Exim that don't send or receive messages; it's
a waste of time for them. I changed the code so that the daemon does
make the call - that makes sense for incoming messages via the daemon,
and then I had to put it also in the server/client start-up code for the
individual cases.

2. The next problem with the global initialization is that it takes a
long time to generate the D-H parameters. I have in fact cut that out,
because it delays starting up the daemon by quite a few seconds (on a
SPARC Ultra 1 running Solaris 8). The RSA start-up is relatively quick,
probably less than 1 second, which is still a while, but may be
tolerable. When Exim is delivering a message, it doesn't know whether
it's going to be using TLS in many cases until it has actually connected
to the remote host. Thus, you don't want to spend resources on expensive
initialization until you know that TLS is going to be used.

3. Anyway, I tried testing the server with gnutls-cli-debug and the
problem I have is the error NO_CERTIFICATE_FOUND from the call to
gnutls_handshake(). I seem to be able to hand over the file names OK,
but it doesn't like what's in the file. Question: what format does the
certificate and key have to be in? I was just using the same files that
I had successfully used with OpenSSL. Can the key and the certificate be
in the same file, as they can for OpenSSL? (I tried both ways, but still
got the error.) I'll copy the certificate file below, for your
information. It's just a self-signed certificate for testing. If you can
suggest a good way for me to find out what's going wrong here, I'd be

4. It is really good to have documentation with a complete list of
functions, but it would be easier to find them for reference if they
were in alphabetical order. A list of errors and explanations could also
be useful - earlier I had MEMORY_ERROR, and had no idea what it meant.
It went away when I changed something.

5. There's a teeny buglet in gnutls-cli-debug. The command

  gnutls-cli-debug localhost 1225

(note: the -p is missing) doesn't complain: it tries to connect to port 443.

6. Your previous comment about waiting for the client to close after a
startup failure is deliberate. I think I must have based it on these
words from RFC 2487:

   If the SMTP server decides that the level of authentication or
   privacy is not high enough for it to continue, it SHOULD reply to
   every SMTP command from the client (other than a QUIT command) with
   the 554 reply code (with a possible text string such as "Command
   refused due to lack of security").

This isn't quite the case of a failed handshake, of course.

7. The problem with HELP was a bug I knew about, and have now fixed.


Philip Hazel            University of Cambridge Computing Service,
ph10 at cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.


More information about the Gnutls-devel mailing list