User Help for Mozilla Thunderbird
14 posts • Page 1 of 1
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!
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.
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:
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.
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:
Compare this to the same vcard, sent by Thunderbird, which does not work:
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
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.
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!
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.
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.
Or just "drag into the address area = attachment, drag into message area = inline"
... 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.
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)
Current behavior for text files in HTML compositions:
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.
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.
14 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 8 guests