> On Oct 3, 2017, at 5:04 AM, Daniel Margolis <[email protected]> wrote:
>
> Yes, if we are going to allow cache-control, I think we should call it out
> explicitly.
I don't like to see under-specified features in a protocol. So yes!
> But this feels a bit weird to me: we are going to say that cache-control
> headers may be honored by proxies but not by MTA clients fetching the policy
> for their own use? Why do that?
Well MTAs are not Web browsers or HTTP proxies, so they don't go around caching
HTTP content as such. They will cache MTA-STS *policies* in some appropriate
internal representation of said policies, with a cache lifetime that is no
greater
than the policy "max_age" field. Therefore, cache-control is of no possible
relevance to the MTA.
Given that the MTA is accessing an HTTPS URL, even if it were configured to use
a
(forward) HTTPS proxy to access the Web, it would use "CONNECT" to establish an
HTTPS tunnel, and so any proxy cache is typically bypassed. Only when the proxy
is doing MITM SSL interception (mints certificates for remote sites on the fly
via
a CA cert trusted by the MTA) is there a possibility of caching in the proxy,
but
I would expect that SSL MITM proxies are not really in the caching business...
So I think that cache control is simply not applicable to the MTA, and there's
no need to "prohibit" it as such.
> If someone might conceivably proxy your policy, then you really want to get
> your cache-control headers right. At which point you may as well allow MTAs
> to use them, too.
See above. I don't see how or why the MTA would use said cache-control headers.
> In any event, I believe the main argument against cache-control is merely
> that it means deployers (i.e. policy domains) have to be aware of it--they
> must consider, e.g. in section 6.3, that a policy will be valid for "last
> serve time + max age + cache ttl". This isn't especially complex, but I think
> it's the primary simplicity argument against HTTP caching.
The cache TTL should be short enough to be inconsequential by comparison with
"max age", and yet long enough to allow a reverse proxy to consolidate
closely-spaced requests. Anything more than 60s is probably counter-productive
until we start hosting SMTP server farms on Mars.
> In any event, like I said, if we want to allow cache-control, we should just
> allow it globally. It's not horrible to allow it, but we should be
> consistent. No?
See above, it is not that prohibiting processing of HTTP cache control headers
by SMTP servers was needed, but rather than this specification explicitly
overrides any such headers with "max_age", which is intended to be an explicit
part of the policy and not some out of band data managed in the HTTP server
configuration.
The explicit presence of "max_age" makes possible and *invites* the possibility
of using a shorter cache-control lifetime for use-cases like reverse proxies.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
