Bug#440663: exim4-config: MAIN_TLS_* doesn't actually enable TLS

[Marc Haber]

severity #440663 wishlist
retitle #440663 please provide macro-driven configuration for client TLS with client certificates 
tags #440663 wontfix
thanks

On Mon, Sep 03, 2007 at 04:28:22PM -0500, John Goerzen wrote:
> On Monday 03 September 2007 3:37:32 pm Marc Haber wrote:
> > On Mon, Sep 03, 2007 at 12:30:40PM -0500, John Goerzen wrote:
> > > One other thing...  if TLS is enabled by default, then it seems
> > > unnecessary to have a MAIN_TLS_ENABLE macro.
> >
> > TLS is enabled by default for an exim _client_, and it needs to be
> > manually enabled for an exim _server_ since that needs additional
> > handholding (and a certificate).
> 
> I find the client/server distinction confusing for a thing such as exim, 
> which is often both.

Yes, but these things are independent of each other. One is delivering
the message, one accepting it.

> In this particular case, the exim with the problem was the one
> initiating the connection to the remote SMTP server (also a version of
> exim, though an earlier one).

So, it was an SMTP client in this part of the transaction.

> > See also /usr/share/doc/exim4-base/README.Debian.gz chapter 2.2
> 
> I re-read it but found nothing of note.

2.2.1 says "Exim will use TLS via STARTTLS automatically as clint if
the server Exim connects to offers it."

Would adding something like this help:
"This means that you won't need any special configuration if you want
to use TLS for outgoing mail. However, if your server wants to see a
client certificate, you need to amend your remote_smtp and/or
remote_smtp_smarthost transports with a tls_certificate option. The
certificate presented by the remote host is not checked unless you
specify a tls_verify_certificate option on the transport."

> > Can I close this bug?
> 
> No, I still think this is misleading.  Why should I manually have to add the 
> lines to the smtp smarthost transport, when the comments in both the TLS 
> config and README.Debian seem to indicate that this should Just Work, 
> especially once I have pointed it at my cert and key?

It should just work. Using client certificates is secure, but kind of
exotic (I have never seen a mail system requiring client certificates
in the wild, and I see a number of new mail systems each day at work).

> 
> What is the problem with adding the two lines I provided (wrapped in 
> appropriate ifdefs as elsewhere) to the relevant transports?

I don't think that it would be good to make the default configuration
any more confusing than it is already. The whole idea of the macro
stuff is to provice a less complex and more straightforward method of
configuration, and by pulling in all possible configuration options,
this is thrwarted.

An experienced user could have seen that a macro with a MAIN_ prefix
is probably not being used inside a transport, especially because all
other macros used in the remote_smtp(_smarthost) transports are
prefixe REMOTE_SMTP_.

I'm going to tag this bug wontfix just in case that you want to refer
this issue to the tech ctte.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190