Re: Patch for adding tls_honor_cipher_order
On 2014-10-16 19:32, Kristian Kræmmer Nielsen wrote: Hi, Patch attached. Something similar is already in cyrus-imapd-2.4: http://git.cyrusimap.org/cyrus-imapd/commit/?h=cyrus-imapd-2.4id=4b26d2d7244eeaa481871c337e57cd393fd76dfe For master / 2.5, I have a push pending of a similar nature, while it also addresses some client vs. server certificate chain configuration options (i.e. Internet-facing public CA, verify client certificates against private CA, offer client certificates between Cyrus IMAP servers, and allow requiring certs to be set to optional or required). Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: http://www.kolabsys.com pgp: 9342 BF08 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: Patch for adding tls_honor_cipher_order
Hi, already - I see you just added it ;-) But really great Jeroen for implementing these - thanks. Just a few comments - I see you also added tls_compression - maybe you should consider also actually implementing it? ;-) Also I would recommend logging a failure if a wrong tls_eccurve is specified as I do - you may also want to use openssl's automatic method of enabled the elliptic curve instead of prime256v1. I would recommend that you change tls_versions to a negative list instead of a possible list and thereby follow the nature of openssl and other projects, eg. sendmail, apache. The reasoning for this is that you want to disable old protocols but always automatically want to support newer protocols. At the moment you have no control over possible newer protocols which openssl support. They would with your patch be added anyway so the list would only specify a subset of protocols actually known by cyrus imap. E.g. if openssl starts to support e.g. tls1.3 that would actually be supported in cyrus without any upgrade but be counterintuitive since it would not have to be listed in tls_versions. Turning it around also makes transitioning easier for administrators, so they do not have to make sure to update their protocol list in Cyrus IMAP upon updating e.g. OpenSSL. Hence the SSL_OP_NO-options are no-options. /Kristian On Fri, 17 Oct 2014 12:34:21 +0200, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: On 2014-10-16 19:32, Kristian Kræmmer Nielsen wrote: Hi, Patch attached. Something similar is already in cyrus-imapd-2.4: http://git.cyrusimap.org/cyrus-imapd/commit/?h=cyrus-imapd-2.4id=4b26d2d7244eeaa481871c337e57cd393fd76dfe For master / 2.5, I have a push pending of a similar nature, while it also addresses some client vs. server certificate chain configuration options (i.e. Internet-facing public CA, verify client certificates against private CA, offer client certificates between Cyrus IMAP servers, and allow requiring certs to be set to optional or required). Kind regards, Jeroen van Meeuwen 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: Patch for adding tls_honor_cipher_order
Kristian Kræmmer Nielsen wrote on 17/10/14 14:48: already - I see you just added it ;-) No, they (and more) were there for month as https://bugzilla.cyrusimap.org/show_bug.cgi?id=3822 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3823 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3830 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3861 Regards, Wolfgang -- Wolfgang Breyha wbre...@gmx.net | http://www.blafasel.at/ Vienna University Computer Center | Austria 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: Patch for adding tls_honor_cipher_order
Hi Wolfgang, Not to start a flame war - but I was responding to Jeroen stating they were in cyrus-imapd-2.4 Something similar is already in cyrus-imapd-2.4. I know that the bugs were there, my patches even refer to them :) The more important part of my previous mail are that there are issues with the patches that now have been merged into git. E.g. compression is not merged correctly and it is recommended to do negative list and not positive lists of protocols. /Kristian On Fri, 17 Oct 2014 14:54:27 +0200, Wolfgang Breyha wbre...@gmx.net wrote: Kristian Kræmmer Nielsen wrote on 17/10/14 14:48: already - I see you just added it ;-) No, they (and more) were there for month as https://bugzilla.cyrusimap.org/show_bug.cgi?id=3822 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3823 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3830 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3861 Regards, Wolfgang 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: Upgrading from 2.2 to 2.4 (slow cyr_expire)
On 10/16/2014 05:43 PM, Andrew Morgan wrote: You could comment cyr_expire out of cyrus.conf before you upgrade. After a few days, you could uncomment cyr_expire and send a HUP signal to the Cyrus master process to have it re-read cyrus.conf. Remember, the mailbox will be upgraded anytime it is opened. That will occur when a user checks their mailbox AND when new mail is delivered. Still, it seems reasonably safe. Your best bet is to schedule the upgrade at a time of low usage and try to touch as many mailboxes as possible before things get really busy. Great, thanks! That's what I was hoping. Jay 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: messages removed before expire
On Fri, Oct 17, 2014, at 01:48 AM, Stephen Ingram wrote:
On Thu, Oct 2, 2014 at 8:48 AM, Stephen Ingram [1]sbing...@gmail.com wrote:
On Tue, Sep 16, 2014 at 11:15 PM, Bron Gondwana [2]br...@fastmail.fm wrote:
On Wed, Sep 17, 2014, at 08:24 AM, Stephen Ingram wrote:
On Tue, Sep 16, 2014 at 3:02 PM, Bron Gondwana [3]br...@fastmail.fm wrote:
Dumb question - but I don't suppose anything happened to your clock recently?
More non-dumb question, what version of Cyrus?
Sorry, I should have included the version. I'm using 2.4.16 rpms from Invoca
Systems. Nothing has happened with the clock. This is the only mailbox that
seems to have the problem too, user.ken.Trash. We are running a murder
configuration with 2 backends and 2 front ends. Not may users accounts, just
large mailboxes. Maybe there is some setting on the mupdate master or somewhere
else that is set for 14 days?
I don't think so. Do you have any entries in the syslog showing the deletes?
I'm pretty sure 'auditlog: 1' works in imapd.conf in 2.4.16, so you should be
able to add that to see more logging.
I finally got a chance to put in auditlog and I see several entries like this
everyday:
Oct 1 09:45:41 imap1 imap[7357]: auditlog: expunge
sessionid=imap1.4test.net-7357-1412174740-1 mailbox=user.ken.Trash
uniqueid=5f184bff4ee3c346 uid=170665
guid=5bbe70214bd4c7979f72977adda664afaa8ebe24
and then:
Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash
at then end. The system is now removing everything down to 7 days when info
user.ken.Trash yields:
{user.ken.Trash}:
duplicatedeliver: false
expire: 30
lastpop:
lastupdate: 2-Oct-2014 10:39:17 -0500
partition: default
pop3newuidl: true
sharedseen: false
size: 7749319
I did check the client as Alexei had suggested too as I thought the 14 days
(and now 7) were a little coincidental, but there was nothing there causing the
issue. Now after turning on auditlog, it does show the system removing these
mails. Is this expire 30 number stored somewhere that has become corrupt or
changed? This is just baffling to me as it seems to only affect this mailbox.
After another log search, I see there are messages removed every night. There
are dates stretching back 14 days on the file system and 7 days in the actual
Trash folder. I can't imagine that this could be a bug in Cyrus as I would have
thought others to have seen it by now. I'm guessing perhaps under some unique
set of circumstances, the file that contains the expiration information has
become corrupt causing the mail to be removed pre-maturely. Does anyone know
what file that information is contained within and if it can somehow be
regenerated?
I assume it's cyr_expire that's cleaning it up?
The likely places are either the command line flags to cyr_expire, the
annotations database entry for that folder, or this config item:
{ expunge_days, 7, INT }
/* Number of days to retain expunged messages before cleaning up their
index records. The default is 7. This is necessary for QRESYNC
to work correctly. If combined with delayed expunge (above) you
will also be able to unexpunge messages during this time. */
Note that that is only messages which are already expunged being unlinked from
the folder.
Bron.
--
Bron Gondwana
br...@fastmail.fm
References
1. mailto:sbing...@gmail.com
2. mailto:br...@fastmail.fm
3. mailto:br...@fastmail.fm
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: messages removed before expire
Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash The above shows *imap* doing an expunge. The imap client did this. Given delayed expunge the messages would still be there on the filesystem after this. The real expunge done by the expire job does not say imap: Oct 17 05:16:28 salmon cyr_expire[11566]: Expunged 2 messages from user.xxx Joseph Brennan Columbia University Information Technology 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: messages removed before expire
iOS is known for deleting messages from the Trash folder on its own behalf. On Fri, Oct 17, 2014, at 10:36 AM, Joseph Brennan wrote: Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash The above shows *imap* doing an expunge. The imap client did this. Given delayed expunge the messages would still be there on the filesystem after this. The real expunge done by the expire job does not say imap: Oct 17 05:16:28 salmon cyr_expire[11566]: Expunged 2 messages from user.xxx Joseph Brennan Columbia University Information Technology 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 -- Bron Gondwana br...@fastmail.fm 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: messages removed before expire
On Fri, Oct 17, 2014 at 7:50 AM, Bron Gondwana br...@fastmail.fm wrote: iOS is known for deleting messages from the Trash folder on its own behalf. On Fri, Oct 17, 2014, at 10:36 AM, Joseph Brennan wrote: Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash The above shows *imap* doing an expunge. The imap client did this. Given delayed expunge the messages would still be there on the filesystem after this. The real expunge done by the expire job does not say imap: Oct 17 05:16:28 salmon cyr_expire[11566]: Expunged 2 messages from user.xxx Joseph Brennan Columbia University Information Technology Thank you so much! This is a relief to know that Cyrus is not at fault here as it wouldn't make sense that it works for everyone else, but not this person. We just called the user again and asked if there was a phone or tablet that he hadn't disclosed previously. Indeed there was an iPad that he didn't consider important to mention that was set to delete after 7 days. I guess I need to be more thorough about checking all of the clients. Steve 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: messages removed before expire
On Fri, Oct 17, 2014, at 11:19 AM, Stephen Ingram wrote: On Fri, Oct 17, 2014 at 7:50 AM, Bron Gondwana [1]br...@fastmail.fm wrote: iOS is known for deleting messages from the Trash folder on its own behalf. On Fri, Oct 17, 2014, at 10:36 AM, Joseph Brennan wrote: Oct 1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash The above shows *imap* doing an expunge. The imap client did this. Given delayed expunge the messages would still be there on the filesystem after this. The real expunge done by the expire job does not say imap: Oct 17 05:16:28 salmon cyr_expire[11566]: Expunged 2 messages from user.xxx Joseph Brennan Columbia University Information Technology Thank you so much! This is a relief to know that Cyrus is not at fault here as it wouldn't make sense that it works for everyone else, but not this person. We just called the user again and asked if there was a phone or tablet that he hadn't disclosed previously. Indeed there was an iPad that he didn't consider important to mention that was set to delete after 7 days. I guess I need to be more thorough about checking all of the clients. Glad to know it's solved! Cheers, Bron. -- Bron Gondwana br...@fastmail.fm References 1. mailto:br...@fastmail.fm 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
disable SSLv3
Hi, I'm trying to protect myself from POODLE SSLv3 Vulnerability, I have cyrus-imapd-2.3.7-12 and CentOS release 5.9, I need a help, how to disable SSLv3 in my Cyrus IMAP server? Bestregards, Antonio Denizor 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
