Help build the new GNHLUG Internet server

[Steven W. Orr]

On Friday, Feb 10th 2006 at 10:02 -0500, quoth Jeff Kinz:

=>On Fri, Feb 10, 2006 at 09:36:03AM -0500, Steven W. Orr wrote:
=>> May I strongly urge you to not use Mailman and to instead consider 
=>> Majordomo2 (see: http://www.mj2.org) 
=>> 
=>Steve, could you give up some more info about why Majordomo2 is a better 
=>maillist manager?
=>
=>Are there certain features we would want to use, or is it efficient in
=>terms of machine resources, or more secure, or more spamproof?

On Friday, Feb 10th 2006 at 10:29 -0500, quoth Bill McGonigle:

=>On Feb 10, 2006, at 09:36, Steven W. Orr wrote:
=>
=>> It is a better mailinglist manager.
=>
=>Fill in here the ways mailman is insufficient for our use or things that
=>Majordomo would let us do that we can't.
=>
=>> It suffers from not getting enough use
=>> compared to what Mailman was able to achieve with Red Hat having been the
=>> promoter.
=>
=>I remember when Mailman was new and we all jumped at the chance to get away
=>from majordomo.  That's why Redhat included it.  I was just debugging a
=>Majordomo setup for a client last week and bemoaned that they weren't on
=>mailman, which I've found much easier to setup and customize.  For their setup
=>Majordomo didn't offer any benefits, but maybe they exist for other
=>requirements.
=>
=>> I use it here on syslang for the dozen odd lists I run. My
=>> biggest list is about 800 people and it works really well.
=>
=>FYI, mailman scales to about 10K per list.  After that 'python pickles' get in
=>the way and it falls apart.  I've done some research lately for a client with
=>a 120K customer mailing list and the solution seems to be to use the mysql
=>backend to avoid python pickles.   You can also chain 'umbrella lists' but
=>that's somewhat of a hack.  Mailman 3 is also listed as a solution but that
=>appears to be vapor, currently aimed at being a Zope personality.  My
=>goodness.

Good questions. Also very hard to answer. Picking list software is very 
hard because to do it correctly you have to become somewhat expert in all 
of the candidates.

If the goal is to build a new server with the least amount of work then by 
all means, you should stick with what you know. If you'd like to learn a 
few tricks then you might want to consider this.

The entire structure of mj2 configuration is object oriented. The specific 
configuration of a list is simply an instantiation of characteristics that 
are inherited. There is a GLOBAL conf as well as a highly flexible DEFAULT 
conf. Yes, it's called Majordomo with a 2 at the end but it is not related 
to the old Majordomo which has not seen any development in well over a 
decade. It does have a good web interface built in and it is very secure 
as most lists are. The number of parameters that are available for 
tweaking by the sysadmin is extremely rich. Very fine controls for things 
like bounce management, spam control, moderation, digests, headers, 
footers, and I could go on for hours.

Here's an example that some might find sexy:

The goal (for me) is to end up with a list that does not allow 
attachments. That way people are guaranteed to not get a virus in the 
mail.

configshow frambors config_defaults <<ENDAAQ
plaintext
rfc2369
ENDAAQ

What is plaintext you ask? The snip below defines the attachment_filters 
value for the DEFAULT:plaintext instance.

configset DEFAULT:plaintext attachment_filters <<ENDAAC
text/plain | allow
/./ | discard
text/html | format
text/enriched | format
ENDAAC

configset frambors attachment_rules <<ENDAAL
text/plain | require
ENDAAL

configset frambors comments <<ENDAAO
The plaintext template defines attachment_filters (which transform
messages)
and attachment_rules (which determine whether messages should be sent,
forwarded to the list-owner for consultation, or rejected).

The attachment_filters in this template are as follows:

        text/plain | allow
        /./ | discard
        text/html | format
        text/enriched | format

...which, in order, mean:

1) If there is a plaintext part, pass it through as-is.
2) Take all parts and discard them.  Discards only happen if there are
   no other parts, so a message that contains only text/html or
text/enriched
   will not be discarded by this part.  (Neither will any sort of
non-text
   part that is the only part; that will be handled by the
attachment_rules.
3) If there's an HTML part, render it to plain text.
4) Similarly with an enriched text part.

Then the attachment_rules are applied:

        text/plain | require

That is, if a message doesn't have a text/plain section (either by
starting out
with one, or by having HTML or enriched text rendered to plaintext),
kick the
message out for consultation.

ENDAAO

So just by adding the plaintext attr to the config_defaults configuration 
setting, it is done.

:-)