-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
>>> How do you propose to do that? and which of the aims of this working
>>> group will you ignore as you proceed?
>
>None of them and the how follows directly.
>
>The transition is handled by not rejecting good mail on a failure whose
>cause cannot be determined.
OK ... that's "local policy" ... go ahead
> When b= verifies, the signing node's
>signature is genuine and its own declaration is not in question.
There is no b= in DKIM2 ... I assume you mean the body hash in the i=1
Message-Instance field is still correct.
> But
>content outside that guarantee can still change.
By which I assume you mean all of the header fields and the Chain of
Custody ...
> In that case the
>verifier cannot tell a non-participating legacy node from an attacker
>exploiting the same absence.
correct
>This is where it differs from ARC and answers the trust objection raised
>earlier. I am not asserting the hop was good. I am recording that
>something failed and that its cause cannot be determined. There is no
>assertion to trust: a node attests to the outcome of its own
>verification, not to what happened upstream, and claims nothing about
>prior state. Attestation of flow, not reconstruction of it.
Provided that you do not send the message to strangers then this is all
fine ... you can accept any email you wish.
If you do send the email to someone else with a broken Chain of Custody
then the DKIM2 spec says that it should be rejected. If you say that it
should be accepted then DKIM2 becomes useless, so don't do that.
>The mechanism does not remove replay protection;
It will:
... at present at $DAYJOB$ see significant amounts of email sent from
InvoiceCompany where the invoice says "congratulations on purchasing you
iPhone, any issues call 01-555-123456". This is a genuine email from
InvoiceCompany who has unwisely allowed BadPerson to sign up to their
invoice issuing service.
You cannot reject email as a replay on body contents hashes alone; you
will end up rejecting lots of perfectly good email that is sent in bulk
without personalisation (DKIM2 will not do that because of the Chain or
Custody and the documentation of the SMTP protocol parameters).
BUT by all means have a local policy with your own heuristics for replay
detection; and by all means explain in the BCP why some local policies
may make sense to some receivers. Just don't insist that any else adopt
such policies.
- --
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/AwUBapRQ9WHfC/FfW545EQIBPACffKgWSn+9mLzaD/tgxF/kB5zLx2EAnjXC
NIHl9WbC5ln+9/rCZSnFc6HK
=J+yl
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
