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