(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.2 (using KDE 2.1.1 ) Severity: wishlist Installed from: Red Hat Linux 7.0 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79) OS: Linux 2.2.17-8smp i686 OS/Compiler notes: Hi! First thanks for a really nice program. I tried it the last couple days and it is really slick. I like especially the PGP/GPG connectivity. However I will never use it alone on this computer. A very simple reason: sometime I will login from outside with a character terminal and use pine (mutt/elm) to check my mail. Or if I don't want to wait for kmail to startup (start X start kde start kmail) I will use a console based mailer. In this it is quite unfortunate that kmail uses its own inbox in Mail/Inbox. Imagine: * I read a mail with kmail and decide to leave it in my inbox to answer it later * the next time I use pine - but the above mail is gone into ~Mail/inbox. Now I have to tell pine to go into this special folder. My whole workflow is broken. The same problem with procmail. Why do I need to do something special to use procmail? Pine is fine if procmail writes into ~Mail. Why can't kmail? I suppose its all an issue of the .index files. I see at least a couple ways how to solve this: * check modification time on mail folders (or checksums). If somebody other than kmail changed a folder rebuild the .index files * How does pine do it? AFAIK they also use persistent information in some special mail in each folder (or only the inbox?). Yet pine is able to play nice with other mailers and procmail. I really appreciate all the time you put into this. But if kmail doesn't get more interoperable on the local system I won't be able to use this. Of course this is no great threat but I image other people having the same problem. Thanks a lot Hans (Submitted via bugs.kde.org) (Called from KBugReport dialog)
On Thursday 26. April 2001 01:44 hans@ecke.ws wrote: > > In this it is quite unfortunate that kmail uses its own inbox in > Mail/Inbox. Imagine: * I read a mail with kmail and decide to leave it in > my inbox to answer it later * the next time I use pine - but the above > mail is gone into ~Mail/inbox. Now I have to tell pine to go into this > special folder. My whole workflow is broken. What about setting up a local POP3 server if not already running and using that instead of the local account? > The same problem with procmail. Why do I need to do something special to > use procmail? Pine is fine if procmail writes into ~Mail. Why can't kmail? > > I suppose its all an issue of the .index files. I see at least a couple > ways how to solve this: * check modification time on mail folders (or > checksums). If somebody other than kmail changed a folder rebuild the > .index files * How does pine do it? AFAIK they also use persistent > information in some special mail in each folder (or only the inbox?). Yet > pine is able to play nice with other mailers and procmail. A way to use procmail together with KMail is described in the FAQ. Regards Michael Häckel
Dear Michael > > In this it is quite unfortunate that kmail uses its own inbox in > > Mail/Inbox. Imagine: * I read a mail with kmail and decide to leave it in > > my inbox to answer it later * the next time I use pine - but the above > > mail is gone into ~Mail/inbox. Now I have to tell pine to go into this > > special folder. My whole workflow is broken. > > What about setting up a local POP3 server if not already running and using > that instead of the local account? It should be easier than this. What if I'm not the sysadmin on my cluster? See below. > > The same problem with procmail. Why do I need to do something special to > > use procmail? Pine is fine if procmail writes into ~Mail. Why can't kmail? > A way to use procmail together with KMail is described in the FAQ. You are right of course. But the way described is too complicated in my opinion. When I want to add another destination mailfile for procmail I would have to configure it twice: once in my .procmailrc and the other time in the kmail config. Thats too much. What happens if I change a mailfolder name in .procmailrc but forget it for kmail? Right now my .procmailrc knows about 15 destination mailfolders. The probability of screwing up something is high. I assume the two problems are really one: kmail can not deal with folders that change while kmail is running. This means it can't deal with procmail writing into some folder in ~/Mail and it can't deal with the inbox staying /var/spool/mail/<user> because in this case the local mail daemon would write too it sometimes. This problem can be overcome. Pine works just fine with all this. It seems to me this is a model which is a leftover from POP3 and just doesn't cut it for local (or IMAP) mail. Is there a chance that you guys will fix this in the future? I would really like to use kmail.... Sincerely Hans -- Hans Ecke hans@ecke.ws Department of Geophysics http://hans.ecke.ws Colorado School of Mines Tel: (USA) 303-273-3733 Golden Colorado Fax: (USA) 303-273-3478 "Having lost sight of our objectives we redoubled our efforts." -- Walt Kelly
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29. April 2001 05:30 Hans Ecke wrote: > I assume the two problems are really one: kmail can not deal with > folders that change while kmail is running. This means it can't deal > with procmail writing into some folder in ~/Mail and it can't deal > with the inbox staying /var/spool/mail/<user> because in this case > the local mail daemon would write too it sometimes. > > This problem can be overcome. Pine works just fine with all this. On the subject "leave mail in local inbox": Could you please explain why it should make sense to leave some mail in the local inbox while other mail is moved to other folders in your home directory (by procmail or KMail or whatever)? Just because Pine does so is IMHO no reason. If you really need this how about implementing a "move mail back to local inbox" and providing us with the necessary patch. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE66/tfGnR+RTDgudgRAu1wAKDH7z1fmiI96qMYEV99vN4WnRpNWwCgtQ+H WXGMvP8Nm3mMK19UUCWFmyM= =GNQn -----END PGP SIGNATURE-----
Hi Ingo > > I assume the two problems are really one: kmail can not deal with > > folders that change while kmail is running. This means it can't deal > > with procmail writing into some folder in ~/Mail and it can't deal > > with the inbox staying /var/spool/mail/<user> because in this case > > the local mail daemon would write to it sometimes. > > > > This problem can be overcome. Pine works just fine with all this. > > On the subject "leave mail in local inbox": > Could you please explain why it should make sense to leave some mail in > the local inbox while other mail is moved to other folders in your home > directory (by procmail or KMail or whatever)? Just because Pine does so > is IMHO no reason. You are right of course. If I only used kmail or another mailer that can deal with the inbox beeing just a file in ~/Mail everything would be just fine. Problem is that people will continue to use several mailers. At least for the time it takes them to switch to kmail. But even afterwards there are situations where you will need a console-only solution (you are only loged in via telnet not running an X-server). It all comes down to compatibility with other mailers. I believe compatibility is very important. Why I leave read mail in the inbox: My inbox usually contains both unread mail and read mail that I have to act upon in the next couple days. Other mailfolders are for stuff that is not so urgent or important or for high-volume mailing lists. > If you really need this how about implementing a "move mail back to > local inbox" and providing us with the necessary patch. As I see it (which might be wrong you guys are the experts) this would not solve the problem. You have this model that kmail has its own mailfolders in ~/Mail where it has complete control. Every once in a while it looks into all local mailfolders (which are filled by the maildaemon or procmail) and downloads all new mails from them. It seems to me that this model is just fine as long as we are dealing with only POP3. But it is too confining for local mail (or IMAP probably). Please don't take my criticism too serious. You are doing a great job. If it doesn't really work for me this means I have a problem not you. But as I see how most people around here read mail and imagine what it would take for them to switch to kmail they wouldn't like the same things I don't. Cheers Hans -- Hans Ecke hans@ecke.ws Department of Geophysics http://hans.ecke.ws Colorado School of Mines Tel: (USA) 303-273-3733 Golden Colorado Fax: (USA) 303-273-3478 "Is tragic opera everybody die." "Is comic opera everybody die but they die HAPPY!" -- Danny Kaye
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 30. April 2001 17:22 Hans Ecke wrote: > You are right of course. If I only used kmail or another mailer that > can deal with the inbox beeing just a file in ~/Mail everything would > be just fine. Problem is that people will continue to use several > mailers. At least for the time it takes them to switch to kmail. But > even afterwards there are situations where you will need a > console-only solution (you are only loged in via telnet not running > an X-server). Then maybe mutt is a better solution than pine. > It all comes down to compatibility with other mailers. I believe > compatibility is very important. Maybe. But we certainly can't be compatible to all mailers. > > If you really need this how about implementing a "move mail back > > to local inbox" and providing us with the necessary patch. > > As I see it (which might be wrong you guys are the experts) this > would not solve the problem. I guess you are right. But I also guess that this compatibility issue doesn't have a high priority for the developers. Therefore it's not very likely that it will be solved in the near future if ever. > You have this model that kmail has its own mailfolders in ~/Mail > where it has complete control. Every once in a while it looks into > all local mailfolders (which are filled by the maildaemon or > procmail) and downloads all new mails from them. It seems to me that > this model is just fine as long as we are dealing with only POP3. But > it is too confining for local mail (or IMAP probably). Netscape Messenger does it the same way. I know this is no excuse. But I guess the original developers of KMail mimicked Messenger's way of doing it. And this might have been a bad decision with regard to compatibility with other MUAs. Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE67bD5GnR+RTDgudgRAoPSAJwO+jQxuHgc12qy6awYp0mK0B+1sACeLOnW ClO25h5JlcuTnuVrMTf1yjo= =8w9A -----END PGP SIGNATURE-----
First what are the correct mailing addresses to reply to? I do a "reply to all" but don't know if thats correct. > I guess you are right. But I also guess that this compatibility issue > doesn't have a high priority for the developers. Therefore it's not > very likely that it will be solved in the near future if ever. I guess right now thats all I have to say to this issue. Obviously I would have to implement the functionality I want myself which is fine. But I'm already involved in too many projects so I don't have time for that. Thanks a lot for listening to me anyway. And my best wishes for kmail development. Cheers Hans -- Hans Ecke hans@ecke.ws Department of Geophysics http://hans.ecke.ws Colorado School of Mines Tel: (USA) 303-273-3733 Golden Colorado Fax: (USA) 303-273-3478 All opinions expressed herein are solely those of my friend Buck the squirrel.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 30. April 2001 22:56 Hans Ecke wrote: > First what are the correct mailing addresses to reply to? I do a > "reply to all" but don't know if thats correct. You should only reply to the address which contains the bug number (in this case 24783@bugs.kde.org). > > I guess you are right. But I also guess that this compatibility > > issue doesn't have a high priority for the developers. Therefore > > it's not very likely that it will be solved in the near future if > > ever. > > I guess right now thats all I have to say to this issue. Obviously I > would have to implement the functionality I want myself which is > fine. But I'm already involved in too many projects so I don't have > time for that. > > Thanks a lot for listening to me anyway. And my best wishes for > kmail development. Should this bug be closed? Or should we keep it as wish? Regards Ingo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE67t5KGnR+RTDgudgRAooiAJ9pumHU/SUMovIGA+OlnguJBk4YeQCgw7br YaD7DFkNRL+SAGJTnABvm9k= =gd/y -----END PGP SIGNATURE-----
Hi Ingo > > I guess right now thats all I have to say to this issue. Obviously I > > would have to implement the functionality I want myself which is > > fine. But I'm already involved in too many projects so I don't have > > time for that. > > > > Thanks a lot for listening to me anyway. And my best wishes for > > kmail development. > > Should this bug be closed? Or should we keep it as wish? Could you keep it as a wish? Thanks a lot. Sincerely Hans -- Hans Ecke hans@ecke.ws Department of Geophysics http://hans.ecke.ws Colorado School of Mines Tel: (USA) 303-273-3733 Golden Colorado Fax: (USA) 303-273-3478 And just to annoy the Feds: plutonium encryption anthrax Sarin ammonium nitrate bomb guns firearms munitions encryption NSA FDA CIA BATF prevents cancer prescription drug Delta Force militia.
[RANT ON] I would just like to add my $0.02 to Hans' plea. I think KMail does look pretty slick and meshes nice with the KDE I love so much. Too bad I will never use it in it's current state for the very reasons Hans mentioned and then some. I can only get so frustrated before remembering what KMail costs. Still I think you are underestimating those of us that want to use both an X client (i.e. KMail) AND a console client particular trusty ole pine. I believe there are more of us out there than you realize. I was (and still am) under the impression that choice was one of the major tenets of the free software movement not too mention just good sense. You wouldn't go to a movie theatre with only one exit and no fire door. And yet in some way this is what KMail sort of does by forcing a conversion to its '~/Mail' formats with little alternative. (Granted I can kinda read my KMail stuff with pine but the folders are messed up). One usually expects this kinda behavior out of Redmond WA! OK I'm getting snotty now so I'll try to tone it down. ;-) My specific beefs are the Inbox issue procmail and most of all the folder hierarchy : 1) I was a little iritated by parts of the earlier exchange: > Could you please explain why it should make sense to leave some mail in > the local inbox while other mail is moved to other folders in your home > directory (by procmail or KMail or whatever)? Just because Pine does so > is IMHO no reason. Well IMNSHO its a damn good reason! The stuff that shows up in my INBOX is the stuff I need or want in front of my eyeballs RIGHT NOW and perhaps for the near future regardless of the MUA that is doing the showing. 2) I still don't understand why KMail can't deal with the STANDARD UNIX MAIL FILTERING software procmail. The so-called procedure in the FAQ is really just a kludge. 3) Folder hierarchy - this is the biggest thing that makes KMail unusable for me. Under my pine 'mail' dir I have some mail folders and then I have the Unix dir 'Money' with mail folders stocks bills shopping etc the Unix dir 'Computer' with mail folders java linux apps etc. and the Unix dir 'People' with mail folders Mom Amy John etc. Of course none of these are even visible in KMail. Conversely if I make a KMail folder foo and then a subfolder bar all I see in pine is foo with all the messages and the hierarchy is basically gone. The hierarchy is essential to organizing the mail. If you can't organize the mail there is almost no reason to even have an MUA. Obviously this all boils down to what was said before but it bears repeating: Interoperability. If I build an HTML website I can generally view it with Netscape 4.x Mozilla Konqueror or Opera. Why can't I have a "mail site" that is viewable by pine elm mutt and KMail? The wishlist thread says > I guess you are right. But I also guess that this compatibility issue > doesn't have a high priority for the developers. Therefore it's not > very likely that it will be solved in the near future if ever. Well I think it really needs to have a high priority - it just makes good sense. And > Netscape Messenger does it the same way. I know this is no excuse. But I > guess the original developers of KMail mimicked Messenger's way of doing > it. And this might have been a bad decision with regard to compatibility > with other MUAs. No it sure isn't an excuse. Isn't continuing development exactly for fixing these 'bad decisions'? Would not fixing such a 'bad decision' as you admit it is put the KMail system on sounder footing? Would that not be a better state to be in? Why stick with a flawed design? Here in the US there is a phrase that sometimes appears on children's report cards: "Plays well with others". At present KMail does NOT play well with others. )-; [RANT OFF] PS - Not to put words in his mouth but I think what Hans and I both really want is 'KPine' = pine on the I/O backend (incl. folder mgmt) + KMail on the frontend GUI. Wish it actually existed... Wish I had the time and skill to bring it into existence ;-). -- +---------------------------------------------------------------------+ | G. Brannon SMITH WWW: http://www.cs.msstate.edu/~smithg/ | | Computer Science @Mississippi St Univ mailto:gbs1@ra.msstate.edu | | mailto:smithg@cs.msstate.edu | +---------------------------------------------------------------------+ | "There is no off position on the genius switch." - David Letterman | +---------------------------------------------------------------------+
#if G. Brannon Smith > > Netscape Messenger does it the same way. I know this is no excuse. But I > > guess the original developers of KMail mimicked Messenger's way of doing > > it. And this might have been a bad decision with regard to compatibility > > with other MUAs. > No it sure isn't an excuse. Isn't continuing development exactly for > fixing these 'bad decisions'? Would not fixing such a 'bad decision' as > you admit it is put the KMail system on sounder footing? Would that not > be a better state to be in? Why stick with a flawed design? KMail Netscape Messenger and mutt all live together happily. Face it pine is the one that's incompatible not KMail. Rik
I am an ex-Gnome and a new KDE user. As soon as I start using Kmail, I find that Kmail doesn't really extrapolate well with other tools like procmail, and fetchmail. It seems that I am forced to use kmail to retrieve and filter emails which is not as flexible as the counterpart (procmail and fetchmail). What happen when I am not in X. I agree to what Hans has said but I use mutt instead. I use Kmail beause it integrate nicely with the kaddress and kpilot stuff while mutt doesn't. I apprieicate the developer who bring kmail to live. But I think it should be a frontend instead frontend plus a whole bunch of stuff that doesn't work well with a lot of the useful tools out there. BTW, I also think that the nested maildir format is kinda weird. Is it the way it is done? Aside from kmail, I have an impression that KDE generally doesn't just implement the GUI of the existing tools but to duplicate these tools in their GUI counterpart. So the logic of these tools are woven together with the GUI code. Am I right?
Subject: Re: option missing for interoperability: leave/keep =?iso-8859-1?q?mails in=20local?= inbox On Saturday 07 June 2003 05:26, Edwin Lau wrote: > I am an ex-Gnome and a new KDE user. As soon as I > start using Kmail, I find that Kmail doesn't really extrapolate well > with other tools like procmail, and fetchmail. It seems that I am > forced to use kmail to retrieve and filter emails which is not as > flexible as the counterpart (procmail and fetchmail). I use fetchmail to fetch all my mail and I use procmail to prefilter some mail (spam) directly into a KMail folder. All other mail is written to a local file where I then fetch the mail from with KMail. So using fetchmail with KMail is absolutely no problem and using procmail is possible but has some disadvantages. In the FAQ we describe a way how to use procmail in a safe way. > BTW, I also think that the nested > maildir format is kinda weird. Is it the way it is done? There's no standard for nested maildir folders that I'm aware of. Regards, Ingo
Subject: Re: option missing for interoperability: leave/keep =?iso-8859-1?q?mails in=20local?= inbox On June 7, 2003 08:25 am, Ingo Kl
Hi, here is Hans, the guy who filed this bug originally. I'm still using pine which has served me well through the last 10 years of life under different Unix - and now Linux - computing environments. The thing about pine is: IT JUST WORKS. I can use it under Linux in X/KDE/Konsole. Under IRIX with xterm. On vacation, in a public library on a windows computer, I can download PuTTY and SSH into my home workstation and run pine. Of course, here at my main Linux/KDE workstation, pine is a pain. Pictures can't be viewed easily, as can HTTP links or HTML mails. Much of the sorting and searching functionality is a decade out of date. So I'd love to move over to kmail. I'm sure there are adequate filtering facilities to replace procmail. And If I use _only_ kmail, the issue with clearing out the spool are not so important. But the problem is: I am not always using kmail. When on vacation, I'll SSH into the workstation and expect to have a console mail application working and integrating with my usual setup. When X crashes (I work with a lot of experimental stuff at work - and that tends to crash), I sometimes only have the text console available. And if I change my working environment to something else beside KDE, I expect to take my mail archives and setup and have it work somewhere else. That is the only reason (for me) why I don't use kmail: I will only ever use it 90% of the time, and it does not "play nice" with the general environment on which I depend the other 10%. (The same is true of Gnome's Evolution, btw). KDE, you guys have created an amazingly comfortable environment for us all to enjoy. Thank you very much for that. But in this particular case, its not for me and the other people who commented on this "bug". Don't get too happy with your KDE realm that you forget about the world outside and about cooperating with it. Cheers Hans
Subject: Re: option missing for interoperability: leave/keep mails in local inbox I just want to add that we are very well aware of the problems you mention and that we would like to see them fixed. But those interoperability problems don't itch us, the people who are currently working on KMail, enough to actively work on fixing those problems. The situation has already improved a little bit with the introduction of maildir. And it will steadily improve more and more over time. But we are all working on KMail in our spare time for the fun of it and therefore we mostly work on stuff that we'd like to see fixed/improved. On Monday 09 June 2003 01:21, Edwin Lau wrote: > Then I guess using KDE/kde-pim/ to represent kde-pim is under KDE is > more meaningful than .KDE.directory/kde-pim/, isn't it? The problem with this approach is that it would then be impossible to have subfolders named "new", "tmp" or "cur" because those filenames are reserved in the maildir format. > I hope you will consider my ideas. If you don't think they are > valid ideas, can you pt me to an alternative to kmail? Yes, your ideas are valid ideas. But, see above. If you don't need a graphical email client then you should probably consider using mutt. Regards, Ingo
I think there should be a "On exit move read mail to [_______] folder" and let the user select wether or not to move the read mail and where to move it. I have the same problem, for example, when I am at home I use a webmail to read my mail (it uses imap), but when I am at work I use kmail, and sometimes I use text MUAs. Any thoughts on this?
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.
(In reply to comment #17) > 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. That makes sense, lets create a new feature request so it can be ignored for 10 more years. At that time kde5 will be "getting there", and kde4 will go unmaintained.
Hi there- Sorry, I don't have time to try out kmail2. I really appreciate your work on a desktop PIM suite, but (at least for me) it does not have a good use case anymore. How does it integrate with my smartphone, and the various other devices I use to interact with email, calendar, contacts etc? Personally I have moved on to hosted solutions, even if they are less free. Cheers & thank you Hans