> On Sep 17, 2017, at 11:41 AM, martin f krafft <madd...@madduck.net> wrote:
>
> If a client connects and presents a certificate from a CA listed in
> smtpd_tls_CA_file, then I don't see a reason why the new
> check_certname_access shouldn't be able to cast an "OK" and thereby
> permit accepting/relaying of the message.
Can you explain your use-case in a bit more detail? What sort of
SMTP clients are these, that they authenticate using TLS client
certificates not issued by a CA you control and you're then
providing submission access to said clients based on their domain
as found in the certificate CN?
Keep in mind that DNS names stored as the CommonName of the
certificate subject DN is a deprecated representation of the
client identity. Though most CAs have not yet stopped putting
nonempty subject DNs in certificates, the right place for
certificate names is the subjectAlternativeName extension,
which bears zero or more DNS names and perhaps names of other
types too.
Indeed one is supposed to *ignore* the certificate CN when
subject alternative names are present:
https://tools.ietf.org/html/rfc6125#section-2.3
and should the client's DNS name exceed 64 bytes, it can only
be represented as a DNS-ID in the SAN, because the subject
DN CommonName is limited to that length.
--
Viktor.
