Summary | forwarding multipart/related messages |
Queue | IMP |
Queue Version | 4.0.3 |
Type | Enhancement |
State | Rejected |
Priority | 1. Low |
Owners | |
Requester | robin.west (at) dal (dot) ca |
Created | 08/30/2006 (6905 days ago) |
Due | 08/30/2006 (6905 days ago) |
Updated | 09/03/2006 (6901 days ago) |
Assigned | |
Resolved | 09/03/2006 (6901 days ago) |
Milestone | |
Patch | No |
State ⇒ Rejected
ticket 3381.algorithm that is in HEAD (the CVS version).
Michael, would you say this falls under the same umbrella, or is
multipart/related entirely seperate from multipart/alternative?
elsewhere, the only way we can guarantee accurate forwarding of a
message is embedding via a message/rfc822 part - which is one of the
forwarding options offered in HEAD.
State ⇒ Feedback
algorithm that is in HEAD (the CVS version).
Michael, would you say this falls under the same umbrella, or is
multipart/related entirely seperate from multipart/alternative?
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ forwarding multipart/related messages
Due ⇒ 08/30/2006
Queue ⇒ IMP
State ⇒ New
well-versed on what the proper standards are for how this stuff should
work, but I've noticed various different behaviours amongst mail
clients when forwarding multipart messages. Specifically if I have a
multipart/related message (eg. some HTML with an embedded image), when
I forward it (to myself) I get these results:
Outlook Express:
---multipart/related
------text/plain
------text/html
------image/gif
Thunderbird:
---multipart/mixed
------text/plain
------message/rfc822
---------multipart/related (containing all parts of the original message)
IMP Webmail:
---multipart/mixed
------text/plain
------multipart/alternative
---------text/plain
---------text/html
---------image/gif
------text/html
------image/gif
I'm not sure which of these examples follows the "standard" (is there
a standard?). However, IMP's result seems to include an extra copy of
each part of the original message, and the original copy seems to show
up as a text/plain section when viewed. Is there improvement that can
be made here that would make IMP's forwarding behaviour more closely
match that of Outlook's (which seems to produce a pretty clean result)?
I took a look at
ticket 3381, but most of the discussion there is tootechnical for me so I can't tell if this issue is related to that one.
I also took a look through the release notes for v4.0.4+ (we're still
on 4.0.3) but didn't see anything relating to this. If changes have
been made that address this issue please disregard. Thanks.