Mailman 3 January 1999 - Mailman-Developers

Mailman archive and MIME
by Tomas Fasth Jan. 25, 1999

Jan. 25, 1999

Hi. Are there anyone on this list currently working on a MIME fix for mailman pipermail archiving? It currently (1.0b8) lack even the simplest MIME support, as far as I understand. If you browse a pipermail archive any MIME composed messages appears right out ugly and sometimes unreadable (a matter of skill of course). There are at least two angles on this. One is that when MIME encoding (quoted-printable,base64) has been applied it looks messy in raw format. The other is that some mailers (outlook express...) can be configured to send multipart/alternative with message in both HTML and plain text versions. Looks even more messy in raw format. I know you guys are working hard to get a stable release of 1.0 out on the streets. But before that happens I highly recommend to have this particular issue addressed somehow. My point is: making a stable release of a email/web based software in the year of 1999 without basic support for MIME is a big shame. Hopefully, I am plain wrong about the whole issue. May be I have missed the obvious. Of course, it is my hope that someone already have a solution on the problem, or working on one. If not, as a last resort, I may volunteer but not before a few weeks from now. Comments, any? Tomas

4 5

Posting bug
by Balazs Nagy Jan. 24, 1999

Jan. 24, 1999

Hiyas, Three days ago I downloaded the latest CVS snapshot and I applied my patches to it. Now my users reported that their letters didn't posted to the list. I found that there's an error in MailList.py (I think). These fast fixes comes from experience and not from evidence :-> --- MailList.py.orig Mon Jan 11 09:33:44 1999 +++ MailList.py Mon Jan 18 15:33:35 1999 @@ -1140,7 +1140,7 @@ members = self.GetDeliveryMembers() if dont_send_to_sender: try: - recipients.remove(members) + recips.remove(members) # # sender not in list (case sensitive username problem?) # @@ -1149,14 +1149,14 @@ "couldn't remove %s from recipient list: %s", sender, str(members)) - recipients = [] + recips = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): - recipients.append(m) + recips.append(m) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) - self.DeliverToList(msg, recipients, + self.DeliverToList(msg, recips, header = self.msg_header % self.__dict__, footer = self.msg_footer % self.__dict__) if ack_post: -- #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

2 1

commercial maillist system, lyris, looks rather similar
by Ken Manheimer Jan. 24, 1999

Jan. 24, 1999

I just heard mention of a commercial mailling list manager, lyris, that upon a tiny bit of investigation looks similar in some ways to mailman - eg, the admin interface layout: http://www.lyris.com/demo/list/listinfo.html (listinfo?), the orientation on web interfaces, "automatic error handling" (bounce handling), built-in archives, built-in mail engine (for "blinding speed"), etc. From poking around a little, it looks like they use perl at least as an extension language - i wonder how it's built. I'm pretty curious how long it's been around - they claim that: "Lyris was the first email list server to offer a web interface for list administrators and members." so i wonder if it predates the mailman betas. (I also noticed the phrase No more "get me off this list!" messages. on the lyris "about" page (http://www.lyris.com/about.html), , framed as "failsafe unsubscribing" - i think i saw this phrase in a recent mailman-users posting, i would not be surprised if the poster saw it there...) It has some nice stuff that mailman doesn't - one interesting idea seems to be to use a news server for the archives. That way, archive browsers can use a news interface, or use a web browser to a news/web gateway. (They probably do not do exactly this - the mail interface is a separate product, "multi view", so i'm probably missing something...) Wish i had more time to investigate, if anyone does, please report back... Ken Manheimer klm(a)digicool.com

2 1

Re: [Mailman-Developers] An upgrading experience
by Janne Sinkkonen Jan. 23, 1999

Jan. 23, 1999

