On 24 February 2016 at 12:19, Viktor Dukhovni <[email protected]> wrote:
> Please DO NOT do this. For most domains, email infrastructure is > much less static than HTTPS, with domains switching to a different > MX provider at the drop of a hat. Degrading SMTP reliability by > unilaterally pinning volatile configurations on the sending side > is not a good idea. We absolutely understand the point about deliverability, and view that as a non-negotiable design objective. Right now this is experimental code. We aren't going to ship it until we've implemented a few more things: (1) policy map entries are only created if the recipient domain explicitly requests it (via DANE, or SMTP-STS, or a request directly to us), and takes responsibility for its correctness (2) there is a rapid update mechanism in place, so that every mailserver using these policies will update to the latest signed version within hours or less (3) there is a failure reporting mechanism, so that any domain announcing such a policy can be automatically informed by (opted in) senders in real time if the policy starts causing deliverability problems. We'll probably offer that via an HTTPS post, since if that alarm is ringing we can't necessarily rely on SMTP.
