From: "Stephen Farrell"
- Are there any documented surveys on the things that
mail lists actually do? If so, I'd be interested in that for
my own education. But we might also be able to use such a
document to decide which use cases to try support. I don't
think we need to get the ultimate survey document, but if
there's something we can all agree lists some good-to-support
cases that'd be enough. Of course, since no-one's posted a
link that I spotted so far, that probably doesn't exist.
Do you mean a survey of common mailing list features, or basic mailing
list mail flow operations?
Hmmmmmmmm, ok. I am seeing a trend here that is kinda throwing me for a
loop.
For all intent and purpose, the proposed DKIM/SSP protocol or any
similar protocol applies to all internet email operations, regardless of
what specific middle ware you have. We can't selectively choose one
mail processor type over another. They all have to work the same way in
relationship to the DKIM/SSP protocol.
We have a pretty wide spectrum of products for mail operations, from old
UUCP, SMTP, List Servers, News Servers, Gateways, Groupware, News/Email
Gates, Fidonet, QWK, offline readers, online readers, etc, etc.
If we plan to add DKIM/SSP, it has to work and interface consistently
with everything where it is applicable and required. One can't break
the other, and one can't benefit while the other does not. Again, if it
is applicable.
The best we can do is to provide a basic EMAIL security technical
protocol, of course, with good engineering hindsight, and let the
authors fit it into whatever mail operations they have following 100%
the specs and guidelines. Maybe that is what you are looking for, a
summary of general mail operations?
I just hope that LS operations does not become the exception to the
DKIM/SSP specifications.
Note, I'm not saying that the specs should not suggest guidelines as to
what a LS author might consider. That would be great. i.e. as a possible
suggestion:
List Servers "MAY" consider restricting the type of DKIM
policies it wishes to honor. But under no circumstance,
it MUST NOT break the integrity of DKIM messages.
The only squeaky issue is the idea of "stripping" for policies that
might allow it. This might be acceptable because network control lines
(headers) has always traditionally been under the control of the network
mail processors. But is stripping acceptable for a DKIM domain?
This is a big item because it will help define the complexity of List
Server DKIM processing. If we declare no stripping of existing
signatures, even if an optional policy is used, then that forces the
hand (a particular design requirement) we list servers authors have to
do. Allowing us to strip will simplify a big part of the Relaxed
Policies issues.
Anyway, List Server or not, the same applies to any other middle ware
processor. How about Mail Filter Agents (MFA)? Automated responders?
and others. They all need to follow DKIM/SSP in the same way.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org