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

[The Dragon De Monsyne]

On Fri, 1 May 1998, Ken Manheimer wrote:

> 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.

	Good! 

> > 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.)

	I have two mailman users, 'mailman' & 'mm', and separate base
urls, etc. The neccesary magic to make it all work is this line at the
begining of the scripts:

sys.path.append(os.path.join(pwd.getpwuid(os.geteuid())[5],
		"mailman","modules")) 

A bit ugly, but it works.( a package would be more elegant, of course. )

> 
> > 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.

	Shouldn't be too difficult. What I did was very simple. Basically
just re-directing stderr to a file in ~/logs named for sys.argv[0]
The syslogish thing you have (now that I look at it) is a much more
compleate solution. 
> 
> > (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!

	This was one of my first 'big' projects with mm. It helped
preformance quite a bit on my system. 

> 
> > 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...

	Yup. It's fairly simple (just based on whrandom) but it works
nicely. 

> 
> > 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.

	Yah. I had a list with it, and they kept getting 
"prefix Re: prefix Re: prefix ...." I munge the subject before the prefix
gets put on the outgoing message, so the prefix winds up first. The
problem with having the Re first, is then filtering dosen't work.  


> 
> > (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.)

Yup. I may be tweaking the code a bit on this before diving in in earnest
to try to integrate things (I have a circular ref I'd like to eliminate,
and I just saw a very nice way to do so today. ) but basically my idea was
this: I wanted to have hierarchy of objects here. You start with a
Server object that manages all server-wide info. you can get Mailinglist
objects from the Server object (like Server.GetList("foolist") ), that
handle all list-wide info, and you get User objects from the Mailinglist
that handle all User specific stuff.

	Right now, I've just finished/am finishing the User object
addition, and havent gotten to the Server object yet.  

> 
> > 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...
> 

	Hmmm.... Well, I will admit, flexibility was higher in my mind
than preformance, however the UserDB object that manages quering the shelf
full of User objects does do some caching using dictionaries. That should
make the impact minmimal.  


	-The Dragon De Monsyne