On Wed, Sep 7, 2016 at 4:57 PM, Viktor Dukhovni <[email protected]> wrote:
> If 404 is a soft fail, and maxage=0 is revocation, what should a sending > MTA > do when it encounters a 404 (or indeed an HTTPS connection timeout, > handshake > failure, ...)? Retry the HTTPS policy lookup on every delivery? Employ > some > sort of hold-down timer between soft-failed lookups? How should the > hold-down > be chosen? > My point was that a 404 could be treated the same as a DNS lookup failure. Admittedly, it need not be so; 404s are of course signed implicitly if delivered over HTTPS. But because of the operational concerns I outlined, I had thought it made more sense to treat them however we treat DNS resolution failures. (In particular, I believe we specify that if a new, valid policy cannot be found, the cached policy should be used. So in the case of a 404 we would temp-fail and so forth.) > My preference is to not have to hammer away at broken or misconfigured the > HTTPS servers with every message delivery, that can have a big effect on > SMTP > delivery latency and thereby throughput. > The only time it results in that is also if the cached policy is invalid. That is to say, the possibilities are: Sender has cached policy: Y/N Cached policy validates the MX: Y/N If the above is Y/Y, the sender can merely deliver. If the above is Y/N, the sender should not deliver. If the above is N/_, the sender can deliver, same as for any other domain missing a policy. Regardless of the result of a new policy fetch, that applies (so long as the cached policy is not expired). No? > Returning to John Levine's suggestion of SRV records, what should the > reference > identifier (and SNI value) be in that case? If it is the SRC record > target host, > should any sub-domain (at any depth) of the nexthop domain be admissible > if that > becomes the reference identifier? Or must the target host present a > certificate > that exactly matches the original service (nexthop) domain? > > I think some language that nails this down is needed in the spec. Please > discuss. > Well, only if we go with SRV records. Which (as you describe) seems to expand the complexity slightly. I think this can (of course) be done without any security misses, but I'm not sure it's preferable to the hardcoded hostname. That said, I don't want to poo-poo anyone's ideas of a nice zonefile. ;) Maybe we should bite the bullet and use SRV, but I'd like to hear some strong consensus for that before I try to write the language for it. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
