On Fri, Aug 12, 2016 at 5:24 PM, Viktor Dukhovni <[email protected]> wrote:
> Delivery disruption that's due to stale policy is IMHO far less > likely to be the cause of problems, and so doing synchronous HTTPS > refresh and retry is I think too much complexity and latency for > too little gain. I'd like to see that part of the suggested state > machine go away. > I don't think this is incompatible with what you say. Refreshing doesn't have to be synchronous from the sending MTA's perspective; it just has to happen before the message is perm-failed. Your suggested implementation seems to be: 1. Temp fail the message. 2. Check for policy refreshes on every delivery. That has the same properties as the "synchronous" implementation. So I think we can change the language here, but I do think it's important that perm failures are not generated from stale policies. That said, if we check the DNS record on every send, stale policies run very little chance of being the cause of failures since recipients are unlikely to break their cached policies within the difference between time-of-policy-check and time-of-delivery-attempt, so this may be superfluous if we explicitly require a check of the TXT record before delivery (which we don't right now). So in short, I think we can either (or both) a) *require* a check of the TXT record before send (totally reasonable) or b) require at least one check before a perm fail. > > Incidentally, issue "72" on Github completely misses the boat on > extending the state machine to describe the behaviour for multiple > *receiving* MX hosts. There's some needless discussion of cache > coherence (state sharing) among multiple sending hosts, but no > discussion of how the sender state machine interacts with multiple > remote MX hosts. > Yes, I think that's a separate discussion. I think one of the points in https://github.com/mrisher/smtp-sts/issues/85, but I haven't looked in detail yet.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
