4 ms·
"Cache" term in MTA-STS is misleading. Standard encourages to fetch new policy even before expiration of cached copy. If you have some cached policy and "id" is
by Snawoot 7y ago
"Cache" term in MTA-STS is misleading. Standard encourages to fetch new policy even before expiration of cached copy. If you have some cached policy and "id" is not updated since then, you may skip actual request to policy server via HTTPS.
In MTA-STS "cache" is more like fallback minimum known to sending party.
- lvh 7y agoBut why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?
- Snawoot 7y agoRFC 8461 Section 3 states: "These TXT records additionally contain a policy "id" field, allowing Sending MTAs to check that a cached policy is still current without performing an HTTPS request." So, yes, it is "skip that HTTP request". Despite HTTP(S) has caching rules defined, they are just different from "caching" logic incorporated in MTA-STS. Key differences are: 1. Sending party ought to update MTA-STS policy for recipient domain far before it expires. 2. Sending party can check if policy is still actual without direct contact with policy server by mean of retrieving id in TXT record. That significantly reduces amount of requests policy server has to serve in order to keep all senders up to date with its latest STS policy. Normally, HTTPS requests occur only once from each sender per policy version. 3. Sending party must reuse cached policy if STS policy of recipient suddenly disappeared without trace or failed to fetch for other reasons. In a nut shell, "cache" and "max-age" in MTA-STS has different interpretation than in HTTPS and require some additional (obscure) logic for processing.