Version: (using KDE KDE 3.4.91) Installed from: Gentoo Packages I had certain issues with KMail "semi-intelligently" switching the composer to HTML formatting (either by accidently pressed key shortcuts like Ctrl+I or whatever). So I sent HTML messages out accidently. Kmail saved the default composer setting and all further Messages are sent multipart/alternative. IMHO, this is crap. I did not find any option to tell KMail that I never ever want to send HTML messages and I do not want to be able to turn this on while composing. There is a big fat warning when I'm going to view HTML but sending HTML gets no further notification. This is not good, so either a "really?"-dialog should appear when turning on HTML in the composer or a global, non-overridable setting should turn HMTL off. I am one of the persons that did not like KMail to get able to compose HTML. I want my e-mail messages to be plaintext.
I think that warning dialog (plus assigning no key to html switch) would be enough.
I confirm this bug. I was just bitten by it. It should never silently switch to HTML; if Kmail believes it needs HTML and it is not enabled, it must ask user confirmation.
I totally agree. We should have the option to reply plain text only with no sient switching
I consider this fixed for KDE 4.3. Now, multipart/alternative mails are only created if you explicitly apply formatting to the message. If you just have the HTML toolbar enabled and don't use formatting, the mail will be sent as plain text.
*** Bug 182250 has been marked as a duplicate of this bug. ***
I do not see any change in 4.3. I just tested and get exactly the same behaviour: - type in something - type in ^B - type in more something - send message Result is multipart/alternative with HTML. You may argues that typing ^B means "explicitly formatting". I argue that when typing fast it is easy to make mistakes. I repeat - KMail must warn user that message will be switched to HTML. I will open new bug report because I am not allowed to reopen this one.
> I will open new bug report because I am not allowed to reopen this one. I'll reopen.
Thank you!
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
The title of this ticket is misleading. Both the reporter and Andrey (comment #6) call for some confirmation dialog such as "Really send as HTML message?" I'm not sure we need a confirmation, a more subtle indication in the composer might be better. But anyway, this is still relevant for kmail2, component "composer".
Nowadays the composer make it quite clear for the user that they are doing html editing with a big toolbar appearing in this case. I would consider this resolved.