(I see I wrote this as a draft before going away on vacation and then didn't get back to it in the rush before Christmas sorry.
On Tue, Dec 3, 2024, at 14:35, Dave Crocker wrote: > • Second bullet: "The draft seems to include a target of 'trust > relationships' which is an open research topic that DKIM only indirectly > relates to, except for trusting a signature." Happy to drop the term "trust relationships"; it's not necessary. I have reworded to remove it in the copy on notes.ietf.org. > • Third bullet: "IETF Internet Mail handling really only covers a single > posting/delivery sequence. It touches on more elaborate sequences, but only > piecemeal. And draft charter does not really note or deal with this > difference in scope. So the proffered 'holistic' effort is a very > considerable increase in scope from something labeled DKIMbis or DKIM2" Yes, this is a considerable increase in scope - because there problem being addressed requires solutions at that wider scope. I don't believe that the reuse of the label for something which isn't exactly the same scope is a problem, we continue disagree on this point. I don't need it to have the same label, but I do believe that using the same brand will assist in understanding for end-users; since this is intended to serve the same function for them. > And later in my note: > > • "DKIM was designed to work from one posting to one delivery. It was never > intended to survive the vagaries of what can happen between a delivery and a > next posting. That it sometimes does survive is nice, but was not a design > goal. > > So what is being sought here is a very basic and very substantial increase in > scope for DKIM." > As above; yes - because there's a real problem out there for which DKIM is insufficient, and this is an attempt to cover that case. > • "DKIM does not attempt to distinguish 'legitimate' mail from mail that is > not legitimate." Yet the charter cites that as a goal. I'm happy to remove "legitimate", I agree it's wooly terminology. There's a reason why I used "attribution" initially. Basically it comes down to "there is a way to see which party generated which part of the email". Where "party" is "possessor of a private key, for which the public key is published in the DNS of a specific domain". This is true for DKIM only when the entire message is unchanged from its state when it was signed by said domain. The goal is to extend this property to the various parts of an email which contains content generated by more than one party. > • Reference to replay does not distinguish which kind is an issue, and the > only kind that has been discussed is from bad actors who are authorized users > of the abused domain. Hence the problem is, really, internal to the services > with a problem. No, that's simply not true. Any email can be sent to every email address on the planet as if it was intended to be Bcc'd to them, and there is no way for any recipient to know whether the sender did indeed intent to Bcc it to them or not. That is replay, and DKIM does nothing to help detect or mitigate it. This is a problem for everybody, and not internal to their service. > • There is reference to 'alteration by bad actors' yet to my knowledge this > has no history of discussion in the community and has not been cited as a > problem for DKIM. Sure, happy to remove the term. > • There is a vague reference to problems with error handling. Again, what > are they? I don't recall seeing a significant history of this being a > problem discussed in the email or anti-abuse community. https://en.wikipedia.org/wiki/Backscatter_(email) In particular, you can't reliably accept an email and then send a DSN later. Instead, you need to make determinations while the connection is open and reject the email at end-of-data, unless you can trust the SMTP "MAIL FROM:", which you can't do in the general case. > Further, the charter seems to confuse upgrade with replacement. Replacing an > installed base of SPF, DKIM, and DMARC usage is quite a bit more difficult > than starting fresh. Yet there is no indication that that challenge has been > factored in. > Can you propose some charter text which would indicate to your satisfaction that the challenge has been factored in? >> I do agree that some of the written description is vague at present. >> But I'd say that might well be fixed relatively quickly, either via >> a draft that sets out more of the specifics, or via the inability to >> produce such a thing, in which case the proposed WG wouldn't thrive, >> but it wouldn't be the first time that happened. > The topics they touch on have been issues for years, with no proffered > solutions that have gained any traction. Again, take that history and note > the lack of detail in their current documentation, and there is no basis for > believing that anything is going to get 'fixed relatively quickly', in spite > of how excellent the proponents are. > I don't believe the failure of previous attempts to solve a problem is a reason not to try, and there's is energy to try. I disagree that previous failures is a reason to reject proposed work. >> Personally, I'd be confident enough in the proponents to be ok with >> that draft being produced after a WG is formed, (followed by an >> adoption discussion), but I can see that others might disagree with >> that. > They have been meeting and discussing this topic for months. And yet there > is no technical detail so far. > Murray has specifically asked multiple times for technical discussion to be postponed until the chartering discussion has concluded. Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
