(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: KDE 3.0.0 Severity: wishlist Installed from: Compiled From Sources Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified My mail is being delivered directly to several Maildir folders in ~/Mail/. KMail includes them and it is possible to browse through this folders. But in order to check for new emails you have to go through all folders to have the index refreshed. I would appreciate a function (like fetching mails from the POP-accounts) which go through all folders and refreshes them. Or (even better) when KMail recognize changes at these folders. (Submitted via bugs.kde.org)
*** Bug 42415 has been marked as a duplicate of this bug. ***
I read several bugs about procmail and kmail not being compatible. Although I am not completely sure it seems that this is the case with mbox folders and not maildir. I have the same setup as above and it seems that the only thing needed is to have some sort of interval 'index update' in the same way email check happens so that indexes are refreshed. Or even better have fam monitor the directories and update indexes on that event in real time. Everything else seems to be working fairly well.
I have my mail delivered to ~/Mail by procmail (retrieved by fetchmail), which first filters it through bogofilter to catch Spam. I don't have any "receiving" accounts set up. I just use Kmail to read the mail in my maildirs. This is a big turn off for me at the moment. If Kmail could be set to monitor my mail folders for new mail while it's open, it would make it much easier to see if there's anything new in the folders. Like the submitter said, I have to walk through all the folders to see if there's anything new. If there's only one new message in the folder, Kmail will jump directly to it and mark the message/folder read (I have set the option to mark messages read after 0 seconds and would like to keep it that way). So, in fact, I can actually miss new mail, since to me it looks like there's nothing new in the folder. I have to remember if a specific message was there before. I think if this bug gets fixed, Kmail will be more attractive to those, who simply use Kmail to read the mail and not necessarily retrieve it.
> I have my mail delivered to ~/Mail by procmail Please see section 6.28 of the KMail FAQ http://docs.kde.org/en/3.1/kdenetwork/kmail/faq.html#id2839596 Don.
I think the only way this is going to get 'fixed' is to provide diffs :( There appears to be no willingness to allow KMail to share it's folders with anything else, be those folders Maildir or mbox. eg if I go overseas I want to have my mail available offline so I use offlineimap and then read it with Evolution (which is a pain because I dislike a lot of evolution) but KMail won't even consider the possibility of externally manipulated folders (which does seem a little silly given maildir is designed specifically to allow this). The 'solution' I have heard to my problem is to use the experimental offline IMAP feature (which is pretty new).. I haven't tried it yet as I'm a bit loath to trust my email to it :( (Especially when I see problems where KMail won't read a message from an IMAP server if I abort it and then reclick on it sometimes, that indicates cache problems, and hence my nervousness in trusting the cache :)
> ------- Additional Comments From darius dons net au 2004-04-19 > 06:56 ------- I think the only way this is going to get 'fixed' is > to provide diffs :( > > There appears to be no willingness to allow KMail to share it's > folders with anything else, be those folders Maildir or mbox. Personally I'm ok with it. I don't think it's going to happen anytime soon though. It's difficult to allow external manipulation of folders without losing speed or robustness. > eg if I go overseas I want to have my mail available offline so I > use offlineimap and then read it with Evolution (which is a pain > because I dislike a lot of evolution) but KMail won't even consider > the possibility of externally manipulated folders (which does seem > a little silly given maildir is designed specifically to allow > this). I don't see how Evolution is different from KMail here. I believe any modern mail client that uses summary/index files (Evolution, Sylpheed, Mozilla, KMail) suffers the same limitation. Googling seems to confirm this for Evolution: http://braindamage.alal.com/archives/gentoo-user/20030917/2914.html http://mail.gnome.org/archives/gnome-list/2001-December/msg00040.html > The 'solution' I have heard to my problem is to use the > experimental offline IMAP feature (which is pretty new).. I haven't > tried it yet as I'm a bit loath to trust my email to it :( > (Especially when I see problems where KMail won't read a message > from an IMAP server if I abort it and then reclick on it sometimes, > that indicates cache problems, and hence my nervousness in trusting > the cache :) I don't see how that will help to check mail when you're remote. This might help: http://lists.svlug.org/pipermail/svlug/2002-October/042429.html Don.
> I don't see how Evolution is different from KMail here. Earlier versions of Evolution didn't have this functionality but at least since 1.4 evolution supports local maildir folders without trying to be an MTA. I have fetchmail delivering mail locally, procmail filtering (+spamassassin) and if I setup Evolution to look the topmost local maildir everything works properly (including searches and virtual folders). There is a FAQ even for evolution that claims that it works with shared mbox mailboxes as well (I never tried this as it sounds too dangerous): http://support.ximian.com/cgi-bin/ximian.cfg/php/enduser/std_adp.php?p_sid=IG5gIi9h&p_lva=&p_faqid=49&p_created=995288067&p_sp=cF9ncmlkc29ydD0mcF9yb3dfY250PTM4JnBfc2VhcmNoX3RleHQ9bWFpbGRpciZwX3NlYXJjaF90eXBlPTQmcF9wcm9kX2x2bDE9MiZwX3Byb2RfbHZsMj1_YW55fiZwX2NhdF9sdmwxPX5hbnl_JnBfc29ydF9ieT1kZmx0JnBfcGFnZT0y&p_li= Sharing mailboxes with other clients is also in evolution's documented: http://www.ximian.com/support/manuals/evolution_14/x1114.html (search for 'Sharing Mailboxes with Other Mailboxes').
> Personally I'm ok with it. I don't think it's going to happen anytime > soon though. It's difficult to allow external manipulation of folders > without losing speed or robustness. In evolution you can tell it about an existing maildir and it will at least let you look at it. It will look into subdirs for you and generate the folder tree automatically. > I believe any modern mail client that uses summary/index files > (Evolution, Sylpheed, Mozilla, KMail) suffers the same limitation. In my experience evolution worked reasonably well for what I needed - ie sync my mail up over the pathetically slow link I was using and send what I had written, then disconnect. In this case it didn't matter whether concurrent updates happened because it didn't happen. > I don't see how that will help to check mail when you're remote. > > This might help: > http://lists.svlug.org/pipermail/svlug/2002-October/042429.html If I am remote I usually have a slow and expensive dialup to use, so syncing mail over then disconnecting is the best way of reading it otherwise it's too costly. That URL is an interesting idea, but kind of gross :) I was thinking of offlineimap + UW imapd, but haven't got around to it yet (or perhaps use offlineimap + cyrus and skip local maildirs altogether).
> In evolution you can tell it about an existing maildir and it will > at least let you look at it. It will look into subdirs for you and > generate the folder tree automatically. This sounds like a good idea. However it's clear from the example given ( http://www.ximian.com/support/manuals/evolution_14/x1114.html ) that mutt is working on separate mail folders from Evo. Implementing support for this still won't allow KMail to share ~/Mail with other MUAs, and this type of feature doesn't really satisfy the original request as made in this bug report. I guess a new 'Evo like pseudo mailbox sharing' wishlist item should be created, if this is a feature people want in KMail. Don.
Created attachment 5707 [details] evolution and mutt on same maildir mailbox Evolution and mutt working on the same maildir mailbox.
> However it's clear from the example given > ( http://www.ximian.com/support/manuals/evolution_14/x1114.html ) > that mutt is working on separate mail folders from Evo. Implementing > support for this still won't allow KMail to share ~/Mail with other > MUAs, and this type of feature doesn't really satisfy the original > request as made in this bug report. I attached a screenshot of mutt and evolution working side-by-side on the same *local* maildir mailbox on my machine. This is also the mailbox where procmail delivers and sorts emails.
> Evolution and mutt working on the same maildir mailbox. What makes you think this screenshot shows mutt and Evolution working on the same mailbox? What makes you think Evo is not working on it's own copy of the mailbox (in ~/evolution). Don.
> What makes you think this screenshot shows mutt and Evolution working > on the same mailbox? What makes you think Evo is not working on it's > own copy of the mailbox (in ~/evolution). 1) evolution doesn't remove any emails from /home/alkis/.maildir 2) when an email is marked as read in evolution it is also marked as read in mutt 3) when procmail delivers emails in subfolders, they show up in evolution as well 4) unless the developers of evolution found a way to compress email in an very compact way I don't see any evidence that evolution has a copy of my mail: alkis@moro alkis $ du -chs .maildir evolution 451M .maildir 2.4M evolution Just out of curiosity, what makes you think that evolution is not sharing the mailbox with mutt?
> Just out of curiosity, what makes you think that evolution is not > sharing the mailbox with mutt? Not a lot anymore :) Your message is convincing. Does Evolution support this for only maildir or for mbox also? I am definitely interested in looking into this further the next time I upgrade my Evolution. Don.
> Does Evolution support this for only maildir or for mbox also? I only tried it with maildir style mailboxes. But from what I see in Evolution's options, shared mbox and mh style mailboxes are supported as well (the documentation only talks about sharing mbox mailboxes though).
I'd just like it very much to use kmail just to READ the emails - while using procmail to deliver them (this can happen while I'm not logged in ..) - BUT, if kmail is open, it won't realize that there's a new message unless I select the folder. Worse even, if I happen to have selected the inbox in kmail and some mail is delivered to it, it is 'lost' in the sense that it resides in inbox/new but kmail never displays it (even after restarting kmail) - so I have to move it by hand to inbox/cur. Why don't you add an option to the folders' preferences stating something like 'this is a folder where mail could be delivered to', so kmail can periodically check if there is something new?
*** Bug 76025 has been marked as a duplicate of this bug. ***
Reassigning to KMail2. Please all reporters comment on the state of this wish with KMail2, thanks in advance
since nobody commented since one year, I am closing this bug. I believe this should work in kmail2, it automatically updates itself if other programs add mails into the maildir directories. Please reopen if you feel this does not work as wanted with kmail2.