On Wed, Sep 07, 2016 at 06:56:53PM +0200, Daniel Margolis wrote:
> > 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
You're forgetting the DNS refresh trigger, which does not invalidate
the cached policy, but signals a need to attempt to refresh.
If the DNS policy id differs from the cached value, the client
is expected to update the policy, if it tempfails to obtain the
fresh policy, how often should it retry?
> > 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 SRV
> > 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.
I'll leave expanding on the importance of that point to John.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
