Re: MIME disposition

From: Paul Haldane <Paul.Haldane_at_newcastle.ac.uk_at_hypermail-project.org>
Date: Fri, 23 Apr 1999 11:26:34 +0100 (GMT)
Message-ID: <Pine.GSO.3.95-960729.990423102750.28336B-100000_at_carr6.ncl.ac.uk>


On Fri, 23 Apr 1999, Daniel Stenberg wrote:

> On Thu, 22 Apr 1999, John Finlay wrote:
>
> > It's been my experience during some limited testing that the current
> > hypermail 2a18 doesn't correctly parse mail files that include MIME
> > headers. For example, I used 4 mailfiles each containing 800 to 1000
> > messages as a test . The results varied widely but I found that the
> > resulting archives contained between 130 and 400 messages. This seems
> > like a rather substantial loss.
>
> It does indeed. Although it is likely to be because of just one or a few bugs
> that cause many mails to vanish.
>
> > Looking at the code it seems that messages without a message id are
> > tossed. Duplicates are also discarded. Other than that I don't see why
> > the other messages have been discarded. Any ideas?
>
> No...

I've not noticed losing other messages. Handling messages without message-id isn't a problem for me because of the way we construct our mail archives.

Duplicate message-ids _shouldn't_ be a problem - after all message-ids are meant to be unique - in the real world of course, we know that they sometimes aren't - I had to put special case code in the loop detection code of the MLM I was maintaining to not do duplicate msgid checks if the msgid ended _at_MAPI.to.RFC822 :-<. There was also a version of pine that generated duplicates under some circumstances (same machine, day, minute, second, different hour? - something like that).

Hypermail shouldn't drop messages on the floor without letting the user know.

It may be problematic with the current structure of Hypermail to cope with different messages with the same msgid. I think quite a lot of it assumes that there's a 1-1 mapping between msgid and message.

> > I find it almost impossible to understand. Consequently, I plan to
> > rewrite parsemail for correctness and readability and to make future
> > enhancement easier. At the same time I will add in the performance
> > improvements, etc. that I developed for the 1.02 release.
>
> I'd love to see that happening! We have a lot to gain by cleaning up that
> function since that is the very heart of the email parsing in hypermail.

> > One the items that local users have asked for is a kill capability to
> > allow killing messages from specified senders and to allow killing
> > messages not directly addressed to the receiver. This functionality seems
> > like it probably is available elsewhere. Has someone a pointer to a
> > filter program that can be used before processing by hypermail.
>
> I think this sounds like a perfect job for 'procmail'.

...or MailAgent (mail filtering done in perl - available from CPAN archives)

Paul Received on Fri 23 Apr 1999 01:14:55 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT