Talk:Plain text e-mail - Thunderbird

From MozillaZine Knowledge Base
Jump to navigationJump to search

Request for comments

I added this article to the Request for comments category to solicit input from other editors. Please see the "Article merge issues" section and the discussion in . Tanstaafl 06:35, 16 May 2007 (UTC)

Inline attachments

You can send plain text attachments and still have file attachments. Regardless of what's attached, whether it be HTML emails, HTML files, graphics, or just a .zip file, that's independent of message content. In fact, advocates of plain text often point out the availability of attachments. As far as I know, attachments were a very early part of email. Thus, I'd like to remove the part about inline forwarding. Forwarding via attachment still permits plain text. Superm401 04:18, 20 December 2005 (UTC)

To be clear, I am removing it. If you object, explain why here. Superm401 04:19, 20 December 2005 (UTC)
I think the difference is in how one defines "plain": MIME adds a structural element to the message text, adding complexity and reducing the 'plain'-ness. The complexity occasionally causes problems: For example, see Forwarded messages not readable or just search Bugzilla for "MIME" and you'll get hundreds of results.
MIME is plain text 'under the hood', but so is everything -- even HTML -- because the Internet understands only 7-bit ASCII.
The scope of this page includes maximizing 7-bit ASCII, minimizing MIME use and maximizing compatibility. I agree that not everyone wants to take it to that extreme, but they'll have to make the judgement themselves. The page does state, in its second sentence, that "HTML and MIME are understood by most programs". Also, most people reading the page will have some sense of what MIME is -- plain text is not something typical users ask about.
As a compromise, I'll re-add the step and but will create a MIME section under Advanced. If you are concerned that readers will be confused, perhaps add something there?
Guanxi 12:43, 06 Jan 2006 EST
The problem with the "compromise" is that its not targeting the average user, who is typically migrating from Outlook or Outlook Express . I've helped dozens of users set it for plain text and not one has ever wanted to make it only 7-bit ascii. A better compromise would be to have two sections for how to send plain text - one for "7-bit ASCII with no MIME sections" and one for "Plain Text". Tanstaafl 11:49, 13 February 2006 (UTC)
How is this new suggestion significantly different than the original compromise? It seems to advocate moving the alternative step from the Advanced section to a near-duplicate section on sending e-mail. We're only varying one step, so a whole additional, almost exactly identical section seems a waste of space and reader's attention. How does that help average users? I also help those average users: 1) Real average users don't ask for plain text, 2) Not understanding MIME, average users can't ask about it; I don't think we should limit KB content to what the average user already knows. 3) Forward an HTML e-mail as a MIME attachment, and the recipient is reading HTML, not plain text, and 4) This page is about using plain text, not MIME; how about making a separate MIME page for instructions on using MIME. I did try to quickly write the alternative step but got stuck: How to explain to the non-technical user why they want to use MIME for forwarding. I can think of minor advantages, but nothing pursuasive.
Guanxi 23:26, 02 Mar 2006 (Thu) EST
How about expanding the page, Send plain text attachments as real attachments, to Sending real attachments in general or MIME in general. I already linked to it during the last revision, but it could be expanded upon: Just steal the MIME and attachments section, add an explanation of the benefits of MIME, describe how to configure it, and link to it from the 'forward inline' step. The KB could use a central MIME page to which other articles can refer. Guanxi 01:44, 03 Mar 2006 (Fri) EST
In the inline attachments step, I referred readers to other information on the page. It's better than nothing, but I still like the idea of a separate MIME page. Guanxi 12:22, 06 Mar 2006 (Mon) EST

Plain Text Domains

I removed the following:

  1. Click the "Send Options" button (bottom right) and select the Plain Text Domains tab. Press the Add button, enter *.* and then click "OK".

The last step tells Thunderbird to ignore whether a message you're replying to is a HTML message, and the "prefers to receive messages formatted as" setting in the address book. One sideffect is it removes the HTML formatting toolbar, rather than just disabling it.

