> > There is no specification that restricts what lists are allowed to do. > > There will, however, be restrictions on who and how a domain's > name in origination addresses can be used soon enough. That is the basic > conflict.
If you are planning on setting rules for lists about what they can do with the mail that people send them, you might want to drop by Wikipedia and read about the legend of King Canute. I can just barely see some utility in SSP insofar as it describes a domain's own policy, e.g., this domain signs all its mail or this domain sends no mail. As soon as it purports to control the activities of other people, e.g., nobody can sign my mail but me, it leaps into the realm of the unimplementable. > That assumes that mailing list software's perogatives trump all. They > don't. Of course they do. I run majordomo2, I like it just the way it is, and I expect to run its output through my MTA that puts my domain's signature on all its outgoing mail. How exactly do you propose to make me do something else? (Hint: RFCs are suggestions, not commands.) What will happen to me if I don't? > The object here is to reach an accommodation between these two competing > needs. But if I had to say who ought to lose push come to shove, it > would be mailing list software that insists on changing my original > content and then trying to pass it off as if I wrote it. Putting on my list owner hat, I would point out that if you don't like what a list does to your mail, you are free not to send mail to it. I would be amazed if any list operators felt otherwise. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. PS: Was it you who put [ietf-dkim] in the subject line? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
