I composed a fairly simple message using the html compose window, set my preference to send html only, and hit send. When the message arrived, I saved it (File->Save from the mozilla mail window) to a file. The text in the file isn't really plaintext. It's full of things like: --------- Fingers crossed that it's not much of a chance, at least for now. > = > >> Netscape will thread any folder; you can even read your normal incom= ing > mail in threaded mode, though most people don't << > = > I'd sorta like that. I keep all my mail in one file now, but sometimes= > it's a long way back to the one I want to refer to. I do have a search= > function, thank heavens. In Netscape it's easy to switch between views.=A0 I read normal mail in = the order it comes in, but every now and then I want to go back and read = --------- I assume the =, the =A0 and the extra linebreaks have to do with format=flowed, right? How do I turn that off in case I'm sending to people with mailers which don't understand these codes, or in case I just want to save the file to view it in a text editor? I don't see a pref for it, and if we're claiming to convert to ordinary plaintext, we should do that by default or make the pref very easy to find.

Nominating for beta1 because the ability to send plaintext is very important.

Format flowed inserts one SPACE character before some line endings. I don't think it has anything to do with that. The '=' signs reminds me of quoted printable, but I don't know anything about it.

I think that's the send messages "as is" vs. "quoted-printable" pref in the Message pref panel. Is it set to "quoted-printable"? What does the "content-transfer-encoding" line of the message say?

My pref is set to quoted-printable, and the header says: Content-Transfer-Encoding: quoted-printable Should I switch to "as is" if I don't want to see all the ='s?

Yes, that should take care of it. But I wonder why it isn't automatically converted to 8bit on receipt. Reassigning to rhp to check it out.

I think what you are seeing is an issue with the extension of the file you are saving. Try saving your file as: "test.TXT". The extension matters until I get an M15 checkin into the tree. I think if you try that, it should work much better for you. Akkana: unless I'm mistaken, this isn't a problem with Sending email, rather saving a file as text after you receive it. - rhp Note: Marking M16 so it stands out in my list.

Right you are: save as ".txt" converts the QP into plain text. But it also throws away all the mail headers. If someone sends me a text message in QP, or -- god forbid -- in base64, I'd like to be able to save the message with all the headers, but with the text in a readable format.

Can you do me a favor and send me a sample test message...I just checked in a bunch of changes on "Save As" and I want to make sure this is working. - rhp

Ok, I found a bug with this test case that I will be fixing when the tree opens. You will probably get headers now, but lots of asserts with the accented characters. This will be fixed as of today's checkins. I'll mark this fixed when I get it into the tree. - rhp

Ok, should be fixed. - rhp

Ok, what should this do now? Saving as .txt converts to 8bit, and gives From, Date, and Subject headers. Saving as .eml saves the entire raw message. How do I get all the headers and the message still readable?

Hmm...this is a good point...maybe Save As text should give you ALL mail headers. Currently, it will give you the same view you get as when you display the message. Making this happen is easy, but I'd like some discussion on this one before I make a change. - rhp

I would expect Save As from a mail window to save with headers, in Berkeley mail folder format. That's what it's always done before, and I fairly often save messages that way to be used as a mail folder later (much easier than going through the "new folder" series of dialogs).

Well, if you want to see all headers with 4.x, you have to save the raw RFC822 message. This is what it will do saving as a .EML file. We have a better "Save As" text format and HTML format with SeaMonkey, but we save what you see in the mail envelope. Save As Text in 4.x did the same thing. - rhp

I've never heard of .EML, but with 4.72/linux, I just read the bugzilla mail from your last message, right-clicked in the message pane, chose Save As, typed in a filename /tmp/foo and hit OK. The resulting /tmp/foo has full headers (I show "Brief" headers and might have expected it to save only those plus the From line needed to make it a valid Berkeley folder, but don't feel strongly about the full vs. brief issue as long as it saves at least as many headers as it's showing me): From - Wed Feb 23 14:24:55 2000 Return-Path: <nobody@mozilla.org> Received: from shemail.mcom.com ([205.217.237.178]) by dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999 18:28:31) with ESMTP id FQELVU00.MPQ for <akkana@dredd.mcom.com>; Wed, 23 Feb 2000 14:16:42 -0800 Received: from xwing.netscape.com (xwing.mcom.com [207.200.76.40]) by shemail.mcom.com (8.8.8/8.8.5) with ESMTP id OAA20801 for <akkana@netscape.com>; Wed, 23 Feb 2000 14:16:41 -0800 (PST) Received: from lounge.mozilla.org (h-207-200-73-38.netscape.com [207.200.73.38]) by xwing.netscape.com (8.9.3/8.9.3) with ESMTP id OAA20031 for <akkana@netscape.com>; Wed, 23 Feb 2000 14:16:41 -0800 (PST) Received: (from nobody@localhost) by lounge.mozilla.org with id OAA08462; Wed, 23 Feb 2000 14:16:41 -0800 (PST) Date: Wed, 23 Feb 2000 14:16:41 -0800 (PST) Message-Id: <200002232216.OAA08462@lounge.mozilla.org> From: bugzilla-daemon@mozilla.org To: akkana@netscape.com Subject: [Bug 28703] Changed - HTML doesn't convert to plain plaintext when doin g File->Save As http://bugzilla.mozilla.org/show_bug.cgi?id=28703 ------- Additional Comments From rhp@netscape.com 2000-02-23 14:16 ------- Well, if you want to see all headers with 4.x, you have to save the raw RFC822 message. This is what it will do saving as a .EML file. We have a better "Save As" text format and HTML format with SeaMonkey, but we save what you see in the mail envelope. Save As Text in 4.x did the same thing. - rhp

Fair enough. Maybe you can hook up the save as plain text (.txt) feature so it writes the same number of headers as are being displayed. That way, View | Headers could control what headers are saved. Verified fixed on Linux build 2000.02.23.08.

I hope we won't be dependant on what filename the user types in. Linux users don't expect to get different results depending on whether they add a bogus ".txt" to a filename. Is this issue already covered by a bug, or should I file a new one?

Akkana, What you are seeing is the RFC822 message source...which is quite ugly when you have a complex multipart MIME message. About the extensions, I have fixes in my tree that will take what you specify as the file type should be what you get as output. Zach: What you describe is how it will work now. It will save the headers that are specified by your pref setting. - rhp - rhp