>>>>> "C" == C L Etheridge <[EMAIL PROTECTED]> writes:
C> In other words, an e-mail send to a list via Smartlist in the C> "TO" field has the name of the list NOT the e-mail address of C> the recipient. Please note that not only do all mailing list servers do this, but many users _depend_ on it to sort their mail. You may consider "mailing list manager" to be a misnomer, if you like, but the connotation of "one alias, many recipients" is deeply embedded here. You're almost certainly not looking for a mailing list manager, but rather mail-merge or customer relationship management (CRM) software. The FAQ has suggestions for both, IIRC. Here's how to decide for yourself: C> This results in several ISPs dumping the e-mail into the spam bin. (Refer them to the "Part of the Problem" department....) If your application is actually a mailing list in the sense that Mailman et al are (ie, the recipients are an identifiable social group and are in some way interacting through it, either by discussion or announcement of information related to the group), I would write the affected users individually and ask them to "change" their ISP. I would explain that many recipients sort their mail according to this field, and that future services will benefit from having names for mailing lists. "Change" might mean ask the ISP to fix their filters (which are broken; it only marginally increases the cost to spammers to send spam messages individually), or to actually subscribe to a different ISP. If your application is more or less personalized mass-mailing, eg, to customers and potential customers who don't care about each other (at least not in the context of this newsletter), and value your organization first, you might prefer (CRM) software or mail merge software. Another way to think about it: If you envision the "upgrade path" for your service to involve more interaction among the subscribers, Mailman (inter alia) is the way to go. It will make it easier to create subsidiary channels (both topics and new lists) and allow the subscribers to manage their own accounts. The aliases will make it easier for them to make contact with each other, especially the whole group. You'll have to deal with the problem ISPs another way in this case, no matter what. If planned and probable improvements involve more and more personalization, beyond simply individual addressing, then you will find that Mailman (et al) will be obstacles to implementation. They are about serving a self-managing many-to-many network, rather than explicit management of one-to-many relations. HTH -- 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. ------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/