Re: command line deletion of files

Ahh, and reading on I see that this exists already :) On Fri, 30 Sep 2016, at 08:02, Bron Gondwana wrote: > You're the reason we can't have nice things :( rm + reconstruct will bite you > one upgrade for sure. > > A dry run option to ipurge sounds like a great idea. We just always use IMAP >

Re: command line deletion of files

You're the reason we can't have nice things :( rm + reconstruct will bite you one upgrade for sure. A dry run option to ipurge sounds like a great idea. We just always use IMAP to do admin on Cyrus, but I can see a case for improving ipurge. On Fri, 30 Sep 2016, at 01:04, Vladislav Kurz via

Re: Twoskip DB files broken

A couple of things. 1. Why are you doing this? What do you hope to achieve? 2. Possibly kolab's Cyrus configuration stores files in other paths (tmpfs, data dirs) which are Berkeley dbs and don't expect their environment to be trashed under them. On Thu, 29 Sep 2016, at 23:47, Tobias Brunner

Re: watching and processing a Spam folder for each user

Take a look at sa-learn-cyrus. Its a perl program that will traverse users spam/ham boxes and process them. It may not be exactly what you want but would be a good jumping off point. On 09/29/2016 02:48 PM, Adam Tauno Williams via Info-cyrus wrote: While I can see this being a neat built-in

Re: watching and processing a Spam folder for each user

> While I can see this being a neat built-in feature of a mail server > like Cyrus IMAP, I doubt it exists. I'd be happy to be corrected. Good old fecthmail. fetchmail --verbose --all --norewrite \ --folder 'user.awilliam.SPAM' --mda '/usr/bin/sa-learn --spam' > I wonder if such a beast

Re: watching and processing a Spam folder for each user

> "PB" == Patrick Boutilier via Info-cyrus > writes: PB> Only problem with that is users always seem to report some stuff as PB> spam when it clearly isn't. :-) True, but at least it's only a statistical thing. You could easily extract the From:

Re: watching and processing a Spam folder for each user

On Thu, 2016-09-29 at 12:25 -0300, Patrick Boutilier via Info-cyrus wrote: > > Only problem with that is users always seem to report some stuff as > spam  > when it clearly isn't. :-) That's fine.  They are only poisoning their own well if they do since each user has their own Bayes database.

Re: watching and processing a Spam folder for each user

On 09/29/2016 12:12 PM, Jason L Tibbitts III via Info-cyrus wrote: "BJM" == Brian J Murrell via Info-cyrus writes: BJM> So leaving out the latter part (the per-user database and handling, BJM> etc.) I wonder what, if anything exists to monitor the Spam (and

Re: command line deletion of files

On 09/29/16 17:14, Wolfgang Breyha via Info-cyrus wrote: > Vladislav Kurz via Info-cyrus wrote on 29/09/16 17:04: >> ipurge is nice but I would really appreciate if it had a --dry-run >> option. I'm never sure what it will really delete. > > It got one in 2.5.9. > > Greetings, Wolfgang > Ah,

Re: command line deletion of files

Vladislav Kurz via Info-cyrus wrote on 29/09/16 17:04: > ipurge is nice but I would really appreciate if it had a --dry-run > option. I'm never sure what it will really delete. It got one in 2.5.9. Greetings, Wolfgang -- Wolfgang Breyha | http://www.blafasel.at/ Vienna

Re: watching and processing a Spam folder for each user

> "BJM" == Brian J Murrell via Info-cyrus > writes: BJM> So leaving out the latter part (the per-user database and handling, BJM> etc.) I wonder what, if anything exists to monitor the Spam (and BJM> NotSpam) folders for all users. I have a system which

Re: command line deletion of files

On 09/29/16 16:32, Patrick Boutilier via Info-cyrus wrote: > On 09/29/2016 11:27 AM, Shawn Bakhtiar via Info-cyrus wrote: >> Good morning, >> >> trying to get rid of some emails that have large attachments (i.e. >> videos sent over email, or cd images, etc...) >> >> Would it be proper to >> >> rm

watching and processing a Spam folder for each user

I have experienced e-mail systems where each user has a "Spam" (and "NotSpam" on some) folder in their folder hierarchy to which they can simply move spam to have it classified as spam for them personally (per user Bayes databases for example). So leaving out the latter part (the per-user

Re: command line deletion of files

On 09/29/16 14:27 +, Shawn Bakhtiar via Info-cyrus wrote: trying to get rid of some emails that have large attachments (i.e. videos sent over email, or cd images, etc...) Would it be proper to rm -rf /var/spool/imap/u/username/mailbox/4321. then reconstruct -rf user.username Or is

Re: command line deletion of files

On 09/29/2016 11:27 AM, Shawn Bakhtiar via Info-cyrus wrote: Good morning, trying to get rid of some emails that have large attachments (i.e. videos sent over email, or cd images, etc...) Would it be proper to rm -rf /var/spool/imap/u/username/mailbox/4321. then reconstruct -rf

command line deletion of files

Good morning, trying to get rid of some emails that have large attachments (i.e. videos sent over email, or cd images, etc...) Would it be proper to rm -rf /var/spool/imap/u/username/mailbox/4321. then reconstruct -rf user.username Or is there a more "proper" way using cyrus? Thanks,

Twoskip DB files broken

Hi, I've discovered an odd behaviour which I don't understand: After a completely fresh Kolab 16 install on CentOS 7 (cyrus-imapd-2.5.9.27-5.1.el7.kolab_wf.x86_64) everything looks fine. I can create mailboxes, stop/start Cyrus, all works as it should do. The contents of /var/lib/imap looks like

Huge performance problems after updating from 2.4 to 2.5.9

Hi! A can add another story of that type, but with different setup: We already migrated to 2.5.7 on our ten backends some month ago step by step and upgraded to 2.5.9 lately. We never had any performance issues on them. All of them have done a full "reconstruct -V max" and special-use metadata

Re: why sieve's "reject" is incompatible with imap4flags actions ?

On 09/28/2016 10:52 AM, Deniss via Info-cyrus wrote: hello, in sieve/message.c in do_reject() all imap4flags actions are incompatible with reject action. Why ? imap4flags does no delivery indeed. what is a reason to ban "redirect" action with "reject" in rfc5429 This orginally comes from a