[Users] Question regarding forward of HTML e-mails

[Michael Gmelin]

> > 
> > On Thu, 9 Aug 2012 14:51:13 +0200
> > Colin Leroy <colin at colino.net> wrote:
> > > Hi, 

Hi,

This is a little bit longer, but at least I found the cause of the
problem, please let me know if you need additional input or if there is
anything else I can do to help to resolve the issue.

> > > 
> > > > [...]
> > > 
> > > It is turned into an attachment, since that commit:
> > > 
> > > 2010-12-23 [colin]      3.7.8cvs23
> > > 
> > >         * src/compose.c
> > >                 Finish fixing bug #2203: When forwarding (inline)
> > > and there are some text/* parts with no name, set them a
> > >           	name and set their disposition to attachment, so
> > > that recipients with MUAs preferring HTML parts don't show
> > >           	them by default.
> > > 
> > > [...]
> > 
> > I'm using 3.8.1, that's correct. Right now I have no chance to check
> > myself how the E-Mail got represented in the specific Outlook
> > instance of that person.
> > 
> > [...]
> 
> 
> 

It took a while to figure out why this isn't always working as
expected, since the problem is timing sensitive:

In compose_draft(), compose->mode is set to COMPOSE_REEDIT (about line
9780 in compose.c). compose_draft is called from various places
to save a message to a draft - including auto save mode, which kicks in
a few seconds after text has been entered. This means, as soon as the
message gets (auto)saved to drafts, compose->mode is COMPOSE_REEDIT and
*not* the previous value.

This breaks some code in the process of sending the mail, specifically
the code in compose_add_attachments(), which is supposed to turn
the HTML multipart/alternative into an attachment (compose.c, about
line 6080) and depends on compose->mode == COMPOSE_FORWARD_INLINE:

...
    if (mimepart->type == MIMETYPE_MESSAGE &&
        !g_ascii_strcasecmp(mimepart->subtype, "rfc822")) {
      mimepart->disposition = DISPOSITIONTYPE_INLINE;
    } else if (mimepart->type == MIMETYPE_TEXT) {
      if (!ainfo->name && compose->mode == COMPOSE_FORWARD_INLINE) {
        /* Text parts with no name come from multipart/alternative
        * forwards. Make sure the recipient won't look at the 
        * original HTML part by mistake. */
        mimepart->disposition = DISPOSITIONTYPE_ATTACHMENT;   
        ainfo->name = g_strdup_printf(_("Original %s part"),
                mimepart->subtype);
      }
      if (ainfo->charset)
        g_hash_table_insert(mimepart->typeparameters,
                g_strdup("charset"), g_strdup(ainfo->charset));
    }
...

I'm not certain what's the best way to resolve this situation - there
are two issues here:

- Change this, so it works correctly on an immediate forward (so make
  sure autosave doesn't mess with it)
- Make sure that it also works if somebody reopens a previously saved
  draft (in the end, as a user I expect this to work if I interrupt
  writing an email and continue writing it later)

Especially for the second issue it seems to me that the way this is
currently done (turning the HTML to a named attachment on send) is
asking for trouble and it would be better, if the correct message
structure would be created on compose (that is, as soon as the user
hits forward, the HTML attachment is given a name and disposition is
set to attachment); this way reopening a stored Draft wouldn't result in
unexpected results either.

So, to reproduce this problem (in my case using a full IMAP setup):
- Make sure auto-save is enabled in claws
- Receive a multipart/alternative email containing plain text and
  HTML
- Open it in claws and hit the forward button
- Add a comment on the email (this is not really required, but makes
  it clear that HTML and plain text differ)
- Wait until auto save kicks in (should only take a few seconds)
- Hit the send button
- Inspect message structure at the receiving end or in your Sent folder

In addition to this problem, I also noticed that the configuration
option "Select the HTML part of multipart/alternative messages" doesn't
work as expected (using the fancy plugin), since it not only opens the
HTML part of multipart/alternative, but also multipart/mixed emails,
even if the HTML part is a named attachment.

Cheers,
Michael

-- 
Michael Gmelin