|
CommuniGate Pro
|
Integration
with the CommuniGate Pro messaging server software.
|
* Tight
integration with the messaging server software; users in local domains
cannot be created with erroneous addresses.
* Automatic
unsubscribe of addresses that are bouncing messages.
List module is very polite.
|
* Would
like hierarchical Lists with inherited posting preferences, such that a
global list will permit posts from any subscriber of the Staff list but not
from any subscriber of the Student list and messages sent to the global list
go to all subscribers of both lists only once
|
Since
it's also the SMTP server, CGP's List module uses what SMTP flow-control
settings are in place.
|
|
Listproc
|
It was
free.
|
|
* We are
actually looking into other software given the dearth of features.
* Lack of
elimination of bogus addresses.
* Automatic
approval for moderated list from owners/moderators based on email instead of
pwd.
* Bad/Lack
of web interface for owners/subscribers.
* Lack of
web interface for creating and deleting lists
* Poor
processing of large lists.
* Unfortunately
only one common email is responsible for the entire groups of lists as an
administrator so shared pwd are required for list creation.
|
Listproc
budgets it in “groups” of emails. As a result, listproc can be slowed by a
single email address being down.
|
|
LSOFT Listserv
|
* It was selected
10 years ago. It has created a culture in commands and about all the
main tool in work collaborative in technical and scientific environments very
successful. His systems of authentication have come being useful during these
years.
* Listserv
has been a part of our service offerings for many years, so inertia plays
a big part in why we still run it. It is, however, still serving our
mission very well.
We
started using Listserv when it ran over BITNET and had no competition. We
continue to use it due to our familiarity with it, it's extensive
feature set, and excellent support.
When
we started, it was the main one we were aware of for our system -
VM/CMS at the time.
The
list service was originally implemented on IBM VM/CMS during the BITNet era. At the time, LISTSERV was the
only MLM product available for that platform. The service was migrated
to Solaris in 1998. At the time, we compared features of several
products and came to the conclusion that LISTSERV still met our needs better
than any other product we evaluated. LISTSERV provided greater
flexibility in list configuration options and a higher level of
automated list management.
|
* web
interface to manage lists
web
archives;
* web
interface for owners to manage lists. most list owners use this
feature as opposed to the email interface .
* By far
the most desirable feature is the web interface for list
management including: access to list archives; subscriber self-management;
list owner management; ListServ mgt. functions.
* The web
interface for list management is used by almost all of our list
owners. Few, if any, use email as the primary tool for list management.
* security,
validation using email address;
* file
transfer system between subscribers ListServ:
* subscription
renewals and probing used frequently by all list confirmations.
* Extensive
set of configuration options available for lists.
* In
contrast to some other MLM products, LISTSERV supports digest and index
as subscription options, rather than requiring individuals to
unsubscribe from one list and subscribe to another in order to switch from
non-digest to digest, or vice-versa.
|
* need
global change of owner address
The main
problems are due to the attributes of the manager/owner to eliminate certain
subscribers
for
incorrect behavior. There should be two managers' levels: technical and
administrative
* No LDAP
support.
* Missing
a general ability to have "dynamic" lists. We'd like Listserv to
have a supported API for that
purpose,
with interfaces provided for LDAP and other common directories.
* No LDAP
support - We have a number of mandatory subscription lists, where
subscription is based on demographic attributes that are available in our
LDAP directory, however, LISTSERV does not have LDAP support, so we must
periodicaly extract the subscribers' email addresses and refresh the lists.
* No
S/MIME support
* no list
request form. we had to grow our own.
* Many
Listserv subscribers and list owners have multiple e-mail addresses, and fail
to realize that Listserv must be made aware of all the addresses they intend
to use with a list. Subscribers must subscribe all the addresses they plan
to use, and then set all but one address to "nomail" to avoid
receiving multiple copies.
|
We use
L-Softs HPO product. It provides multi-threading capabilities allowing
multiple concurrent deliveries. It does not do rate limiting.We typically
don't limit the rate of bulk. In the case of students where primary accounts
reside on our central mail server we leverage the ability to use direct
injection into our mailstore.
No
special controls for large lists. When we spam all the students or faculty,
we typically create lots of lists with about 5,000 subscribers and then
control their delivery by setting prime time parameters in the list headers.
LISTSERV
has no rate-limiting features. LISTSERV supports a "Prime=" list
keyword configuration statement which enables the list owner to prevent
messages from being distributed during "prime time". Most of our
very large announcement lists are configured to allow message distribution
only between midnight and 5:00 a.m. Messages which arrive between 5:00 a.m.
and
midnight are held until midnight.
|
|
Mailman
|
* Open
Source; ease of integration w. other systems; ease of installation.;
* When
selected, it alone had decent web interface. Now involved in
GNU development team (Universidad de Malaga)
* Web
based interface
* Web
interface and features.
* ease
of use by subscribers and list administrators;
* Product
is maintained (moved from majordomo)
* Free
software actively being maintained.
* Password
management.
* Other
Harvard schools are also using it, allowing for consistency.
|
* mass
subscription;
* web
interface for mgt.; subscribers, moderators, & admins.
* Web
Interface
* Easily
web-accessible for most purposes;
* Easy multilingual
support.
* supports
MIME digests and both exportable (UNIX v7) and HTML
archives.
* Scriptable
using python.
* Customization.
We have been able to modify Mailman to suit our needs and the needs of our
users.
* Many
list and subscriber options.
* Ease
of administration and controlling postings.
|
* queued
delivery hard to manage under spam load
* Using a
separate user database has caused problems with staff and students not
knowing what password to use
* Automated
class lists (data from university database updated nightly).
* Does
not integrate with directory services such as LDAP for on-campus
subscribers.
* Largely
web-dependent for most end-user purposes.
* Requires
much scripting using python.
* Mass
replacement of list members.
* List manager
should allow enforcement of posting policy (members only, moderator only).
* Should
Screen spam;
* automatic unsubscribe for frequent bounces; no manual handling of bounced
messages
|
No
apparent threading or parallelism; performance is OK
sorts destination
domain; recipient 'chunks' by domain
Mailman
is configured to split up outgoing mail into smallish chunks, and hand it off
to our MTA
Badly.
Mailman provides some internal queuing, but when it's engaged trouble ensues.
Mostly we depend on sendmail queue management. No external smtp relay
dedicated to lists, so in cases of large mailings or mail loops (which
Mailman has been particularly vulnerable to), the list server plows into the
ground. However, it's quite reliable about not losing messages.
Mailman
sends through the Postfix mail server, which handles the rate-limiting by
monitoring the response times of the receiving server and adjusting the rate
accordingly.
1000 in
SMTP batches.
|
|
MajorDomo
|
* n/a I
was not involved
* long
time experience;
* email
command interface for mgt
* Open
source and at the time of selection was the best supported
Open Source solution
|
stability;
administration via email;
|
* issues
w. attachments on moderated lists
* No new
release or update in several years.
|
Not an
issue
No.
rely on
procmail to manage queue
We have
Precedence=Bulk set in Majordomo
|
|
Sympa
|
* Sympa
was selected for bulkmail services primarily due to its flexibility to
use various databases and LDAP.
* LDAP
integration
* Single
sign-on to
all lists
* Familiarity
of underlying technology
* Performance
with large numbers of lists
|
* the
biggest advantage here for us was the capability to use Oracle and LDAP
to construct on-demand lists.
* LDAP-driven
list membership
Automated
lists are generated for courses, groups of majors, residents of buildings,
and other collections of people, all dynamically maintained out of LDAP data
without any human intervention required.
* Single
service / one login. This is a key feature.
|
* not
much in the way of management tools provided.
* We have
improved the interface somewhat, but the sheer number of options makes it
difficult for casual users to manage list settings. The overall interface
needs a complete usability review.
|
The
software controls the sending rate, and batches by destination host where
appropriate.
|
