Hi Victor, > On 14 Mar 2014, at 17:41, Viktor Dukhovni <[email protected]> wrote: > > On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote: > >>> [ Second-last paragraph of 2.2 ] >>> >>> Is it not obvious that this means the misguided: >>> >>> example.com. IN MX 0 192.0.2.1. >> >> No, it is not obvious, otherwise I wouldn't have asked. > > The original sentence reads: > > Similarly, when an MX RRset incorrectly lists a network address in > lieu of an MX hostname, if the MTA chooses to connect to the network > address, DANE TLSA does not apply for such a connection. > > Anyone else feel this deserves an example? There are some poor > sods who attempt to stuff IPv4 addresses into MX hostname RRDATA, > and some MTAs may do them a favour and handle this broken syntax. > In that case DANE is clearly out of scope.
Ok, after thinking more about this, your current text looks Ok as is. > >>> In 6125 (where the exceptions dominate the rules) there are no >>> provisions for matching one of a set of candidate names. >> >> I am not sure I understand. If there are multiple subjectAltName >> values of the same type, any match works. Unless you mean something >> else. > > No, the SMTP and SRV drafts specify that the client has multiple > names it is willing to accept, any one of which may match one of > the many SAN names in the peer certificate. There can be up to > three names. The original name before redirection by MX or SRV, > the securely CNAME expanded version of that if different, and > finally the TLSA base domain of the server. RFC 6125 allows for that, so I see no conflict. > >>> I don't know whether the Postfix (on by default) Postini work-around >>> deserves IETF blessing. Perhaps it would be better for Postini to >>> fix their certificates, >> >> I think so, yes. > > That is Postini fix their mess? Yes. > Or SMTP support multi-label wildcards? I suppose this might be another reasonable outcome, if we can get IETF consensus on this. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
