-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
.PROD.OUTLOOK.COM>, MCN-IETF <[email protected]> writes
>there is one point about null recipes that I am still trying to understand.
>I think I understand and agree with the principle that a null recipe should
>only
>be acceptable where there is a pre-established trust relationship with the
>eventual recipient, and that otherwise losing the ability to reconstruct the
>previous message state should result in significantly lower trust.
correct ... in fact, you might not wish to receive the email at all
>What I am less clear about is how the receiver is expected to establish that
>relationship in practice.
we envisage the MTA being provided with an "allowlist" that specifies
the relevant signing keys
>For example, if a security gateway directly operated by, or explicitly
>configured for, the receiving ADMD uses a null recipe, the answer seems
>relatively straightforward: the receiver already knows that this particular
>signer is trusted to perform destructive content filtering.
exactly so (you could also configure an "allowlist" of relevant sending
IP addresses)
>But what happens if the null recipe appears at an earlier point in the DKIM2
>chain?
then the receiver will have no reason to trust that the modification is
legitimate
>A valid DKIM2 signature can authenticate which signer performed the
>modification, but it does not seem, by itself, to establish that this signer
>was
>authorized to make a destructive modification and discard the evidence needed
>to
>reconstruct the previous state.
correct ... now you could flag this up to a human who could make a
decision like "ah, AlmaMater University has deployed a security gateway
on their system, I picked their quarterback for my fantasy team, I will
add them to my allowlist" (humans make decisions like that).
Failing that you could reject the email, or put it into quarantine, or
decorate it with lots of end-user warnings. Your system, your choice.
>So is the expectation that null recipes should effectively only be accepted
>from
>signers explicitly configured as trusted by the receiving ADMD, or could there
>perhaps be a mechanism for establishing that authorization?
I don't see that any other decision is likely to withstand scrutiny when
something bad has just happened to you.
BTW: if the security gateway is at the edge of the original sending
organisation then it should not be generating null recipes, but it
should instead have a copy of the organisations keys and be signing the
email on their behalf at i=1
That is, if it is altering the outgoing email at all rather than
blocking it.
I really dislike people who send you mail saying "this was for you, but
it contained bad things so I removed them and sent you this bowdlerised
version").
Anyway, the edge gateway may not be filtering, it may be adding
disclaimers or similar; and though you could use recipes to document
that, its probably simpler for most sites to create the i=1 version of
the document after that type of change has been made.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaqs6emHfC/FfW545EQI0vwCfZ3Q/pk0mCgYTNtSKKrB05jno9PMAoP1n
KIq6yN+G8CFBH2oH8mxTPN5O
=AeXf
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
