Murray S. Kucherawy wrote in <cal0qlwyq2mwoo7wmagj6n5sjww-utw509ehzhu8mgxndun8...@mail.gmail.com>: |On Sat, Aug 17, 2024 at 3:05 PM Steffen Nurpmeso <[email protected]> \ |wrote: |> Since then myriads of possibilities have been added to generate |> "more identification value" of an email's source, even "over the |> corner", and what not. | |Myriads? Which ones are those?
ARC, DMARC, SPF. NOTE: we are talking about tremendous burden for private and small company MTA and mailing-list providers. (The SRS that is effectively needed for many due to SPF not even mentioned so far.) |>|indirect mail flows. I think you'd need to address those as well. Do |> you |>|have something in mind? |> |> I must admit i currently do not know what you are talking about. | |You said you've read RFC 6377, so I think you probably do because it lays |out the problem I'm talking about. Fine. |> If a message has been altered, all bets are off. |> This is a tremendous failure of the IETF and those giants which do |> it the way they do it. | |I can't follow this line of argument. | |> In my humble opinion the solution is |> |> - announce this change in the DKIM signature via a new, backward- |> compatible flag | |I don't understand this flag. What information is this giving to end |users? Will they understand it? Why should they trust it? - The message was modified *here*. Verifying elder DKIM signatures (shall they remain; elder means down the header stack) *will* fail. - When adapted, yes. Otherwise it does not matter, because the situation effectively did not change for them. (They just keep on wasting DNS and processing ressources, like they do now.) - Because it part of the DKIM signature which' verification will succeed. No? |If you hand the spam community a trusted way to say "please forgive the |fact that this message does not bear a valid author domain signature", I |assure you they will use it. Hm, i do not know how you come to this conclusion. This is not what happens. Or -- you do refer to the IETF mailing-lists, which were shamelessly hacked to *not* change the RFC5322.From *even though* they *do change* the message, *forcefully* causing breakage of *any DKIM verifier* of *any receiver*. This is indeed such a tremendous absurdity, yes, i do not exaggerate when i say it is an obscenity, that is like slapping an uncounted number of private and small-company mailing-list operators openly into the face. I cannot count what trouble even experienced people had with all that shit that the IETF has produced in the past, even the internet history list with those people on that invented the internet and more (way too many american military therein that only want to hear shiny happy people, but that aside), over years, again and again. TUHS for the UNIX people went sofar to provide a split option even, one with From rewriting and with continued message footer and Subject: tagging, and one without, where the message remains unchanged, and therefore DKIM will not break. *That* would have been an option for the IETF, like the very friendly price winning dear Warren Toomey! Instead the IETF (seems to) look(s) for a receiver's DMARC record, and if there is none (why again should *i* provide a DMARC DNS entry???) and if there is one there is a very smart solution regarding dmarc. addresses, but if not, and now *hold me back*, they *forcefully break* DKIM signatures and cause all receivers to walk over garbage! I mean, sorry, what.the.heck.is.that?? So yes, i can assure you they will use it. So "why should they trust it"? That is a good question given that the IETF itself turns DKIM signature verification into a marginal thing that in the western world ends up flowing down in the toilet with lots of water thereover?? *That* is the question. I vote for a total *restart*. I copy this message to art@. I do not know what is going on in the IETF that protocols like POP3, IMAP, HTTP and more are allowed to simply gain an additional port that can be used to directly enwrap the protocol via TLS, whereas an unbelievable number of working groups and other outcome invents one method after the other to "make SMTP secure". I claim that no mentally sane person gets that problem right. What the people want is a port number. If it cannot be port number for whatever reason, give this protocol a SRV record, so that after resolving MX one can lookup that SRV record, and if it says port 0, then the MTA understands STARTTLS on port 25, and if there is a port number, then the MTA supports direct TLS connections on that port. Finished. That is not extra-ordinary, that is exactly what other protocols do. Obsolete all those many other growing-mushroom RFCs. (And hope that the world owning american giants start supporting DNSSEC.) So to come back to your |I don't understand this flag. What information is this giving to end |users? Will they understand it? Why should they trust it? The IETF modifies this message, its DKIM signature will break. It is an act of courtesy and colloquial form that it then announces that it has done so. It will also create a DKIM signature that cannot be deduced via RFC5322.From. It would possibly be interesting that this is also signalled via a flag, too. |We have already tinkered with the idea of augmenting DKIM in some way to Yes, maybe *this* needs an update (instead of turning many other screws i mean) |indicate "these mutations were made to the message; if you undo them, you |may recover the author domain signature". My recollection is that the |community feels like this approach is too fragile, or too hard to make |comprehensive; there are too many possible mutations for this approach to |work universally or to be sufficiently robust. Yes, no that is. Me too. I would obsolete parts that are to the best of my knowledge never true in practice, like the reordering note, it was SHOULD NOT and should be MUST NOT (aka treat as trace header, no reorder). Etc. There are lots of things i personally disagree with, or find useless aka "blow" etc, like for example the DKIM specific quoted-printable encoding, and that. Alessandro Vesely pointed to z=, for example. The l= seems to be disliked or even rejected by many. Yes, i said that, but i also think it is impossible to create "undo lists" to get back to the original message. That is, with reasonable effort, that is. (It must be said that i saw messages on Outlook.com which included many, many kilobytes, and growing, of intransparent data that could *very well* have included the entire message thread in compressed form, for example, though.) On the other hand, and that i said to Dave Crocker already quite some years ago on the IH mailing-list, because he always said that "it is not DKIM that is the culprit, it is DMARC", that i think it is a user interface issue, and nothing has changed here. (Though he is of course right in that DKIM is not worth meaning anything in practice .. which i would change completely.) But the message's stack can give a clear impression of where the message was modified (and i still think the Authentication-Results header could for the most also be reduced to yet another DKIM flag, because why not?), and if users get a visual representation (like a(n un)foldable tree view (of signature domains and their validity, coloured, etc etc), they could "ok" or "reject" that certain domains perform modifications. Even more so domains which break signatures but do not announce it. Having said that, and hypothetically, *if* people agree that the usual mailing-list modification (Subject: tagging, footer addition, [From: rewriting]) is worth the hassle, this form of message modification COULD be turned into a specific DKIM mode, and *that* could be presented to users, too. If RFC 9057 Author: would finally be adapted by more, the From: rewriting could even easily be solved, .. up to the very first DKIM signature, cryptographically secure. That is: RFC 6376 is much too generic with z= and l=. It consciously breaks mailing-lists just as SPF consciously breaks (beyond first hop) aliases, but gives a generic approach to possibly overcome that which is not really doable, and which i never saw used for any purpose at all. (Ever since i look.) Instead it should throw all that down the trashbin and give detailed info for the very (Subject: tagging, footer addition, [From: rewriting]) case that it consciously breaks for soon two decades. However, since "footer addition" may mean turning a non-MIME message into a MIME message, or turning a multipart/alternative into another MIME form, even that simple task is almost impossible to achieve. And that -- and that was clear in the discussion with Dave Crocker quite some years ago -- is a general fault of the system, because for centuries people put in envelope, put their seal on, and then it was put in sealed envelope, in sealed envelope, etc. Ie, mailman for example offers placing the original message in an attachment. Yet noone uses this approach, because it seems especially the american giants Google, Apple, Microsoft do not have mail clients which' interface gives easy access to, aka an understanding of what is going on. *Here*, on the user interface side, decades of desaster have passed, and all answers of the IETF, as far as i know it, were adding further complications and workarounds. |> No. If you have to alter the message, flag that this has |> happened, and user interfaces need to be changed over time so that |> users are given possibilities to white/allow-list some specific |> party which does that, like a mailing-list. | |Relying on users to edit some kind of allow list is prone to error. Users |will forget to do it, and then complain. Users will complain that they |have to go through an extra step at all. Users will unsubscribe, but |forget to clean this up, possibly exposing themselves to attacks. I do not think this is right -- except for "forget to clean this up", which, as you say, should take your "attacks" thought into account thus. Thank you. Well i mean, mailing-list subscribers can choose to get the monthly password reminder (that is clear text by the way, as the IETF has still not succeeded making S/MIME keys and OpenPGP easily accessible via DNS, apart from some CA thing that is -- at least no hand is to be expected for the typical user that i know and am myself, from the IETF), or not. That is the way it goes. Ie, this is an implementation issue. One could think about a couple of things that tend to get complicated, say. But there are also clients which offer "unsubscribe" buttons for List-* messages, in and for the US there are also those one-click unsubscribe things, even in law i think. Ie, the user-interface could (and should, say) bundle all necessary actions under the hood, then. But you are of course right with this remark. The others i cannot help, you know, there *could* be just another funky icon somewhere, in according traffic light colour, if no action has been defined yet -- this is no different than it is now. It is the same for HTTP, i do have to use a browser, that is firefox, and there are funky items at the left of the address line regarding "tracking status" and what not. (I also use one addition, umatrix, which should be default i think, even though this *really* leads to many complaints .. in today's web.) Ie there is a tradeoff, why should email be any different than web sites? It cannot be automatized here, nor can it be there. For the MUA i maintain, a BSD Mail clone, and thus only for a couple of people, i would possibly extend the "mlsubscribe" command and say "if the first letter of an argument is \a (ASCII BEL), DKIM-Signature: breakages are not complained about" or something like this. (First off it will be a long time before this matters, and second it is hard to add now to this all-text configuration, as arguments may be extended regular expressions and such, and local-parts can practially be almost anything; if designed from scratch i would make this for example flags/address tuples, or so.) Ie, one has to manually remove the list name of the subscription anyway. |> Google and/or KI may even (offer) auto-pilot(s for) *that*, simply |> by tracking their users: ie, if a thousand people say "yes" to |> some IETF mailing-list, there is a high probability this is ok. |> (But it is not more than that, never. Without a real person.) | |I suspect that automation has to work at a threshold much lower than a |thousand to be practical. 'Could be a ratio, too. (Sure, for most lists.) --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]
