Viktor Dukhovni:
> On Tue, Jul 29, 2014 at 10:03:04AM -0400, Wietse Venema wrote:
>
> > > 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?
> >
> > smtpd_tls_ask_ccert_helo_names does not generalize. We'd also need
> > smtpd_tls_ask_ccert_client_names and smtpd_tls_ask_ccert_client_addrs
> > and so on. Instead of introducing code that solves only one user-visible
> > problem, introduce infrastructure that can be reused in other contexts.
>
> My thinking is that only the HELO name is a plausibly correct client
> identity for certificate checks. This is that the client calls itself.
It does not matter. We have a client with N properties and we need
a matching mechanism. The matching mechanism should be more general
than the specific user-visible problem at hand.
Anf if at all possible, we should also avoid a user interface that
requires two parameters to turn on/off one feature: one binary
parameter and one matching parameter.
Wietse