You get the same results by skipping this step: Unchecking 'Compose in HTML Format' accomplishes the same thing.

Try it:

  1. Configure TB without the above step.
  2. In your address book, set someone as 'prefers to receive mail in' 'HTML format'.
  3. Open an html email from that person and click reply

I see a plain text composition window, with no html formatting toolbar at all.

If there is some other benefit not described above, please explain.

Guanxi 13:34, 16 Jan 2006 (Mon) EST
The problem is that Thunderbirds behavior changes from version to version. In v1.5 if you check compose in HTML , have no preference set for that user, select "ask me what to do" and have a *.* in plain text domains it composes it in HTML and then asks what do you want to do. I believe we need a writeup that is less version dependent rather than trying to optimize it for the fewest steps. I think it also helps to document somewhere what the dependencies are (such as the "prefers to receive messages formatted as" setting in the address book). Tanstaafl 11:49, 13 February 2006 (UTC)
if you check compose in HTML -- That seems outside the scope of this page?
I believe we need a writeup that is less version dependent -- My impression is that the KB is written for the latest version, but has that been discussed somewhere? I will say: Supporting multiple versions is expensive; support 3 versions and every update must be tested 3 times ... and someone must keep those old versions on their machine. Who, in 6 months, will remember if some new step or edit worked on TB 1.0?
rather than trying to optimize it for the fewest steps -- I think everyone faces the a tradeoff between being succinct and being complete. I generally do it by writing a succinct, procedural section for non-technical readers who just want a quick solution, and then an advanced section with options and details. But certainly others will draw the line in other places and ways. The procedural sections are already pretty long, however.
In any case, I'm not sure what specifically you want to add or change.
Guanxi 22:30, 02 Mar 2006 (Thu) EST

removed unclear wording

I removed the following because it was unclear, and because I could not clairfy it because I'm not sure what the author intended.

There are two parts to message format, first the appearance of the composition window and then the format of the delivered message. When composing as rich (HTML) text, the message window typically has a Format menu item and Formatting toolbar.


Article merge issues

On Talk:Mail_content_types, I raised some issues that should properly be discussed here, so I'll restate the important ones:

  • This article deals with "7-bit ASCII" but you don't find that out until the Advanced section. It would be better to explain up front what the article is really about.
  • The term "plain text" is ambiguous. In Mozilla applications it usually means the MIME type text/plain, but in this article it is not always clear what it means. It would be better to say "ASCII" where that is what is meant. This comment also applies to the article's title.
  • Not everyone agrees that "plain text is much more secure". It would be better to remove this statement, or else to support it by links to confirmed security bugs in current Mozilla products.
  • Not everyone agrees that plain text is "likely to be readable many years in the future". It would be better to remove this statement, or else to support it by links to Mozilla's and W3C's plans to sunset HTML.

Rod Whiteley 19:42, 26 March 2007 (UTC)

These issues are already discussed at Talk:Mail_content_types. Please see the discussion there. Guanxi 15:09, 28 March 2007 (UTC)

I don't want to hurt anybodies feelings but nobody owns an article and this stalemate has gone way too long. I've simplified the article, replaced the discussion about the merits of plain text vs HTML with a link to a web page on that topic, eliminated the plain text means 7bit ASCII focus, moved any of advanced topics that weren't covered elsewhere to either Mail_content_types or Quote_bars, and removed the request for comments tag. Tanstaafl 11:53, 14 March 2008 (UTC)

I've restored some information about the format=flowed issue as I'm frequently referring to this article (wrapping issues are quite common, given that some e-mail programs still don't know how to correctly flow paragraphs...). Also, f=f is not the cause for the '>' quotes, that's a separate issue, even though f=f implies a certain format to distinguish between '>' indicating a quote and those which are part of the actual message. I retained the link to that quite informational tutorial, linked to the relevant Mail content types sections for the preferences, and added a forum thread on the rewrap issue. --Rsx11m 14:21, 22 March 2008 (UTC)