"Postfix has no SNI support. Effort >> benefit." Dovecot implemented SNI support. Dovecot implements a different set of protocols, but they implemented SNI for 50% of e-mail (the receiving end). If the receiving end of e-mail has SNI, the sending end should probably implement it too if, for no other reason, for completeness. Mail clients tend to follow servers, not the other way around.
- Fiona ________________________________ From: Viktor Dukhovni <postfix-us...@dukhovni.org> To: postfix-users@postfix.org Sent: Monday, May 7, 2012 12:05 AM Subject: Re: TLS SNI support? On Sun, May 06, 2012 at 11:46:45PM -0700, Fiona Hines wrote: > That won't work for me.? SNI support is the only solution for my > scenario since I can't use just one SSL certificate. I haven't used > Google Apps to know what you are talking about. Postfix has no SNI support. Effort >> benefit. Which SMTP clients send SNI indications? Which (other than Postfix) SMTP servers support SNI? SNI assumes that the client has in hand a single name by which it is willing to authenticate the server. In practice, (e.g. Postfix default smtp_tls_secure_certmatch) the matching criteria are more fuzzy, and SNI is too rigid a mechanism. Only with submission clients that are configured to a single logical SMTP server is SNI potentially workable. Hence my question about the state of clients supporting SNI. Which mail clients are these? Are there existing MTAs that work with these clients? Have you considered a single certificate with subjectAltNames (much simpler if the number of domains you support is not too large or dynamic). If you want to host submission for large numbers of vanity domains on a single MTA, why must the clients be configured to contact "smtp.vanity-domain.com"? What's wrong with "smtp.provider.net"? > And I've got a feeling that the "250 response" part of your reply > is just wrong - which 250 response?? Certificates are validated by > clients during the handshake and the connection is terminated if > the verification step fails.? That happens long before even the > SMTP banner is emitted. The answer is "wrong", but not for the reason you indicate. With STARTTLS, the SMTP client *does* see the server's EHLO (250) response before the TLS handshake. This said, verification of a name supplied by the server over an unencrypted, unauthenticated channel is entirely pointless. If certificates are intended to thwart MITM attacks, allowing the MITM to control the server's identity removes all vestiges of MITM protection. I am aware that in the past some vendors have implemented TLS certificate checks in exactly this futile manner. I find the situation tragically comical. -- Viktor.
