Jason Dixon <mailto:jason@xxxxxxxxxxxxxx> on Monday, April 19, 2004 4:32 PM said:
It helps to know what your requirements are. I'm happy with Mailman on my Postfix server. Requires a couple extra hoops for virtual domains, but works great.
oh how i always forget to list these things...!
I've replied to each requirement below with a brief explanation of how Mailman handles these.
i'd like: (and i think this might be pretty standard stuff, nothing special)
1. to know how many email addresses are on the list
Via the mailman admin (web) interface or "$mailman_dir/bin/list_members <listname> | wc -l".
2. to maintain more than one list
Mailman supports this via unique url. Example:
http://domain.tld/mailman/listinfo/list_a or http://domain.tld/mailman/listinfo/list_b.
3. to know when each email address was added
Enable "Should administrator get notices of subscribes and unsubscribes?" in the General options section of your list.
4. to know if an email address bounced during the last mass mailing (and
why if possible)
You should get a bounce notification to your postmaster account (at least, I do).
5. to have, for archival purposes, a copy of each mail that's been sent to each list
Mailman saves list archives with the included pipermail.
6. for the recipients of each mass mail to not be aware of the other members. in other words, i don't want a mail sent out with 1000 email addresses all in the cc field! :)
Mailman uses the standard aliases format. Each email is re-written by Mailman and an individual mail is sent out to each client.
this will not be a public list such as the one we are communicating
through right now. it's just meant as a place for a company to store and
manage their customer mailing list with the purpose of sending out
product notices and event announcements every once in a while.
Obviously, you can control access to the list and/or interface via a number of different methodologies available on any Linux/UNIX server. Basic Auth (via httpd.conf or .htaccess) on the mailman interface is the simplest to come to mind. Note, however, that creating NEW lists still requires some manual intervention unless you a) find some software that does it for you, or b) you write a simple CGI to take in the most basic list information from the customer "admin" and create the lists. This could be probably be done in under 30 lines of perl CGI.
Basic new list creation goes as follows (virtual-specific stuff noted as such):
1) $mailman_dir/bin/newlist -q listname@xxxxxxxxxx admin@xxxxxxxxxx password (non-interactive)
2) Paste the aliases output into your /etc/aliases
3) If using virtual domains with Postfix, append the virtual domain to the new aliases in /etc/aliases
4) Rebuild your aliases.db with "postalias /etc/aliases" (postfix) or "makemap hash /etc/aliases < /etc/aliases" (sendmail).
5) If using virtual domains with Postfix, create a virtual alias that points the alias to the local server. Looks something like this for the example in #1:
listname@xxxxxxxxxx -> listname.domain.com@xxxxxxxxxxxxxxxxxxxx
6) Reload your MTA configuration to enforce the changes immediately. "postfix reload" (postfix) or "kill -HUP `cat /var/run/sendmail.pid` (sendmail) or "service sendmail restart" (sendmail on Red Hat).
HTH.
-- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
