Set Content-Transfer-Encoding for attachment?

User Help for Mozilla Thunderbird
Post Reply
MadOverlord
Posts: 5
Joined: December 3rd, 2004, 12:53 pm

Set Content-Transfer-Encoding for attachment?

Post by MadOverlord »

The problem: Thunderbird on OS X does not properly send vcard (text/vcard, .vcf) files as attachments.

Instead of sending them as text/vcard in base64 encoding (as, say, gmail does) it sends them in text/text 7bit encoding.

You can teach TB to send as text/vcard by opening a "good" text/vcard attachment sent to you and telling TB what app to use; it picks up on the mime type and uses it thereafter. You can also use the MIME Edit addon to set this relationship.

However, there seems to be no way to specify the content-transfer-encoding for an attachment type. Thunderbird apparently looks at it, says "it's text", and sends it as 7bit. After an hour of searching the various forums and support threads, I'm stumped. And it's annoying that I can send vcards to an iPhone from gmail but not from my Mac!
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

In general, those v-cards are text files, therefore can be sent in either 7bit, 8bit, quoted-printable, or base64 encoding, at the discretion of the sending application. Thus, I don't see the need to require it to be sent in a binary encoding, it's the task of the receiving application (here, the iPhone) to interpret it correctly. Having said that, the encoding appears to be incorrect anyway with respect to the Content-Transfer-Encoding:

Without any modification of the MIME settings, on Windows XP SP2, it sends it out as Content-Type: text/x-vcard; charset=utf-8; (not text/text) with Content-Transfer-Encoding: 7bit. However, if I put some non-ASCII characters with accents into the name field, they will be encoded as UTF-8 but with "quoted-printable" encoding even though it still says "7bit" in the header information. Edit: (see below!)

You can globally enforce base64 encoding by going into the Thunderbird > Preferences > Advanced > General tab and click Config Editor. Copy-paste mail.file_attach_binary into the search bar on top of the preference list, and double-click on the entry that remains so that it shows "true". This will send all files in binary format, including v-cards, and even "real" text attachments. The MIME Edit extension is certainly a good way to change the MIME types as needed.
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

Sorry, I didn't look carefully enough on the generated messages. Thunderbird would add "quoted-printable" as encoding to the "fn" and "n" fields in the v-card when using 8-bit characters:

Code: Select all

begin:vcard
fn;quoted-printable:...
n;quoted-printable:...
email;internet:...@...
x-mozilla-html:FALSE
version:2.1
end:vcard
Thus, while the content of the v-card may be encoded differently, the v-card itself can be represented in 7-bit encoding and is therefore categorized respectively in the MIME headers.

Anyway, you can send it in binary and modify "text/x-vcard" to "text/vcard" with MIME Edit if this is the only way iPhone understands it.
MadOverlord
Posts: 5
Joined: December 3rd, 2004, 12:53 pm

Post by MadOverlord »

Thank you very much. Progress is being made, but it's not quite there yet.

The following mime enclosure is the vCard as sent by gmail; it works:

Code: Select all

------=_Part_4546_24185659.1200702715457
Content-Type: text/vcard; name="Janice Hindle.vcf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fblfe1ox0
Content-Disposition: attachment; filename="Janice Hindle.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpOOkhpbmRsZTtKYW5pY2U7OzsNCkZOOkphbmljZSBI
aW5kbGUNCk5JQ0tOQU1FOmNhYmluY292ZQ0KRU1BSUw7dHlwZT1JTlRFUk5FVDt0eXBlPUhPTUU7
dHlwZT1wcmVmOmpoaW5kbGVAYmVsbHNvdXRoLm5ldA0KRU1BSUw7dHlwZT1JTlRFUk5FVDt0eXBl
PVdPUks6amFuaWNlQGFuaW1laWdvLmNvbQ0KVEVMO3R5cGU9SE9NRTt0eXBlPXByZWY6OTEwLTQ1
OC0wNzA5DQpURUw7dHlwZT1DRUxMOig5MTApIDYxNi0wNjg0DQppdGVtMS5BRFI7dHlwZT1IT01F
O3R5cGU9cHJlZjo7OzYyNSBTbG9vcCBQb2ludGUgTGFuZTtLdXJlIEJlYWNoO05DOzI4NDQ5O1VT
QQ0KaXRlbTEuWC1BQkFEUjp1cw0KQ0FURUdPUklFUzpQcmlvcml0eS0xIChUb3ApLGlQaG9uZQ0K
WC1BQlVJRDowOTBGQUE3Qi0zNjQ2LTExREItOTA5OC0wMDE2Q0I4RkI5MTJcOkFCUGVyc29uDQpF
TkQ6VkNBUkQNCg==
------=_Part_4546_24185659.1200702715457--


Compare this to the same vcard, sent by Thunderbird, which does not work:

Code: Select all

--------------000003080102050705020304
Content-Type: text/vcard;
 name="Janice Hindle.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Janice Hindle.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046My4wDQpOOkhpbmRsZTtKYW5pY2U7OzsNCkZOOkphbmlj
ZSBIaW5kbGUNCk5JQ0tOQU1FOmNhYmluY292ZQ0KRU1BSUw7dHlwZT1JTlRFUk5FVDt0eXBl
PUhPTUU7dHlwZT1wcmVmOmpoaW5kbGVAYmVsbHNvdXRoLm5ldA0KRU1BSUw7dHlwZT1JTlRF
Uk5FVDt0eXBlPVdPUks6amFuaWNlQGFuaW1laWdvLmNvbQ0KVEVMO3R5cGU9SE9NRTt0eXBl
PXByZWY6OTEwLTQ1OC0wNzA5DQpURUw7dHlwZT1DRUxMOig5MTApIDYxNi0wNjg0DQppdGVt
MS5BRFI7dHlwZT1IT01FO3R5cGU9cHJlZjo7OzYyNSBTbG9vcCBQb2ludGUgTGFuZTtLdXJl
IEJlYWNoO05DOzI4NDQ5O1VTQQ0KaXRlbTEuWC1BQkFEUjp1cw0KQ0FURUdPUklFUzpQcmlv
cml0eS0xIChUb3ApLGlQaG9uZQ0KWC1BQlVJRDowOTBGQUE3Qi0zNjQ2LTExREItOTA5OC0w
MDE2Q0I4RkI5MTJcOkFCUGVyc29uDQpFTkQ6VkNBUkQNCg==
--------------000003080102050705020304--


