[Users] Question regarding forward of HTML e-mails

[Michael Gmelin]

On Sun, 12 Aug 2012 18:18:54 +0200
Colin Leroy <colin at colino.net> wrote:

> On 12 August 2012 at 17h40, Michael Gmelin wrote:
> 
> Hi, 

I revisited the previous patch again (turning additional text
parts into named disposition attachment).

I think it would make sense to exclude "text/plain" from this mechanism.

I just received the mail I wrote earlier from the mailing list,
which contains:

rfc/822
 plain/text (my message)
 plain/x-patch (the patch)
 plain/text (the footer added by the mailing list)

When looking at this email in claws it shows as:

My Text
[messageview.patch  text/x-patch (590 bytes)] 
Claws mailing list footer

Now, if I forward this email, the second plain/text is turned into an
attachment and the resulting email looks like:

My Text
[messageview.patch  text/x-patch (590 bytes)] 
[Original plain part  text/plain (153 bytes)] 

Since showing multiple plain text parts in a multipart/mixed header is
a common scenario I would suggest to change the recently modified part
in compile.c again.

Original (before 3.8.1cvs29):
} else if (mimepart->type == MIMETYPE_TEXT) {
  if (!ainfo->name && compose->mode == COMPOSE_FORWARD_INLINE) {

Current:
} else if (mimepart->type == MIMETYPE_TEXT) {
  if (!ainfo->name)

Proposed version:
} else if (mimepart->type == MIMETYPE_TEXT) {
  if (!ainfo->name && g_ascii_strcasecmp(mimepart->subtype, "plain"))

Does this make sense?

> 
> > I checked the fix in CVS (3.8.1cvs30) and I think there is a typo in
> > there - in line 1472 of messageview.c it says:
> > 
> > mimeinfo->disposition == DISPOSITIONTYPE_ATTACHMENT
> 
> Oops. Fixed in CVS, thanks.
> 
> > Also, after testing the change I realized, that this is still
> > showing the HTML part of multipart/mixed (whereas the setting says
> > it will only show multipart/alternative).
> > 
> > So I would suggest to also check if alt_parent->subtype ==
> > "alternative". (The changes after line 1495 are fine, the comparison
> > operator is ok and since it is only executed in the context of a
> > multipart/alternative header anyway).
> 
> Yeah, I wonder if we wouldn't break other cases that I can't think of
> right now. I remember adding these for a reason, but don't remember
> which one... I'll investigate further...

Better safe than sorry (I can't think of any cases where this would
be a serious problem though - worst case would be not opening the HTML
part automatically right? - I'm a lot more concerned about seeing wrong
piece of information - what use is that feature, if you have to double
check with the plain text part every time to make sure you didn't miss
anything important?!).

I'll stay tuned ;)

-- 
Michael Gmelin