If sending HTML is appropriate depends on a more or less arbitary decision of the recipient, which can't even always be guessed from his/her MUA. It was suggested on n.p.m.mail-news (threads "Assuming "plain text" or "html mail".." and "Are users HTML compliant by default"), that a mail header should be implemented, which states, which content types the sender accepts (similar to the X-Accept-Language header). This header could be read by other MUAs, so they can base the decision, which content type to send, on that. The following suggestions have been made: - A header "X-Accept-Content-Type" could list the accepted content types in order of preference, e.g. "text/html, text/plain; format=flowed, text/plain" (delimiters have to change), if you like it "rich", or "text/plain, text/html", if you prefer plain text, but also accept HTML. - A header "X-Sender-Accepts:", in the HTTP "Accept:" header format, for mail and news. - A header based on <http://www.ietf.org/html.charters/conneg-charter.html> The implementation could look like the following: - There's some pref UI, which lets the user decide, which content types he/she likes. - Mail compose inserts the content type preference header. - Mail reply reads the header of incoming mails and stores them into some new field of the address book. This could be done in the code, which feeds the "Collected addresses" address book. - The code, that opens mail compose (nsMsgCompose::Initialize <http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#396> ?), asks this field of the address book, which content type to create, of type=default. - The address book UI needs some way to display the read header, but maybe also a way to override it.

> This could be done in the code, which feeds the "Collected addresses" address > book. See nsIAbAddressCollecter <http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/public/nsIAbAddressCollecter.idl> There's an issue about invalidating the collected headers: A user might switch to a MUA, which doesn't support the header and certain, previously preferred content types.

To update the header, one could store the Date from the message where the X-Accept header was harvested, along with the X-Accept contents itself. Overwrite the X-Accept information whenever the new Date is more recent than the old one.

roc, the problem is, if the new MUA doesn't support the header at all, i.e. there won't be an updating header at all.

Well then, if the latest message has no X-Accept header, just wipe out the X-Accept entry as if it never existed.

Consider the case where a user regularly uses two different MUAs. One MUA supports HTML, the other does not.

In that case, the user will have to configure the HTML-reading, Accept-header-producing MUA to disable HTML, or disable sending the Accept header altogether. If you think this is a really serious problem and users won't be able to handle it, then we simply disable sending of the Accept header by default. Savvy users can enable it, and then we can assume they will turn it off if there are problems. Personally, I think that the number of people using both an HTML-aware, Accept-aware MUA and a plaintext-only MUA to access the same account who are also not savvy enough to disable Accept will be fairly small. One could try something funky like, if we see a message from this user's account sent by another MUA, prompt the user with the option to fall back to that MUA's supported types. That's probably overcomplicated.

Cellphone/PDA mail clients are not unlikely to be text-only. I respectfully disagree with roc+moz@cs.cmu.edu

Fine. Then make the default behaviour "don't send header", i.e. the status quo. In the UI for enabling the header, also include selection of the acceptable content types so the user can't miss it. Any further objections? (Personally, I hope that my cellPDA has the ability to suck the text out of HTML and show it to me, otherwise it's not going to be nearly as useful.)

.

It's a pity that I never got to fix this bug.

Changing personal priorities. Giving away most of my bugs :-( (reassigning to default owner). I will still track these bugs closely. If you need my input, feel free to ask me. New owner: Please do *not* close these bugs (as WONTFIX or whatever you may find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you don't want to work on them.