So the problem appears to be that Content-Disposition is required to be "attachment" for the iPhone to recognize the vcard! Well, following up on your explanation of the config editor, I went looking and found the preference mail.content_disposition_type, and a quick google revealed that I needed to set it to 1. Doing that gets the attachments to the iPhone.

I also checked that both were needed by reverting the mail.file_attach_binary setting. As it turns out, it is not. The real cause of the problem is that Thunderbird defaults to sending attachments inline.

Thank you VERY much for the quick help on this, I'll pass on the results to the Apple Support forums
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

You are welcome, the iPhone seems to be quite picky then as far as attachments are concerned! :-)
Sending attachments as "inline" even though they are not is a known TB bug...

And yes, bringing this to attention in the Apple forums is probably a good idea.
MadOverlord
Posts: 5
Joined: December 3rd, 2004, 12:53 pm

Post by MadOverlord »

It's done; I also dropped a feedback note on them (assuming they actually do read them) pointing out the issue and suggesting the handler code be more robust -- heck, they've got to parse vcards anyway, so they can run the parser on any text attachments that start appropriately to see if they are valid.

The iPhone seems to be picky about content-disposition, but less so in other ways. I got curious and found that a text/text or text/plain .vcf file works just fine.

I checked bugzilla and this bug has been around since 2001!

https://bugzilla.mozilla.org/show_bug.cgi?id=65794

Some of the comments about the delay in fixing it -- in particular after a couple of "it's not a bug" comments -- are, shall we say, a wee bit acidic.
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

Yes, some bugs are around forever already, and some discussions don't seem to go anywhere... :?

Personally, I like your initial idea of being able to explicitly set the desired content transfer encoding and content disposition in the individual MIME specifications, which would require quite a bit of coding in those parts though to make it work. There are scenarios where you want to have text attachments inline, so making it configurable would be the best solution to make both sides happy.
MadOverlord
Posts: 5
Joined: December 3rd, 2004, 12:53 pm

Post by MadOverlord »

Or just "drag into the address area = attachment, drag into message area = inline"

R
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

... that might introduce some inconsistency/ambiguity in how drag-and-drop are handled. If you take an image, for example, and drag it into the message, it will become embedded into the HTML text, or it will be an inlined attachment if dragged into the address/attachment area. So, this would be different for text files then, following your suggestion. I certainly agree that some sort of marker for an individual attachment (there are three classes only anyway: text, image, and message) whether or not they are inline or true attachments, on top of the global preference.
MadOverlord
Posts: 5
Joined: December 3rd, 2004, 12:53 pm

Post by MadOverlord »

My suggestion is that if you drag that image into the body of the message, it's inlined; if you drag it into the address area, it's attached. Furthermore, in the bugzilla posting, I suggested that the first time a user drags in a file, a popup dialog appears that explains the difference between the two methods and some of the consequences.

Seems to me that the implied semantics are clear -- if I drag something into a message body, I want it in the body at the point where I dropped it. If the user-agent at the other side can't display it inline, that's beyond my control. But I can definitely see times where I'd like to have a text file included inline (say, a FAQ list) and others where I'd want them attached (an xml file, or in my gotcha case, a vcard)
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

Current behavior for text files in HTML compositions:
  • You drag into the address or attachment area, it will be an attachment with content disposition depending on the preference;
  • you drag it into the message area, a "file:" link will be added (which doesn't make any sense at all as it is only of local context); the file is actually attached (not so in plain-text compositions) but only pops up when you click on the link even when displaying inline is set (so, this is an absolutely unintuitive behavior).
So, here the drag-to-message-body behavior would be unambiguous. Different story for images, current behavior:
  • You drag into the address or attachment area, it will be an attachment with content disposition depending on the preference;
  • you drag it into the message area, the message will be "multipart/related" and the image part of the HTML message.
If you change the behavior here, you would cover the cases "multipart/mixed" with "attachment" disposition but can only have either "multipart/mixed" with "inline" disposition or the current "multipart/related" inclusion. Thus, you cannot distinguish between those two cases with the proposed way of attaching. Thus, for images, the semantics is indeed ambiguous...
rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

Just added my two cents to the bug report, the list of recipients watching it is quite impressive. I tried to resolve the ambiguity by distinguishing between plain-text and HTML composition for the drag-image-into-message case. I don't think there would be much of a problem dragging a text file into the message, as there doesn't appear to exist any useful method to embed this into a message.

So, there is certainly enough discussion there, let's see if something is going to happen. It would already be helpful if a disposition based on MIME types could be implemented, as suggested in a couple of comments.
Giulioski
Posts: 30
Joined: March 3rd, 2007, 2:26 am

Post by Giulioski »

rsx11m
Moderator
Posts: 14404
Joined: May 3rd, 2007, 7:40 am
Location: US

Post by rsx11m »

Thanks, Giulioski. These preferences are working globally though and present a workaround for the issues addressed here. A true "solution" would be to determine the content disposition on a case-by-case basis for MIME types that can be displayed inline, and to send everything else with attachment disposition in general. This is what bug 65794 will hopefully result in.
Post Reply