Subject: Re: [Uta] MTA STS and HTTPS fetch timeouts

From: Daniel Margolis <[email-masked]>
Date: Sat, 1 Oct 2016 16:33:58 +0200

Fair point on the pseudocode. My point wasn't so much that it's not useful
as that it's hard and I have to carve out some time to sit down and try to
do a better job of it. ;)

Regarding 3.2, I think you're misinterpreting (due to, as I think Stephen
pointed out, a misuse of the "MAY" terminology and general lack of clarity
in this section). The point of 3.2. isn't that senders must be aware of the
DNS TTL; it's that senders are only aware of the policy expiration
("max_age") and thus *receivers* should be cognizant of the fact that from
a sender perspective, a policy may be valid for "ttl + max_age". Senders
*don't* know the TTL in this formulation, but they (or their resolvers) do
honor it.

I believe this is clearer in the version in Github, however:

   Updating the policy requires that the owner make changes in two
>    places: the "_mta_sts" TXT record in the Policy Domain's DNS zone and
>    at the corresponding HTTPS endpoint.  In the case where the HTTPS
>    endpoint has been updated but the TXT record has not been, senders
>    will not know there is a new policy released and may thus continue to
>    use old, previously cached versions.  Recipients should thus expect a
>    policy will continue to be used by senders until both the HTTPS and
>    TXT endpoints are updated and the TXT record's TTL has passed.

Let me know if that doesn't make it more clear. But tl;dr: senders do not
need to know the DNS TTL.

On Wed, Sep 28, 2016 at 7:30 PM, Ned Freed <[email-masked]> wrote:

> > (Sorry for the late reply. I was on vacation.)
>
> > As Janet said, thanks for the feedback. A few specific points:
>
> > 1. Agreed on the psuedocode. I had actually removed it entirely from the
> > latest draft in the Git repo (github.com/mrisher/smtp-sts) because I
> also
> > didn't find it to be of much value.
>
> Actually, there's no agreement here whatsoever since I regard simply
> removing
> the pseudocode as the worst thing you could possibly do.
>
> > I do agree with you and Viktor that
> > fleshing out a hypothetical implementation can make things a lot easier
> for
> > implementors, but doing so in a way that is sufficiently specific to be a
> > useful guide yet sufficiently generic as to be applicable in most cases
> > isn't trivial.
>
> Did you take a look at the code I came up with? I don't believe there
> was anything in it that made it specific to any particular implementation.
>
> > I had punted on this in the current version in head because
> > I didn't have a great idea of how to express this--as Viktor notes,
> > diagramming the state machine may in some form be helpful; I'm not 100%
> > sure pseudocode is in fact the right way to do it. Thoughts?
>
> I could not care less about the format you use. But the fact is right now
> you
> have a document that defines a process consisting of a precise series of
> steps
> which presents those steps out of order and which, without some
> psuedocode, a
> flowchart, an outline, whatever to tie it all together is pretty much
> guaranteed not to be implemented correctly.
>
> > 2. In what case is DNS TTL information needed?
>
> Section 3.2, first paragraph. There's also been discussion of making more
> use of DNS TTL info on the list.
>
>                                 Ned
>

---

From: [email-masked]
Date: Mon, 03 Oct 2016 09:28:42 -0700 (PDT)

> need to know the DNS TTL.

This is much clearer, and addresses my concern.

				Ned