Some clarifications to my earlier blurb: > - I had some archives, but after running 'make update' a few times, > they are gone. Instead I have symlinks (list, list.mbox - yes both are > symlinks) in the archives directory pointing to > public_html/archives/*. But public_html/archives does not > exist. This was partly incorrect and I did find the archives from $prefix/archives/private. > Further, apparently new messages do not get archived now, at least I > can't find them anywhere. Should the mailboxes reside in the > $prefix/archives directory? Actually they do get archived, no problem here. It seems that I should have mailed to the mailman-users list first or checked things more carefully. Sorry... -- Janne

1 0

An upgrading experience
by Janne Sinkkonen Jan. 23, 1999

Jan. 23, 1999

I just upgraded from 1.0b4 to the latest b8 (CVS snapshot). It went mostly fine. Some problems though: - Python 1.5 doesn't have smtplib.py. Python 1.5.1 does. The documentation claims that 1.5 is good enough. - When I try to edit HTML through the WWW interface, I get an attribute error about Error.MMBadPassword (or some such). Is this a bug, or are my mailing list objects too old? - in update.log mailman says templates seem like pre-b4. Do I need to upgrade them manually, or does it just meant the templates were in wrong directories? - I had some archives, but after running 'make update' a few times, they are gone. Instead I have symlinks (list, list.mbox - yes both are symlinks) in the archives directory pointing to public_html/archives/*. But public_html/archives does not exist. Further, apparently new messages do not get archived now, at least I can't find them anywhere. Should the mailboxes reside in the $prefix/archives directory? Just out of curiosity, I tried to run the $prefix/cron/archive script manually (writing "python archive 1"). The current crontab does not seem to call it. It complains: Traceback (innermost last): File "archive", line 55, in ? if level <= list.archive_update_frequency: AttributeError: archive_update_frequency Does just loading and saving all the mailing lists help, or should I set archive_update_frequency manually? -- Janne

1 0

Re: [Mailman-Developers] Mailman archive and MIME
by Tomas Fasth Jan. 22, 1999

Jan. 22, 1999

From: Harald Meland <Harald.Meland(a)usit.uio.no> Date: den 22 januari 1999 01:02 Subject: Re: [Mailman-Developers] Mailman archive and MIME >Unless there is some standard Python module for doing this, I opt for >leaving it all out until after 1.0 is out -- we might as well do this >Right from the start. Have a look at http://www.oac.uci.edu/indiv/ehood/mhonarc.html It's written in Perl but even so a good piece of software when it comes to graceful handling of MIME messages. >Do include all of RFC2045 when you say "the basics of MIME body >format"? I really can't see the benefit of e.g. parsing >multipart/alternative messages and such when formatting them as HTML. Again, take a look at http://www.oac.uci.edu/indiv/ehood/mhamimeeg/complex.html for an example on how it could be handled gracefully. The example is way to it's extreme but still... Tomas

1 0

Re: [Mailman-Developers] Mailman archive and MIME
by Harald Meland Jan. 21, 1999

Jan. 21, 1999

[Tomas Fasth] > From: Harald Meland <Harald.Meland(a)usit.uio.no> > > >I haven't tried this, but wouldn't simply squeezing the mail text > >through the .unmimify() method of the `mimify' standard Python module > >before formatting it into HTML work (for the QP/base64 MIME issue, > >multipart messages is a whole other can of worms)? In the general case it wouldn't, unless there also was some kind of 8bit-character-set -> HTML representation thingy, i.e. something to convert the ISO-8859-1 character "å" into the HTML element "å". Unless there is some standard Python module for doing this, I opt for leaving it all out until after 1.0 is out -- we might as well do this Right from the start. > That's probably one way to go. A good thing trying to use existing code. I'm > not sure what exactly .unmimify() does, though. It converts quoted-printable (and optionally base64) encoded parts to 8bit parts. I does not format it as HTML, though. It also does nothing with regard to "Content-Type:"-type things. > The minimum requirements for messages written in western european > languages would be for the archiver's email-to-html conversion to > honor the MIME header encoding (RFC 2047) and the basics of MIME > body format (RFC 2045). Do include all of RFC2045 when you say "the basics of MIME body format"? I really can't see the benefit of e.g. parsing multipart/alternative messages and such when formatting them as HTML. > >Is there a problem with what headers are retained in the mbox-format > >version of the archive (i.e. are the headers needed for proper MIME > >decoding stripped from the archive)? > > Not as far as I can see. Both Content-* and MIME-Version headers > seem to be retained. Duh, just me looking in the wrong place -- indeed, the listname.mbox/listname.mbox archive does include all headers. BTW, is there any way of configuring which headers (if any) should be removed when generating the static downloadable text files? -- Harald

1 0

Re: [Mailman-Developers] Mailman archive and MIME
by Tomas Fasth Jan. 21, 1999

Jan. 21, 1999

From: Harald Meland <Harald.Meland(a)usit.uio.no> Date: den 21 januari 1999 13:16 >I haven't tried this, but wouldn't simply squeezing the mail text >through the .unmimify() method of the `mimify' standard Python module >before formatting it into HTML work (for the QP/base64 MIME issue, >multipart messages is a whole other can of worms)? That's probably one way to go. A good thing trying to use existing code. I'm not sure what exactly .unmimify() does, though. The minimum requirements for messages written in western european languages would be for the archiver's email-to-html conversion to honor the MIME header encoding (RFC 2047) and the basics of MIME body format (RFC 2045). >Is there a problem with what headers are retained in the mbox-format >version of the archive (i.e. are the headers needed for proper MIME >decoding stripped from the archive)? Not as far as I can see. Both Content-* and MIME-Version headers seem to be retained. The problem occurs when the static html pages are generated. Tomas

1 0

Re: [Mailman-Developers] Mailman archive and MIME
by Harald Meland Jan. 21, 1999

Jan. 21, 1999

[Balazs Nagy] > On Wed, 20 Jan 1999, Tomas Fasth wrote: > > > Hi. > > > Are there anyone on this list currently working on a MIME fix for mailman > > pipermail archiving? It currently (1.0b8) lack even the simplest MIME > > support, as far as I understand. If you browse a pipermail archive any > > Not just the pipermail archiving lacks any mail support but admindb > too. I think that's a separate issue -- you're talking about quoting special HTML characters. Which, of course, should be done -- but it hasn't got anything to do with MIME. > > MIME composed messages appears right out ugly and sometimes unreadable (a > > matter of skill of course). I haven't tried this, but wouldn't simply squeezing the mail text through the .unmimify() method of the `mimify' standard Python module before formatting it into HTML work (for the QP/base64 MIME issue, multipart messages is a whole other can of worms)? Is there a problem with what headers are retained in the mbox-format version of the archive (i.e. are the headers needed for proper MIME decoding stripped from the archive)? -- Harald

1 0

Mailman logo submission
by Barry A. Warsaw Jan. 19, 1999

Jan. 19, 1999

Hi folks, we have our first Mailman logo submission! Heidi Henderson has contributed a very cool logo -- see www.list.org for the large and small version. -Barry

1 0