1178073 - prefer "Forward as attachment" over "inline" if the mail contains attachments

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[Toralf Förster]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150614002547

Steps to reproduce:

tfoerste@t44 ~ $ echo "text" > msg
tfoerste@t44 ~ $ echo foo | gzip | uuencode foo.gz >> msg
tfoerste@t44 ~ $ echo bar | gzip | uuencode bar.gz >> msg
tfoerste@t44 ~ $ echo "greatings" >> msg
tfoerste@t44 ~ $ mail -s miau tfoerste < msg



Actual results:

That local delivered email at my stable Gentoo Linux I'd like to forward w/o breaking the attachments.


Forward as inline however deattaches the 2 files as seen here :

-------- Forwarded Message --------
Subject: miau
Date: Sun, 28 Jun 2015 11:55:05 +0200
From: [e-mail]
To: [e-mail]

text
begin 644 foo.gz
8'XL(`.S#CU4``TO+S^<"`*AE,GX$````
`
end
begin 644 bar.gz
8'XL(`/7#CU4``TM*+.("`.FSH@0$````
`
end
greatings





Expected results:

the forward email should not break the attached binary files

Comment 1

[rsx11m]

You are creating a single message which is the concatenation of text, two uuencoded binary components, then text again. Thus, this is a single text/plain message as sent, without explicitly encoding attachments. You'd have to follow MIME encoding guidelines for your uuencoded content to be treated as such. Can you attach the original message to this bug report, /before/ forwarding, thus as received in your local mailbox?

Comment 2

[Toralf Förster]

well - the original message is created in the same manner.
So I do have to change the creation to be mime-compliant I fear, or ?

OTOH for the few case where I need to forward those message I still have the option to forward the whole message itself as attachment.
/me wonders if in this case I can customize Thunderbird to have the button beside the common "Forward" button ?

Comment 3

[rsx11m]

(In reply to Toralf Förster from comment #2)
> well - the original message is created in the same manner.

Ok, I wasn't sure if you have some piece of software creating a MIME multipart/mixed construct out of that mixture, but apparently not.

> So I do have to change the creation to be mime-compliant I fear, or ?

If you want others to be able to easily extract those attachments in the mailer itself, yes. MIME is the universally accepted standard (along with base64 encoding).

> OTOH for the few case where I need to forward those message I still have the
> option to forward the whole message itself as attachment.
> /me wonders if in this case I can customize Thunderbird to have the button
> beside the common "Forward" button ?

Right-click on the Reply/Forward/etc. toolbar and select "Customize" from the context menu. Drag the "Forward As" button from the palette to the toolbar, and in turn, the "Forward" button from the toolbar back to the palette, then close. Now your "Forward" button has a menu which allows you to pick inline vs. attachment mode.

Comment 4

[Toralf Förster]

Thx, ok, so this is solved

Comment 5

[Toralf Förster]

There's one point left however.

Although the message isn't composed as MIME-compliant - Thunderbird recognizes the attachments and shows them as attachments in the bottom of the mail - separated from the text.

That's why I'm wondering why TB doesn't handle the attachments right during "Forward inline"

Comment 6

[rsx11m]

(In reply to Toralf Förster from comment #5)
> Although the message isn't composed as MIME-compliant - Thunderbird
> recognizes the attachments and shows them as attachments in the bottom of
> the mail - separated from the text.

Interesting but unexpected. That's why I've asked you to attach the message as sent by "mail -s ..." but /before/ you forward it, thus to see how "mail" encoded it and/or if the server has altered it.

Comment 7

[Toralf Förster]

Attachment: msg

attached the output of :

echo "text" > msg; echo foo | gzip | uuencode foo.gz >> msg; echo bar | gzip | uuencode bar.gz >> msg; echo "greatings" >> msg

Comment 8

[rsx11m]

Thanks, but you misunderstood.
 1. Send the message to you using /your/ "mail -s" command
 2. receive the message in Thunderbird
 3. select File > Save As > File for this message
 4. attach the "miau.eml" file

In this way, it can be seen whether or not (and potentially how) that message was translated into a MIME construct.

Comment 9

[Toralf Förster]

Attachment: miau.eml

(In reply to rsx11m from comment #8)
> Thanks, but you misunderstood.
>  1. Send the message to you using /your/ "mail -s" command
>  2. receive the message in Thunderbird
>  3. select File > Save As > File for this message
>  4. attach the "miau.eml" file
> 
> In this way, it can be seen whether or not (and potentially how) that
> message was translated into a MIME construct.

Comment 10

[rsx11m]

Hehe, this is interesting indeed. Loading that message into Thunderbird shows the two attachments as such, thus there must be some "hidden" mechanism to detect and interpret uuencoded embedded parts. Furthermore, the message itself doesn't have any MIME headings at all added by the mailer, which may facilitate that behavior (I'd have to try, but my guess is that adding the explicit text/* MIME header during the forward operation bypasses that check and therefore won't split those parts off).

Adding our MIME guru to the discussion to determine if anything of this is accidental or incomplete.

Comment 11

[rsx11m]

Actually, that behavior is pending as an old report (bug 234449) already, but the question is if "forwarding as attachment if uuencoded parts are detected" should be implemented to work around the issue (the question being how common that encoding is still supported by other mailers). Converting those to true MIME attachments may be preferable, to not mess with the default forwarding pref.

Comment 12

[Joshua Cranmer [:jcranmer]]

(In reply to rsx11m from comment #10)
> Hehe, this is interesting indeed. Loading that message into Thunderbird
> shows the two attachments as such, thus there must be some "hidden"
> mechanism to detect and interpret uuencoded embedded parts. Furthermore, the
> message itself doesn't have any MIME headings at all added by the mailer,
> which may facilitate that behavior (I'd have to try, but my guess is that
> adding the explicit text/* MIME header during the forward operation bypasses
> that check and therefore won't split those parts off).

uuencode and yEnc are special snowflakes, since they're not-MIME attachment types that we support (but please don't use them; they're evil and obviated by MIME). We decide to do special snowflake handling of these via "untyped" handling, so they don't get processed during text/plain (although I've found that they are interpreted by other clients in that case, so that we don't do it is our bug).

I don't know, without digging into the code, the reason why they're not working, but I do know that there is enough ugliness in that code as-is.

(In reply to rsx11m from comment #11)
> Actually, that behavior is pending as an old report (bug 234449) already,
> but the question is if "forwarding as attachment if uuencoded parts are
> detected" should be implemented to work around the issue (the question being
> how common that encoding is still supported by other mailers). Converting
> those to true MIME attachments may be preferable, to not mess with the
> default forwarding pref.

The ideal solution to this problem would be to introduce a sane API that decomposed messages into headers, body, and attachments and then use that for all MIME decoding tasks (including reply/forward). I don't think it's worth working around the issue, uuencode and yEnc are fairly rare outside of NNTP.