Hector Santos wrote: > Just to be clear, I was referring with screwing around with > all the existing options that a sysop traditionally desires > in mailing list based distributions.
<joke mode="fido"> My desire to screw around with echomail was somewhat limited to the "reduced seen-by lines" </joke> Traditionally sysops don't want to screw with in-transit mail, in their religion that's a taboo. Anybody with the desire to get in serious trouble can still start a gateway or cancelbot. The survivors can quote chapter and verse of obscure texts like son-of-1036 by heart. It's clear that you're one of them, but I doubt that there are much more than a hundred worldwide. > No doubt, we desperately need a new WG for LIST SERVERS. > There are many old issues that needs to get resolved. Makes sense. Maybe when USEFOR and 2821bis are ready would be a good time. That's unfortunately too late for DKIM. > the way we use List servers today is basically KLUDGING > email to be a "Groupware" conference systems. Groupware is a big word, it can cover everything from vCard and calendar formats up to XMPP / Atom / Wiki / subversion and what else. Mailing lists probably have their place in this broad concept, but this won't require them to add funny trailers or subject tags to ordinary mails (excl. digests). Quite the contrary they'd be expected to do nothing that can destroy S/MIME / PGP / vCard. Or back on topic now DKIM. Ignoring PRA one case to watch for DKIM is "Reply-To: list". If participants want this they should be free to get it from their list. So that's tricky if the original sender already set a Reply-To, or worse if a signing entity before the list signed that there is no Reply-To. [author to list arrived at list server] > After that, he has no control of what happens and for the > most part, NO say about the storage, transformation > presentation and/or distribution. Arguable, but I'm not rejecting it as valid model, I'm only concerned how deep DKIM wants to get involved with the fine print of this model, So far I'd say that anything where PGP or S/MIME would fail miserably is also out of scope for DKIM. With the option to arrange things to work with trivial cases, taking John's ASRG experiment as further input, and maybe some known mail2news + news2mail idiosyncrasies. > one reason why "thou shall not tamper with passthrus" exist Let's ignore legal aspects and US law, as John said we're no experts for such issues. AFAIK any tampering without prior consent of all involved parties could be also relevant for an article in the German "base law" (an ersatz-constitution). For a mailing list the author and all recipients subscribed, that should be good enough for the legal side of things. Or maybe not for cases of PRA != author, but IIRC Jim said that he will fix most "originator" to "authors" in his draft. >> What does WEAK mean for an _unsigned_ mail at a third party >> willing to sign it ? > To me, if is SSP is suppose to define what a DKIM/SSP > compliant mail processor is suppose to do, it means it can't > sign it. Okay, then Jim's very first diagram in the threats draft _is_ wrong, it suggests to look at the SSP only for signed mails. Now you propose a procedure where you have to look at the SSP also before signing anything. We need a diagram covering the MON -> mediator -> MRN case. One mediator as a placeholder for zero or more mediators. (Read "sysop" if you don't like "mediator", in that case I don't care about the terminology.) > I predict it will get worst, in the area of Ad-Ware email. > Some receivers are already stripping this junk. Yes, that's convincing. OTOH I'm not interested in a design where DKIM-signed mails with ESP-Ads survive mailing lists adding their own Ad-trailers or similar stunts. Bye, Frank _______________________________________________ ietf-dkim mailing list http://dkim.org
