On Thu, Nov 11, 2010 at 12:18:52AM -0600, David Champion wrote:
> * On 10 Nov 2010, Will Fiveash wrote: 
> > I've received a message from an iPhone that has a MIME structure as
> > follows:
> > 
> >     1 <no description>               [multipa/alternativ, 7bit, 48K]
> 
> Mutt's attachment counter does not recurse through multipart/alternative
> MIME parts.  See parse.c:1556.  I checked the latest version of this
> patch that I made before it was mainlined 5 years ago.  While several
> things were simplified to get that patch upstream, it has the same logic
> for multipart/alternative.  I'm afraid I don't remember for sure why I
> made this choice, but it's probably because there's no objective basis
> for deciding which alternative in a multipart/alternative should be
> analyzed.  Counting attachments among all available alternatives is
> almost certainly not what a user wants.
> 
> In principle the attachment counter could follow display rules and
> choose the "preferred" alternative based upon alternative_order,
> etc.  This crosses an imaginary boundary between describing the
> absolute structure of the message and making subjective decisions
> about interpretation, but there's nothing logically incorrect about
> it.  However there could be unwated computational expense in that
> approach.  In 2005 at least there was pretty serious concern about the
> computational cost of counting attachments at all, so in order to get
> the code upsteam I took all possible steps to minimize that.

Perhaps there could be a mutt MIME parsing recursion level option that
could be set to restrict the levels of multipart attachments that are
parsed if this is an issue for people?  Of course I have no experience
as to whether allowing recursive parsing is too much of a performance
hit to be usable but in my case it may not be too bad since I'm reading
mail from mbox files that are updated via fetchmail(from IMAP
server)->procmail->mbox files.

-- 
Will Fiveash
Oracle
Austin, TX, USA
Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com
http://opensolaris.org/os/project/kerberos/

Reply via email to