suggestion for Full Customization [Mailman-Developers]

[Barry Warsaw]

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.