Hallo, I recently stumple over some discussion about Sieve and what's the advantage to integrate it into the server rather than the LDA. Most of the filtering capabilites local users want to have performed are related to the INBOX or more preciesly the way to filter the message coming in. However, there are few tasks left: 1) Auto-archive old mail. 2) Drop old mail. 3) "Seen" mails are moved from INBOX to somewhere else. To 1) Several people love to store each single mail, but because the system becomes very slow when they open a mailbox with, day, 5000 messages (Mozilla even core dumps sometimes); they archive the mails by year or month, if they got elder than, say, 6 month. I do not want to discuss this habbit, it's like it is and I have the trouble with it. To 2) There is the doing of dropping all messages flagged as SPAM into a specific folder. It would be nice if the does messages are deleted, when they grew get elder. To 3) I don't grasp the idea, but it seems that notebook users want to look, what messages are new, flag and download selected ones; when they connect next time the "old, already seen" ones should be invisible, but still accessable on demand in another folder. Maybe it has to do with that the client sometimes reads the whole IMAP INBOX again, instead just the new ones. I've seen this behaviour with Mozilla myself in conjunction with a variaty of IMAP servers now and then. Those things must be user-configurable, of course ;-), I hoped Sieve would solve this problems, but it doesn't. The MVMF mentioned in the mailing list, doesn't as well. Does somebody has some solution for these tasks, besides to setup a cronjob and hack a webinterface? Is there some Dovecot tool that one can use to manipulate the mail storage? UW-IMAP ships such thing (mailutil), but it does not support Maildir and it would be nice, when the Dovecot extensions are created well. Bye, -- Steffen Kaiser
(05.07.01 kl.10:24) Steffen Kaiser skrev f?ljande till dovecot at dovecot.org:> Hallo, > > I recently stumple over some discussion about Sieve and what's the advantage > to integrate it into the server rather than the LDA. > > Most of the filtering capabilites local users want to have performed are > related to the INBOX or more preciesly the way to filter the message coming > in. > > However, there are few tasks left: > > 1) Auto-archive old mail. > 2) Drop old mail. > 3) "Seen" mails are moved from INBOX to somewhere else. > > To 1) Several people love to store each single mail, but because the system > becomes very slow when they open a mailbox with, day, 5000 messages (Mozilla > even core dumps sometimes); they archive the mails by year or month, if they > got elder than, say, 6 month. > I do not want to discuss this habbit, it's like it is and I have the trouble > with it.Ive not worked with sieve but with procmail. I gather sieve is more powerful so whats possible with procmail should be in sieve. With procmail simple store copies of all mails into a separate file. A cronjob can take care of renaming this file at appropriate times. Disadvantage is you dont archive per imap folder. You get all rolled into one.> > To 2) There is the doing of dropping all messages flagged as SPAM into a > specific folder. It would be nice if the does messages are deleted, when they > grew get elder.We sort the spam into a separate file. We rename the spam files via a cronjob. SPAM.1 becomes SPAM.2, SPAM becomes SPAM.1, the old SPAM.2 is overwritten.> > To 3) I don't grasp the idea, but it seems that notebook users want to look, > what messages are new, flag and download selected ones; when they connect > next time the "old, already seen" ones should be invisible, but still > accessable on demand in another folder. Maybe it has to do with that the > client sometimes reads the whole IMAP INBOX again, instead just the new ones. > I've seen this behaviour with Mozilla myself in conjunction with a variaty of > IMAP servers now and then.That one I dont understand at all.> > Those things must be user-configurable, of course ;-), I hoped Sieve would > solve this problems, but it doesn't. The MVMF mentioned in the mailing list, > doesn't as well. > > Does somebody has some solution for these tasks, besides to setup a cronjob > and hack a webinterface?Well if someone did a webinterface that would be nice. But everyone seems to have a different setup so this might not be trivial. Whats wrong with cronjobs ? Cheers, Jens> > Is there some Dovecot tool that one can use to manipulate the mail storage? > UW-IMAP ships such thing (mailutil), but it does not support Maildir and it > would be nice, when the Dovecot extensions are created well. > > Bye, > > -- > Steffen Kaiser >----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens L??s Email: jens.laas at data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrov?gen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN -----------------------------------------------------------------------
On 1.7.2005, at 11:24, Steffen Kaiser wrote:> I recently stumple over some discussion about Sieve and what's the > advantage to integrate it into the server rather than the LDA. > > Most of the filtering capabilites local users want to have performed > are related to the INBOX or more preciesly the way to filter the > message coming in. > > However, there are few tasks left: > > 1) Auto-archive old mail. > 2) Drop old mail. > 3) "Seen" mails are moved from INBOX to somewhere else.Hmm. I'm not really sure how these should be done. Sieve scripting doesn't seem like a correct place for this. It doesn't support expunging or moving mails so without some kind of extension none of these could even be done.> Is there some Dovecot tool that one can use to manipulate the mail > storage? UW-IMAP ships such thing (mailutil), but it does not support > Maildir and it would be nice, when the Dovecot extensions are created > well.I've been thinking about some scripting-friendly protocol, kind of a replacement for imap itself. I guess the "protocol" could be used as command line parameters directly as well. Anyway its main point is to separate search condition and action for it. So your tasks could be done something like: 1) move all mails received before June 01 to inbox-05: dovecot-mailutil -u username -m inbox -s "before 2005-06-01" -a "copy $ inbox-05" -a "expunge $" 2) just delete instead of moving anywhere: dovecot-mailutil -u username -m inbox -s "before 2005-06-01" -a "expunge $" 3) move seen mails: dovecot-mailutil -u username -m inbox -s "seen" -a "copy $ inbox-seen" -a "expunge $" -s would tell the search condition (like IMAP's SEARCH) and -a tell the action what to do with the mails that were found. Now it'd just have to be implemented.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050704/f1caf602/attachment-0001.bin>