3 ms·

Thing I don't understand about the MTA-STS spec and glossed over until someone pointed it out to me: there's both an `id` in the DNS record (which is supposed t

by lvh 8y ago

Thing I don't understand about the MTA-STS spec and glossed over until someone pointed it out to me: there's both an `id` in the DNS record (which is supposed to refer to the specific policy uniquely, but can be anything e.g. a hash or an incrementing identifier) _and_ the policy itself has a max_age. I don't quite understand why the max_age itself isn't sufficient, since that does expiry anyway? (The stated reason is preventing an HTTPS lookup, but HTTP already has a fine cache mechanism so that sounds like a potential false economy.)

Snawoot 8y 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 8y ago
  But why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?
  - Snawoot 8y ago
    RFC 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.

by lvh 8y ago

Snawoot 8y 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 8y ago
But why have that mechanism when HTTP already has a caching mechanism? Is it really "skip that HTTP request"?
- Snawoot 8y ago
  RFC 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.