bugMHonArc - Bugs: bug #15415, mhonarc eats part of a message

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #15415: mhonarc eats part of a message

Submitter:  Jeff Breidenbach <jab>
Submitted:  Tue 10 Jan 2006 05:28:04 AM UTC
   
 
Category:  Mail Parsing Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Undesired Behavior
Status:  Invalid Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  All Perl Version:  5.8.4
Component Version:  2.6.15 Fixed Release:  N/A

Jump to the original submission

Sat 26 Aug 2006 01:41:12 AM UTC, comment #9: 

The HTML is malformed, causing the HTML filter to remove
almost all of the content.

The HTML has duplicate <head>...</head> sections, with the
dup at the very end of the HTML part of the message.  MHonArc
removes the <head> component, and the regex is greedy, so
it deletes everything 'til the last </head> tag.  Unfortunately,
for this message, the last </head> tag appears near the
end of the message since the the dup <head>...</head>
occurs after the </body>.

I'm unsure how you would like to proceed.  The HTML filter
could be made more robust to deal with such abominations, but
it may impact performance.

Since this problem is separate from what this bug item is
initially about (and this item is currently closed), I
request you submit a new bug.  You can use for the description
my explanation of the real problem described above.

Earl Hood <ehood>
Group administrator
Mon 21 Aug 2006 03:53:06 AM UTC, comment #8: 

I just attached a file that has the same symptoms;
"show" from nmh can't see the message nor can mhonarc.
It's also multipart/alternative. However, I'm not seeing
a telltale double text/html section.

This is a YahooGroups message.

Jeff Breidenbach <jab>
Mon 20 Feb 2006 08:43:08 PM UTC, comment #7: 

Closing bug since it is a Lyris problem and not a mhonarc
problem.  Any further discussion can be done with whatever
tracking system Lyris provides.

Earl Hood <ehood>
Group administrator
Mon 20 Feb 2006 08:25:22 PM UTC, comment #6: 


> Ok, we've pretty much confirmed that the blame goes to the list
> server software (Lyris). Do you know the version number of the
> software? Do you have contact info for the person administering
> the list server?
>
> I'm going to contact the vendor, but that information will be
> helpful.


I don't know the version number. Our listowner is Bill Southerly and he can be reached at bsoutherly [AT) frostburg (dot] edu

Jeff Breidenbach <jab>
Sun 19 Feb 2006 06:05:54 PM UTC, comment #5: 

Due to not being fulling awake, I had a brain fart and deleted
the AFTER attachment you posted.

However, based upon the first message you attached, here is what
I believe is going on:

The original message is structured as follows before going
through list server:

  multipart/alternative
    text/plain
    text/html

The list server is configured to add a footer to each outgoing
message, with the list server trying to be MIME-aware by adding
the footer as a MIME entity in the desire for it to render in
the MUA.

Unfortunately, it appears the list software does not handle
multipart/alternative messages correctly.  When such a message
occurs, the list software creates:

   multipart/alternative
    text/plain
    text/html
    text/plain (footer)

And multipart/alternative semantics state that the MUA takes
the last-most entity it can render, which is the footer in
this case, and not render the other parts.

If the root media-type was multipart/mixed, there would
be no problem.  For the list software to do things right,
and still want the footer to be rendered in the MUA, it needs
to do the following with multipart/alternative messages:

   multipart/mixed
     multipart/alternative
       text/plain
       text/html
     text/plain (footer)

I.e. The message body must be wrapped in a multipart/mixed,
with the original m/a entity as the first part and the added
footer as the second part.

Earl Hood <ehood>
Group administrator
Sun 19 Feb 2006 12:33:41 AM UTC, comment #4: 

Ok, it's interesting. The program "show" from nmh does not like the  message after it had gone through Lyris. But comparing the two messages ('before' and 'after') line by line, I'm not sure exactly what went wrong. Earl, can you point out the problem a little more explicitly? I'm ready to send a bug report over to Lyris, but I'm not exactly sure what to point at.

Jeff Breidenbach <jab>
Sun 19 Feb 2006 12:15:47 AM UTC, comment #3: 

I had the poster send a message to the list, and also put me personally on the BCC: line. The goal was to find out where the problem occurred. Mhonarc is quite happy with the message until after it goes through the list server. Current hypothesis: list server is doing something bad. List server appears to be LYRIS according to headers.

Jeff Breidenbach <jab>
Thu 12 Jan 2006 07:25:31 PM UTC, comment #2: 
[Not a Bug]

The message that is not formatted as expected.  All parts
are part of a single multipart/alternative entity.  MHonArc
correctly renders only the last part.  MH/nmh's show command
and Mozilla do the same thing as MHonArc.

It is possible that the list restructured the original message,
losing the nested multipart construct that should be present.

Earl Hood <ehood>
Group administrator
Tue 10 Jan 2006 05:37:51 AM UTC, comment #1: 

I suspect this is due to the unusual triple MIME section (text/html/text) MIME sections and may be actually be a mhonarc buglet. Probably the MUA is providing the first two sections, and the list server is tacking on the third.

Jeff Breidenbach <jab>
Tue 10 Jan 2006 05:28:04 AM UTC, original submission:  

It's a little weird, mhonarc appears to be consuming messages from a particular list poster. It tends to eat everything but the footer of the message. I am not sure if there is corruption involved in the message body, but I'm definitely not seeing any warnings from mhonarc. See attachment for raw message in MH format.

Jeff Breidenbach <jab>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #10562:  9138.gz added by jab (10KiB - application/x-gzip - very similar symptoms)
file #1898:  after added by jab (6KiB - application/octet-stream - message AFTER going through list server)
file #1897:  before added by jab (8KiB - application/octet-stream - message NOT going through list server)
file #2220:  9008 added by jab (10KiB - application/octet-stream - Message that triggers problem)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 13 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-08-21 jab Carbon-Copy- Added -email is unavailable-
2006-08-21 jab Attached File- Added 9138.gz, #10562
2006-02-20 ehood Open/ClosedOpen Closed
2006-02-19 jab Attached File- Added after, #3421
2006-02-19 ehood Attached File#3417 Removed
2006-02-19 jab Attached File- Added after, #3417
2006-02-19 jab Attached File- Added before, #3416
2006-01-12 ehood StatusNone Invalid
    Perl Version5.8.4 5.8.4
    Fixed Release N/A
2006-01-10 jab Carbon-CopyRemoved -email is unavailable- -
2006-01-10 jab Carbon-Copy- Added -email is unavailable-
2006-01-10 jab Attached File- Added 9008, #3262

Back to the top

Powered by Savane 3.13-02a9.
Corresponding source code