Steffen Nurpmeso wrote in <20250827103340.t674HfOy@steffen%sdaoden.eu>: |I am very, very sorry to disturb Orie Steele and Andy Newton |again, and one last time, but a message i sent a week ago |disappeared without trace. I am 99.9 percent sure it was not |automatically discared, i do not end up in spam folders due to |robotic intervention, normally.[.]
One more week has passed, yet i seem to know that in US August is holiday for many, and September is fresh, and also, as far as i know, your (dea Orie and Andy) IETF roles are voluntarily and "best effort", and so there are more important things than this issue here. *Ok*. |[.](I know one occasion, when |someone funny registered my IP at an RBL list, and .. the list |weighed that single RBL too much. (Granted my own MTA config does |that too, but zen.spamhaus.org has not yet caused any trouble; it |hits practically never here, eh, etc etc etc).) | |So at the famous and interesting and wonderful TUHS/COFF list that |likely most of you know, Warren Toomey is known to the IETF, and |has received the 2022 USENIX Lifetime Achievement Award, |Warren Toomey himself got in trouble configuring the TUHS list, |and asked for help. That made me actually look over the archives |of the (then) four weeks that passed since i had unsubscribed, and |in turn resubscribed for a single message. | |That message disappeared. | |I for one cannot understand that and find nothing in it that is |neither not true nor somehow not pretty objective, and would like |to ask that it gets posted to the list. |I'll include the message next. Yet i really insist and want this to be heard, and continue not to understand non-post, and never will understand the discarding of messages. Since memories are short-lived, or certain members of the audience never read or heard the technical context on "my accusations", i edited the below to insert some technical context in brackets. (Btw Warren Toomey conducted yet another test email, after taking note of the surrounding message, whatever that may -- or may not, i do not know! -- mean.) |Thanks for your consideration already here, Yes. Thanks for your consideration, Orie and Andy. |--- Forwarded from Steffen Nurpmeso <[email protected]> --- |Author: Steffen Nurpmeso <[email protected]> |From: Steffen Nurpmeso <[email protected]> |To: [email protected] |Subject: Technical Context. |Date: Thu, 21 Aug 2025 17:22:02 +0200 |Message-ID: <20250821152202.tNsmOIu6@sdaoden%gmail.com> |Mail-Followup-To: [email protected] | |WHY is my name STILL in | | <175460645960.670.4496668193869287877@dt-datatracker-6f95f9d9c-8g9j6> | Participants who must be present: | Dave Crocker | Richard Clayton | Wei Chuang | Bron Gondwana | Steffen Nurpmeso | Allen Robinson | |Have you STILL not managed to push through that other proposal |despite all the spooky false-question false/no-context threads, |the favouring, the hush up of anything? That is ridiculous. | |I am NOT the ball rubber of neither people that i do not like, nor |of what is pushed through her as a new healing bearer. It is not. |(Imho.) | |In all those hush up (i like that term!) years i was subscribed |i have not read a hand full of useful, and mentally sane posts. |Regarding the new healing bearer it was, from two (main) |developers of the most widely used MTAs of the world, if we let |aside the giants, which are subscribed here, but which are not |asked nor even heard for real -- what a shame, what a waste, what |a presumption! What moderator malfunction. -- | | - ~"that with the asynchronous bounces will not work out". | |and | | - 'For "commercial" mail single RCPT is probably the "standard" | to allow for tracking.' | |That it is about it. (Plus good messages by Tero Kivinen.) |Just to reiterate -- if YOU DO NOT KNOW ABOUT THE SOFTWARE, YOU |SHOULD NOT WRITE STANDARDS FOR THEM! |There is not a single serious MTA on this planet that i know |the source code of -- which distinguishes me from many of you, |especially those which say a lot here -- which uses single |RCPT TO mode. Not one. They all try to minimize bandwidth and |scale as much as possible. Have YOU ever given just ONE name. |Because you cannot. I was actually deeply disappointed by Dave |Crocker in this respect, fwiw. REALITY .. NOT ON THIS LIST HERE. |Dreamers who long for slim Porsche 911s, but prefer single |recipient and multiple MAIL FROMs; a long way the former, IETF |caused email detoration the latter. | |There is no technical foundation or necessity for all this -- NOT |AT ALL! This proposal satisfies giants with lots of overview, as |you can, for the first time, and different to all other parts of |the IETF that i knew (i am no longer subscribed except for very |fewest), which try to PROTECT PEOPLES PRIVACY, create deep flow |graphs on the SMTP connection level. And this data is worth lots |of real money, not only in the US; you may read lots of Bruce |Schneier outcomes regarding that on interest. | |To reiterate: | | - The IETF destructed many decades of grown email aliases. | This now "works as designed", and by IETF means this means not | at all. You need the external SRS solution. [SPF works for one hop. If A sends to B, but B is expanded via alias to C -- please note this means all the "alias farms" that make up the internet, cpan, sourceforge, maybe kernel, Free|Net|OpenBSD, many universities, and more -- then C cannot SPF-verify. That is: unless - B uses the IETF-external SenderRewritingScheme solution. or - A does not use "-all" (hyphen-minus) but "~all" (tilde). Question is about the life entitlement of "~all" (tilde). What is that actually worth? What meaning can be applied to "~all" (tilde)?? SPF should either be not used at all. *OR* only be "-all" (hyphen-minus), meaning that an email comes from *only* the given IP(s), in which case SPF has a decisive meaning! In order to end up with the decisive "-all" (at some unspecified later time), each hop must ensure that the RFC 5321.MAIL FROM:<> will succeed a possible SPF test at the next hop.] | - The IETF destructed "the easy mailing-list". There is no will | to make this any better. Do not dare to mention 6377, it is | from 2011. [This also results from the context of the surroundings. Shall it not be clear by itself.] | - The IETF shits myriads of a-point-in-space-and-time outcome | into email headers, which are maximally worth being developer | debug information, not more. | Authentication-Results -- rubbish! By the time i look at it, | it all child porn. Gigabytes of stored rubbish. [You can see messages which crossed several hops and have (a) thousand(s of) byte(s) of Authentication-Results from them all. I am aware of RFC 7001. Still, also given "MUAs and downstream filters SHOULD NOT interpret this header field", it is one of those standards that put the burden on anyone else!!, for undecided and far-ceiling "entirely possible", "deliberately not made", "elect not to", "can be desirable" -- etc etc etc. This is not rocket science. (And then rocket science leads to nowhere, not even in our own -- haha -- solar system.) This says dkim=passed spf=passed and gives plenty of data that at the time i see it, even as a local consumer, is outdated. (Not that searching for "ttl" in RFC 7001 gives two times "little", and i add hereby another one.)] | Actually the email side of the IETF desensibilized itself | regarding user privacy, after living with such standards for | years. [That. In. Addition.] | - The IETF got on a lost track with DMARC that caused nothing | but havoc, to this very day. In an onion-alike environment of | runs, this was the intestinal incident. [See. The IETF came and implemented another master piece for little minds. The internet had to react and started mitigation the IETF also here -- your only option to deal with these IETF standards! In practice. So in practice anyone concerned *MITIGATES* this by rewriting RFC 5322.From etc etc. Like this DMARC does not kick in. That is the ONLY good thing about this deep track standard that they -- and mind you, the requested room size went from i think 100 to 50 to 25, and if they continue like they do, next time they can go to the five-in-a-row pissoir, that is large enough, honestly -- did, that with "differential changes unrolling" *USER INTERFACES* can adapt and show "some" (the) original From:, not that "X via Y" syntax. What a shame. SPF mitigated, or, more often, mutilated to TILDE, because some "intermediate" just does not implement SRS, and it simply bounces!! What a shame. And. What a shame. DMARC mitigated to "X via Y". So that it works. Even mailing-lists function! With quite some effort, but still. How good that the IETF is incapable to destruct that!!!] | - The IETF completely bailed by applying cryptographical | signatures on completely non-verifiable, fishy data. | ARC. (Argh!) [That thing. The IETF talks that high, just today it was mentioned in a positive way -- technically false, by the way, unless i am very mistaken. But it is not. It is *so* unspeakable mislead. *So*. Placing cryptographic signatures on completely unverified data. No.] |Btw here is a moderator active who finds it acceptable to |mutilate the SMTP protocol backward incompatibly, in order to |ensure STARTTLS availability, but does not even comment(!) on an |easily implementable solution that is used for all other email |protocols, and has been made a law in a country (that pays and |pays and pays for the escapades of the country of the moderator, |just to mention this) about one and half a decade ago. That is |schizophrenic; if i would act like that, i would be placed in |the asylum! Noone understands this, noone. Judged from private |feedback. Yay MTA-STS, and the cacert pool. [Again, and again, and again. For years, and years, and years. Everywhere. Noone understands what the IETF is doing to SMTP regarding TLS. I mean, just do it. SMTP is *not* special. In Germany we have this law for providers, they announce SRV instead of MX, and there you go, in between them. Hey, make this a standard, and allow for Implicit TLS even! No secret service still believes there are criminals or journalists (wait! let me think about that some more) so dumb that you can get a SMTP man in the middle on unencrypted data? Noone understands it. I do not know how visiting an IETF meeting can "fish" studied engineers away from wanting a possible announcement and Implicit TLS for SMTP. For decades?!] |So, as i am mentioned as a "must be present" -- thank you, here |i am! --, please let me reiterate: [At least i try hard for two weeks now.] | - DKIMv1 as a foundation is enough. | It protects the RFC 5322 email message by cryptographically | linking it with the domain where it was sent. [Yes. Even if i let aside the snaky false downspeak of DKIMv1 for technically false reasons -- split tongue talk is disgusting, yet here at certain IETF forums, you here it often, yuck! -- that is what it does, and it does this very well.] | - I propose(d) to trim it a bit, and trim away practically | unused, and often non-implemented features. Just for fun. [Ok it was not fun. I mentioned "dead wood", and that is what it actually is. It is not always implemented, possibly so more often than not, one had to count all; i think the majority does not. It is unneeded, so just drop it. There are more important things to be done.] | - I (finally) propose(d) to address certain shortcomings, namely | replay and backscatter bounces, aka DKIM Access Control. | | This in a way that protects the path from the message sender | to the RFC 3461 "final delivery". Not any further. | Recipient domain delivery specific. Cryptographically save. [And *that* is really important. No tracking. But security.] | - I propose(d), and for years dreamed of, creating | a cryptographically verifiable chain of signatures, so that | each and every modification OF THE RFC 5322 IMF MESSAGE can be | unrolled, all the way back to the original sender. [Btw the only thing *i* heard from those people is "you are silent now", after they went doing this. I would do this differently. My approach is easier to implement. Actually there is mature plug and play code available.] | + This, in fact, and i am happy some of you have recognized it | immediately, hey!, is of course nothing but Wheeler's | fundamental theorem of software engineering, that "We can | solve any problem by introducing an extra level of | indirection". | | Yes, mitigate! mitigate! mitigate!, let the data flow on the | SMTP level, throw away the useless and poisoning DMARC, ARC, | Authentication-Results, mitigate! also SPF, so that even | aliases work again!, as they should! | | Yes, "align" each and every RFC 5322.From, and each and every | RFC 5321.MAIL\ FROM, all the time! [That is the key. The internet does this anyway, except for buzz words all the IETF standards are not worth the bits on the storage. The internet mitigates you! *BUT* if the IETF finally comes back to some sanity, and sees the devastation it has caused, and that includes, possibly even not few, hopeful life concepts. Then, if it mitigates the mess itself. Then the only sane standards of the last at least one decade, DKIM and SPF, can become empowered to *real* value: - SPF can use -all (hyphen-minus). - DKIM's crytographic signature is worth as much as the TLS certificate handshake, and more, dependent upon key retrieval. All the others can vanish, they have no meaning, they never had a good one, and the internet mitigates. I mean, hey. It should not need this. You are the IETF! But they have to. Because you are the IETF.] | And let interested user interfaces adapt, crytographically | safe, for example by tagging X as a mailing-list, so that if | i get an email from X, the original From: is restored, so that | i do not have to see that "X via Y" syntax. | |You will never be able to identify what is a valid "intermediate". |*The problem cannot be solved on the smtp level.* |Nor do i think it should. Because: why? | |So here is the ACDC proposal, which uses the fantastic BSDIFF |algorithm of Colin Percival to keep track of the Differential |Changes, and the RFCd ZLIB and the non-RFCd but fantastic and |omnipresent XZ of Lasse Collin (and Igor Pavlov) for compressing |those, with ships with automatic Mitigation'25 to finally get |email going again. |This is all DKIMv1. |(It can be made completely DKIMv1 by not placing the acdc= tag |inside the DKIM-Signature, but by placing that in its own header; |yet i do not think this is necessary; i would keep the sequence |numbers anyway, they make things programmatically a little bit |easier.) |It is all easy to implement. In fact existing software that |i looked at could slice in the functionality quite easily. | |So. THANK YOU for still requesting the presence of myself and |that proposal, *i* absolutely believe it is the better one. |For the email infrastructure, and especially for the "little |people going email" everywhere. | |With many greetings from Germany, |Ciao! | |P.S.: | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 259) for (i \ | = 0;i < reciplist.len;++i) | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 260) { | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 261) if \ | (substdio_puts(&ssto,"RCPT TO:<") == -1) writeerr(); | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 262) if \ | (substdio_put(&ssto,reciplist.sa[i].s,reciplist.sa[i].len) == -1) \ | writeerr(); | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 263) if \ | (substdio_puts(&ssto,">\r\n") == -1) writeerr(); | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 264) if \ | (substdio_flush(&ssto) == -1) writeerr(); | ^af9625ddf9 (D. J. Bernstein 1997-10-28 00:00:00 +0100 265) | |Which makes *me* think that a possible Bernstein quotation of ~"always sent |single recipient" is to be interpreted as ~"we are not only more secure, \ |we are |also faster". In 1998, wetting of seats and such was as common as always. | |P.P.S.: | You do not need to moderate this address. I mostly resubscribed | only for sending this message, as *i* think it is only | a moderator fault to still include my name, maybe as an alibi | to make it appear as a free decision based upon technical | reasoning. Which it never was. Or simply without any thought. | That fits better. | |P.P.P.S.: | ACDC has no deal at all with the unobtrusive signature stuff | from the OpenPGP world. I like that approach, though. (It even | turns the Autokey approach i spoke against long ago into | something really useful, if implemented like Kahn-Gillmore did | it, aka protected by Sigs:, .. all that only because PGP, | different to S/MIME, does not allow extraction of the public key | from within the signature as such, say.) | |Well. I think this is the last good-bye. [I mean, i'd wish it would be different, i have at times something good to say. Yet i walk and walk and walk, and that is distressing, and also very time consuming. Yet another hour that i did not work for the heart and souls here, or by programming that can be fun. |o/ | -- End forward <20250821152202.tNsmOIu6@sdaoden%gmail.com> --End of <20250827103340.t674HfOy@steffen%sdaoden.eu> Ciao and greetings from Germany, --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]
