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

[John Viega]

On Fri, May 01, 1998 at 09:20:41AM -0500, The Dragon De Monsyne wrote:
> 
> Aha!! a mailman developer's list!! 
>  
> Apparently I was in the same position as Ken Manheimer, with regards to
> MailMan. When the origional Mailman web sites & lists dissapeared, and
> didn't come back, I thought the author had abandoned development, and
> continued hacking at MailMan for my own use. 

Well, Ken and I were still in contact.  I guess it's too bad you
didn't contact me then, as we could have had your work integrated
already and made things a bit easier on you.

> Added Makefile to make & install all the wrappers. Earlier versions of 
> 	this were posted to the previous MailMan dev list. Things have
> 	been improved since. 

This one has been done.

> Removed  all dependance on MailMan being in /home/mailman. 

This one I was going to do in the near future.  I am glad that I did not :)

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

Hmm, I wrote a basic smtplib a few months ago with the intent of using
that instead of a call to sendmail, and I think I saw a cvs checkin
from Ken that actually replaced the sendmail call.

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

Cool.

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

You might want to check the archives of this list on this topic, as
we've discussed it recently, and agreed that we don't find it
desirable for us.  However, in thinking about it, I see no reason why
it couldn't be added as an option if the list administrator seems to
prefer it.

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

That's good.  I'd been moving in that direction when that disk crash occured.

> 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 reasonable, though I'd like to see it...

> Hopefully all this work wasn't redundant :>

For the most part, not!  My only concern is keeping the amount of work
necessary for integration on your part as low as possible.

John