-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
.PROD.OUTLOOK.COM>, Tobias Herkula <[email protected]
.org> writes
> One more observation from my reading of the draft.
>
> I noticed that I couldn't find any guidance on introducing DKIM2
> for messages originating from systems that are not DKIM2-aware.
that would not belong in the spec document but in Todd's BCP document
> The draft appears to assume that the trust chain starts at the
> originator, which intuitively seems like the cleaner model to me.
> However, I could also imagine deployments where the first
> DKIM2-capable MTA attempts to introduce an existing message into
> the DKIM2 ecosystem.
in general that would be unwise ... if there is a DKIM replay event and
you are the first DKIM2 signer then DKIM2-aware recipients will identify
your system as the source of the replay and ding your reputation
accordingly
if you are a mailing list then there is something to be gained from
DKIM2 signing -- yes your reputation can be dinged, but at least the way
in which DSNs are handled means that you will become aware of the event
(and because you have declared that you are exploding mail, then various
heuristics may be more tolerant)
so unless you are operating a submission server or a mailing list I
cannot see much upside to DKIM2 signing messages that you are just
blindly forwarding. It will not make much difference to their
deliverability in either the short term (when DKIM2 is rare and DKIM1
will be acceptable) or the long term (when DKIM2 is common and the
presence of DKIM1 will not make the message any more likely to be
delivered at all)
> If such a deployment is not intended, I think it might be worth
> stating that explicitly. If it is intended, I would have expected
> the draft to discuss the associated trust semantics and what
> exactly the first DKIM2 signature is asserting in that situation.
DKIM2 signatures can only ever assert that a system has seen the email
(headers) and have access to a private key whose public key is published
by the signing domain. Everything else (especially the "trust" word) is
people's fertile imagination about what those two things might imply
about the systems involved.
> I'm not advocating for introducing this capability—in fact, my
> expectation was that the trust chain should begin with the
> originator. I was simply surprised that I couldn't find any text
> confirming or rejecting this deployment model.
There should certainly be a discussion of the topic in the BCP document.
When I next get some copious free time I will contribute some text
- --
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/AwUBaljxJ2HfC/FfW545EQLuFgCdHLagWyGnHb0x3ho1lbtuN8Tbx4MAn09A
QBJjtYxFD1+v1i93GJr7uEV+
=+FS4
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
