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