Some comments: ,---- | Is the Transmitted: header useful enough to include in this spec? | Should it be dropped, or perhaps moved to another document? `----
It does seem useful; I'm indifferent to in this document or in a document of its own. ,---- | Is the description of DNSSEC validation over-done? Can it be trimmed | down so it relies more on the core DNSSEC specs? `---- Given the desire to ensure that partial tlsa provisioning doesn't block mail delivery, it seems squarely to have hit the as simple as needed but no simpler nail. ,---- | o If there is no TLSA record or its DNSSEC validation state is | insecure or indeterminate, this protocol has not been fully | deployed. The client SHOULD deliver to this server insecurely | (which might be over unauthenticated TLS). `---- In that case the target mta might offer a cert which the client mta can authenticate by some means other than dane (eg a pool in CApath or the like). So 'insecurely' is not the right adverb. I haven't come up with an alternative wording, though. ,---- | A <Transmitted-line> SHALL include: | | o A <To-domain> clause describing the SMTP server. The <Domain> | part of a <To-domain> SHALL be the same as the SMTP server host | name. `---- When would/could/should the To-domain not in its entirety match the string used for the A/AAAA and TLSA lookups? ,---- | 6.1. "with" protocol types `---- It seems odd that with is used for some auth but not all. Perhaps there should be a with keyword for tlsa, too? -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
