Stephen,
Ok, I see. I can provide my "feature list". But all I was saying is
that, why should it matter? :-)
DKIM/SSP is an RFC 822 extended EMAIL protocol. Mailing List or List
Servers and all other mail processors are augmented technology that fit
on top of the 822/821 model
So regardless of a extended mail processor features, its I/O, outer
edge, must be consistent with the expectations of the email system.
So you have:
AUTHOR/822 ----> whatever ----> RECIPIENT/822
"Whatever" could of been a dozen transformations. Who knows!? But the
governing rule of thumb is that what went in, should be what comes out
and we shoot for 100% maintaining the integrity.
So lets make Whatever a group of items that includes, all the basic
parts, including a List Server as well:
MUA/MTA --> | MSA --> MFA --> LS --> MTA--> MDA | --> MUA
No matter what features you have, the input must equal the output.
That's the goal in all this.
The MUA/MTA comes with a DKIM/SSP header. Nothing in the middle should
break it, and its known to do something that could break it, then either
the adjusts itself to DKIM or not. But to do it correctly, it has to
adjust, especially if something in the middle is changing content.
Do you really want a list of features? <g>
The basic features of a general list server are pretty simple:
- Subscription control
- open, close, open/confirm
- Submission Control/Options
- Allow Posting?
- Allow Any Poster?
- Moderated?
- Stripping
- Attachments
- HTML
- Expansion/Distribution Options
- Set Reply-To Field to List Address
- Keep Original To: Address
- Auto-Unsubscribe for failed transactions
- Body Headers/Footers
- Additional 822 Headers
- Digest
- Frequency
- Size
- Request Files
- Help via EMAIL
- Others options
Pretty basic stuff, and the above is a short list, but I tried to show
some items that might affect DKIM/SSP.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
--- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Do you mean a survey of common mailing list
features, or basic mailing list mail flow operations?
I'm not sure, probably the former. Let me try explain again.
Mailing lists (and others) do things that break signatures,
for good, bad and indifferent reasons.
If we want to define a protocol that allows for both original
and mailing list signatures, so that the one doesn't have to
interfere with the other, then we have to have some understanding
of how lists (and others) break signatures.
Probably a bunch of people on this list already know all about
this. I don't, at least not sufficiently well to judge some of
the options. So I'm asking for a pointer to the "how mailing
lists break signatures" report, if it exists so I can learn
a bit more.
Now, if that did exist, it might also be useful to folks who
already know all about this area in that it would give us a
way to say "if you do this it breaks when the message is handled
by things like those in section 9.1.32", or, "we defined this
field so that you can still verify even if you go through a
server like that in section 8.2.3 which is fairly common".
Being able to point at bits of such a report might help us go
quicker.
However, I can well imagine that this doesn't exist in any
usable form, but it'd be nice if it did.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org