On Wed, Dec 14, 2016 at 03:38:20PM -0500, Viktor Dukhovni wrote:
>
> > On Dec 14, 2016, at 3:20 PM, Alberto Bertogli <[email protected]>
> > wrote:
> >
> >
> > As I see it, going HTTPS-only now in the interest of increasing adoption
> > and aiming at making it easier to extend the policy in the future is a
> > better tradeoff than going with DNS now and having to tweak/change it
> > later when expansions appear.
>
> I would not support implementation in Postfix of a protocol that causes
> the SMTP client to trigger unsolicited HTTPS probes for all destination
> domains.
I think this is totally reasonable, but not exactly what I'm proposing :)
> The proposed DNS probe is cheap and cached by the local resolver.
> HTTPS probes are then only initiated for domains that publish a new policy
> ID (or whose cached policy is sufficiently near expiration).
>
> The proposed DNS record can also be used to expedite policy refresh without
> requiring frequent HTTPS polling. I'd like to see the DNS record retained,
But using HTTPS only has the same polling frequency. The MTA doesn't
need to trigger the probe any more often than with the current proposal.
MTAs would do _less_ probing, as with HTTPS only there would be a window
of time without any probing at all, while in the current proposal you do
a DNS lookup to see if the policy has changed.
On domains without a published policy, it's exactly the same cost (a
single failed DNS lookup).
<longer explanation of the above>
The first time the MTA sends an email to a domain, it would do a DNS A
lookup for _mta-sts.domain. If the domain does not exist, there's no
published policy and there's nothing else to do.
This is equivalent to the current proposal (A lookup vs TXT lookup).
Then, an HTTPS request is made to fetch the policy. Alongside the
contents of the policy (unchanged from the draft), you get a max-age and
max-stale parameters which control caching.
MTA then caches the policy (unchanged from draft).
- MTA can use the policy without probing or checking anything until
max-age.
- Note max-age could be taken from the policy contents as in today's
draft, or from the HTTPS headers.
- After max-age, the policy has to be fetched again.
So in both the draft and my HTTPS-only proposal you only need to do a
single HTTPS probe every max-age.
The difference is that in the current draft you need to do DNS-only
checks for every email on top of that.
</>
I hope this clarifies!
> and would recommend avoiding an over-engineered kitchen-sink policy mechanism.
I don't know what this refers to, as the policy itself would not be
changed (and if anything the RFC would be shorter). Can you elaborate?
Thanks!
Alberto
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
