First off, I apologize for not having much time to interact with folks on this list. Hopefully I can improve that situation soon.
Rather that respond to every message in this thread, I'll try to summarize my thoughts on this issue. First, IMO there's little we can do to stop spammers from using Mailman as their email engine as long as it's covered by the GPL (which I have no intention of changing). The GPL cannot make prohibitions based on the use of a product, and there's nothing from stopping some evil hackers from distributing a spammer-patch that does some magical stuff that all spammers want. Does that mean we should make it easy for them? No, of course not. But that also doesn't mean we should forgo useful features because we're afraid of it being corrupted. On the one hand, I tend to think that Mailman just isn't the most efficient tool for spamming people, but OTOH, I do get waves of hatemail occasionally from people who get signed up to Mailman lists against their wishes and think I can do anything about getting them off those lists. Those sites usually don't stay up long though. Hmm, maybe I should start sneaking backdoors into the software that dead-kills lusers who use Mailman for spamming. ;) On CRM systems. See the Zope Registration Manager (ZRM) at zope.com for a system I worked on before I left ZC[1]. The mail component of that system (only a small part of the entire system) had many similarities to things you'll see in Mailman3, including the ability to efficiently mail-merge information into the body of a message. I do think that more personal email is more user friendly email, but I am definitely sensitive to subversion of the technology to nefarious purposes. On this specific issue, I think there are legitimate arguments for suppressing the addition of the posting address to the recipient headers. Both discussion lists and announce-only lists are within Mailman's scope, and to the extent that including the posting address on an announce-only list is meaningless, we should find a way to fix that. My biggest concern is not that it will be a subverted by spammers, but that adding yet another option will make configuring Mailman2 lists even more complex. That's aside from the fact that I'm already feature-add averse for the MM2.1 line. OTOH, I don't see a way to tie the reply_goes_to_list value to whether the posting address gets added to a CC header. They are separate things. A hack might be to tie this behavior to include_list_post_header. The intention of that variable was to suppress the RFC 2369 List-Post header for announce-only lists, which seems the purpose here in not including the posting address in the CC header. Can anybody think of a reason why you would want either the List-Post header or the posting address in a CC header, but not both -- or neither? -Barry [1] This is a proprietary "visible source" product so I won't talk about it much here. You can contact Zope Corp for more information. However, my agreement with them allows me to use what I want from the Mailman component of that for Mailman3. _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
