On 11/20/24 12:03, Richard Clayton wrote:
In message <[email protected]>, Steven M
Jones <[email protected]> writes
> If I follow this, the use case is a Secure Email Gateway or SEG, to
use a
> Gartner-ism, and is likely the last hop before delivery to the
recipient ADMD or
> mailstore. So why is DKIM2's "it's complicated" flag more useful
here than the
> configured exception for the service or gateway the receiving ADMD
contracted
> with?
it means that if the message, for whatever reason, reaches another DKIM2
system it is possible to determine that the gateway intentionally
changed the message ... (and hence local policy is going to have to kick
in to decide what to do with a failing signature) otherwise one might
conclude that the failure of every preceding signature was some other
systems failure to look after the message properly -- and it might be
that a DSN was speciously generated (depending on the exact chain of
custody)
So the proposition is that we would universally apply DKIM2 at the SEG
and verify again at the recipient ADMD/mailstore, so that if X% of
messages are forwarded or otherwise escape, they could be checked with
DKIM2 at the downstream hops, and not have to be treated as ever having
left the DKIM2 world, which... would mean just handling it as they do
today, right? Once you've left DKIM2, you fallback to the old ways of
doing things.
I thought we were looking at a not-uncommon enterprise situation where
we have an adequate trust mechanism in place today without much
forwarding, and we're going to impose a lot of overhead for what looked
like not much benefit. But are we more thinking of large mailbox
providers like mobile telcos using SEGs/services, with massive
forwarding populations, and we're focused on their downstream impacts?
--S.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
