-----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. - -=-=-=-=-=-=-=-=-=-=-=-=- >> Ad hoc systems have been developed so that systems that have placed a >> DKIM signature onto an email may be informed about the quality of the >> messages that they are relaying -- so called feedback loops. >> However, there are no formal specifications for such schemes and >> feedback may be sent where it is not actually required. > > *A DKIM feedback loop seems to be a separate work item, a la DMARC. > In general, I'd encourage making the text distinguish different > goals and tasks more carefully. * > >As noted in postings by others, there is some community practice established >here, so this is a specific task for which it well might be possible to >document >and agree on a particular scheme that scales. If you are suggesting that feedback loops should be incorporated into a separate document then I don't think that is going to be very useful since would of necessity spend most of its text referring elsewhere. The Goal is of course, to standardise a robust and privacy observing method of providing feedback loops; the Task is to document how that is done and what aspects need careful thought by implementers. >> Furthermore, where the origin of a message has been forged and the >> final intermediary in a chain finds that it is undeliverable, then >> the Delivery Status Notification (DSN) may be sent to an unsuspecting >> third-party -- a phenomenon called backscatter. > >Given the regular misuse of the term forged, I strongly suggest using a >different term or, at least, defining its use here. Here we mean "misrepresented" ... I don't think that this warrants a lot of editing at this time since the aim was to briefly remind people what backscatter might be. As documents progress then of course clarity is important, but that often increases their length considerably and reduces their readership >For that matter, >specificity about 'the origin' would also help, given that it, too, can >translate into different technical specifics. > >Apparently, 'origin' here means the SMTP Mail From. Since it has never had >any >requirement about what address is in there -- other than SPF and DMARC when it >is using SPF -- forged is simply a false assertion. > >Also, in spite of the name Mail From and the RFC 821(etc.) language about it, >its actual usage has always been as a return address, rather than as a >declaration of authorship. A role assigned to the RFC822/733 From: field. This in my view is an irrelevant point. Backscatter is not disliked because people are outraged that they are accused of authoring something - -- it is disliked because of the clutter in the inbox (and many recipients are likely to be completely unaware of the mechanisms that has caused the DSNs to appear). > *This is not a small point. The ability to specify a return (ie, > handling notification) address that differs from the author has been > an important bit of flexibility for email.* I do not believe that anything in our DKIM2 design changes that - -- 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/l0ImHfC/FfW545EQLI5wCg3au0VoLfPI0aTDZr79Fh6GDBMQwAn3Xf wMD7Wr47SMUFL+Uw7E9eiiq3 =FS02 -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
