* Viktor Dukhovni <postfix-us...@dukhovni.org>: > On Thu, Sep 19, 2013 at 10:44:27AM +0200, Stefan Foerster wrote: > > * Viktor Dukhovni <postfix-us...@dukhovni.org>: > > > You should be looking at the SMTP draft, not the OPS draft. [...] > > Would that be draft-ietf-dane-smtp-01? Because this one, too, > > explicitely doesn't cover mail submission. > No: > > https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01
I see. So, for joe.u...@example.com the whole setup would probably be something along: - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com - publish TLSA record for mail.example.com - one might think about certificate usage 0 or 1 here, right? - make sure the submission server at mail.example.com has certificates for mail.example.com as well as example.com, with example.com being the certificate that's displayed when the client does't support SNI, at least according to draft-fanf-dane-mua-00 I can see why you are being sceptical about MUA support for this. And, from an ops PoV, the requirement of having two certificates, one for the server hostname and one for the mail domain, with the need of obtaining both from a CA that has widepread support amongst MUAs, with the further need to provide two endpoints, one for old and one for new clients, is a real PITA. JFTR: The second mentioning of RFC6409 in section 3 of draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo, referring to RFC6186. Stefan
signature.asc
Description: Digital signature
