[Mailman-developers] Found it! (I have a divergent version of MailMan)

[Ken Manheimer]

Mr dragon,

It looks like we've got a nice synergy here - a number of the items you
attacked are things i wanted to do, but did not yet do, while i (and now
we) have taken care of a number of other things.  (Most of the big
things are mentioned in the notes i included in the distributions.)

On Fri, 1 May 1998, The Dragon De Monsyne wrote:

> 	I have made numerous changes to the code as a result. Now that I
> am aware that MailMan is being actively developed, I would like to see
> what I can do about merging these versions together. 

As barry mentioned, we're planning to make a cvs view of our version
available across the net sometime soon.  I should add that we will need
to clear some admin issues first, so it's not guaranteed, but likely.

> 	I started with a copy of Mailman 1.0b1. Because I was unsure of
> the status of MailMan, I have been calling my version DMM (the Dragon's
> version of MailMan), and the python modules I have added start with 'dmm_'

I suspect that we started at the same place.  Not sure whether there
were any micro-releases or such that would lead to version skew.

> 	I haven't yet had the time to download & go over the 1.0b2.0 (that
> is the most current version ?) sources, to see what things I've done may
> be redundant, (I will this weekend) but here is a list of the changes that
> I've made (that I can think of so far): 

That is the latest version.  I may release a patch with my latest
hacking over the weekend, if i have time. ( Mostly bug fixes, some
refinements - mime digest format, bounce handling, admin-option help.) 


> Removed  all dependance on MailMan being in /home/mailman. 
> 	I made sure all scripts were always being run as the MailMan user,
> then used the pwd module to find the current user's home directory. 
> Everything else is found from there. (I did this so I could have two 
> MailMan installs on one machine, a 'production' server, which runs several
> lists, and a development server) 

Relaxing the /home/mailman rigidity is high on my list!  My ideal would
be to have as much as possible be in a package or use relative paths
(which have the same effect - independence from location of the root). 
Unfortunately, i have a few other things on my agenda before that, so
i'm not sure when i'll get to it.  (High up is gettings things like the
admin pages behind a cookied password, another item is making sure that
a single mailman install can use different addresses for the host for
different lists - os, eg, ISP clients with their own domains can use
their domains for their mailman lists...) 

(I'm confused about how working with respect to the ~mailman homedir
enables you to have to install's, btw.)

> Re-did logging system. Removed all /tmp logging. Created module that
> 	redirects errors to files in ~/logs  Error log files are named for
> the scripts (thus errors from admin show up in ~/logs/admin.err) This is
> done automatically by importing the logging module. 

This is a place where we completely overlapped - and came up with
similar answers, at least in the abstract.  I also used ~mailman/logs,
but am using a few categories of logs - bounce, vette, subscribe,
digest, and error.  Error gets the errors from bugs in any of the
scripts, so you can just check the file periodically to see if anything
is malfunctioning in a way that is caught...

I guess we'll have to reconcile the two approaches.

> (major) Compleatly changed the way outgoing mail gets sent. 
> 	Did much re-writing of mm_message & mm_deliver modules. Both
> OutgoingMessage & IncomingMessage are now derived from a common base
> class, ListMessage. Sending is accomplished by calling send method of
> message object. 
> 	Mail is no longer sent by piping to 'sendmail'! Instead, outgoing
> messages are punted to a mailserver (currently always localhost)
> via SMTP. I wrote an SMTP module, smtplib to do this. smtplib is now part
> of the python standard library as of 1.5.1  

As barry also mentioned, this is one of the things up there on my
"desired" list - but it never was high enough urgency to percolate to
the top.  (John actually sent me an smtplib.py that he was playing with,
but i never took the step of hooking it up.)  I'm glad you've done this,
and that it uses something you've gotten into the distribution!

> Added random-mnemnonic password generator. Instead of passwords like 
> 	'qZ', AOL-like random-word passwords are generated (like
> 	'cold-blue-tiger') 

That's nice!  People won't have to visit the site to either select
reasonable passwords, or have their unmemorable one's sent to them...

> Added multiple subject: prefix removal and Re: compaction 
> 	changes subjects like:
> 	"Re: Prefix Re: Prefix Re Something"
> 	to "Prefix Re[3]: Something"

Me too, except i didn't do any munging of the Re, and in particular
leave the Re before the prefix so mail readers sort threads
appropriately.  I'd rather avoid the fancy Re stuff, with the idea that
mailman should do as little intrusion as possible to the content.

> (major) Changed the way user data is stored (still tying up loose ends on
> 	this)
> 	Created a User class. User data is no longer stored in the
> config.db file. Instead there is a shelf full of User objects. 
> The main Mailinglist object contains an instance of a UserDB class that
> manages storing, retrieving & quering this database. Most of the *User*
> methods of the Mailinglist class have become methods of the User class.

If you're saying what i think you're saying, this is a real biggie, one
which i've dearly wanted to see happen if i didn't get to it myself.  (I
think john had something like it going in a later, lost version of
mailman, and i know a number of us have expressed interest in it.)

> Changed the way user options are handled. Options are referenced by name
> 	(a string) and can be Boolean or "multiple-choice" values. Info on
> available options & allowed values for them are available via methods 
> of the User objects. I compacted the 'Digests', "DisableDelivery" and
> "EnableMIME" options into one multiple-choice "delivery_mode" option."

Sounds cool, provided there's no scaleup-defeating performance hits. 
We've got some people on this list interested in handling lists of
several thousand members...

> There  have prolly been soem bugfixes too. 
> 
> Hopefully all this work wasn't redundant :>

Mostly not!

ken manheimer
klm@python.org