Well, like I said, STS requires clients to provide SNI, so they should not consider it an STS violation if they don't send SNI and consequently get the wrong cert.
I am not claiming your setup is broken--just that among possible fixes (a cert with many SANs, using SNI to serve one cert of many, renaming the MX), renaming the MX may be the easiest. Whether that's worth it is your call, not mine. :) Dan On Wed, Jan 9, 2019 at 3:22 PM John Levine <[email protected]> wrote: > In article <CANtKdUee4d=bexpAUj-9+qGLO1ght= > [email protected]> you write: > >I think this is hard. You probably could get a single cert with SANs for > >all of your 80 domains, or one for each new domain, but you will have to > >figure out how to automate this (and I guess use SNI to pick the right > cert > >on the server side--note that the RFC does require SMTP clients to support > >SNI, so as to enable this). > > I use the standard gnutls library which supports SNI, so I suppose I > could put 80 certs into a folder and pick out the right one. I wonder > how many SMTP clients send the name they expect -- until STS came > along there was no expectation that the name the client used matches > the cert. I can certainly write a stunt https server that invents a > suitable policy document on the fly, > > The larger issue is that this is the same unfortunate road that SPF > and DMARC went down. Oh, our magic bullet can't handle your totally > standard but slightly unsusual setup, so we will retroactively redefine > it as broken. > > -- How's my emailing? http://go/dan-email-slo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
