Re: parsemail rewrite

From: John Finlay <>
Date: Fri, 23 Apr 1999 13:41:51 -0700
Message-ID: <>

Daniel Stenberg wrote:

> On Fri, 23 Apr 1999, John Finlay wrote:
> > Just to follow up on my previous message. My thinking is that the
> > strategy of parsemail is to extract each email message as a whole
> > breaking it into header and body sections but not doing further
> > processing of the body until later. This is simple and straightforward.
> I agree that it sounds simple and straightforward eoungh, only a tad too much
> memory consuming for my taste.

I assume that you are referring to the pathological case you mention below. I notice that the current code drops a lot of attachments. Is this done because of these concerns?

> > During the printing of the messages, the message decoding and MIME
> > decoding of the message bodies would be done (though this can be done any
> > time after it is decided to save the message.
> Consider the case when reading a mail with 10MB mime attachment. I say it
> needs to be stored while read, while your version would alloc memory for this
> beast and keep it in memory for a while until later. What if you read a
> mailbox with a 100 of such attachments...?

I suspect that this would be a problem in any case for lot of mail systems, receivers, etc. I don't believe that this size attachment occurs frequently in practice - I would think that many email gateways would choke. The largest attachment I've ever received was about 2MB but maybe I've been lucky. In any event I don't think that 10MB by itself is much of a problem though I take your point about letting hundreds of these stack up. This would argue for disposing of attachments soon after basic message extraction. The incremental mode would fare much better by only having to deal with one of these beasts at a time.

I'd like to avoid as much of the complexity of the current parsemail by deferring the depth first message extraction as long as possible. I believe that the proposed strategy will work perfectly in 99.99% of the cases and degrade performance only in the case of a mailfile with lots of large attachments.

> > I'm not sure I completely understand the handling of multipart messages
> > especially when they are recursive (e.g. multipart/digest). Is it the
> > intention to handle these fully i.e. multipart messages inside multipart
> > messages? the comments seem to recognize the problem but it's unclear to
> > me whether full recursion has been implemented.
> I don't think multipart/digest is fully supported, no.

Is it the goal to support all of the MIME types fully as the effort progresses?

John Received on Fri 23 Apr 1999 10:41:33 PM GMT

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