Linux Planet features "KMail in Depth" describing KDE's e-mail application as having 'masses of features and no malware'. The article describes converting to KMail, encrypting & signing e-mail and configuring multiple accounts.
... like Thunderbird or Operamail did?
Is there a patch or is this an option in near future? I think, it made your/my day instead of boring text smileys. Pls look at Kopete!
If you made these smileys in Kmail (and maybe Knode?) themeable, then I don't want to think about what we'll see on kde-look.org soon ;-)
Thank's for your answers!
PS: it's not a security hole, textbased mails will be text based. It's only the rendering. And for the "serious" users here, there should be an option to disable this goodie of course...
i'd say file a wish on bugs.kde.org. or ask some coder you know to try to make a patch.
bug 83388 is what you wanna vote for!
Thank you very much too for your informations. That's what I want to see in Kmail. It's not a feature, it's only a very nice goodie!
are you kidding me? I can't believe so many others are supporting this idea... Graphical smileys are _not_ a good thing. If you're going to add the feature, please disable it by default!
If KDE is used in business settings, such eye-rollers can't do much for KDE's reputation...
How wrong you are. Microsoft Outlook, the gold standard for PIM clients, used at businesses worldwide, automatically replaces any smiley you type with the stupid ugly smiley-face from the Wingdings font. KMail's smileys (and I've heard that they have already been added for 3.4) are going to look much better than THAT for sure.
a) How's it going to be represented in the email? Is it going to remain as :) (colon + close parenthesis), or is it going to be converted to a standard smiley character (U+263A, ☺)?
b) If the latter, what character encoding is going to be the default (US-ASCII won't cut it)?
c) What compatibility issues arise from switching character encodings?
d) If you actually mean to type a colon and a close parenthesis, how do you get it to not do it?
Only Outlook does that weird conversion thing, and I believe it simply changes the font to wingdings and types a letter "J", as opposed to using the real unicode smiley character.
If it works in KMail the way it does in Thunderbird, it is something that happens only when you view other people's emails, not during composing (unless you explicitly select a smiley from the smiley button in the toolbar, but it still sends only the text version). So it won't convert any characters to anything else or use any special encodings. However, it will mess you up if you are trying to read an email that legitimately has the character sequence :) not representing a smiley. Luckily these emails are few and far between, and there will of course be an option to turn it off. Furthermore if you copy and paste the smiley into a text editor it will hopefully come out as :), so copy and paste of code snippets should still work even if they have smileys in them. I can't guarantee that's how it works in KMail, but that's how it *should* work.
"However, it will mess you up if you are trying to read an email that legitimately has the character sequence :) not representing a smiley. Luckily these emails are few and far between"
I agree, but how about "(?)"? I have a tendency to write this (when I just wrote something that I'm not entirely sure of), and the annoying "ASL?"-figure is drawn. Sure I can turn it off, but that won't help the recipient much. Also, when discussing C++, a really common thing is writing for example std::string, where ":s" will be rendered as a smily with an "s"-mouth.
These examples are from kopete, but I guess it's true for more IMs. I like the smilies, but they sure can be annoying when you didn't really want one there.
Wow, kopete must has a pretty comprehensive set of smiley replacements. I guess that is to be expected in an IM client. Hopefully KMail does not go quite that far in its smiley support.
Oh, please. Since when is Microsoft Outlook the yardstick by which software should be measured? Or are you one of those people whose car gets 40 rods to the hogshead, and that's the way you like it?
In the "In Progress" section of the KDE 3.4 Feature Plan , there's a listing under Kmail that says "Smileys" which may or may not be what you're wanting.
FWIW, an Anonymous Coward over at Slashdot mentioned that having emoticons in Kmail is one of the new features.
Thank you very much for your information, hopefully this is what I want!
At least to me, a LaTeX plugin like the one in Kopete would be much more handy :) Also, ability to load images on demand would be nice.
Not really adding anything usefull here, but KMail is great. KMail is great, again, KMail is great. And so is KDE, and so is KDE3.4, it's all great.
I mean, KMail is great. Can't mention it enough. Hey, KMail is great.
Meh. I use it (switched from Mozilla mail) and I'm still not sure if it was a good trade or not.
Advantages: deals with file associations correctly (this is why I switched)
Disadvantages: No Cut/Copy/Paste application or context menus in composition windows (hotkeys only? What is this, EMACS?), no "format=flowed" support makes you choose between all of your mail looking bad on other people's machines (linebreaks everywhere!) OR having your mail composition scroll indefinitely off the right side of the window, and the window for choosing address book entries for new mails is so large the buttons disappear off the bottom of the screen (workaround: hit enter for OK)!
It's rough. Still. Yes, all of the above bugs are being worked on. The Cut/Copy/paste thing will even be fixed in 3.4. But "polished" it is not.
Then again, it opens my attachments in the correct applications, and even uses nice icons. So that's better than Mozilla.
Wait...and when you click a URL in KMail, it for some reason reads the whole page in Konqui (silently) and THEN launches your preferred browser! No, this is not me forgetting to put %U on the end of the file association, it really does this. Because it's silent (there's no Konqui window) you can tell if you make Konqui prompt you for cookies and then go to a URL with cookies. Loading the same page twice is pretty silly.
There are bugs filed on all of these. I'm just venting. I WANT to agree that KMail is great. Unfortunately, I just find it to be adequate.
"No Cut/Copy/Paste application or context menus in composition windows (hotkeys only? What is this, EMACS?)"
Not so for me (KDE 3.3.1). Cut/Copy/Paste are in the usual places (toolbar, edit menu, context menu) in the new mail composition/edit menu. Do you mean something else?
"no "format=flowed" support"
Would be nice to have I guess, but I don't see that it's really a problem. Mail that you send does not look bad on other people's computers. Lines will be a consistant length. Lots of email programs do this. I've never heard anyone complain.
" the window for choosing address book entries for new mails is so large the buttons disappear off the bottom of the screen"
Once again, I have no idea what you're talking about. On my machine the window is very small. Would even fit on a 640x480 screen with room to spare.
"and when you click a URL in KMail, it for some reason reads the whole page in Konqui (silently) and THEN launches your preferred browser!"
It doesn't load the whole page in Konqueror, as evidenced by the fact that if you click on a link, it will pop up konqueror (on my machine) and then finish loading the page. It may check if the website can be connected to before launching your preferred browser. This may be silly but its not a big deal.
I believe that KMail is checking what type of file is being linked to, so it can choose whether to launch your web browser or some other program (for example a video player). It doesn't just automatically send any http:// links to your web browser, and it doesn't assume that the file extension is correct. Personally I think that this is a misfeature because it makes the common case (link to an html page) twice as slow.
Some form of email text flowing is really important. I just can't stand looking at 10 layers of word-wrapped >>>s any more! What year is this, 1985? I think the real fix for this is HTML composition (which I heard is possible now in kmail?). I don't understand why so many peole hate HTML mail. IMHO every mail should be HTML, even unformatted ones, just so you get the nice word wrapping and the ability to indent sensibly instead of using >>>. I don't care about the images and fonts and colors; in fact I think KMail should have a feature to throw those all away when rendering HTML messages, and it should be enabled by default. Wacky colored fonts and background images in email should die a horrible death, but we shouldn't deny ourselves nice word wrapping and indenting just because some people have bad taste. It can be fixed with technology! :-)
> I don't understand why so many peole hate HTML mail.
- because 99% of all html-mail I get is SPAM, and ~95% of all SPAM I get is html-mail
- because a lot of clients set the font in html-mails to some ridiculously small size making it unreadable with greater resolutions
- because html-mail (as commonly send by for instance outlook) is often (at least) 30 times as big, as plain-text-mail (and that's without using background images, background music, and similar idiocy)
- because with html-mail, I'm now at the mercy of people who like sending their mail in a light blue font on a slightly darker blue background, and using hidious font.
- because using html brings up security concerns (as you can embed all kinds of weird stuff in it)
1. So get a spam filter, this isn't HTML's fault and it's no reason to ignore the benefits HTML mail can give.
2. That's why KMail should automatically fix up these types of problems in incoming mail. It would be easy to remove backgrounds and fix low-contrast or tiny text.
3. Even large HTML mails are still small enough that they've never caused me any problems. Outlook's HTML is generated by Word and of course bad, but good HTML isn't much larger than plain text.
4. See 2
5. No embedding is possible in decent email clients (including kmail of course), they forbid it.
If you use a decent email client, HTML mail is nothing to fear. The important thing is the simple formatting that HTML allows, like text flowing and justification, lists, tables, and indented quotes. The the other crap can and should be stripped out by your mail client.
> 1. So get a spam filter,
Why bother when I can suffize whith just filtering html-mail
>this isn't HTML's fault and it's no reason to ignore the benefits HTML mail can give.
what benifits would that be exactly?
html-mail gives the sender more controk about how to display his mails, but IME those that actually use the extra possibilities (most legitimate html-mail does not), use it a way I _really_ don't want
> 2. That's why KMail should automatically fix up these types of problems in
> incoming mail. It would be easy to remove backgrounds and fix low-contrast or
> tiny text.
yep, but then why use html-mail, as doing so would get rid of the html stuff (from legitimate html-mail) I've ever got (everything else can be done in plain text)
> . Even large HTML mails are still small enough that they've never caused me
> any problems. Outlook's HTML is generated by Word and of course bad,
my mail archive currently takes up 1.2 GB, times 30 that would take up more then half of my laptops harddisk (leaving to little space for the rest)
> but good HTML isn't much larger than plain text.
true, but I've yet to see such mail (and that's assuming people don't start adding backgrounds and such), the html produced by almost all e-mail clients sucks big time
> 4. See 2
yep but that kind ogf thing is the only thing I've seen people actually using it for
> 5. No embedding is possible in decent email clients (including kmail of
> course), they forbid it.
ideally yes, by:
1. I's one more avenue for attack, one that's not necesary
2. Most non-geeks, unfortunately, don't use a decent e-mail client
> The important thing is the simple formatting that HTML allows, like text
> flowing and justification, lists, tables, and indented quotes.
tables are the only thing a good text editor can't do easily in that list, and I have yet to see an html-email using tables for something other than layout.
>my mail archive currently takes up 1.2 GB, times 30 that would take up more >then half of my laptops harddisk (leaving to little space for the rest)
Why not archive it? I'm sure a *giggle* "power user" *giggle* such as yourself could easily write a script to bzcat it when needed.
You are what's wrong with linux today: too much conservatorism. You don't want HTML mail? So delete it. Nobody's forcing you to keep your mail. By the same logic, we should all turn our web sites to space formatted .txt files because it would obviously take way less space. It never ceases to amaise me how hardcore adepts of an operating system can be so opposed to new technologies. Anything that makes your work easier is "bloat", something a "real" user wouldn't look at. Well guess what: you are not a real user! You are just a network administrator or a developer at best.
> You are what's wrong with linux today: too much conservatorism. You don't
> want HTML mail?
Why on earth would I want html-mail? I have yet to find a single real benefit to it. And I know of several (readibility, space, security) real disadvantages.
You seem to think html-mail is the best thing ever, so enlighten me exactly what makes it so?
> So delete it. Nobody's forcing you to keep your mail.
I do for html-mail (unless in the extreeeemly rare case it contains something potentially interesting)
> By the same logic, we should all turn our web sites to space formatted .txt
> files because it would obviously take way less space.
Web sites and mail are 2 different media with different requirements, and goals. I suppose you think we should al start to IRC in html-code to? How about SMS, let's start html-coding them also.
Note: I won't oppose anybody using html-mail, when it's sensible and necessary, but I have yet to come across a _single_ instance of that. Html-mail I used to get from relatives and friends (before I educated them), was mostly less then 12 lines of simple text without any formatting at all.
> It never ceases to
> amaise me how hardcore adepts of an operating system can be so opposed to new
When those new technologies don't offer advantages, only disadvantages, off course I'm opposed.
> Anything that makes your work easier is "bloat", something a
> "real" user wouldn't look at.
er, sorry? what on earth are you talking about?
> Well guess what: you are not a real user! You
> are just a network administrator or a developer at best.
oogh! I just love the condescending tone of that! (note: sarcasme in preceeding sentence) So in your world a network admin, or developer is somehow worth less then someone else?
Being an network admin, developer, power user, ordinary user, total newby, or whatever other category you think up in no way implies anything abouth worth. It might tell you something about gathered knowledge, experience, and typical use, but even then you'll make mistakes by assuming.
Don't even bother with the ad hominem attacks, I've been online to long to bother getting mad about them (besides they only weaken your position)
>Why on earth would I want html-mail? I have yet to find a single real benefit
>to it. And I know of several (readibility, space, security) real
I don't actually care what *you* want. It's about what other people want. I don't personally write a lot of html mail, but I don't bitch about other people using it like some baby who's favorite toy is been shaded by that cool new kid's car.
>You seem to think html-mail is the best thing ever, so enlighten me exactly
>what makes it so?
I never said that. And read above.
>Web sites and mail are 2 different media with different requirements, and
>goals. I suppose you think we should al start to IRC in html-code to? How
>about SMS, let's start html-coding them also.
Again: read first
>Note: I won't oppose anybody using html-mail, when it's sensible and
Good for you, but who say's when it is sensible and necessary? For me it's
sensible that my gf is going to buy me drinks when we go out. For some abhorant
reason, for her it is not!
>When those new technologies don't offer advantages, only disadvantages, off
>course I'm opposed.
When those new technologies don't offer advantages, only disadvantages, they
won't be used by anyone. If they are used by at least one person, they offer
something usefull. To become academical, most new technologies don't offer
anything usefull at the time of their introduction (not that html mail was just
introduced so don't get into that; note "academical").
>> Anything that makes your work easier is "bloat", something a
>> "real" user wouldn't look at.
>er, sorry? what on earth are you talking about?
er, ranting :)
>> Well guess what: you are not a real user! You
>> are just a network administrator or a developer at best.
>oogh! I just love the condescending tone of that! (note: sarcasme in
>preceeding sentence) So in your world a network admin, or developer is somehow
>worth less then someone else?
It's not about worth, it's about numbers (newsflash no1); "real" users far
outnumber the number of educated computer users. I am sorry you view
that as an attack on your own person(newsflash no2). It's a dissagreement with
your point of view.
A spam filter would be a million times more effective and accurate than simply filtering HTML mail. I get plenty of text spam and legitimate HTML in my mailbox.
You say that plain text can do everything HTML can do, but you are living in a dream world. Non-HTML email CANNOT do text flowing and justification, or indented quotes, or bulleted lists, in a reasonable way that survives forwarding or mangling by SMTP servers. These are the benefits HTML provides.
HTML can do many very useful things that plain text simply cannot do. That is why it is necessary in a modern email client. It can also do many things that should not be done in email. That is why modern email clients should (and do) only support a subset of HTML's full capabilities. When you use a good mail client HTML mail is good, *even if* everybody else uses bad email clients. That's why KMail should support HTML mail.
We use standard KDE methods for opening a URL you click on so it behaves just like any other KDE application. If you think that's wrong then file a bug report against kdelibs.
I'd really prefer to have a better ascii-editor in Kmail instead of HTML.
A lot of layout (like indenting, itemization, enumerated lists, centered text) can be done in ascii without compromising the security of the reader or setting off false alarms because of using a technique normally used by spammers.
Would be great to have some buttons for these purposes in the normal plain text mode. And it would really set kmail apart from the other MUAs.
HELLO! KMAIL DEVELOPERS! PLAIN TEXT LAYOUTING!!!
HTML Email offers a lot of benefits if used appropriately.
As a business owner, when replying to potential customers it is very useful for sending a professionally layed out document, that provides them with all of the necessary information in a very readable way. Email is not just about mailing lists but also about business communications.
An important part of that communication is branding. One thing we like to do with our mail is to include the business logo in the signature of every email. Now my current "Windoze" email client PEGASUS (a very security minded app) supports not only HTML email but also embedded images, including there use in signatures.
In Linux land (where I am progressively moving) the only Email app that seems to support that feature is Evolution. When weighing up the differences between Kmail and Evolution, I much prefere the PIM elements of Kontact to the ones in Evolution, but the very limited HTML supported by Kmail is pushing me in the direction of choosing to use Evolution.
In now way do I suggest the use of remote hosted images. This kind of content should always we blocked (let a browser view that content if wanted), but the embedding of appropriate images/logos within the text of an email is a very proper use of HTML email.
A look at the user functionality of Pegasus would show that yes this can be done securely, even on a "Windose" platform. So how about Kmail implementing embedded images in email (incoming & outgoing)?
It's on the TODO-list, AFAIK.
Yes, it's one the feature I miss most too.
Bug#59101 (no copy/paste, etc). Resolved 2005/1/9 in CVS. Can't wait to finally see what apparently you've been seeing.
Bug#41926 (format=flowed). Lines are only all the same length if the window size on the receiving computer is wider than your line length. If it's narrower, they get automatic line breaks AND your line breaks too. Looks like crap.
Maybe I have more address book entries than you. Can't find this bug number--may it hasn't been reported after all.
Bug#60787 (Konqui downloads file twice). Actually it DOES download the whole file twice--otherwise why would Konqui prompt for every cookie on the page before launching Firefox?!? It may not do this if your preferred browser IS Konqueror.
These are real bugs. I won't be a happy KMail user until they're fixed.
It doesn't use Konqueror to download the whole file, it just uses the HTTP IOSlave to request the very beginning of the file from the server to determine the file type so it knows what application to launch. The cookie-handler is a separate service provided by KDE through the HTTP IOSlave; it doesn't have anything to do specifically with Konqueror.
I do agree that this behavior is annoying, but the alternatives all seem bad too. KMail could always launch your web browser for HTTP links, but then if you clicked a PDF file link (for example) you would end up with an empty browser window in addition to your PDF reader. It could get the file type from the file extension alone but then it would need to know about every funky extension used on the web (.aspx, .jsp, etc).
The real solution is for KMail to hand off the partially downloaded file to the application that will use it, so the download continues instead of being restarted. But this really is impractical, especially for applications that don't use KDE's IOSlaves. I suppose the practical solution is to always launch your web browser, and just ignore the empty browser windows that pop up when viewing PDFs or videos or such. Or perhaps the popping up of browser windows could be suppressed somehow?
"Bug#59101 (no copy/paste, etc). Resolved 2005/1/9 in CVS."
Oh. You mean when viewing messages, I thought you meant when composing them.
It's a problem for sure, but shouldn't be critical for you. CTRL-C and CTRL-V work just fine in 3.3.1.
"Bug#41926 (format=flowed). Lines are only all the same length if the window size on the receiving computer is wider than your line length. If it's narrower, they get automatic line breaks AND your line breaks too. Looks like crap."
What is your line length set to? It should be about 72 or so. Of course if you set it to longer than most people's screen size it will look like crap.
"Bug#60787 (Konqui downloads file twice). Actually it DOES download the whole file twice"
Actually it doesn't. But Spy Hunter already explained that. I think you're making these small issues out to be a much bigger deal than they really are. I would classify them more as minor annoyances, not critical bugs
No, I meant viewing AND composing. Yes, Ctrl+C and Ctrl+V works great, but if there are no menu options in the compose screen in KDE 3.4, I'll file another bug. I'd certainly hate it if they fixed the problem in only one spot.
I set mine for 72, which is smaller than most people's windows at a standard font size. But not everyone. Is that their problem? I'd say no--one of my friends has vision problems and sets the fonts large so they can read my mail. This works great for everyone else's mail--but mail from me looks bad because it comes from KMail.
I appreciate that exactly ONE of the several problems I highlighted was explained as less severe than I had thought. (on what planet is not being able to see the OK/Cancel buttons not critical?!?) Let's hope the rest are fixed.
There are people out there on slow connections and they work sometimes on text MUAs. Why should KMail insist on using HTML?
I mean, writing a message, a letter or something like that means dealing with WRITING. You don't draw a picture to invite your colleagues to a meeting. You write a short text, do you?
KMail by default uses text messages. This is simple and enough. This is secure and efficient.
OTOH you can use KMail to read and to compose HTML messages. Just use it.
I remember times when watches started to get LCDs. Soon there were watches with calculator functionality. It was a demonstration of what could be achived using that state of technology. Most young people dreamed of such a watch. Do you want to know what that watches really were? They were crap. The keys were so small, you could use them with a pen only. And soon people started to realize, that they usually don't need that calculator functionality because you usually use a watch as a watch.
I (personally) see HTML mails as such an overkill. Yes, a lot of people use it. Given that HTML composition is on by default in most of the "business" MUAs, we'll get more and more HTML mails. But this is hopefully only a phase. How many watch models with calculator functionality can be found today in a shop or catalog?
HTML provides a lot of features that are not useful for mail (and these should not even be supported by KMail), but unlike calculator watches, HTML also provides many features that *are* useful. It is the only way to send a mail message that wraps properly, has any text formatting at all (center, italics, etc), and survives quoting or forwarding gracefully.
I consider these features essential in a modern email client, and even terminal users can benefit from them. Links is a fine HTML viewer; any modern email client has no excuse for not supporting HTML.
Proper HTML need not be much larger than the text alone (and it could be smaller if you try fancy ASCII formatting in the text version). Not providing the good features of HTML mail by default may turn quite a few people off from using KMail.
It's 2007 and it's still hard to impossible to link to websites when composing email in kmail. I'm not saying that html should be the default mode, but at least it should be an option for those that desire it.
Any way to view email attachments like jpg, txt and whatnot rendered within the main kmail window as opposed to launching an outside app? I know, security, security. I mean just having the option available, or I completely missed it!
It's a minor little annoyance in an overall great app! Kontact rox!
View > Attachments > Inline
what you're looking for?
(Using Kmail 1.7.2)
Thank you!!! I missed it.
The KDE Community rocks.
the only major issue with any KDE apps is they required X11 to function, KMail would be great it if ran natively in one of the GUI OS's that buisness people used. ( W32 or OSX )
Those OSes have their own email applications. It is a misktake to invest development time and resources into a platform where the platform owners have greater control than you over defaults and over the functioning and hooks to the platform.
Tell me how well is Eudora doing on Win32? How about Opera Mail or even Thunderbird?
The latter might be doing a slightly bit better based on the free price of admission. Most people are clueless and just use whatever is on the computer.
It would do KDE no good to spend considerable time porting to these other operating systems. What we need is more Linux, Free/Open/Net BSD users. That's a goal worth striving for.
I have no interest in seeing free software apps on proprietary apps, other than as gateway apps, such as OpenOffice.org
"LinuxQuestions.org has opened voting for their 2004 Members Choice Awards, so be sure to head on over and vote for your favorite applications. GNOME and various other GNOME/GTK related projects are in the running so be sure to make your vote count!"
Why don't we blatantly advertise KDE and drive users to vote. I'm sure it wouldn't hurt.
take a close look at the other articles on the Dot :o)