From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95) BuildID: 2001021508 The mail component needs a feature that lets you turn off HTML rendering of messages. This would allow one to prevent e-mail tracking in the form of "invisible" images that send a user's IP to back to the sender/spammer. Reproducible: Always Steps to Reproduce: none. Actual Results: There's no way to turn off HTML rendering in e-mail. Expected Results: There should be an easy way -- maybe a button on the Mail & News window?
See also bug 28327, "No server hits at HTML mailnews reading - privacy"
*** This bug has been marked as a duplicate of 31907 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Wait, this isn't quite a duplicate, because bug 31907 seems to be leaning toward allowing the user to turn off specific features of HTML instead of turning off HTML entirely.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Mail needs HTML options → pref to disable HTML mail
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows ME → All
Hardware: PC → All
Summary: pref to disable HTML mail → [RFE] Pref to disable HTML mail
It sounds like the various ideas flying around for this are needlessly complex for the user (e.g. blocking image loading in mail for specific domains). What I think is a very clean approach that works well for mail is: "Disable HTML mail for all addresses not in my address book" That seems like a reasonable source for trust information. Perhaps it should omit automatically collected addresses though. It's sort of the inverse of using your address book to decide who you can send HTML mail to. You could do the receive thing on that basis as well, but I think that's probably needlessly complex. I think the main application of this is to avoid rendering HTML-based spam, at least, that's what I want it for. This wouldn't work as well for news, of course, but then you can get down to blocking specfic domains, etc. if people still want to go that route. It still might be a useful option for news. It might be worth optionally prompting users to see if they want to render HTML from unknown addresses. The pref could be: (X) Always show HTML email/news. ( ) Prompt before showing HTML email/news from people not in my address book. ( ) Never show HTML email/news from people not in my address book. ( ) Never show HTML email/news. Some messages have both plaintext and HTML, and the plaintext should be displayed if available. What would be really great, but probably hard, would be to take HTML-only messages and strip out the tags and display that. But that should probably be another feature request. I would be more than happy to see the simple idea presented above. Sorry this is kind of long.
I wouldn't mind if the HTML is just displayed inside a <pre> tag or even just displayed as plain text. The HTML rendering still occasionally crashes Mozilla Mail and News. And I find HTML mail really annoying. A link to a site is much better. Maybe a link should be displayed instead of the HTML and clicking this shows it from the cache or message...
"dont show HTML" could mean: show the source; for those who from the source decide that the email is harmless a button or context menu option would come in handy to show as rendered HTML.
*** Bug 86406 has been marked as a duplicate of this bug. ***
I'd be happy if this was a toggle in the menus. I like the idea of using my addressbook to determine whether I want plaintext or HTML (as described above on 2001-05-01 19:43).
It is wrong to do this. HTML mail is the new standard for email - like it or not. It has many advantages, and all of the "disadvantages" are purely problems with current implementations.
The preceeding comments doesn't seem particularly useful. It claims that HTML mail is the future and that it is currently flawed, but completely fails to suggest how to deal with "all of the disadvantages". That is hardly constructive. This RFE addresses a very real problem. While I am delighted to receive HTML mail from trusted sources, I value my privacy and HTML is sufficiently powerful to violate that privacy. Were it purely a formatting language (e.g. LaTeX) there would be no problem. As it stands, I believe this feature is necessary for privacy. I'm certainly not willing to trade my privacy and control of network activity for the sake of nice fonts and pretty pictures. Note also that this is a "preference". If you don't like it, don't turn it on.
The solutions have already been suggested - bug #28327 and bug #18427. With these fixed, I see no reason that anyone would want HTML mail off. Don't get me wrong, I'm as annoyed at bad HTML mail implementations as the next person. But we are not that far off of a good implementation. Just because you can preference it doesn't make it a good idea. Firstly, we'll never get into a world of decent rich mail if everyone turns HTML mail off. And secondly, we don't want to spatter useless preferences around the product. If it's always going to be a user preference fine, but if there's a better solution, we shouldn't introduce the preference. Note that I never advocated "fonts" as a useful feature. Quite the opposite. Pictures (within MHTML so there's no privacy concern) are certainly a useful feature though. Useful features are stuff like soft wrap, proper hyperlinks, and structural styling (emphasis, headers, bulleting, etc).
I think this bug is proposing an alternate fix for #28327/#18427 which solves the same problem (avoiding spammers / privacy issues). See comments on 2001-05-01 19:43.
I don't think that this bug is _only_ related to avoiding spammers / privacy issues. Personaly I would like it to be implemented like a comment has previously stated: "Disable HTML mail for all addresses not in my address book" I say that because there out there too many people that think that sending emails with big fonts, colorful backgrounds, etc.. is "nice", but whenever such a mail arrives at me I know that he is a looser and he's got nothing interesting to say. Reading only the text of such messages will show what they really got to say, not the beautiful backgrounds that his email client got.
I still want to be have the ability to disable HTML from everyone (including people in my address book). So far, I have never recieved any HTML-mail where the HTML was neccesary to understand the contant, or even made it more understandable. HTML makes it more difficult to copy and paste, a "nice" background makes the mail less readable. Tables, images, fonts.. all this makes the viewing of the actual mail slower. I want to read the content of the mail, and that's it. Notice - I do not want to deny any of you the pleasure of looking at those nice, colorful and blinking mails. All I want is the freedom to choose how I want to see the mails I recieve. On a sidenote, though... a huge photo of you and your dog included in every mail is a waste of both your (which I don't care about) and my (wich I definetly care about) badwidth. I read mail on everything from a 100Mbit local LAN to a 9600bps GSM-dialup. So please remember, that your mail - with all your pretty formatting and flashy images - could make me give up reading mail when I am on the road, and thereby missing some important info. - Important info for me - or even for you. Rgds.
I just want to be able to set a global flag of "Ignore HTML body parts completely", but I think firstname.lastname@example.org's four options idea will suit the general audience better.
*** Bug 102511 has been marked as a duplicate of this bug. ***
Changing my e-mail address.
Removing old e-mail address.
I don't think that MrEricSir intetion was to disable HTML at all but what I ever wanted to be able to do: forbid the mail reader to follow external links to images anywhere on the net. That's the point of this bug and not disable HTML because people do worse things with it (that's true but subject of other bugs). Bringing up an alert "Code in this mail will load content from the net. Do you want to allow this? YES|NO" would a very nice solution for this I think (one time no should also be enough for two or more images in this mail).
Comments From Tim Powell 2001-02-20 12:44; > May be a duplicate of Bug 30888. It is. *** This bug has been marked as a duplicate of 30888 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
Sorry, NACK. Comments from Bug 30888 : Jeandré : Not just have a "View as plain text" option to textify HTML emails, but have an Edit | Preferences option that all email with f*#$% HTML is displayed as plain text (source) - never allow images, webbugs, invisible forms... Alec Flett : that's another bug, go file it.. dont' polute this one.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 108004 has been marked as a duplicate of this bug. ***
While displaying HTML mail we can just allow simple tags like <hr> <br> <pre> <b> <li> <table> and ignore rest of the tags e.g. <img> <link>. I guess it'll be tough to do, but that may combine best of both worlds. A preference entry could be ( ) Render all HTML tags in mail-news (X) Only render simple HTML tags in mail-news ( ) Never render HTML tags in mail-news
What I mean with "do not render html" is not "view source". I want either: a) If the mail is two parts, one text and one html - but with the same content (as some mailers send), then only show the textpart. b) If the mail is html-only. Strip all tags, scripts whatnot and show it as text only. Maybe handle it a slight bit more intelligent and render <br> and <p> so we keep the linebreaks, but nothing else. I want mail to be text only. Both when I send and when I recieve. Call me old fashioned - I handle 200+ mail every day, and text-only is the easiest, fastest and most convenient way to read them. =;-) Ola (T)
Please, please read the entire bug before commenting. 1) we're repeating ourselves 2) we're arguing "this but is really that" when those other related features are covered in other bugs, clearly referenced in this bug bug 30888 - strip html and show plain text bug 18427 - suppress some HTML styles (more or less, maybe user mail stylesheet?) bug 28327 - don't hit the net while reading mail (privacy feature) This one is "show unprocessed mail source -- disable HTML processing" Maybe those other bugs would be nice, but this one's got to be a dead easy way of getting us part of the way there and I, for one, would appreciate the faster mail rendering and don't mind seeing junky HTML tags for spam I'm just going to delete anyway. This differs from the current view-source in two ways - would be the default presentation, no need to process the HTML also and open a new window. - would show the mail body plain source, but would still do the current nice things for the headers and attachments I realize lots of people want more, but that more is covered in other bugs.
dveditz, most people incl the report just requested to "turn HTML off" but didn't suggest what to show instead. Some people suggested plain text (version/conversion), some (incl. you) HTML source. The first option would be a dup of bug 30888, if alecf allows a pref (in contrast to only a menu option with temporary effects).
Isn't that what I said? People want different things and they are covered in different bugs. Let's keep the conversation in *this* bug to the topic not covered in those other related bugs. If I put "bicycle" on my Christmas wishlist I don't need someone to tell me that a car is faster and would keep me dry in the rain. I want a car too, but meanwhile a bike would be better than walking and much more affordable.
modifying summary to clarify the differences between this and bug 30888
Summary: [RFE] Pref to disable HTML mail → [RFE] Pref to view mail as unprocessed source
*** Bug 121853 has been marked as a duplicate of this bug. ***
OK, I have this implemented, so I am taking this bug. I hope, Seth, you don't mind (otherwiese feel free to assign back to you). What I did: You can set the pref (no UI) "mailnews.display.disable_html" to true. If it is a multipart/alternative message, we will ignore the HTML part, ending up displaying the plaintext part. If it is an HTML-only message, I followed dveditz's suggestion and just display the HTML source for now (technically, I treat the HTML part as plaintext part), because that indeed turned out to be much easier. However, I don't think that's a good idea in general and we should convert HTML->TXT->HTML instead (which would be more towards bug 30888 - I think). I will do that once I figured out how to drive the HTML->TXT conversion syncronously. I will attach the current state of the patch here, but further versions will probably be attached to bug 30888.
Assignee: sspitzer → ben.bucksch
Status: REOPENED → NEW
Component: Mail Window Front End → MIME
Keywords: polish → patch, review
Summary: [RFE] Pref to view mail as unprocessed source → Pref to view mail in plaintext alternative or as unprocessed source
Target Milestone: --- → mozilla0.9.9
I disagree with the proposed implementation. I thought that the earlier discussion to keep these methods distinct was the agreed solution. That is, I expected something like: mailnews.display.html=full (displaying everything is OK) mailnews.display.html=source (only display source) mailnews.display.html=privacy (http://bugzilla.mozilla.org/show_bug.cgi?id= 28327) mailnews.display.html=text (http://bugzilla.mozilla.org/show_bug.cgi?id= 30888) For new users, the "privacy" selection should be the default, until explicitly overridden. On the UI side, what I really wanted was a default preference, with a UI to change that on a per message basis, which would be remembered in the database for that particular message. As to multipart alternative, what I expected was: mailnews.display.alternative=list (list the parts, like 4.x) mailnews.display.alternative=text (show text part only) mailnews.display.alternative=html (show html part only) For new users, the "list" selection should be the default, until explicitly overridden -- similar to message composition.
wsimpson, it does not make sense to show the HTML source in the message page. Almost no user can do anything useful with it, and even hardly any people who do know HTML will want to read the mess that MS Outlook and spammers throw out. As I understood dveditz, he suggested showing the HTML source only as interim solution until we can do something more useful. If you still disagree, then exaplin me why the browser has no option to show the HTML source instead of the rendered page. Remember that you can always call View Source (in both the browser and Mailnews). Bug 28327 (your "privacy" setting) is completely different. It would only be needed, if disable_html pref is false. We can have another pref for that, no need to fold them into one. This makes sense, because it's a completely different feature. It just happens to have the same goal, but prefs are no UI. The prefs UI can might show them together somehow, the backend prefs are a different matter. > On the UI side [...] Fine. Let's get the backend done first.
Actually I did want to see the HTML source. I'll trash it immediately, of course, but I want to see the entire mail message that's sent to me, not pieces selected and processed by the MuA. Yes, I can do "View Source", but when I find my self doing "View Source" for every message I find myself wanting a pref to make that the default view. As a side benefit it should speed up my mail viewing, too, since there won't be any processing.
> I did want to see the HTML source. I see. The mimei.cpp subset of the attached patch should do what you want, then. Personally, I don't see the point of showing HTML source, when there is a plaintext alternative, but luckily, it's open-source, so you can have what you want :). > As a side benefit it should speed up my mail viewing, too, since there > won't be any processing. Actually, there is more processing, because the HTML source is treated as plaintext. We display plaintext by converting it to HTML and displaying that. The least processing (in libmime) actually happens when displaying HTML.
My usual credo is "Backend-prefs are cheap. If they make people happy...", so I guess I should add the pref. I did so. It is part of the patch that I will attach to bug 30888. The prefs are atomic, so you should be able to get all requested and thinkable combinations. There is no UI yet, and I don't think showing the HTML source in the message pane should have any UI. If you disagree, file a new bug (and cite the number here), but I will vote for WONTFIX. IMO, there should be UI for bug 30888, however, and I might implement it.
Keywords: patch, review
Attachment #67037 - Attachment is obsolete: true
Narrowing scope of bug to displaying HTML source, as requested.
Status: NEW → ASSIGNED
Summary: Pref to view mail in plaintext alternative or as unprocessed source → Pref to view mail as unprocessed source
Whiteboard: Done. Patch in bug 30888.
*** Bug 130897 has been marked as a duplicate of this bug. ***
Fix checked into trunk. Thanks to all reviewers and all others involved. This is not yet in the 1.0 branch. I still would like to check it into the branch. If not, it would not be in any Mozilla 1.0 releases, but only trunk nightlies and 1.1alpha. Please test the feature and try to circumvent it, i.e. get arbitary HTML rendered although the new options are active. If so, please file a new bug against Mailnews/MIME, owner me, and mention it here. Some documentation can be found at <http://www.beonex.com/temp/index.html>. When I have ftp access to my private server again, I will move it to <http://www.bucksch.com/1/projects/mozilla/108153>.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 17 years ago
Resolution: --- → FIXED
*** Bug 147201 has been marked as a duplicate of this bug. ***
*** Bug 149305 has been marked as a duplicate of this bug. ***
Whiteboard: Done. Patch in bug 30888. → Done. Patch in bug 30888. branchOEM
Whiteboard: Done. Patch in bug 30888. branchOEM → Done. Patch in bug 30888. branchOEM+
Whiteboard: Done. Patch in bug 30888. branchOEM+ → Done. Patch in bug 30888.
You need to log in before you can comment on or make changes to this bug.