suggestion for Full Customization [Mailman-Developers]
Mailman 2.1.4, Mailman/Handlers/CookHeaders.py, line 138:
# The To field normally contains the list posting address. However
# when messages are fully personalized, that header will get
# overwritten with the address of the recipient. We need to get the
# posting address in one of the recipient headers or they won't be
# able to reply back to the list. It's possible the posting address
# was munged into the Reply-To header, but if not, we'll add it to a
# Cc header. BAW: should we force it into a Reply-To header in the
# above code?
if mlist.personalize == 2 and mlist.reply_goes_to_list <> 1:
# Watch out for existing Cc headers, merge, and remove dups. Note
# that RFC 2822 says only zero or one Cc header is allowed.
new = []
d = {}
for pair in getaddresses(msg.get_all('cc', [])):
add(pair)
i18ndesc = uheader(mlist, mlist.description)
add((str(i18ndesc), mlist.GetListEmail()))
del msg['Cc']
msg['Cc'] = COMMASPACE.join([formataddr(pair) for pair in new])Question: why was this done?
If I have set the "personalize" option to "Full Personalization", a very likely reason why I have done so is because I don't *WANT* the recipient to reply back to the list--or, for that matter, even realize that the message was sent through a mailing list at all. I want the recipient to see an individual message that looked like it was sent *from* an individual person *to* an individual person.
Adding the list address to the CC header perfectly defeats this.
While I can address this locally simply by excising the above code snippet, I'd rather see this issue addressed upstream.
Would it make sense to split the "Full Personalization" setting into its own option? Meaning, make the existing personalize Option a yes/no toggle, and create another option to specify how to customize the headers:
- To: header is listname; recipient address does not appear (default)
- To: header is recipient; CC: header is listname
- To: header is recipient; listname does not appearIf someone would be willing to double-check my Python code (and proofread my documentation), I'd be willing to implement a patch to perform the above split.
Thoughts?
-- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA
At 7:03 PM -0400 2004/05/05, James Ralston wrote:
If I have set the "personalize" option to "Full Personalization", a very likely reason why I have done so is because I don't *WANT* the recipient to reply back to the list--or, for that matter, even realize that the message was sent through a mailing list at all. I want the recipient to see an individual message that looked like it was sent *from* an individual person *to* an individual person.
Adding the list address to the CC header perfectly defeats this.
This is a mailing list. Mailman is a mailing list manager. It is not a "hidden address so you can spam" manager. We're not trying to hide anything here, and I doubt that anyone is going to be interested to see code in the mainstream package that would try to address this "problem".
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
On Thu, May 06, 2004 at 10:26:05AM +0200, Brad Knowles wrote:
This is a mailing list. Mailman is a mailing list manager. It is not a "hidden address so you can spam" manager. We're not trying to hide anything here, and I doubt that anyone is going to be interested to see code in the mainstream package that would try to address this "problem".
For announcement lists[0], being able to do handle subscriptions, unsubscriptions and bounce handling via Mailman is a plus, since it (in my organization) is already used for "normal" mailing lists for internal and external use.
Many customers, who normally only use the net for web and mail, would prefer a mail being sent from Customer Service, and addressed to their own address, so that they know the mail was sent to them, and that they can hit reply to get help.
I would certainly prefer that, since a not insignificant fraction of the users usually hits "reply to all" anyway. This creates a lot of unneccesary noise on the moderator interface.
Yes, that same functionality could be used to spam, but in most cases it won't. Mailman is simply not efficient enough for that purpose. The spammers use hundreds of thousands of worm-infected computers today, to spread messages.
I guess many of my problems could be solved by combining mailman options, but I'd like a "this is an announcement list" option, that does all this for me.
[0] Information about planned outages, unplanned outages, etc...
-- Stig Sandbeck Mathisen
"The key to change ... is to let go of fear" -- Rosanne Cash
At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:
Many customers, who normally only use the net for web and mail, would prefer a mail being sent from Customer Service, and addressed to their own address, so that they know the mail was sent to them, and that they can hit reply to get help.
What do you need a mailing list manager for? Just use a simple program that sends out e-mail claiming to be from your customer service address. I see no need for a mailing list manager for this function.
I guess many of my problems could be solved by combining mailman options, but I'd like a "this is an announcement list" option, that does all this for me.
That certainly doesn't sound like any "announcement" mailing list I've ever seen.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
"Stig" == Stig Sandbeck Mathisen <ssm@fnord.no> wrote:
Stig> Many customers, who normally only use the net for web and
Stig> mail, would prefer a mail being sent from Customer Service,
Stig> and addressed to their own address, so that they know the
Stig> mail was sent to them, and that they can hit reply to get
Stig> help."Brad" == Brad Knowles <brad.knowles@skynet.be> writes:
Brad> That certainly doesn't sound like any "announcement"
Brad> mailing list I've ever seen.But it accurately describes every vendor newsletter I'm subscribed to (about 4 independent ones, some of the companies send 3 or 4, which I hadn't counted on ;-). They all have the editor's mailbox in From, my address in To, no other visible addressee headers. Some have List-* headers, others don't. True, mostly the editor's mailbox screams "mass mailing", but then so does "Customer Service".
James clearly jerked your chain hard when he wrote
I don't *WANT* the recipient to reply back to the list--or, for
that matter, even realize that the message was sent through a
mailing list at all. I want the recipient to see an individual
message that looked like it was sent *from* an individual person
*to* an individual person.I agree, without more context that exactly matches the spam I hate most. But it's very possible that the members have signed up for it and want it that way (pastor's newsletter at their church), or didn't sign up but would appreciate the fiction (holiday mailing to the extended circle of family and friends). I'm stretching, I know, but then the stuff I'm smoking is not so good today. :-)
And Stig describes a quite different, and very plausible, use for the same facility. If James is willing to do the work for it, I think it's potentially useful, and appropriate to accept it.
-- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:
Many customers, who normally only use the net for web and mail, would prefer a mail being sent from Customer Service, and addressed to their own address, so that they know the mail was sent to them, and that they can hit reply to get help.
I would certainly prefer that, since a not insignificant fraction of the users usually hits "reply to all" anyway. This creates a lot of unneccesary noise on the moderator interface.
I've been thinking about this a bit more. The attributes you're asking for seem to me to be more appropriate to a Customer Relation Manager system, not a mailing list management system.
Any attempt to abuse a mailing list management system (e.g., Mailman) into functioning like a CRM are likely to be both unsuccessful and painful.
I am a strong advocate of using the right tool for the right job, and I'm pretty sure that Mailman is absolutely not the right tool for this one.
If you (or anyone else) had any patches to bring this kind of functionality into Mailman, and they could be guaranteed not to interfere with anything else, I would still be opposed to them, but there would be fewer logical arguments I could make to support my case.
Certainly, I would be strongly opposed to anything that would make it easier to abuse Mailman into a spamming tool, so you'd need to make sure that you addressed that issue as thoroughly as possible in your patches.
If that issue was addressed, then I'd be left with arguments relating to code bloat and size of the community (or potential community) that would benefit from such patches versus the amount of work that would be required to keep them from suffering excessive "bit rot".
However, I think my most persuasive argument would probably be that this would be a slippery slope and the benefited user community would then be even more insistent on seeing additional modifications made in the future to further benefit them to the potential detriment of the rest of the Mailman community, and the expectations that would be set up that could cause these two groups to become adversarial towards each other, with all the resulting fallout, etc....
Yes, that same functionality could be used to spam, but in most cases it won't. Mailman is simply not efficient enough for that purpose. The spammers use hundreds of thousands of worm-infected computers today, to spread messages.
Those are the end transmission systems for the bulk of the spam that is sent out, yes. But there is plenty of spam being sent out that does not use bot-nets. Moreover, the spam has to be injected into these bot-nets, and you would have to be very careful to make sure that these modifications don't make it easier to abuse Mailman towards that end.
I guess many of my problems could be solved by combining mailman options, but I'd like a "this is an announcement list" option, that does all this for me.
I really don't think what you're asking for is appropriate to a mailing list management system. Try Googling for "customer relationship management system", or words to that effect.
At the ISP I use today, and where I previously worked for two years, they have a simple "POP Bulletin" system to achieve these goals, with the messages appearing to come from Customer Service and all replies being sent back to them. No mailing list management system involved at all -- indeed no MTAs involved, and no extra copies of this message stored anywhere on the server, and no "deliveries" of this message to individual private mailboxes. You can achieve the same sorts of things with a shared IMAP folder system, and subscribing all users to the appropriate shared folder(s).
If you're not an ISP and you can't use "POP Bulletin" or IMAP shared folder solutions, then you'd be left with traditional CRM systems which do actually send out real e-mail messages.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:
Many customers, who normally only use the net for web and mail, would prefer a mail being sent from Customer Service, and addressed to their own address, so that they know the mail was sent to them, and that they can hit reply to get help.
For the benefit of the community, I have summarized my answer on this subject and put it into the Mailman FAQ at <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.018.htp>.
Please let me know if there are any other aspects of this issue that need to be addressed.
-- Brad Knowles, <brad.knowles@skynet.be>
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.
SAGE member since 1995. See <http://www.sage.org/> for more info.
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.
participants (5)
-
Barry Warsaw -
Brad Knowles -
James Ralston -
Stephen J. Turnbull -
Stig Sandbeck Mathisen