-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <09ee9385-c706-42b8-945f-360148d3b...@dcrocker.net>, Dave Crocker <d...@dcrocker.net> writes
>A basic problem, throughout this entire discussion, has been the effort to >treat >simple relaying through MTAs, and a multiple-posting/delivering forwarding >sequence such as with mailing lists, as the same thing. > >They aren't and never have been. > >Treating them the same is a fundamental architectural change, at best The >above >language hides this reality. > >Mailing lists managers are not MTAs. Not architecturally, not as software, and >not operationally. The proposed DKIM2 design does not treat them the same ... but it recognises that there are two issues that arise when email is handled by an intermediary ... the first is that one incoming email may result in <N> outgoing emails which may or may not be the same as each other, and secondly that the intermediary may alter the email in such a way that an existing DKIM1 signature no longer validates. Note that mailing lists generally explode and alter and relayers generally do not explode and do not alter. Nevertheless some relayers will explode (to "distribution lists") and some relayers may alter (changing the Subject header field to contain [EXTERNAL] for example). Equally some mailing lists have a single subscriber and some don't break DKIM1 signatures. I don't think how a mailing list manager is implemented affects this (you could make a simple one by a suitable Exim config) so it might be an MTA after all. >> or evaluation of the content for any sort of validity or safety. > >I have no idea what providing for evaluation of the content for validity or >safety means. Nor, I believe, is there any widespread history of discussion >of >that, in those terms. > >I suggest breaking this point out and writing something very different, to set >up the concern. (I don't understand the am not sufficiently clear about what >is >intended here to be able to draft possible wording.) This part of the charter is I assume meant to put assessing the safety of an intermediaries change out of scope -- the proposed DKIM2 design merely records what the change was and provides a robust way of knowing which entity made it (so that one might hang some reputation on that entity in an out-of-scope manner). >> Still, there exist known shortcomings in the email model that DKIM >> alone is not designed to address, including the following: > >There are additional needs. They are new. Or, at least, they were not >previously a priority. Since they were not needs when DKIM was developed, >they >are not 'shortcomings'. they may not have been perceived to be shortcomings then -- they are now, which is why a number of people wish to improve things for the people whose email they handle >> The working group will observe the success of current technologies, >> primarily DKIM, reusing its techniques where applicable, to develop a >> new technology suite that seeks to address these concerns. Early >> experience from the deployment of ARC [RFC 8617] will also be >> considered. In particular, this technology will: > >Rather: > > The working group will pursue incremental enhancements to DKIM > and/or DKIM use, where possible. It will pursue parallel or > replacement mechanisms only where incremental change is not feasible. this is recipe for spending a considerable amount of time arguing about exotic changes to existing fields and will result in complex and hard to maintain code that has to handle two (or more) interpretations of header fields in parallel. This heats up the planet to no purpose (let alone heating up the tempers of WG participants) if the engineers (including myself) who have been debating these issues (for most of a year now) thought that simple mods to DKIM1 were a good way forward that is what we would have proposed. >> * Provide stronger assurances against unauthorized use of the >> (envelope) sender, reducing the success of direct domain name misuse >> and improving the value of delivery status notifications; > >The concept of authorized use of the Mail From exists in SPF and nowhere else. > >As such, the premise of this objective is problematic. I think the text in the charter is meant to nod towards the DKIM2 notion that DSNs should not be sent to the envelope sender but "back along the chain" and hence various mangling of MAIL FROM that is used to direct DSNs to an appropriate entity will no longer be required >> * Identify message mutations made by any handling agent; and > >I suspect this means identification of common mutations, rather than all >mutations, since there is no limit to the latter. This text needs elaboration, >for clarity and precision. I didn't think "clarity and precision" were required for a charter, merely an indication of what was or was not in scope. Identifying all mutations is clearly in scope ... being able to "undo" them may be too complicated to consider (and self-defeating --- an intermediary that redacts sensitive information or removes malicious attachments will not wish a recipient to be able to undo their changes) >> The working group will strongly prefer output that, when deployed, >> does not disturb the deployed ecosystem. > >Given the presumption of DKIM replacement, this sentence is surprising. With >the incremental approach I'm advocating, it might be reasonable to retain. > >> It may, however, through the normal course of evolution, replace >> technologies such as DKIM and ARC. > >The draft specification this work is currently based on requires replacement. you can DKIM1 and DKIM2 sign in parallel if you wish (and SPF will continue to be "a thing" whilst there is continued toleration of dumb devices such as security cameras sending direct to a destination mailbox). In the fullness of time, I doubt that larger mailbox providers will care much about the DKIM1 signature and it may be that security cameras cannot be configured as they are today. - -- 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/AwUBZ5Uo/2HfC/FfW545EQJKowCgtrOyTJs5u/uPj8u47osFx34tjDkAnA53 epA6DU/xrMMOZz/KsuYRPbOA =Yw3s -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
