On Mon, Feb 25, 2013 at 10:33:09AM +0100, marcos gonzalez wrote:
> Im preparing a server with postfix 2.7.1 and now Im with the process
> to certificate de connection. I have two domains and normally using
> multipli domains certificate ou can join this, but the propierty of
> domains is different and you can't do that. How resolves this
> problem the companies with N domains associated?
For the most recent variant of the usual answers, see:
http://archives.neohapsis.com/archives/postfix/2013-01/0174.html
http://archives.neohapsis.com/archives/postfix/2013-01/0657.html
and similar older answers. Admittedly, these answers are all
predicated on the idea that the client is an MTA, sending messages
to a destination domain via MX records, ...
If the client is an MUA (say Thunderbird), and Postfix is the MSA,
then indeed the client posesses an unambiguous TLS destination
host, and may well be SNI capable. One could perhaps attempt to
make the case that Postfix should support the server side of SNI
on the submission port.
However, to date all the OPs who've asked for SNI have motivated
it by saying they're receiving email for multiple domains. This is
not MUA->MSA use-case above and is subject to my standard objection.
If someone is instead hosting many independnt MSA services on a
single machine (or cluster of machines).
smtp.example.net:587
smtp.example.com:587
smtp.example.org:587
...
rather than just:
smtp.example.net:587
and has a compelling reason for doing this, we'd at least have a
rational basis for discussing the merits of SNI in Postfix. Mind
you, at this point my efforts are going to be focused on DANE (RFC
6698), which makes the whole issue go away, since each domain can
securely bind to the same trusted public key via DNSSEC (via a
CNAME!) and there's no longer any need for multiple certs.
_587._tcp.smtp.example.net. IN TLSA 3 1 1 0123456789abcdef...
; + RRSIG
_587._tcp.smtp.example.com. IN CNAME _587._tcp.smtp.example.net.
; + RRSIG
_587._tcp.smtp.example.org. IN CNAME _587._tcp.smtp.example.net.
; + RRSIG
I see negligible benefit from an SNI implementation for Postfix.
Is it time to add an anti-SNI rationale section to TLS_README? This
would set a bad precedent, there is no limit to the number of
non-features we could document.
--
Viktor.
