On Fri, Aug 12, 2016 at 11:16:54AM +0200, Daniel Margolis wrote:
> > > In the case of validation failures, we
> > > need to force a policy fetch to make sure we are using the latest
> > > policy.
> >
> > I think this is a waste of time. Failure will rarely be resolved
> > via a policy update. Order of magnitude or two more likely is a
> > belated replacement of an expired certificate, in which case one
> > just waits until the operator notices, a policy poll won't help.
>
> To be clear, the incentive to force a check for a new policy (via DNS, not
> HTTPS, in my preferred design) is to ensure that recipient domains can
> safely update non-expired policies without worrying about breaking
> delivery.
>
> I think you knew that, but I wanted to call it out explicitly here.
I am all for doing the DNS-triggered policy refresh, likely on
every delivery since the answer will typically come from the DNS
cache. I was commenting on refresh "on failure". I am not convinced
this warrants the suggested refresh and retry logic. I would just
queue the mail and wait for the remote operator to get his act
together and fix the problem:
* Replaces expired certificates.
* Ensures that the certificate chain contains all the required
intermediates.
* Makes sure that the private key and certificate are compatible.
* Disables anti-spam proxies that block STARTTLS.
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.
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.
If you drop refresh on failure from the spec, the state machine
gets simpler, but you still need to describe the handling of multiple
MX hosts when only some don't match the "mx" policy, or only some
fail to establish TLS or produce a trusted certificate chain with
a matching host name. Nor do you discuss which names are valid in
this context:
* Just the MX hostname
* Either the MX hostname *or* the nexthop domain name?
* (Wholly impractical at scale) Just the nexthop domain name.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
