-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At the end of January Dave Crocker posted a review of the then current
"-01" version of draft-gondwana-dkim2-motivation. This document has now
been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over
14 (sorry) emails... ">>" is a quote from our document, ">" a quote from
Dave Crocker ... lines that do not start with a ">" are me speaking.
- -=-=-=-=-=-=-=-=-=-=-=-=-
>> 8. DKIM1/DKIM2 Interworking
>
> *There is no interworking, These are entirely independent and
> parallel systems.*
>
> *This section should be written without reference to DKIM and only
> in terms of incremental adoption and handling of non-support.*
we agreed -- and the headers-00 document now has a section on
"Handling of messages that leave the DKIM2 ecosystem"
>> Note that DKIM2 signed email can also be DKIM1 signed, and so systems
>> that are not DKIM2 aware can and will operate as they do at present.
>>
>> DKIM2 capable servers will announce the capability in their initial
>> banner in the usual manner for SMTP extensions.
>
>What effect does the SMTP server's making the announcement have? What
>difference
>does it make?
this is an area where our thinking continues to evolve ...
We originally thought it would be valuable for a DKIM2-aware system to
know that it was about to pass an email to an non-DKIM2-aware system.
For example, this could be recorded in such a way that a later
DKIM2-aware system could inspect the message and if it had not been
"damaged" by it's trip outside the DKIM2-ecosystem then things could
pick up where they left off.
However, this introduces a lot of complexity so we don't think it would
be super-useful. There are also some ideas about declaring
DKIM2-awareness in the DNS ... but this then opens up further complexity
when the DNS is out of step with the capabilities of servers.
>DKIM is able to be implemented only in MUAs and does not require any
>infrastructure support, though of course it is permitted. DKIM2 apparently
>requires deep infrastructure support at every hop along the way. That makes
>it
>extremely fragile.
>
>
>
>> When a DKIM2 signed email is delivered to a server that does not
>> understand DKIM2 and leaves the DKIM2 ecosystem the DKIM2 specific
>> events can no longer be expected to occur. In particular any
>> failures to be deliver will be reported to the address in the
>> relevant return path and not back along the DKIM2 chain.
>>
>> A DKIM2 signed email may be delivered to a server that understands
>> DKIM2 but if that server needs to forward the email elsewhere it may
>> find that there is no signing key available for the relevant domain
>> (recalling that the incoming email recorded the destination domain
>> and it is necessary for the next "hop" to match with that. In such a
>> case, once more the email will leave the DKIM2 ecosystem.
>
>I don't understand. What signing key that it might not find? Signing for what?
>
>
>> Refusing to allow an email to leave the DKIM2 ecosystem may be an
>> appropriate choice in some circumstances. If so then an appropriate
>> DSN should be created and passed back along the chain in the normal
>> manner.
>
>Tossing this comment out, with no basis, detail, or precedent, is odd and
>probably not very helpful, since it ultimately is a vote for making email even
>more restrictive. Limiting who mail can go to is a tad counter-productive.
I am not replying to the rest of these points since they are overtaken
by events.
Our latest thoughts are in the header-00 document, but there is still
more work to be done (and documented) here.
- -=-=-=-=-=-=-=-=-=-=-=-=-
and that was the end of Dave Crocker's original email. So my task is
done (for the moment at least)
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA+AwUBZ/l142HfC/FfW545EQIC4wCgoGv1I/jDvaWHiWIRzXKV7wp/v14Al2te
4+M17dm0QuMnNTpfyK8VhY0=
=fFYY
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
