On Tue, Jul 29, 2014 at 09:13:19AM -0400, Wietse Venema wrote:
> > IIRC smtpd_tls_ask_ccert should not be enabled on publicly referenced MTAs,
> > because there are enough MTAs out there unable to handle client certificate
> > requests from a server they connect to.
>
> Is this still true? Assuming that you are referring to MTA-MTA
> communication, not end-user MUAs (such as old Netscape clients that
> should have fallen to dust by now).
There were IIRC (also?) some issues with qmail, which is not updated
terribly frequently. TLS_README says:
Note, that unless client certificates are used to allow greater access to
TLS authenticated clients, it is best to not ask for client certificates at
all, as in addition to increased overhead some clients (notably in some
cases qmail) are unable to complete the TLS handshake when client
certificates are requested.
This was long ago, someone might need to configure a few versions
of qmail with TLS and test... No idea which versions of qmail are
still in use.
> > It that is true, would it be possible to make smtpd_tls_ask_ccert client
> > dependent e.g. request a ccert when the client sends e.g. a specific HELO
> > hostname?
> >
> > mail.example.com ask_ccert
> > .example.net ask_ccert
>
> Alternatively, allow a richer input to smtpd_tls_ask_ccert besides
> yes and no. For example, a (match)list.
That was also my thinking, but I was expecting a new parameter,
smtpd_tls_ask_ccert_helo_names = <domain match list>
Turning "smtpd_tls_ask_ccert" from a boolean to a matchlist, requires
a bit of special gymnastics to deal with "yes" and "no", would that
be better?
--
Viktor.
