Correct use of cyr_expire on replicas when expire annotations are in use
What flags should I supply to cyr_expire in a replication configuration when I have expire annotations in use? I have a replication relationship from a 2.5.12 machine (in the process of being replaced, but currently the master) to a 3.0.8-6+deb10u4 (as replica). I have had problems with old messages not being deleted on the replica, and found I was not running cyr_expire on the replica. I have configured it, so I have: master: cmd="cyr_expire -E 7 -X 3 -D 3" at=0100 slave: cmd="cyr_expire -E 7 -X 3 -D 3" at=0300 Since I installed this, I have had periodic replication failures. What seems to happen is this: MAILBOX received NO response: IMAP_SYNC_CHECKSUM Checksum Failure CRC failure on sync for user.igb.routine, trying full update SYNCNOTICE: highestmodseq higher on replica user.igb.routine, updating 49317 => 49321 SYNCERROR: guid mismatch user.igb.routine 46708 (890a6db331aaccd8c423bbff598bb81bc3c19146 87fb316dea9c9dbbed691d11759b7b1e000d5487) FETCH received NO response: IMAP_PROTOCOL_BAD_PARAMETERS SYNCNOTICE: failed to prepare update for user.igb.routine: The remote Server(s) denied the operation do_folders(): update failed: user.igb.routine 'The remote Server(s) denied the operation' MAILBOX received NO response: IMAP_SYNC_CHECKSUM Checksum Failure CRC failure on sync for user.igb.routine, trying full update SYNCERROR: guid mismatch user.igb.routine 46708 (890a6db331aaccd8c423bbff598bb81bc3c19146 87fb316dea9c9dbbed691d11759b7b1e000d5487) FETCH received NO response: IMAP_PROTOCOL_BAD_PARAMETERS SYNCNOTICE: failed to prepare update for user.igb.routine: The remote Server(s) denied the operation do_folders(): update failed: user.igb.routine 'The remote Server(s) denied the operation' IOERROR: The remote Server(s) denied the operation Error in do_sync(): bailing out! The remote Server(s) denied the operation The synchronisation continues to do this, making no progress. The clean-up is straightforward: I delete all the files in user.igb.routine on the replica, reconstruct -G -U user.igb.routine on replica, sync_client -m user.igb.routine on the master. It then runs for a few days, and then goes bang again: suggestively, always in the early but not too early hours of the morning. What’s going wrong, and what’s needed to fix it properly? user.igb.routine is the only mailbox I have which both (a) is relatively high traffic and (b) has the expire annotation. My hypothesis (I only have 8 days of searchable logs, so this is n=small) is that the failure happens as we replicate the first message to be delivered to user.igb.routine after 0300. My supposition is that a trap is set by the delivery of a message into user.igb.routine between 0100 and 0300. 3 (the value of the “expire” annotation) days later at 0300, that message is deleted on the replica (as it is >(86400*3) seconds old) but was not deleted on the master (because when expire ran on the master, at 0100, the message was _not_ >(86400*3) seconds old). Something bad happens during the replication run, and bad things then continue to ensue. To test this theory my original thought was to run expire on the slave at the same time it runs on the master, making the race condition much smaller. But I see that in 3.0.8 there is a “-a” flag to cyr_expire which suppresses processing of the expire annotation, which I assume deals with this case. Am I thinking along the right lines? ian Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Replication and Deleted Files
On Thu 04 Jun 2020 at 18:57:37, Michael Menge (michael.me...@zdv.uni-tuebingen.de) wrote: > you also need to run cyr_expire on the "new_server" to remove the old expunged mails and deleted folders. Obvious when you try it! Thanks so much. Expired 23 and expunged 7617 out of 289060 messages from 268 mailboxes For some reason I had decided that you only ran cyr_expire on the master, and I was quite emphatic about it some years ago: # expire old stuff: dups 7 days, keep deletions for 3 days # XXX XXX XXX expire does not run on replica, does run on master XXX XXX XXX # expire cmd="cyr_expire -E 7 -X 3 -D 3" at=0100 Thank you again,.,.I shall be back in another 25 years with another query :-) ian Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Replication and Deleted Files
Hi, long-time Cyrus user (25 years, I think), but stumped on this one… I have an ancient Cyrus 2.5.11 on Solaris 11 installation I am trying to migrate off. The strategy is to run rolling replication onto the new server (3.0.8-6+deb10u4 on Debian 10.4), and then point the DNS record at the new server. With Covid, this has become more protracted than I would like, as I don’t want to accidentally mess up users who are isolating, so the replication has been running for some weeks. The replication structure is old-server -> new-server -> (backup1, backup2) where backup1 and backup2 are configured as separate channels on new-server. This has been running seemingly correctly for about three months now. Today I decided to check all was well by using rsync -an to confirm that the replicas have everything that is on the master. They do, in that using rsync -anvO --size-only --exclude='cyrus.*' root@mail:/var/imap/partition1/user/ /var/imap/partition1/user where “mail” is the old server shows that there are no messages missing (—size-only because there’s some time slew in a few places, usually only of a few seconds, but up to a day in others). However, reversing it: rsync -anvO --size-only --exclude='cyrus.*' /var/imap/partition1/user/ root@mail:/var/imap/partition1/user Shows that there are a _lot_ of files on the replicas which are not on the master, some of them relating to recent deletions, but some of them seemingly quite old. I am using: delete_mode: delayed expunge_mode: delayed everywhere, running cyr_expire on the master but not on the replicas. I have enough bandwidth that sync_reset and re-sync is realistic, but I’d rather not have to do that immediately prior to a cut-over. These old files are a worry because if I ever had to reconstruct one of the mailboxes, presumably the deleted (I think) messages would all reappear. Does anyone have any suggestions? Thanks ian Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Replication rolling or cron?
> > (at FastMail we start it from cyrus.conf, but also have a job that > runs from cron and checks that there's a sync_client running every 10 > minutes. It also works well with SMF if you're a Solaris site. $ svcs -x sync_client svc:/network/sync_client:default (?) State: online since Thu Feb 12 22:53:26 2009 See: /var/svc/log/network-sync_client:default.log Impact: None. $ That way it restarts on failure. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: imp webmail, cyrus imap and virus filtering
On 20 Feb 09, at 1727, andreas moroder wrote: > Hello, > > we have a imp/postfix/cyrus system. The mail that goes out and comes > in > from/to our system via smtp is checked by trendmicros virus wall. > > The problem is mail that remains in our mailsystem and is accessed via > imap from imp. Viruswall has no way to check this mail. > > Is it possible to write a sieve filter to start a virusscan on this > mail > ( by scanning the specific file in the users mail directory ? ) every > time a mail is created or read via imap ? You need to integrate virus scanning into your postfix environment. Mail sent between users of your IMP environment presumably is handed off to postfix and thence to lmtpd or deliver, and if your virus scanning were performed there you'd be sorted. If your virus scanning is instead an SMTP relay outside your internal system then you have a problem. We use clamav-milter alongside every sendmail instance and therefore scan every piece of mail at every point of handling. ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Security risk of POP3 & IMAP protocols
On 13 Feb 09, at 0149, Joseph Brennan wrote: > > The protocol itself is no less secure than POP. Security isn't about protocols, it's about systems, and I suspect POP3 vs IMAP is metonymic for local vs remote mail storage. I can see an argument that says that one problem with IMAP is that your entire mail store, which is much more interesting to an attacker than a message in flight or your current mail pending collection a la POP3, is under someone else's control. So if, say, you use a whole disk encryption product, mail delivered via traditional POP3 will be wrapped in the arms of the encryption immediately after collection, while mail stored on a remote server and accessed via IMAP will have whatever security features the server has. If you control the IMAP server (for some suitable value of `you') then a risk assessment is the same task in both scenarios. However, if, as is common in many situations, the IMAP server isn't within the scope of a risk assessment, then I can imagine that your 27001 life is a little easier if you don't have a large pool of potentially sensitive data under someone else's (for some value of `someone else') control. Data at rest is a different class of problem to data in motion, and IMAP implies a _lot_ of data at rest. To make this more concrete, imagine you're an HR department within a large enterprise, handling job applications, CVs, disciplinary processes, dismissals, etc. You need to demonstrate your compliance with your local data protection regulations. The theft of a day's email would be severely embarrassing, but is analogous to the theft of a day's postal mail: a risk which most businesses would accept. It would expose limited amounts of information about a small subset of your employees. However, the theft of a year's or a decade's email would expose substantial information about a large percentage of your employees, and would be analogous to allowing a few filing cabinets to be stolen. Your email system is run by your corporation's IT function in another jurisdiction which has laxer data protection laws --- say, an EU company whose head office is in the USA. Do you (a) store all your long term records in the other jurisdiction or (b) store them locally? Now I'm not defending the argument, and indeed here we have ~4TB of email on our Cyrus servers. But I don't think the position is entirely without merit, and having gone through the simplifying and distorting mirror of sales droids I can see where it's come from... ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
enforcing TLS certificates for replication
With my private network hat on, I have a requirement to secure replication. I have one machine in a data centre which runs 2.3.13 on Solaris 10. I've recently brought up an Open Solaris machine at home, similarly running 2.3.13, with a static IP number and an appropriate hole in the firewall to run replication. Which is all good, but I'm not at all sure how good my ISP is at preventing Bad People from mis- using IP numbers, so I'd like to require the sync_server to offer a certificate to prove its good will to the sync_client. I assume I can do it, but what are the options? ian Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Storage Sizing: IOPS per mailbox
On 08 Jan 09, at 1508, Blake Hudson wrote: > Original Message > Subject: Storage Sizing: IOPS per mailbox > From: ram > To: info-cyrus > Date: Friday, January 02, 2009 10:40:17 PM >> When sizing a storage device for a large cyrus server, the typical >> question asked by storage vendors is what is the IOPS required per >> mailbox >> M$$ Exchange has this concept of IOPS. and they suggest 1.5 IOPS per >> mailbox ( heavy users ) >> >> If I use postfix and cyrus , on my imap server ( pure IMAP >> server .. All >> spam filtering , outgoing mails , authentication etc happens on >> different servers ) >> >> >> If the storage is used only for imap storage , what is the typical >> "IOPS" requirement per user >> We will probably assume 30-50 mails a day of average 100k , and an >> email >> client checking for new mail every 5minutes >> >> >> > In my experience I would estimate 0.1 IOPS per user for heavy users > (thousands of emails per day, checked every few minutes) and 0.01 IOPS > per user for typical ISP accounts (under a dozen emails, checked a few > times daily). Our IMAP server has as I type 1020 imap connections up, representing most of our staff. The metadata (both /var/imap and per-mailbox) is in a ZFS pool configured as a two-way mirror of two-way stripes of SAS drives. The load on that is low. The zfs statistics on the metadata are as an example: mailhost-new# zpool iostat 1 capacity operationsbandwidth pool used avail read write read write -- - - - - - - pool1 54.4G 23.6G 12 77 489K 499K pool1 54.4G 23.6G 0785 0 3.74M pool1 54.4G 23.6G 0 14 0 135K pool1 54.4G 23.6G 0 24 0 877K pool1 54.4G 23.6G 0 33 0 242K pool1 54.4G 23.6G 0 10 0 43.6K pool1 54.4G 23.6G 0417 1.48K 2.06M pool1 54.4G 23.6G 0 22 0 139K pool1 54.4G 23.6G 0 1 0 7.92K pool1 54.4G 23.6G 0 7 0 31.7K pool1 54.4G 23.6G 0 20 0 83.2K pool1 54.4G 23.6G 0504 1013 1.93M pool1 54.4G 23.6G 0 23 0 574K pool1 54.4G 23.6G 2 17 96.5K 123K pool1 54.4G 23.6G 0 40 0 285K pool1 54.4G 23.6G 0 26 0 123K pool1 54.4G 23.6G 0698 1.98K 3.41M pool1 54.4G 23.6G 0 3 0 15.8K pool1 54.4G 23.6G 0 24 0 744K pool1 54.4G 23.6G 0 16 0 713K pool1 54.4G 23.6G 3 15 209K 147K pool1 54.4G 23.6G 5569 760K 2.71M pool1 54.4G 23.6G 0 16 0 222K ^Cmailhost-new# You can see the five-second sync. The first line, average, figures aren't representative because they of course include backup activity. The actual messages are stored in the lowest (`archive') QoS band of a Pillar Axiom 500, in NAS mode. The load is very small on each of two 2TB-ish partitions (it's approaching four pm, so the business is going at close to full load): mailpool1 I/O Operations Read I/Os per second: 58.677 Write I/Os per second: 7.129 Average Request Time: 4.475 ms Current MB per second: 1.003 General Statistics Read/Write Cache Hit Percentage: 69% Read/Write I/O Ratio: 89:11 mailpool2 I/O Operations Read I/Os per second: 46.733 Write I/Os per second: 9.467 Average Request Time: 1.923 ms Current MB per second: 0.544 General Statistics Read/Write Cache Hit Percentage: 56% Read/Write I/O Ratio: 83:17 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
