Inveigle.net wrote in <[email protected]>: |On 25/07/2026 3:13 am, Steffen Nurpmeso wrote:Steffen Nurpmeso wrote in |> <20260722225956.YiFNSrni@steffen%sdaoden.eu>: |>|It does not change anything really, it actually addresses problems |>|already pointed out in RFC 6376, the DKIM that is now known. |>|(Backscatter bounces, and message replay. Good that this is |>|addressed, yes.) |>| |>|In order to do that it dramatically changes SMTP. |>|That effectively becomes single-recipient. |>|How can a simple (though cryptographic) helper dare to mutilate |>|its base protocol like this? |>|What a massive transaction overhead! Unbelievable!! | |Agreed. None of these problems are shortcomings of DKIM as it was never |intended to address them, however, all can be easily addressed by |extending DKIM as it exists now, without mutilating SMTP.
For sure. |It's only change tracking and the chain of custody (which isn't |necessary to prevent backscatter) that necessitate extensive protocol |changes. That functionality would be solely for the benefit of larger |scale receivers and at the expense of established DKIM behaviour. The |benefits to the majority or e-mail users can, and should be, achieved |through less invasive means. I do not follow terms and speech. To me it seems that over the last decade or so the heads have been fixated on certain solutions. I recall Mr. Kucherawy mentioning a draft of him which wanted to place Bcc in the signature. This (i was not listening to dkim by then) did not fly, it very likely would have ended up single recipient for obvious reasons. And .. in this spirit, whereas the security people even think about making anything anonymous aka hidden, these here want to have a completely revealed envelope from first author to final destination, and all in permanent storage. For whom this is good, two people, three opinions. But definitely not for the subjects along the way. |>|Unfortunately the email part of the IETF only has balls to create |>|barriers and distress for administrators and email users, but not |>|for creating a slim, efficient and practicable solution to fix the |>|mess they themselves have created. | |The scope of this Working Group permits them to recommend a solution .. is to create an iterated DKIM. |that addresses this ongoing issue, although I feel they have gone off |track by focusing on an ARC replacement. | |The tidiest solution IMO is to bite the bullet and insist on strict |alignment from the sender to receiver. This eliminates the need for SPF, |DMARC (except possibly for reporting), and IP reputation filtering |except under extreme circumstances, such as a large scale leak of |private keys by an ESP. Far from being a significant imposition, this |would deliverer the greatest benefits senders, many of whom are |struggling with deliverability and being forced down the path of using |ESPs or hosting services out of necessity. Or, to turn this around (and my english .. sorry). In the 80s with all the groups and all academics. Almost ditto the 90s. Then transport layer security became a thing, and spam began to be the majority of it all. But today, where practically anything is encrypted transport layer wise, in practice, and "best common practice" etc etc etc. There it is an anachronism to require users, or their providers, because most of the users just cannot even define their own policy, to create DNS records (DMARC), in order to ensure (or "request") that emails that are modified along the way are mitigated. (Effectively.) That is to say. I wonder if they understand, because from Google, for example, help, they surely do not learn, and noone else told them. Thus yes, i would, to say it in my words, require emails to be either unchanged, or explicitly and always mitigated, and immediately identifiably so. Where "mitigated" means that if i change something, i practically take the ownership, and make that visible to anyone down the path. And if you do that everything you say on DMARC and more is true. By the way that, as i remember it, this approach can really be seen in spirit of RFC 3461. |Only mailing lists where true continuation of transit is permissible |would be affected. The realities of the modern Internet mean few such |lists would exist these days. The expectations of RFC 5321 are clear. |You don't 'fix' SMTP to accommodate broken software. My english, i think i do not really understand what you are saying. (To me SMTP is out of scope. It just works, as always. And that means, pipelined and with as many recipients as possible, without data duplication.) |Forwarders would be able to comply by simply switching to MIME |encapsulation, wrapping the original e-mail in a message/rfc822 |container, as defined in RFC 1341. Going for encapsulation is a good thing, yes. But, sorry, for one i know, granted fewest, people which use mailers without MIME capability. (Quite a bit more which use mailers with MIME capabilities, but which do not decode RFC 2047 and such, deliberately.) And i tried it for mailing-lists, but it was a total no-go by then. Maybe things have changed for Apple Mail, and GMail, in the meantime, i would have to make a survey again, after so many years. However the security guys just recently pushed forward this "unobtrusive signatures" draft, because many seem, and they made a survey then, did they, still do not support even PGP and S/MIME stuff well. Which does not make me optimistic for entire message/rfc822 attachments, and all that. Here one could of course start thinking again, why so many people in this WG seem to be keen to do certain things the way they do, for so many years, now with the cumulation of so many bad ideas in one things they will get through, as i see it. Given their employers, which have problems with these other things. Or their governments, in the end. Yes. One could start thinking about that. I agree that MIME encapsulation would be nice, for mailing lists, and some other things which modify the message. (Like these legal footers of companies, or headers and footers, and all that.) Things like the beaten-to-death URL rewriter, and such, there you surely will not get an attachment with the original stuff. So two people three opinions. The draft i wrote and will get one more iteration (i added "U" flag to allow one hop to define the next is allowed to modify the document without applying mitigations; as of today, however, this will not do because of DMARC for example, the way it is; and some) does not fiddle with MIME, it only acts on the main header of an email message. And then, one more. You know the email standard for message/rfc822 does have a technical failure, which actually makes its use impossible at times? The problem is that RFC 2046 says that such an attachment can only be 7bit, 8bit or binary encoding (whatever that binary encoding actually is). Yes, it was naively thinking the original message must be correctly encoded, but what if it is not? And you will find messages with ^From_ and other problems that *will* cause problems for certain people, unless you *do* encode them to something better. So then you *do* have to modify the original message, breaking it. Yes, many of the non-absolute-core-SMTP standards are bad, or worse. This *must* have something to do with how they were written, and by whom. Right. Not that i am any better, mind you. Lots of errors, everywhere, and all the time. Those old standards are, however, in my opinion, galaxies better than anything these people here did in the last decade and a bit. The only option would be to define a new attachment type, or do allow content-transfer-encoding for them. I will use text/plain, and an .eml filename, so that this is not lost. Greetings, and a nice Sunday i wish. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
