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
> to
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 Inf
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 v
We use a perl scrip that does similar process to delete mass phishing or
malware email messages from the mail spool. The script locates the
sequence number for the message based on the message ID/filename, and
then issues the IMAP delete and expunge commands.
Relevant section of code below
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 f
> 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 exis
> "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: headers and blacklist them, but that wou
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.
Bu
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
BJM> NotSpam) folders for all users
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, tha
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 University Computer Cente
> "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 sucks things out of everyone's "c
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 -
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 database
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 there
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 user.usernam
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,
Shawn
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 t
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 is
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
20 matches
Mail list logo