Re: Configure Cyrus 2.4.17+caldav~beta9 and CalDavZAP 0.12.1
Support for the expand-property REPORT which CalDAVZAP 0.12.x is using
was added to Cyrus in October of last year, which was post-beta10.
If you want to try this with the 2.4 code, you will need to fetch the
caldav-2.4 branch from http://git.cyrus.foundation
On 04/29/2015 11:09 AM, Lucas Zinato Carraro wrote:
OK I put caldavzap on cyrus httpd server
In Web browser JavaScript console:
REPORT http://webserver:8088/dav/principals/user/lucas.carraro/
net::ERR_EMPTY_RESPONSE
---
In Cyrus telemetry log: http-18367
-- lucas.carraro Wed Apr 29 12:00:15 2015
1430319615 tel:1430319615REPORT
/dav/principals/user/lucas.carraro/ HTTP/1.1
Accept-encoding: gzip, deflate, sdch
Content-type: text/xml
Accept-language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
Origin: http://webserver:8088
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/44.0.2376.0 Safari/537.36
Host: webserver:8088
Accept: application/xml, text/xml, */*; q=0.01
X-client: CalDavZAP 0.12.1 (Inf-IT CalDAV Web Client)
Connection: keep-alive
Content-length: 723
Cookie: agendav_sessid=2f3062c5049a5ec4ab347756128627e4
X-requested-with: XMLHttpRequest
Authorization: Basic ...
Depth: 0
Referer: http://mail.icict.fiocruz.br:8088/caldavzap/index.html
?xml version=1.0 encoding=utf-8?A:expand-property
xmlns:A=DAV:A:property name=calendar-proxy-read-for
namespace=http://calendarserver.org/ns/;A:property
name=email-address-set
namespace=http://calendarserver.org/ns//A:property
name=displayname namespace=DAV:/A:property
name=calendar-user-address-set
namespace=urn:ietf:params:xml:ns:caldav//A:propertyA:property
name=calendar-proxy-write-for
namespace=http://calendarserver.org/ns/;A:property
name=email-address-set
namespace=http://calendarserver.org/ns//A:property
name=displayname namespace=DAV:/A:property
name=calendar-user-address-set
namespace=urn:ietf:params:xml:ns:caldav//A:property/A:expand-property
--
In config.js
var globalNetworkCheckSettings={href:
'http://webserver:8088/dav/principals/user/', hrefLabel: null,
additionalResources: [], forceReadOnly: null, settingsAccount: true,
timeOut: 9, lockTimeOut: 1, delegation: true,
backgroundCalendars: [], ignoreAlarms: false}
--
Another idea ?
On Wed, Apr 29, 2015 at 9:56 AM, Ken Murchison mu...@andrew.cmu.edu
mailto:mu...@andrew.cmu.edu wrote:
On 04/29/2015 08:41 AM, Lucas Zinato Carraro wrote:
How to set document root to dcyrus httpd?
Only put
httpdocroot: /var/lib/cyrus/htdocs ?
in imapd.conf or is necessary to configure another option ?
That's all you need.
On Wed, Apr 29, 2015 at 8:51 AM, Ken Murchison
mu...@andrew.cmu.edu mailto:mu...@andrew.cmu.edu wrote:
On 04/28/2015 11:27 PM, Lucas Zinato Carraro wrote:
caldavzap is in another server.
Why not just have Cyrus HTTP serve up CalDAVZAP? This will
avoid the cross-origin requests the JavasScript is
complaining about.
I debug more and find this log in JavaScript console.
XMLHttpRequest cannot load
http://mailserver.com:8088/dav/principals/user/. No
'Access-Control-Allow-Origin' header is present on the
requested resource. Origin 'http://webserver.com' is
therefore not allowed access.
---
Anyway to put this specific header in cyrus httpd ?
Try setting the httpallowcors option in imap.conf. This
should enable the cross-origin headers,
On Mon, Apr 27, 2015 at 8:25 AM, Ken Murchison
mu...@andrew.cmu.edu mailto:mu...@andrew.cmu.edu wrote:
On 04/17/2015 10:17 AM, Lucas Zinato Carraro wrote:
I'm testing Cyrus Caldav ( 2.4.17+beta9 ) with
several clients iCal, Lightning, AgendaDAV, Evolution .
Unfortunately, I could not configure with the
CalDavZAP 0.12.1
I follow the procedure to 2.5.0 (
http://cyrusimap.org/docs/cyrus-imapd/2.5.0/install-http.php)
---
In cyrus.conf
SERVICES {
..
http cmd=httpd listen=8088 prefork=0 maxchild=400
.
}
---
In caldav/config.js
var globalNetworkCheckSettings={href:
'http://myserver.com:8088/dav/principals/user/
http://mail.icict.fiocruz.br:8088/dav/principals/user/',
hrefLabel: null, additionalResources: [],
forceReadOnly: null, settingsAccount: true, timeOut:
9, lockTimeOut: 1, delegation: true,
backgroundCalendars: [], ignoreAlarms: false}
var globalSettingsType='calendar-home-set';
Any suggestion
Re: Configure Cyrus 2.4.17+caldav~beta9 and CalDavZAP 0.12.1
You could also test with CalDAVZap 0.11.x
On 04/29/2015 11:09 AM, Lucas Zinato Carraro wrote:
OK I put caldavzap on cyrus httpd server
In Web browser JavaScript console:
REPORT http://webserver:8088/dav/principals/user/lucas.carraro/
net::ERR_EMPTY_RESPONSE
---
In Cyrus telemetry log: http-18367
-- lucas.carraro Wed Apr 29 12:00:15 2015
1430319615 tel:1430319615REPORT
/dav/principals/user/lucas.carraro/ HTTP/1.1
Accept-encoding: gzip, deflate, sdch
Content-type: text/xml
Accept-language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
Origin: http://webserver:8088
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/44.0.2376.0 Safari/537.36
Host: webserver:8088
Accept: application/xml, text/xml, */*; q=0.01
X-client: CalDavZAP 0.12.1 (Inf-IT CalDAV Web Client)
Connection: keep-alive
Content-length: 723
Cookie: agendav_sessid=2f3062c5049a5ec4ab347756128627e4
X-requested-with: XMLHttpRequest
Authorization: Basic ...
Depth: 0
Referer: http://mail.icict.fiocruz.br:8088/caldavzap/index.html
?xml version=1.0 encoding=utf-8?A:expand-property
xmlns:A=DAV:A:property name=calendar-proxy-read-for
namespace=http://calendarserver.org/ns/;A:property
name=email-address-set
namespace=http://calendarserver.org/ns//A:property
name=displayname namespace=DAV:/A:property
name=calendar-user-address-set
namespace=urn:ietf:params:xml:ns:caldav//A:propertyA:property
name=calendar-proxy-write-for
namespace=http://calendarserver.org/ns/;A:property
name=email-address-set
namespace=http://calendarserver.org/ns//A:property
name=displayname namespace=DAV:/A:property
name=calendar-user-address-set
namespace=urn:ietf:params:xml:ns:caldav//A:property/A:expand-property
--
In config.js
var globalNetworkCheckSettings={href:
'http://webserver:8088/dav/principals/user/', hrefLabel: null,
additionalResources: [], forceReadOnly: null, settingsAccount: true,
timeOut: 9, lockTimeOut: 1, delegation: true,
backgroundCalendars: [], ignoreAlarms: false}
--
Another idea ?
On Wed, Apr 29, 2015 at 9:56 AM, Ken Murchison mu...@andrew.cmu.edu
mailto:mu...@andrew.cmu.edu wrote:
On 04/29/2015 08:41 AM, Lucas Zinato Carraro wrote:
How to set document root to dcyrus httpd?
Only put
httpdocroot: /var/lib/cyrus/htdocs ?
in imapd.conf or is necessary to configure another option ?
That's all you need.
On Wed, Apr 29, 2015 at 8:51 AM, Ken Murchison
mu...@andrew.cmu.edu mailto:mu...@andrew.cmu.edu wrote:
On 04/28/2015 11:27 PM, Lucas Zinato Carraro wrote:
caldavzap is in another server.
Why not just have Cyrus HTTP serve up CalDAVZAP? This will
avoid the cross-origin requests the JavasScript is
complaining about.
I debug more and find this log in JavaScript console.
XMLHttpRequest cannot load
http://mailserver.com:8088/dav/principals/user/. No
'Access-Control-Allow-Origin' header is present on the
requested resource. Origin 'http://webserver.com' is
therefore not allowed access.
---
Anyway to put this specific header in cyrus httpd ?
Try setting the httpallowcors option in imap.conf. This
should enable the cross-origin headers,
On Mon, Apr 27, 2015 at 8:25 AM, Ken Murchison
mu...@andrew.cmu.edu mailto:mu...@andrew.cmu.edu wrote:
On 04/17/2015 10:17 AM, Lucas Zinato Carraro wrote:
I'm testing Cyrus Caldav ( 2.4.17+beta9 ) with
several clients iCal, Lightning, AgendaDAV, Evolution .
Unfortunately, I could not configure with the
CalDavZAP 0.12.1
I follow the procedure to 2.5.0 (
http://cyrusimap.org/docs/cyrus-imapd/2.5.0/install-http.php)
---
In cyrus.conf
SERVICES {
..
http cmd=httpd listen=8088 prefork=0 maxchild=400
.
}
---
In caldav/config.js
var globalNetworkCheckSettings={href:
'http://myserver.com:8088/dav/principals/user/
http://mail.icict.fiocruz.br:8088/dav/principals/user/',
hrefLabel: null, additionalResources: [],
forceReadOnly: null, settingsAccount: true, timeOut:
9, lockTimeOut: 1, delegation: true,
backgroundCalendars: [], ignoreAlarms: false}
var globalSettingsType='calendar-home-set';
Any suggestion ?
Have you placed all of the CalDAVZap files in a location
within your Cyrus 'htdocs' directory?
Are they readable by the Cyrus user?
Do you have a trailing '/' in the URL when you
Re: Configure Cyrus 2.4.17+caldav~beta9 and CalDavZAP 0.12.1
On 04/17/2015 10:17 AM, Lucas Zinato Carraro wrote:
I'm testing Cyrus Caldav ( 2.4.17+beta9 ) with several clients
iCal, Lightning, AgendaDAV, Evolution .
Unfortunately, I could not configure with the CalDavZAP 0.12.1
I follow the procedure to 2.5.0 (
http://cyrusimap.org/docs/cyrus-imapd/2.5.0/install-http.php)
---
In cyrus.conf
SERVICES {
..
httpcmd=httpd listen=8088 prefork=0 maxchild=400
.
}
---
In caldav/config.js
var globalNetworkCheckSettings={href:
'http://myserver.com:8088/dav/principals/user/
http://mail.icict.fiocruz.br:8088/dav/principals/user/', hrefLabel:
null, additionalResources: [], forceReadOnly: null, settingsAccount:
true, timeOut: 9, lockTimeOut: 1, delegation: true,
backgroundCalendars: [], ignoreAlarms: false}
var globalSettingsType='calendar-home-set';
Any suggestion ?
Have you placed all of the CalDAVZap files in a location within your
Cyrus 'htdocs' directory?
Are they readable by the Cyrus user?
Do you have a trailing '/' in the URL when you try to access CalDAVZap
(e.g. http://myserver.com:8088/caldavzap/) ?
Are you seeing any kind of errors in syslog?
Have you enabled any kind of logging in your browser?
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
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: deleting emails directly
On 03/04/2015 05:04 AM, hw wrote: Hi, can I remove or delete emails from the imap directory directly (with rm) without screwing things up? I'm running a virus scan over the spool directory and wonder how to get those messages removed within which a virus has been found. The easiest way would be to let the virus scanner do this, and the virus scanner doesn't use IMAP. Take a look at cyr_virusscan in Cyrus. It currently only supports ClamAV, but it should be easy to add other scanners if needed. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: LAS shoutout for FastMail
On 01/11/2015 06:52 PM, Adam Tauno Williams wrote: On Mon, 2015-01-12 at 10:28 +1100, Robert Norris wrote: Thanks for the heads up! Its pretty exciting to see all the interest in JMAP :) Is there / will there be JMAP support in/for Cyrus IMAPd? I already have a stub for http_jmap.c in the cyrus-caldav-2.4 branch which will most likely be migrated over to the master branch after 2.5 is released. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: CalDAV?
Hi Patrick, On 12/16/2014 03:49 PM, Patrick Goetz wrote: On 12/16/2014 12:16 PM, Ken Murchison wrote: Are you talking about public calendars, sharing a private calendar with a colleague, or both? Our 2 primary use cases are this: 1. We have lots of people with busy schedules who have their administrative assistant schedule and manage appointments for them. In this case we need to be able to have 2-3 people view/edit the same calendar, which happens to be the primary private calendar for one of these people. This actually sounds like delegation, but Cyrus CalDAV doesn't currently support this or sharing. As I said earlier, Fastmail has a patch to non-standard calendar sharing in the same way that IMAP mailboxes are shared. This might give you what you need. 2. There are various groups of users that have to identify compatible meeting times. Usually the way this goes down is that the biggest wig (which also is typically the one with the busiest schedule) has his/her assistant send out 3-5 potential meeting times and then everyone This is actually what consensus scheduling is, and is supported by Cyrus CalDAV with the VPOLL iCalendar component (spec is still in draft state). We have done interoperability testing with the JS demo client from Apple http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/contrib/webpoll/ which can be served up to users via Cyrus httpd. responds with which of those times they can make. This is a bit clunky and laborious, it would be nice if the assistant could just have compatible meeting times identified automatically based on what everyone has on their calendar. Even without doing consensus scheduling, any decent CalDAV client (Apple, Lightning) will do free/busy lookups on other user's calendars when trying to schedule a meeting and the organizer will be able to see if/when the others are free. The third less common, but still critical shared calendar use is a public or semi-public calendar which shows what times a conference room or piece of expensive lab equipment has been reserved for use. Typically wannabe users then email a particular administrator responsible for keeping this calendar up to date in order to schedule their own meeting or use of the equipment. I haven't done any work on public calendars yet, but the ultimate goal would be to have shared calendars for meeting rooms, projectors, white boards, etc, which could all be scheduled in the same way as users. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: CalDAV?
Hi Patrick, On 12/16/2014 12:38 PM, Patrick Goetz wrote: On 12/15/2014 04:24 PM, Nic Bernstein wrote: Patrick, You'll find a link to the latest Beta release with CalDav/CardDav support on the Cyrus IMAP website: http://cyrusimap.org/ Thanks for that information. I've had to educate myself on how CalDav works, but this looks fairly promising. How can I find out more about what kinds of calendar functionality is supported (e.g. shared calendars, email-based appointment scheduling, simultaneous access to multiple calendars, etc.)? The current list of supported DAV functionality is returned in the DAV header in OPTIONS responses: DAV: 1, 2, 3, access-control, extended-mkcol DAV: calendar-access, calendar-availability, calendar-auto-schedule DAV: calendar-managed-attachments, calendar-managed-attachments-no-recurrence DAV: addressbook calendar-sharing isn't supported yet, at least not per the specs that are being worked on in CalConnect and eventually the IETF. The Fastmail folks have added some code to share calendars strictly based on ACLs, but this is different from the invite/accept method that is being worked on in the specs. Are you talking about public calendars, sharing a private calendar with a colleague, or both? Email-based appointment scheduling is only used if you try to schedule with someone NOT on the Cyrus server. The Cyrus server will send out invites/replies via email for remote users. Any local attendees will have the appointment automatically added to their calendar per the calendar-auto-schedule spec. If you receive an email appointment, and have a calendar-aware email client, then the client will have to add the appointment to your calendar. Eventually, I would like to add iMIP gateway functionality to lmtpd which would auto-handle replies (I think auto-handling initial requests is just asking for problems). This works for well me when I receive Exchange emails from colleagues. Thunderbird/Lightning or Apple Mail.app will correctly put events on my calendar. The CalDAV scheduling support probably still has some holes it in, but as the only person that I'm aware of that's using it, its working fine. As far as the rest of the CalDAV support, its pretty mature. Fastmail has had it rolled out to their user base for the better part of 2014. The documentation on all of the DAV stuff is still pretty bare, so feel free to ask questions and/or supply additional documentation. Let me and/or the list know if you have any other questions. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: CalDAV?
On 12/16/2014 01:30 PM, Andy Bennett wrote: Hi, Email-based appointment scheduling is only used if you try to schedule with someone NOT on the Cyrus server. The Cyrus server will send out invites/replies via email for remote users. Any local attendees will have the appointment automatically added to their calendar per the calendar-auto-schedule spec. If you receive an email appointment, and have a calendar-aware email client, then the client will have to add the appointment to your calendar. Eventually, I would like to add iMIP gateway functionality to lmtpd which would auto-handle replies (I think auto-handling initial requests is just asking for problems). Interesting. How do you deal robustly with that asymmetry? In all other respects, when Cyrus generates an output, such as a response in a sieve rule, or quota bounce or whatever, it goes via the MTA and is therefore subject to all the regular routing rules for mail. In this instance, there seems to be a special data path for calendaring which could yield some strange symptoms in setups that aren't extremely basic. Sorry, I wasn't clear on this point. Cyrus CalDAV sends out remote invites/replies in the same way that Sieve does its work. Its done via the MTA by piping the email to the local sendmail binary. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: CalDAV?
On 12/16/2014 08:03 PM, Andy Bennett wrote: Hi, Sorry, I wasn't clear on this point. Cyrus CalDAV sends out remote invites/replies in the same way that Sieve does its work. Its done via the MTA by piping the email to the local sendmail binary. Thanks for the clarification but I'm still not clear on what happens for users / mailboxes that the Cyrus server thinks have their INBOX hosted on the same server but might have routing rules in the MTA, sieve rules or elsewhere? Surely iMIP and iTIP should be entirely transparent transports and therefore entirely interchangeable with a native / short circuit transport? If the user's calendars are on the same server, then the iTIP is handled internally per RFC6638. The MTA never comes into play for user's hosted on the Cyrus server. Technically, for users outside the Cyrus server, we first try to use iSchedule (iTIP over HTTP with DKIM) and then fallback to iMIP (iTIP over SMTP). No currently deployed Calendaring services support iSchedule but I have done interop testing with Apple Calendar Server, Bedework, and Oracle during CalConnect events. Cyrus uses iSchedule (w/o DKIM) between servers in a Murder. The draft for iSchedule will eventually (we hope) be accepted by the IETF CalExt WG and progress as a proposed standard. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Internationalization of sieve reject message
Hi Fabio, Currently there is no way to change the text without recompiling. In the future, I'd like to use ICU4C to internationalize auto responses and error messages. On 8/1/14, 8:10 PM, Fabio S. Schmidt wrote: Hi ! I noticed that that when a message is rejected automatically by Sieve, the Subject and the text as well are fixed in english in the code (lmtp_sieve.c). I do known that the user is able to inform the reason for the reject, but with the Subject and the initial text in english it may cause confusion, on my environment for instance, most users do not understand english at all and actually delete or mark those messages as Spams. Is there any plan to change this behaviour on future versions? I mean, a way to change the Subject and the initial text of the automatically reject messages without recompiling Cyrus? -- My best regards, Fabio Soares Schmidt Linux Professional Institute - LPIC-3 Microsoft Certified Technology Specialist: Active Directory 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta10 released
We are pleased to announce the tenth beta release of Cyrus IMAP with integrated calendaring and contacts. This release contains mostly small CalDAV fixes/enhancements, but does include the following noteworthy changes: - DAV DB changes now occur in the mailbox API which means that replication works for calendars and addressbooks. - IMAP XFER is now based on replication. - Added support for free/busy query URL to CalDAV. - Authentication for GET/HEAD requests is now done on-demand so that free/busy queries and/or calendar subscriptions can be done anonymously (subject to ACL). - Added support for VAVAILABILITY, VPOLL, RSCALE to CalDAV based on current drafts (requires libical from git). - Updated http_timezone.c to be compliant with current draft. Many thanks go out to Fastmail for contributing the DAV DB changes and other fixes back to CyrusIMAP.org. The CalDAV code in this release forms the core of what Fastmail is now running in production. This code is based on the stable Cyrus 2.4.17 release with support for HTTP-based services (CalDAV, CardDAV, RSS, and Timezone) added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support is in late beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta10.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta10.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Upgrade documentation will be found in doc/install-upgrade.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: carddav with DIGEST-MD5
I would probably have to see the protocol exchange to in order to understand what is happening. On 07/23/2014 06:59 PM, Johan Hattne wrote: Thanks Ken, I’ll keep that in mind. In this particular case (and with your earlier patch applied) it appears that http_auth() in cyrus-imap’s httpd.c returns SASL_CONTINUE. The comment around line 3272 says “Need another step to complete authentication”, but the caller (response_header(), line ~2270) appears not to invoke that other step. I tested this by calling http_auth() again if it returns SASL_CONTINUE, and that authenticated me. // Johan On Jul 23, 2014, at 13:30, Ken Murchison mu...@andrew.cmu.edu wrote: I had issues with the Apple clients and Digest. Unless you really need Digest, I'd recommend using TLS + Basic. On 07/23/2014 01:27 PM, Johan Hattne wrote: Hi Ken; That fixes the crash but results in a “401 Unauthorized”. I’ll look into that a bit more at the next opportunity. This is using Contacts (8.0 1371) on an up-to-date OS X 10.9.4. It also works on the iPhone (iOS 7.1.2). // Johan On Jul 23, 2014, at 10:55, Ken Murchison mu...@andrew.cmu.edu wrote: Hi Johan, I believe this issue is fixed by the following commit: http://git.cyrusimap.org/cyrus-sasl/commit/?id=76ce885a44e7cb511ba54ceae46349036abb9cc8 BTW, which CardDAV client is using Digest? On 07/22/2014 01:48 PM, Johan Hattne wrote: While PLAIN authentication works fine, I had the https daemon crash during DIGEST-MD5 authentication. The crash turned out to be a divide error in libdigestmd5 from cyrus-sasl. In particular (in cyrus-sasl’s plugins/digestmd5.c): /* Create an initial cache entry for non-persistent HTTP connections */ unsigned val = hash((char *) nonce) % text-reauth-size; would fail due to text-reauth-size being zero. If I’m reading this correctly, this appears to be the effect of initializing the plugin (as done in digestmd5_server_plug_init(), defined in same file as the snippet above) with an undefined reauth_timeout. And indeed, adding sasl_reauth_timeout: 10” to /etc/imapd.conf makes the crash go away. I didn’t expect a configuration without reauth_timeout to crash imapd, but I haven’t done enough research to be sure, nor to tell where the problem lies should this be a real issue. Any further insight is greatly appreciated! // Cheers; Johan 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: carddav with DIGEST-MD5
Actually, let me do some testing of my own with Apple Contacts and see if I can replicate the problem. On 07/24/2014 10:57 AM, Johan Hattne wrote: What format would you like that in (and how do I produce that)? On Jul 24, 2014, at 10:48, Ken Murchison mu...@andrew.cmu.edu wrote: I would probably have to see the protocol exchange to in order to understand what is happening. On 07/23/2014 06:59 PM, Johan Hattne wrote: Thanks Ken, I’ll keep that in mind. In this particular case (and with your earlier patch applied) it appears that http_auth() in cyrus-imap’s httpd.c returns SASL_CONTINUE. The comment around line 3272 says “Need another step to complete authentication”, but the caller (response_header(), line ~2270) appears not to invoke that other step. I tested this by calling http_auth() again if it returns SASL_CONTINUE, and that authenticated me. // Johan On Jul 23, 2014, at 13:30, Ken Murchison mu...@andrew.cmu.edu wrote: I had issues with the Apple clients and Digest. Unless you really need Digest, I'd recommend using TLS + Basic. On 07/23/2014 01:27 PM, Johan Hattne wrote: Hi Ken; That fixes the crash but results in a “401 Unauthorized”. I’ll look into that a bit more at the next opportunity. This is using Contacts (8.0 1371) on an up-to-date OS X 10.9.4. It also works on the iPhone (iOS 7.1.2). // Johan On Jul 23, 2014, at 10:55, Ken Murchison mu...@andrew.cmu.edu wrote: Hi Johan, I believe this issue is fixed by the following commit: http://git.cyrusimap.org/cyrus-sasl/commit/?id=76ce885a44e7cb511ba54ceae46349036abb9cc8 BTW, which CardDAV client is using Digest? On 07/22/2014 01:48 PM, Johan Hattne wrote: While PLAIN authentication works fine, I had the https daemon crash during DIGEST-MD5 authentication. The crash turned out to be a divide error in libdigestmd5 from cyrus-sasl. In particular (in cyrus-sasl’s plugins/digestmd5.c): /* Create an initial cache entry for non-persistent HTTP connections */ unsigned val = hash((char *) nonce) % text-reauth-size; would fail due to text-reauth-size being zero. If I’m reading this correctly, this appears to be the effect of initializing the plugin (as done in digestmd5_server_plug_init(), defined in same file as the snippet above) with an undefined reauth_timeout. And indeed, adding sasl_reauth_timeout: 10” to /etc/imapd.conf makes the crash go away. I didn’t expect a configuration without reauth_timeout to crash imapd, but I haven’t done enough research to be sure, nor to tell where the problem lies should this be a real issue. Any further insight is greatly appreciated! // Cheers; Johan 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: carddav with DIGEST-MD5
Hi Johan, I believe this issue is fixed by the following commit: http://git.cyrusimap.org/cyrus-sasl/commit/?id=76ce885a44e7cb511ba54ceae46349036abb9cc8 BTW, which CardDAV client is using Digest? On 07/22/2014 01:48 PM, Johan Hattne wrote: While PLAIN authentication works fine, I had the https daemon crash during DIGEST-MD5 authentication. The crash turned out to be a divide error in libdigestmd5 from cyrus-sasl. In particular (in cyrus-sasl’s plugins/digestmd5.c): /* Create an initial cache entry for non-persistent HTTP connections */ unsigned val = hash((char *) nonce) % text-reauth-size; would fail due to text-reauth-size being zero. If I’m reading this correctly, this appears to be the effect of initializing the plugin (as done in digestmd5_server_plug_init(), defined in same file as the snippet above) with an undefined reauth_timeout. And indeed, adding sasl_reauth_timeout: 10” to /etc/imapd.conf makes the crash go away. I didn’t expect a configuration without reauth_timeout to crash imapd, but I haven’t done enough research to be sure, nor to tell where the problem lies should this be a real issue. Any further insight is greatly appreciated! // Cheers; Johan 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: carddav with DIGEST-MD5
I had issues with the Apple clients and Digest. Unless you really need Digest, I'd recommend using TLS + Basic. On 07/23/2014 01:27 PM, Johan Hattne wrote: Hi Ken; That fixes the crash but results in a “401 Unauthorized”. I’ll look into that a bit more at the next opportunity. This is using Contacts (8.0 1371) on an up-to-date OS X 10.9.4. It also works on the iPhone (iOS 7.1.2). // Johan On Jul 23, 2014, at 10:55, Ken Murchison mu...@andrew.cmu.edu wrote: Hi Johan, I believe this issue is fixed by the following commit: http://git.cyrusimap.org/cyrus-sasl/commit/?id=76ce885a44e7cb511ba54ceae46349036abb9cc8 BTW, which CardDAV client is using Digest? On 07/22/2014 01:48 PM, Johan Hattne wrote: While PLAIN authentication works fine, I had the https daemon crash during DIGEST-MD5 authentication. The crash turned out to be a divide error in libdigestmd5 from cyrus-sasl. In particular (in cyrus-sasl’s plugins/digestmd5.c): /* Create an initial cache entry for non-persistent HTTP connections */ unsigned val = hash((char *) nonce) % text-reauth-size; would fail due to text-reauth-size being zero. If I’m reading this correctly, this appears to be the effect of initializing the plugin (as done in digestmd5_server_plug_init(), defined in same file as the snippet above) with an undefined reauth_timeout. And indeed, adding sasl_reauth_timeout: 10” to /etc/imapd.conf makes the crash go away. I didn’t expect a configuration without reauth_timeout to crash imapd, but I haven’t done enough research to be sure, nor to tell where the problem lies should this be a real issue. Any further insight is greatly appreciated! // Cheers; Johan 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: mboxlist_createmailbox_full() in http_carddav.c
Hi Johan, Good catch. This a result of me always testing in a Murder environment for use at CMU. I just committed this fix: http://git.cyrusimap.org/cyrus-imapd/commit/?h=caldav-2.4id=72dd0606feac1abf798a94448434a2d9013e490a On 07/18/2014 02:34 PM, Johan Hattne wrote: Dear all; I’m trying to understand what’s happening in the my_carddav_auth() function in http_carddav.c, in particular the part that creates carddav mailboxes. If I understand correctly, on the user’s first successful authentication, mboxlist_lookup() will return r = IMAP_MAILBOX_NONEXISTENT, and program goes into the if-clause (line ~362 in the beta9-code I’m looking at). Unless there’s an mupdate-server, the subsequent call to mboxlist_createmailbox_full() will not happen because !r is false, and no mailboxes would be created. I suppose this isn’t what was intended—clues? // Johan 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: user_deny.db and lmtpd
On 07/04/2014 11:05 AM, Deniss wrote: Hello, is it possible to force lmtp to bounce messages with temporary reject code like 421 for certain user(s) ? Looks like lmtp does not respect user_deny.db file. You could try setting their quota to something small, e.g. 1 (one) But mailbox may be flagged with MBTYPE_MOVING which is considered by lmtpd. Is there any tool to manually set / clear MBTYPE_MOVING flag on a given mailbox ? Best, Deniss 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Cyrus Caldav Murder integration
On 06/05/2014 05:33 AM, Jean-Christophe Delaye wrote: Hi, After successfully tested Cyrus IMAPD v2.4.17-caldav on a stand-alone Cyrus IMAP server, I wonder how to integrate CalDAV features in our running Imap systems. We're currently using 2 murder hosts and 4 backend servers, running in a cluster (Solaris) environment. Users mailboxes are distributed on 4 backends and I plan to offer caldendars to those users. I understand that the CalDAV module will automatically create the required calendars for a user the first time that the user authenticates to the CalDAV server; but what's happen if mailboxes are located on different backends ? - Do I have to configure CalDAV server only on the murder agreggator hosts ? - Is there (or in the future) such a proxy mode for http services (or referrals like sieve) ? - Or shall I consider using a separate Cyrus Caldav server acting as stand-alone calendar server with LOCAL mailboxes containing ONLY CAL information? The setup for CalDAV Murder is the same as for IMAP. Run httpd processes on both the frontend and backend servers. httpd will proxy the requests to the proper backend. CMU is currently doing this for RSS access to shared mailboxes on our production Murder and I have been using CalDAV on our test Murder for well over a year. That being said, I can't guarantee that CalDAV auto-scheduling will work between users on different backends. Best-case, the backend server will send an email, worst-case it will fail to store the scheduling object. I haven't done a lot of scheduling testing in a Murder environment yet. I might have to rework the scheduling code so that the frontend machine directs the traffic to various backends. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: PROPFIND Method Not Allowed caldav-beta9
On 06/04/2014 04:03 AM, Jean-Christophe Delaye wrote: On 03/06/2014 20:20, Ken Murchison wrote: Can you telnet to port 80 on the server and give it the following command (followed by 2 carriage returns): OPTIONS * HTTP/1.0 Thanks Ken, Connected to cyrus0.eurecom.fr. Escape character is '^]'. OPTIONS * HTTP/1.0 HTTP/1.1 200 OK Connection: close Date: Wed, 04 Jun 2014 08:00:23 GMT Cache-Control: no-cache Server: Cyrus/v2.4.17-caldav-beta9 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.0 zlib/1.2.3 libxml2/2.6.23 Allow: OPTIONS, GET, HEAD Content-Length: 0 OK. It looks like configure didn't find some of the necessary prerequisites for CalDAV support when you compiled Cyrus. You need to have both SQLite and libical. When support for CalDAV is compiled in and enabled, your OPTIONS response should look something like this: HTTP/1.1 200 OK Connection: close Date: Wed, 04 Jun 2014 11:02:57 GMT Cache-Control: no-cache Server: Cyrus/git2.4.17-caldav-beta9+163 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.1e zlib/1.2.7 libxml/2.9.1 SQLite/3.7.13 libical/0.48 DAV: 1, 2, 3, access-control, extended-mkcol DAV: calendar-access, calendar-auto-schedule Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE Allow: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK, PROPPATCH, MKCOL, ACL Allow: MKCALENDAR Content-Length: 0 On 06/03/2014 11:30 AM, Jean-Christophe Delaye wrote: We're trying to use calendars with Cyrus IMAPD v2.4.17-caldav-beta9. The following caldav settings are in imapd.conf httpmodules: caldav httpprettytelemetry: 1 calendarprefix: #calendars http/https process are listening. master[27932]: [ID local2.debug] listening for messages from http master[27932]: [ID local2.debug] listening for messages from https When trying to use calendars features with Thunderbird/24.5.0 Lightning/2.6.5, Create a new calendar (network) Format CalDAV Location http://cyrus0.eurecom.fr/dav/calendars/users/foo/Default/ I have errors in log: http[1360]: [ID 213405 local2.debug] read parse request-line http[1360]: [ID 472354 local2.debug] read parse headers http[1360]: [ID 702911 local2.info] x.eurecom.fr with Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Lightning/2.6.5; PROPFIND /dav/calendars/users/foo/Default/ HTTP/1.1 (depth=0) = 405 Method Not Allowed (error=The requested method is not allowed for the URL.) http[1360]: [ID 286617 local2.debug] read_body(0x8) does anyone have any ideas what could be causing this ? Thanks in advance. 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: PROPFIND Method Not Allowed caldav-beta9
On 06/04/2014 11:59 AM, Jean-Christophe Delaye wrote: On 04/06/2014 13:08, Ken Murchison wrote: On 06/04/2014 04:03 AM, Jean-Christophe Delaye wrote: On 03/06/2014 20:20, Ken Murchison wrote: Can you telnet to port 80 on the server and give it the following command (followed by 2 carriage returns): OPTIONS * HTTP/1.0 Thanks Ken, Connected to cyrus0.eurecom.fr. Escape character is '^]'. OPTIONS * HTTP/1.0 HTTP/1.1 200 OK Connection: close Date: Wed, 04 Jun 2014 08:00:23 GMT Cache-Control: no-cache Server: Cyrus/v2.4.17-caldav-beta9 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.0 zlib/1.2.3 libxml2/2.6.23 Allow: OPTIONS, GET, HEAD Content-Length: 0 OK. It looks like configure didn't find some of the necessary prerequisites for CalDAV support when you compiled Cyrus. You need to have both SQLite and libical. When support for CalDAV is compiled in and enabled, your OPTIONS response should look something like this: HTTP/1.1 200 OK Connection: close Date: Wed, 04 Jun 2014 11:02:57 GMT Cache-Control: no-cache Server: Cyrus/git2.4.17-caldav-beta9+163 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.1e zlib/1.2.7 libxml/2.9.1 SQLite/3.7.13 libical/0.48 DAV: 1, 2, 3, access-control, extended-mkcol DAV: calendar-access, calendar-auto-schedule Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE Allow: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK, PROPPATCH, MKCOL, ACL Allow: MKCALENDAR Content-Length: 0 Ok that's it. It was a configure issue using ICAL_LIBS the linker flags for ICAL which had overriding pkg-config. Now, I have the following http response: HTTP/1.1 200 OK Connection: close Date: Wed, 04 Jun 2014 14:57:38 GMT Cache-Control: no-cache Server: Cyrus/v2.4.17-caldav-beta9 (Murder) Cyrus-SASL/2.1.26 OpenSSL/1.0.0 zlib /1.2.3 libxml2/2.6.23 SQLite/3.8.4.3 libical/1.0 iSchedule-Version: 1.0 DAV: 1, 2, 3, access-control, extended-mkcol DAV: calendar-access, calendar-auto-schedule Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE Allow: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK, PROPPATCH, MKCOL, ACL Allow: MKCALENDAR Content-Length: 0 I confirm that module automatically create the required calendars for a user at the first login. cyrus0.eurecom.fr lm user.standard.%.% user.standard.#addressbooks.Default (\HasNoChildren) user.standard.#calendars.Default (\HasNoChildren) user.standard.#calendars.Inbox (\HasNoChildren) user.standard.#calendars.Outbox (\HasNoChildren) user.standard.Junk.Spam_Client (\HasNoChildren) user.standard.Junk.Spam_Server (\HasNoChildren) cyrus0.eurecom.fr lam user.standard.#calendars.Default standard lrswipkxtecda9 anyone 9 But, I have to deal with 404 Not Found. [ID 596527 local2.notice] login: standard Basic+TLS User logged in [ID 693975 local2.debug] dav_exec(standard.dav): CREATE TABLE IF NOT EXISTS ical_objs ( rowid INTEGER PRIMARY KEY, creationdate INTEGER, mailbox TEXT NOT NULL, resource TEXT NOT NULL, imap_uid INTEGER, lock_token TEXT, lock_owner TEXT, lock_ownerid TEXT, lock_expire INTEGER, comp_type INTEGER, ical_uid TEXT, organizer TEXT, dtstart TEXT, dtend TEXT, recurring INTEGER, transp INTEGER, sched_tag TEXT, UNIQUE( mailbox, resource ) ); [ID 693975 local2.debug] dav_exec(standard.dav): CREATE INDEX IF NOT EXISTS idx_ical_uid ON ical_objs ( ical_uid ); [ID 693975 local2.debug] dav_exec(standard.dav): CREATE TABLE IF NOT EXISTS vcard_objs ( rowid INTEGER PRIMARY KEY, creationdate INTEGER, mailbox TEXT NOT NULL, resource TEXT NOT NULL, imap_uid INTEGER, lock_token TEXT, lock_owner TEXT, lock_ownerid TEXT, lock_expire INTEGER, version INTEGER, vcard_uid TEXT, kind INTEGER, fullname TEXT, name TEXT, nickname TEXT, email TEXT, UNIQUE( mailbox, resource ) ); [ID 693975 local2.debug] dav_exec(standard.dav): CREATE INDEX IF NOT EXISTS idx_vcard_uid ON vcard_objs ( vcard_uid ); [ID 702911 local2.info] as standard with Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Lightning/2.6.5; PROPFIND /dav/calendars/users/standard/Default/ HTTP/1.1 (depth=0) = 404 Not Found (error=The requested URL was not found on this server.) /dav/calendars/users/standard/Default/ should be: /dav/calendars/user/standard/Default/ -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: PROPFIND Method Not Allowed caldav-beta9
Can you telnet to port 80 on the server and give it the following command (followed by 2 carriage returns): OPTIONS * HTTP/1.0 On 06/03/2014 11:30 AM, Jean-Christophe Delaye wrote: We're trying to use calendars with Cyrus IMAPD v2.4.17-caldav-beta9. The following caldav settings are in imapd.conf httpmodules: caldav httpprettytelemetry: 1 calendarprefix: #calendars http/https process are listening. master[27932]: [ID local2.debug] listening for messages from http master[27932]: [ID local2.debug] listening for messages from https When trying to use calendars features with Thunderbird/24.5.0 Lightning/2.6.5, Create a new calendar (network) Format CalDAV Location http://cyrus0.eurecom.fr/dav/calendars/users/foo/Default/ I have errors in log: http[1360]: [ID 213405 local2.debug] read parse request-line http[1360]: [ID 472354 local2.debug] read parse headers http[1360]: [ID 702911 local2.info] x.eurecom.fr with Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Lightning/2.6.5; PROPFIND /dav/calendars/users/foo/Default/ HTTP/1.1 (depth=0) = 405 Method Not Allowed (error=The requested method is not allowed for the URL.) http[1360]: [ID 286617 local2.debug] read_body(0x8) does anyone have any ideas what could be causing this ? Thanks in advance. 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: calendar provisioning: need to create #calendars for a user
On 05/08/2014 11:37 AM, Paul Dekkers wrote: Hi, Reading doc/install-http.html, Calendar provisioning The CalDAV module will automatically create the required calendars for a user the first time that the user authenticates to the CalDAV server. Note that the user MUST have an existing IMAP Inbox in order for the calendars to be created. ... I'm a bit confused: it seems I need to create INBOX.#calendars myself, but INBOX.#calendars.Default, .Outbox and .Inbox are indeed created automatically. Is that correct? Another way to interpret this was that whenever a user wants to access its Calendar and the INBOX is created but INBOX.#calendars isn't, this is also created. For me, on Ubuntu 14.04 with the cyrus package including the beta stuff (I like it :-)) that didn't work. Hi Paul, As long as user.foo exists (IMAP Inbox), the user.foo.#calendars* tree will be automatically created the first time that user 'foo' authenticates to httpd. If this doesn't work, I'd like to know about it and see any telemetry and/or syslog output. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: xfer problems between 2.3.15 and 2.4.17
Hi Gavin, Have you tried running reconstruct with the -G and/or -R options to see if they fix the corruption without having to remove cyrus.index? Another option is to place a copy of the user's user.seen file from the 2.3 machine on the 2.4 machine prior to removing cyrus.index and reconstructing. I *think* the server will then upgrade the seen state from user.seen to cyrus.index. On 05/15/2014 11:53 AM, gavin.g...@ed.ac.uk wrote: Any help with this would be much appreciated. We keep coming across folders that once they have been migrated seem to have corrupt cyrus.index files. The only way to fix them is to remove the files and do a reconstruct. This is not a workable solution from our users point of view as is sets all the messages back to flaggged as new etc. We have tried various tests, but we can't discover the cause of the corruption of the cyrus.index files. regards, Gavin Gray On Wed, 7 May 2014, gavin.g...@ed.ac.uk wrote: I have been testing xfer of accounts within a cyrus murder from 2.3.15 backends to new 2.4.17. backends. all the email and folders seem to migrate perfectly and the xfer'd accounts can send and receive email. However when reading email with an IMAP client I am having strange issues setting flags within folders on messages. In particular setting and unsetting deletion flags is very erratic. In some folders it doesn't work at all, on others I can set the deletion flag but can't unset it. All of the backends have delayed expunge switched on. debug output from the alpine IMAP client seems to suggest the server is doing what it's told: IMAP DEBUG 12:04:30 5/7: 0169 STORE 93 +Flags (\DELETED) IMAP DEBUG 12:04:30 5/7: 0169 OK Completed IMAP DEBUG 12:04:31 5/7: 016a STORE 94 +Flags (\DELETED) IMAP DEBUG 12:04:31 5/7: 016a OK Completed but then something seems to immediately remove the flag, because on issuing an expunge the client finds nothing to expunge. nothing of note seems to be logged on the backend, even logging in debug mode. the other baffling thing is that in some folders within the same users account, this whole process works perfectly. does anyone have any ideas what could be causing this and if there might be a solution? many thanks, Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 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 Gavin Gray Edinburgh University Information Services Rm 2013 JCMB Kings Buildings Edinburgh EH9 3JZ UK tel +44 (0)131 650 5987 email gavin.g...@ed.ac.uk -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
Heartbleed warning - Cyrus admin password leak!
All, I'm sure you have all heard about the Heartbleed http://heartbleed.com/ bug by now. If not, you definitely need to read up on it and take appropriate action. A Cyrus admin (not at CMU) has recently run the check-ssl-heartbleed https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl script against his server which was using one of the effected versions of OpenSSL and was easily able to capture usernames and passwords, including the admin password. Again, please check the versions of OpenSSL on your servers and patch or upgrade them ASAP. Regards, Ken -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: sieve VARIABLES extension -- when?
As far as I know, nobody has done any work on it. On 01/16/2014 12:25 PM, IMAP List Administration wrote: Hello, what is the progress, if any, implementing the VARIABLES extension to sieve? Google only turns this up: Ken Murchison | 2 Aug 15:49 2007 Re: Sieve variables draft support? Dale Ghent wrote: Hey all. Just curious, are there any plans re: implementing the variables extension to Cyrus's implementation of Sieve? Yes, but I can't give you a firm time frame. cheers, Rob 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: popularity of NNTP (Re: nntp not working after upgrade)
On 01/06/2014 01:01 PM, Mikhail T. wrote: On 06.01.2014 8:03, Bron Gondwana wrote: I think the problem is that just about nobody is running nntp I for one would /love/ to make some of the mailboxes, where I archive some private mailing lists, available to people via NNTP (read-only) -- one list per news-group. In my opinion, it is a method much superior to the perversely popular HTML archivers (like mhonarc or the mailman's component), for example. Unfortunately, every time I ventured to configure such a set up, I could not do it in reasonable time and was forced to abandon the effort. Whereas there are plenty of howtos and manuals for setting up an IMAP-server with Cyrus, the NNTP is either undocumented, or the documentation is so old, it refers to obsoleted versions of the software. If someone using NNTP were to document it, maybe, the user-base would start growing? so it didn't get much testing. Maybe, if Cyrus developers ate their own dogfood -- keeping the archives of this mailing list available via NNTP, for example?.. We actually are using the Cyrus NNTP stuff at CMU, and other than the bug that I introduced when adding the 'newsgroups' option (since fixed), it works just fine. The instructions in doc/install-netnews.html should be sufficient to get you going. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta9 released
We are pleased to announce the ninth beta release of Cyrus IMAP with integrated calendaring and contacts. This is a bugfix release with the following changes: - Fixed bug in parsing of Accept header (now accepts */* and type/*) - Fixed telemetry logging bug (old garbage appearing in log) - Added a workaround for the DELETE bug in MacOS X 10.9.0 Calendar client The complete list of changes can be found in doc/changes.html in the distribution. This code is based on the stable Cyrus 2.4.17 release with support for HTTP-based services (CalDAV, CardDAV, RSS, and Timezone) added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta9.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta9.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Upgrade documentation will be found in doc/install-upgrade.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Cyrus IMAP / CalDAV
I confirmed that the DELETE problem is indeed a bug in the Apple client,
and that Apple is aware of it. I'm somewhat reluctant to to include a
fix in Cyrus for a bug in a client that will hopefully get fixed sooner
rather than later. The patch below will work around the problem by
making the faulty conditional DELETE a non-conditional one. But, by
doing so we may delete a resource that has been changed by another
user/client/session. Given that we really don't support shared
calendars at the moment, this probably isn't a big deal but I don't
really want to create potentially bigger problems moving forward.
The real fix is Apple correcting their client to use an If-Match header
rather than If-Schedule-Tag-Match header if the resource doesn't have a
Schedule-Tag and/or isn't a scheduling object.
On 12/14/2013 01:02 PM, Ken Murchison wrote:
I just committed a fix to git for the 406 response to GET. I will make
a beta9 release with this fix, and hopefully with a fix for the DELETE
issue by early next week.
I have an email into one of the CalDAV experts that I know at Apple to
see what CalendarServer does with the empty If-Schedule-Tag-Match
header. I think its a bug in the Apple client, but I will have to come
up with a sane workaround for it. In the meantime, this uncommitted
patch should fix your problem with DELETE:
diff --git a/imap/http_caldav.c b/imap/http_caldav.c
index c00223f..641feb8 100644
--- a/imap/http_caldav.c
+++ b/imap/http_caldav.c
@@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t
*txn, const void *data,
/* Per RFC 6638, check Schedule-Tag */
if ((hdr = spool_getheader(txn-req_hdrs, If-Schedule-Tag-Match))) {
+if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */
if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED;
}
On 12/14/2013 09:39 AM, Marty Lee wrote:
No worries.. I'm about to get back onto another train so will back out b8..
Only me using it in earnest, so if you need anything else tested before
pushing out, just send me a link.
Marty Lee
v: 07827 950 918
On 14 Dec 2013, at 14:26, Ken Murchison mu...@andrew.cmu.edu wrote:
Hi Marty,
Thanks for the info. The 406 is in response to the GET, caused by a bug I
introduced when I added support for jCal and xCal data. I can't believe
that this didn't present itself in my testing. I will need to fix this
immediately. You probably want to downgrade to beta7 in the meantime.
I *think* the problem with DELETE is that iCal is sending an empty
If-Schedule-Tag-Match header. I will need to test this here and possibly
talk to the Apple guys to find out why they are sending an empty header,
and what they expect the behavior to be.
On 12/14/2013 03:09 AM, Marty Lee wrote:
Ken,
I haven’t but have just taken the opportunity to update to Beta 8 and also
to refresh Sqlite, which
seems to be the source of the error message…
Using cyrus beta 7, the iCal client would delete the event, but when it
updated with the server, the
event would magically just re-appear. With b8, this has changed; now I get
a dialog box:
--
The request for “Marty” in account “Maui” failed.
The server responded with
“406” to operation CalDAVDeleteEntityQueueableOperation.
-
Telemetry log:
1387007669DELETE
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
If-schedule-tag-match:
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T02
TZNAME:GMT
TZOFFSETTO:+
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:1387007670GET
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ
Re: Cyrus IMAP / CalDAV
I have decided to commit my workaround patch to git, but it will only
work for requests from the Apple client in question. I will be making a
beta9 release shortly.
The Apple guys aren't at liberty to disclose if/when there will be a
release, but I would expect them to fix this soonish.
On 12/16/2013 04:19 PM, Marty Lee wrote:
Thanks for all the hard work to get the actual answer Ken; I’ll apply the
patch to my
local server for me to test (only 2 of us using the calendar stuff at the
moment) and
wait with baited breath for an apple update :-)
If you get wind of apple fixing things, let me know - if I spot it at this
end, I’ll send
something out too.
Cheers
marty
On 16 Dec 2013, at 19:09, Ken Murchison mu...@andrew.cmu.edu wrote:
I confirmed that the DELETE problem is indeed a bug in the Apple client, and
that Apple is aware of it. I'm somewhat reluctant to to include a fix in
Cyrus for a bug in a client that will hopefully get fixed sooner rather than
later. The patch below will work around the problem by making the faulty
conditional DELETE a non-conditional one. But, by doing so we may delete a
resource that has been changed by another user/client/session. Given that
we really don't support shared calendars at the moment, this probably isn't
a big deal but I don't really want to create potentially bigger problems
moving forward.
The real fix is Apple correcting their client to use an If-Match header
rather than If-Schedule-Tag-Match header if the resource doesn't have a
Schedule-Tag and/or isn't a scheduling object.
On 12/14/2013 01:02 PM, Ken Murchison wrote:
I just committed a fix to git for the 406 response to GET. I will make
a beta9 release with this fix, and hopefully with a fix for the DELETE
issue by early next week.
I have an email into one of the CalDAV experts that I know at Apple to
see what CalendarServer does with the empty If-Schedule-Tag-Match
header. I think its a bug in the Apple client, but I will have to come
up with a sane workaround for it. In the meantime, this uncommitted
patch should fix your problem with DELETE:
diff --git a/imap/http_caldav.c b/imap/http_caldav.c
index c00223f..641feb8 100644
--- a/imap/http_caldav.c
+++ b/imap/http_caldav.c
@@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t
*txn, const void *data,
/* Per RFC 6638, check Schedule-Tag */
if ((hdr = spool_getheader(txn-req_hdrs, If-Schedule-Tag-Match)))
{
+if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */
if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED;
}
On 12/14/2013 09:39 AM, Marty Lee wrote:
No worries.. I'm about to get back onto another train so will back out
b8.. Only me using it in earnest, so if you need anything else tested
before pushing out, just send me a link.
Marty Lee
v: 07827 950 918
On 14 Dec 2013, at 14:26, Ken Murchison mu...@andrew.cmu.edu wrote:
Hi Marty,
Thanks for the info. The 406 is in response to the GET, caused by a bug
I introduced when I added support for jCal and xCal data. I can't
believe that this didn't present itself in my testing. I will need to
fix this immediately. You probably want to downgrade to beta7 in the
meantime.
I *think* the problem with DELETE is that iCal is sending an empty
If-Schedule-Tag-Match header. I will need to test this here and possibly
talk to the Apple guys to find out why they are sending an empty header,
and what they expect the behavior to be.
On 12/14/2013 03:09 AM, Marty Lee wrote:
Ken,
I haven’t but have just taken the opportunity to update to Beta 8 and
also to refresh Sqlite, which
seems to be the source of the error message…
Using cyrus beta 7, the iCal client would delete the event, but when it
updated with the server, the
event would magically just re-appear. With b8, this has changed; now I
get a dialog box:
--
The request for “Marty” in account “Maui” failed.
The server responded with
“406” to operation CalDAVDeleteEntityQueueableOperation.
-
Telemetry log:
1387007669DELETE
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
If-schedule-tag-match:
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T02
TZNAME:GMT
TZOFFSETTO:+
Re: Cyrus IMAP / CalDAV
I can't make a formal announcement of beta9 until tomorrow when I get my
coworker to upload the distro to cyrusimap.org, but here it is if you
want to give it a try:
http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.4.17-caldav-beta9.tar.gz
http://www.contrib.andrew.cmu.edu/%7Emurch/cyrus-imapd-2.4.17-caldav-beta9.tar.gz
On 12/16/2013 04:19 PM, Marty Lee wrote:
Thanks for all the hard work to get the actual answer Ken; I’ll apply the
patch to my
local server for me to test (only 2 of us using the calendar stuff at the
moment) and
wait with baited breath for an apple update :-)
If you get wind of apple fixing things, let me know - if I spot it at this
end, I’ll send
something out too.
Cheers
marty
On 16 Dec 2013, at 19:09, Ken Murchison mu...@andrew.cmu.edu wrote:
I confirmed that the DELETE problem is indeed a bug in the Apple client, and
that Apple is aware of it. I'm somewhat reluctant to to include a fix in
Cyrus for a bug in a client that will hopefully get fixed sooner rather than
later. The patch below will work around the problem by making the faulty
conditional DELETE a non-conditional one. But, by doing so we may delete a
resource that has been changed by another user/client/session. Given that
we really don't support shared calendars at the moment, this probably isn't
a big deal but I don't really want to create potentially bigger problems
moving forward.
The real fix is Apple correcting their client to use an If-Match header
rather than If-Schedule-Tag-Match header if the resource doesn't have a
Schedule-Tag and/or isn't a scheduling object.
On 12/14/2013 01:02 PM, Ken Murchison wrote:
I just committed a fix to git for the 406 response to GET. I will make
a beta9 release with this fix, and hopefully with a fix for the DELETE
issue by early next week.
I have an email into one of the CalDAV experts that I know at Apple to
see what CalendarServer does with the empty If-Schedule-Tag-Match
header. I think its a bug in the Apple client, but I will have to come
up with a sane workaround for it. In the meantime, this uncommitted
patch should fix your problem with DELETE:
diff --git a/imap/http_caldav.c b/imap/http_caldav.c
index c00223f..641feb8 100644
--- a/imap/http_caldav.c
+++ b/imap/http_caldav.c
@@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t
*txn, const void *data,
/* Per RFC 6638, check Schedule-Tag */
if ((hdr = spool_getheader(txn-req_hdrs, If-Schedule-Tag-Match)))
{
+if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */
if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED;
}
On 12/14/2013 09:39 AM, Marty Lee wrote:
No worries.. I'm about to get back onto another train so will back out
b8.. Only me using it in earnest, so if you need anything else tested
before pushing out, just send me a link.
Marty Lee
v: 07827 950 918
On 14 Dec 2013, at 14:26, Ken Murchison mu...@andrew.cmu.edu wrote:
Hi Marty,
Thanks for the info. The 406 is in response to the GET, caused by a bug
I introduced when I added support for jCal and xCal data. I can't
believe that this didn't present itself in my testing. I will need to
fix this immediately. You probably want to downgrade to beta7 in the
meantime.
I *think* the problem with DELETE is that iCal is sending an empty
If-Schedule-Tag-Match header. I will need to test this here and possibly
talk to the Apple guys to find out why they are sending an empty header,
and what they expect the behavior to be.
On 12/14/2013 03:09 AM, Marty Lee wrote:
Ken,
I haven’t but have just taken the opportunity to update to Beta 8 and
also to refresh Sqlite, which
seems to be the source of the error message…
Using cyrus beta 7, the iCal client would delete the event, but when it
updated with the server, the
event would magically just re-appear. With b8, this has changed; now I
get a dialog box:
--
The request for “Marty” in account “Maui” failed.
The server responded with
“406” to operation CalDAVDeleteEntityQueueableOperation.
-
Telemetry log:
1387007669DELETE
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
If-schedule-tag-match:
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T02
Re: Cyrus IMAP / CalDAV
Hi Marty, Thanks for the info. The 406 is in response to the GET, caused by a bug I introduced when I added support for jCal and xCal data. I can't believe that this didn't present itself in my testing. I will need to fix this immediately. You probably want to downgrade to beta7 in the meantime. I *think* the problem with DELETE is that iCal is sending an empty If-Schedule-Tag-Match header. I will need to test this here and possibly talk to the Apple guys to find out why they are sending an empty header, and what they expect the behavior to be. On 12/14/2013 03:09 AM, Marty Lee wrote: Ken, I haven’t but have just taken the opportunity to update to Beta 8 and also to refresh Sqlite, which seems to be the source of the error message… Using cyrus beta 7, the iCal client would delete the event, but when it updated with the server, the event would magically just re-appear. With b8, this has changed; now I get a dialog box: -- The request for “Marty” in account “Maui” failed. The server responded with “406” to operation CalDAVDeleteEntityQueueableOperation. - Telemetry log: 1387007669DELETE /dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics HTTP/1.1 Accept-encoding: gzip, deflate Max-forwards: 10 Accept-language: en-gb User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174 Host: 192.168.253.16:1443 Accept: */* Content-length: 0 X-forwarded-server: dav.maui.co.uk If-schedule-tag-match: X-forwarded-for: 176.12.107.140 Authorization: Basic ... X-forwarded-host: cal.maui.co.uk BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Mac OS X 10.9//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:Europe/London BEGIN:DAYLIGHT TZOFFSETFROM:+ RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU DTSTART:19810329T01 TZNAME:BST TZOFFSETTO:+0100 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU DTSTART:19961027T02 TZNAME:GMT TZOFFSETTO:+ END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:1387007670GET /dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics HTTP/1.1 Accept-encoding: gzip, deflate Max-forwards: 10 Accept-language: en-gb User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174 Host: 192.168.253.16:1443 Accept: */* Content-length: 0 X-forwarded-server: dav.maui.co.uk X-forwarded-for: 176.12.107.140 Authorization: Basic ... X-forwarded-host: cal.maui.co.uk BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Mac OS X 10.9//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:Europe/London BEGIN:DAYLIGHT TZOFFSETFROM:+ RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU DTSTART:19810329T01 TZNAME:BST TZOFFSETTO:+0100 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU DTSTART:19961027T02 TZNAME:GMT TZOFFSETTO:+ END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20131214T075350Z UID:0C48ECD9-44A7-4F1F-9C87-9A2EF647C574 DTEND;TZID=Europe/London:20131207T10 TRANSP:OPAQUE SUMMARY:Change Event Name DTSTART;TZID=Europe/London:20131207T09 DTSTAMP:20131214T075411Z SEQUENCE:3 END:VEVENT END:VCALENDAR 1387007670HTTP/1.1 406 Not Acceptable Date: Sat, 14 Dec 2013 07:54:30 GMT Strict-Transport-Security: max-age=600 Vary: Accept-Encoding Server: Cyrus/v2.4.17-caldav-beta8 Cyrus-SASL/2.1.23 OpenSSL/0.9.8 zlib/1.2.3 libxml2/2.6.29 SQLite/3.8.2 libical/0.48 Content-Length: 0 I’ll keep looking; I can create and edit events, just not delete them… marty On 12 Dec 2013, at 17:30, Ken Murchison mu...@andrew.cmu.edu wrote: Hi Marty, Did you find anything related to this? I don't have Mavericks yet, but maybe a telemetry log of the client trying to delete an entry would point me in the right direction. Worst case, I will be with the Apple client developers in early February and can test then. On 10/24/2013 07:22 AM, Marty Lee wrote: Good afternoon (local time for me!) Updated my Mac to Mavericks this morning and am now getting the following error from the CalDAV part of Cyrus when I try to delete an entry. dav_exec() step: cannot start a transaction within a transaction Creation modification works fine, but iCal on the mac now can’t delete items. I can work around this by using a web interface to my calendars, but I just thought I’d mention it here that Apple have changed something in iCal with the new version of OS-X. If I get a chance this weekend, I’ll have a look at the source code and see if I can do anything to help. cheers marty - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https
Re: Cyrus IMAP / CalDAV
I just committed a fix to git for the 406 response to GET. I will make
a beta9 release with this fix, and hopefully with a fix for the DELETE
issue by early next week.
I have an email into one of the CalDAV experts that I know at Apple to
see what CalendarServer does with the empty If-Schedule-Tag-Match
header. I think its a bug in the Apple client, but I will have to come
up with a sane workaround for it. In the meantime, this uncommitted
patch should fix your problem with DELETE:
diff --git a/imap/http_caldav.c b/imap/http_caldav.c
index c00223f..641feb8 100644
--- a/imap/http_caldav.c
+++ b/imap/http_caldav.c
@@ -695,6 +695,7 @@ static int caldav_check_precond(struct transaction_t
*txn, const void *data,
/* Per RFC 6638, check Schedule-Tag */
if ((hdr = spool_getheader(txn-req_hdrs, If-Schedule-Tag-Match))) {
+if (!*hdr[0]) return precond; /* XXX Hack for bug in Apple client */
if (etagcmp(hdr[0], stag)) return HTTP_PRECOND_FAILED;
}
On 12/14/2013 09:39 AM, Marty Lee wrote:
No worries.. I'm about to get back onto another train so will back out b8..
Only me using it in earnest, so if you need anything else tested before
pushing out, just send me a link.
Marty Lee
v: 07827 950 918
On 14 Dec 2013, at 14:26, Ken Murchison mu...@andrew.cmu.edu wrote:
Hi Marty,
Thanks for the info. The 406 is in response to the GET, caused by a bug I
introduced when I added support for jCal and xCal data. I can't believe
that this didn't present itself in my testing. I will need to fix this
immediately. You probably want to downgrade to beta7 in the meantime.
I *think* the problem with DELETE is that iCal is sending an empty
If-Schedule-Tag-Match header. I will need to test this here and possibly
talk to the Apple guys to find out why they are sending an empty header, and
what they expect the behavior to be.
On 12/14/2013 03:09 AM, Marty Lee wrote:
Ken,
I haven’t but have just taken the opportunity to update to Beta 8 and also
to refresh Sqlite, which
seems to be the source of the error message…
Using cyrus beta 7, the iCal client would delete the event, but when it
updated with the server, the
event would magically just re-appear. With b8, this has changed; now I get
a dialog box:
--
The request for “Marty” in account “Maui” failed.
The server responded with
“406” to operation CalDAVDeleteEntityQueueableOperation.
-
Telemetry log:
1387007669DELETE
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
If-schedule-tag-match:
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T02
TZNAME:GMT
TZOFFSETTO:+
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:1387007670GET
/dav/calendars/user/marty/Default/0C48ECD9-44A7-4F1F-9C87-9A2EF647C574.ics
HTTP/1.1
Accept-encoding: gzip, deflate
Max-forwards: 10
Accept-language: en-gb
User-agent: Mac_OS_X/10.9 (13A603) CalendarAgent/174
Host: 192.168.253.16:1443
Accept: */*
Content-length: 0
X-forwarded-server: dav.maui.co.uk
X-forwarded-for: 176.12.107.140
Authorization: Basic ...
X-forwarded-host: cal.maui.co.uk
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Apple Inc.//Mac OS X 10.9//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T01
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T02
TZNAME:GMT
TZOFFSETTO:+
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20131214T075350Z
UID:0C48ECD9-44A7-4F1F-9C87-9A2EF647C574
DTEND;TZID=Europe/London:20131207T10
TRANSP:OPAQUE
SUMMARY:Change Event Name
DTSTART;TZID=Europe/London:20131207T09
DTSTAMP:20131214T075411Z
SEQUENCE:3
END:VEVENT
END:VCALENDAR
1387007670HTTP/1.1 406 Not Acceptable
Date: Sat, 14 Dec 2013 07:54:30 GMT
Strict-Transport-Security: max-age=600
Vary: Accept-Encoding
Server: Cyrus/v2.4.17-caldav-beta8 Cyrus-SASL/2.1.23 OpenSSL/0.9.8
zlib/1.2.3 libxml2/2.6.29 SQLite/3.8.2 libical/0.48
Content-Length: 0
I’ll keep looking; I can create and edit events, just not delete them…
marty
On 12 Dec 2013, at 17:30, Ken Murchison mu...@andrew.cmu.edu wrote:
Hi Marty,
Did you find anything related to this? I don't
cyrus-imapd-2.4.17-caldav-beta8 released
We are pleased to announce the eighth beta release of Cyrus IMAP with integrated calendaring and contacts. Major changes in the release include: - Added a Timezone Service module - Added support for jCal and xCal data - Better handling of COPY/MOVE between backends - Better handling of proxied responses The complete list of changes can be found in doc/changes.html in the distribution. This code is based on the stable Cyrus 2.4.17 release with support for HTTP-based services (CalDAV, CardDAV, RSS, and Timezone) added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta8.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta8.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Upgrade documentation will be found in doc/install-upgrade.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Cyrus IMAP / CalDAV
Hi Marty, Did you find anything related to this? I don't have Mavericks yet, but maybe a telemetry log of the client trying to delete an entry would point me in the right direction. Worst case, I will be with the Apple client developers in early February and can test then. On 10/24/2013 07:22 AM, Marty Lee wrote: Good afternoon (local time for me!) Updated my Mac to Mavericks this morning and am now getting the following error from the CalDAV part of Cyrus when I try to delete an entry. dav_exec() step: cannot start a transaction within a transaction Creation modification works fine, but iCal on the mac now can't delete items. I can work around this by using a web interface to my calendars, but I just thought I'd mention it here that Apple have changed something in iCal with the new version of OS-X. If I get a chance this weekend, I'll have a look at the source code and see if I can do anything to help. cheers marty - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta7 released
We are pleased to announce the seventh beta release of Cyrus IMAP with integrated calendaring and contacts. This is mainly a bug fix release, with only a few minor features added. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta7.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta7.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Upgrade documentation will be found in doc/install-upgrade.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: mysql problem
On 9/11/13 5:43 AM, Bron Gondwana wrote: On Wed, Sep 11, 2013, at 05:46 PM, Rudolf Gabler wrote: Hi, the cyrus-imapd-2.4.17-caldav-beta6 release shows the following: After a fresh start with a mysql database for several purposes duplicate_db: sql mboxlist_db: sql quota_db: sql tlscache_db: sql the system is running as expected. After approximately the 10 imaps contact suddenly the following occurs: Sep 11 09:43:29 xmailer imaps[8168]: DBERROR: SQL query failed: MySQL server has gone away Sep 11 09:43:29 xmailer imaps[8168]: DBERROR: SQL failed SELECT * FROM mailboxes_db WHERE dbkey = 'user….. But the local mysql server is o.k. and running. After a restart of cyrus (/etc/init.d/cyrus-imapd restart) everything is working until the next appr. 10 connection times by the user. Smells like connection handle leakage, or leakage of some other finite resource in the mysql library. Any hint what may occur? Ken - any ideas? You know this code better than I do. Bron. No, I don't have any ideas. I don't have any experience using MySQL for all Cyrus databases (or any Cyrus db for that matter), and the *DAV code uses SQLite, not mySQL, and does so directly without going through the cyrusdb API. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: SETACL and virtdomains
Without actually trying to code this feature, I can't think of any issues beyond how to expose the shared mailboxes to clients as Bron mentions below. That being said, I'm pretty sure there will be other stumbling blocks that we haven't thought of yet. On 09/05/2013 04:08 AM, Andrzej Kwiatkowski wrote: Hi Ken, Have you got a minute to think about my problem/question ? Pozdrawiam AK W dniu 08.08.2013 02:10, Ken Murchison pisze: I'm on holiday at the moment. Give me another week to ponder this. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University On Aug 7, 2013, at 7:47 PM, Bron Gondwana br...@fastmail.fm wrote: On Wed, Aug 7, 2013, at 07:11 AM, Andrzej Kwiatkowski wrote: I'm using medium scale installation, with a lot clients domains, and mailboxex in mutliple domains. Now we want to add to clients functions of sharing mailboxes with some apps from Kolab. In docs i have found: * Domains are mutually exclusive - Users only have access to mailboxes within their own domain (intra-domain). The following example will not work: setacl user.j...@herdomain.com r...@hisdomain.com read. Is there any workaround ? Patch maybe ? TO share folder from us...@domain.com to us...@domain2.com in the same server ? I'm afraid it's not possible in the general case without major name mangling on the shared mailboxes, which is why we just don't allow it. I have CC'd Ken, who might also have some ideas. Ken - do you see super-strong reasons to enforce the no sharing over domains? The biggest issue I can see is unixhs being off by default - so you can't share it as: user.usern...@domain.com.subfolder because of the dots. user/usern...@domain.com/subfolder would work fine (you can already emulate this by turning OFF virtdomains... as I discovered when people reported bugs in it. But best of all would be unixhs on and altnamespace, so it's: INBOX Sent Other Users/usern...@domain.com/... The other alternative is to expose our internal structure even more, so people see: domain.com!user.username.subfolder But that will probably cause massive pain to clients. Bron. -- 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
Cyrus CalDAV deployment
Is anyone using Cyrus CalDAV in production? I most likely need to extend the CalDAV DB schema and if nobody is using the code in production, I won't bother adding code to extend/upgrade the schema on the fly. I will have a tool to rebuild the DB from the calendar resources. Please let me know if being forced to rebuild the DB in bulk is going to cause problems for anybody. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: SETACL and virtdomains
I'm on holiday at the moment. Give me another week to ponder this. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University On Aug 7, 2013, at 7:47 PM, Bron Gondwana br...@fastmail.fm wrote: On Wed, Aug 7, 2013, at 07:11 AM, Andrzej Kwiatkowski wrote: I'm using medium scale installation, with a lot clients domains, and mailboxex in mutliple domains. Now we want to add to clients functions of sharing mailboxes with some apps from Kolab. In docs i have found: * Domains are mutually exclusive - Users only have access to mailboxes within their own domain (intra-domain). The following example will not work: setacl user.j...@herdomain.com r...@hisdomain.com read. Is there any workaround ? Patch maybe ? TO share folder from us...@domain.com to us...@domain2.com in the same server ? I'm afraid it's not possible in the general case without major name mangling on the shared mailboxes, which is why we just don't allow it. I have CC'd Ken, who might also have some ideas. Ken - do you see super-strong reasons to enforce the no sharing over domains? The biggest issue I can see is unixhs being off by default - so you can't share it as: user.usern...@domain.com.subfolder because of the dots. user/usern...@domain.com/subfolder would work fine (you can already emulate this by turning OFF virtdomains... as I discovered when people reported bugs in it. But best of all would be unixhs on and altnamespace, so it's: INBOX Sent Other Users/usern...@domain.com/... The other alternative is to expose our internal structure even more, so people see: domain.com!user.username.subfolder But that will probably cause massive pain to clients. Bron. -- 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: CalDAV and virtual domains not working
Hi Robert, Bron is correct. The code isn't doing the right thing for virtdomains, mainly because I hadn't bothered to add support for it as I was coding. Obviously, this needs to be fixed. I guess the big question is what the URLs should look like. Should we go with the current URL format and encode the '@' as your log entry shows below, or should we do something like: /dav/calendars/domain/fastmail.fm/user/robn/Default/ I think I prefer /dav/calendars/user/robn%40fastmail.fm/Default/ as long as clients support it. Bron, any thoughts? On 07/21/2013 08:53 PM, Robert Norris wrote: It looks like the CalDAV stuff is not doing the right thing with virtual domains (beta6 and git e415f906) 2013-07-21T20:44:55.580301-04:00 calendar1 calendar/http[30755]: login: vpn94.mail.srv.osa [10.203.0.94] r...@fastmail.fm Basic User logged in 2013-07-21T20:44:55.580929-04:00 calendar1 calendar/http[30755]: mlookup(user.robn@fastmail^fm.#calendars.Default) failed: Mailbox does not exist 2013-07-21T20:44:55.581141-04:00 calendar1 calendar/http[30755]: vpn94.mail.srv.osa [10.203.0.94] as r...@fastmail.fm with Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 Lightning/1.9b1; PROPFIND /dav/calendars/user/robn%40fastmail.fm/Default/ HTTP/1.1 (depth=0) = 404 Not Found (error=Mailbox does not exist) Mailbox structure via IMAP is: . LIST * * LIST (\HasChildren) . user.r...@fastmail.fm * LIST (\HasChildren) . user.robn.#calend...@fastmail.fm * LIST (\HasNoChildren) . user.robn.#calendars.defa...@fastmail.fm * LIST (\HasNoChildren) . user.robn.#calendars.in...@fastmail.fm * LIST (\HasNoChildren) . user.robn.#calendars.out...@fastmail.fm Bron tells me (if I understood him correctly) that the domain splitting is broken, and it should be producing eg fastmail.fm!user.robn.#calendars.Default instead. Cheers, Rob N. 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 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Cyrus+CalDAV
Hi Marty, On 07/17/2013 09:33 AM, Marty Lee wrote: Hi, I've been playing with the latest Cyrus beta which includes the CalDAV CardDAV additions - from a personal perspective, almost all seems ok. Server is a Solaris 10 (x86) box; clients are mainly Mac OSX (Mountain Lion) and some PCs (Thunderbird/Lightning). One question that Ken or someone may already know and one issue that I need to track down further. The question first: I've got two users that have permission to read each others Default calendar (lr9) - but I'm guessing that the list of calendars returned to the Mac calendar app only includes calendars for the actual user, not shared ones, as the shared calendars can't be seen… does this sound right, or should I be able to see the shared calendars (or need to do something to make it work)? Even though you set the ACLs properly, this won't help you by itself. There is a separate CALDAV sharing spec which essentially makes shared calendars appear under a user's own calendar-home-set. Unfortunately, Cyrus doesn't support this spec yet. I don't know if there are other ways for a user to access someone else's calendars. I've also seem similar with the CardDAV interface - I use a DAV client to pull down all my contacts and put them into a local LDAP server for address book lookups for a number of other apps. This works if I use my username+password, but not if I use a different account with permissions to read my Default address book (lr). There has been talk of a sharing spec for CardDAV, but I don't believe any work has been done on it yet. The issue I've seen revolves around adding pictures to vCards - some existing cards have pictures (copied from existing Mac address book), but changing pictures or adding new cards with photos seems to cause problems - I suspect it's 'segfaulting' the server process, but I'm not 100% certain of that yet, so I won't log a bug just yet… Hmm. Which client are you using to edit the vCard? I know that I used the CardDAVMate javascript client to add a picture and it worked. But that's not to say that I don't have a bug somewhere. Thanks for the feedback! -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: Cyrus+CalDAV
On 07/18/2013 02:59 PM, Ken Murchison wrote: The issue I've seen revolves around adding pictures to vCards - some existing cards have pictures (copied from existing Mac address book), but changing pictures or adding new cards with photos seems to cause problems - I suspect it's 'segfaulting' the server process, but I'm not 100% certain of that yet, so I won't log a bug just yet… Hmm. Which client are you using to edit the vCard? I know that I used the CardDAVMate javascript client to add a picture and it worked. But that's not to say that I don't have a bug somewhere. I did some more testing with Apple Contacts and it looks like the vCard parser that I'm using doesn't like the data. The server doesn't segfault, its returns a 403 (Forbidden) with the CARDDAV:valid-address-data/ precondition. I'm looking into this. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta6 released
We are pleased to announce the sixth beta release of Cyrus IMAP with integrated calendaring and contacts. This is a bug fix release, with only a few minor features added. The biggest changes are support for unixhierarchysep in all HTTP modules, and the switch from RSS 2.0 to Atom 1.0 format for RSS feeds. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta6.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta6.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: cyrus-imapd-2.4.17-caldav-beta5 released
Hi Ondrej,
I have not done any testing with unixhierarchysep or virtdomains. From
the error messages below, it looks like the mailbox name translation is
not being done properly, or not being done at all.
I will look into this today.
On 06/11/2013 09:54 AM, Ondřej Surý wrote:
Ken,
does the Ca{l,rd}DAV module support unixhierarchysep?
I managed to setup the httpd server after some hassle on test machine,
and running the Mac Addressbook generates these lines into syslog:
Jun 11 15:43:01 git cyrus/https[1402]:
mlookup(user.ondrej.sury.#addressbooks) failed: Mailbox does not exist
Jun 11 15:43:01 git cyrus/https[1402]:
mlookup(user.ondrej.sury.#addressbooks) failed: Mailbox does not exist
I have similar experience with CalDAV (various account doesn't exists
messages from Apple Calendar - and one nice crash of the application :).
Ondrej
On Fri, May 31, 2013 at 6:43 PM, Ken Murchison mu...@andrew.cmu.edu
mailto:mu...@andrew.cmu.edu wrote:
We are pleased to announce the fifth beta release of Cyrus IMAP with
integrated calendaring and contacts. This is a security and bug fix
release, with only two minor features added. Sites that are using or
testing any of the HTTP-based services are urged to upgrade to this
release.
This code is based on the stable Cyrus 2.4.17 release with support
for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP
daemons and utilities should be considered production quality in this
release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status.
You can download via HTTP or FTP:
http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta5.tar.gz
ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta5.tar.gz
Installation documentation will be found in doc/install-http.html in
the distribution.
Thanks for your continued support, and we look forward to any and
all feedback.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
--
Ondřej Surý ond...@sury.org mailto:ond...@sury.org
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
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
cyrus-imapd-2.4.17-caldav-beta5 released
We are pleased to announce the fifth beta release of Cyrus IMAP with integrated calendaring and contacts. This is a security and bug fix release, with only two minor features added. Sites that are using or testing any of the HTTP-based services are urged to upgrade to this release. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta5.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta5.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: cyrus-imapd-2.4.17-caldav-beta4 released
Dave is correct. The older imapd will show the calendar mailboxes to users in the LIST output. If you want to hide them, you will have to install the new imapd binary. Otherwise, you could change the ACLs on the calendar mailboxes so that the user can't write to them, but they will still see them. On 05/21/2013 06:55 AM, Sebastian Hagedorn wrote: Hi Dave, thanks. My understanding was that the other daemons hadn't changed, so I thought that base 2.4.17 already included the intelligence about those special folders. Ken, could you please clarify if that is the case or if I also need to replace the other binaries to be safe? Cheers, Sebastian --On 21. Mai 2013 09:28:22 + Dave McMurtrie dav...@andrew.cmu.edu wrote: The calendar and contact data is stored within a user's normal mailbox heirarchy. imapd from cyrus-imapd-caldav-2.4.17 knows to not return the calendar and contact folders to an IMAP client in LIST output. If you just copy the htttpd binary in place, I think it should work, but your IMAP users will see those folders. At the very least they'll wonder what they are. At the worst, they'll manipulate them with an IMAP client and make them unstable for CalDAV use. If I missed anything, I'm sure Ken can chime in. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta4 released
We are pleased to announce the fourth beta release of Cyrus IMAP with integrated calendaring and contacts (beta3 was an internal release only). This is a security and bug fix release, with only one new feature added. Sites that are using or testing any of the HTTP-based services are urged to upgrade to this release. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta4.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta4.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: cyrus-imapd-2.4.17-caldav-beta1 released
Nic, The doc/install-http.html file hopefully should tell you everything you need to know. If not, let me know. The server will automatically create a Default calendar and addressbook, for dumb clients like Lightning that can't create their own. Otherwise, an admin can create additional collections just by creating a mailbox in the correct location. We are toying with the idea of creating a webpage that allows the end-user to admin their collections (create, delete, rename, acl management) themselves for those not using smart clients like iCal. On 05/09/2013 09:17 AM, Nic Bernstein wrote: Ken, Much thanks for this -- it's quite welcome indeed. Have you got any documentation on the specifics of collection management, rights assignment, etc.? Given that most clients currently available are pretty brain-dead about creating new calendars, address books, etc., it would be nice to know if it's possible to handle this manually or via the underlying mailboxes. Cheers, -nic On 05/07/2013 10:23 AM, Ken Murchison wrote: Ken Murchison wrote: We are please to announce the release of Cyrus IMAP with integrated calendaring and contacts for beta testing. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. More specifically, the CalDAV and CardDAV modules should be considered beta. The RSS module has been running in production at CMU for over a year and has proven the main HTTP code to be stable. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta2 released
We are please to announce the second beta release of Cyrus IMAP with integrated calendaring and contacts. This is a bug fix release centered mostly on build issues. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta2.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta2.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
cyrus-imapd-2.4.17-caldav-beta1 released
We are please to announce the release of Cyrus IMAP with integrated calendaring and contacts for beta testing. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta1.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta1.tar.gz Installation documentation will be found in doc/install-http.html in the distribution. Thanks for your continued support, and we look forward to any and all feedback. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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: cyrus-imapd-2.4.17-caldav-beta1 released
Ken Murchison wrote: We are please to announce the release of Cyrus IMAP with integrated calendaring and contacts for beta testing. This code is based on the stable Cyrus 2.4.17 release with support for CalDAV, CardDAV and RSS added. All of the standard Cyrus IMAP daemons and utilities should be considered production quality in this release, but the HTTP support (CalDAV, CardDAV and RSS) is in beta status. More specifically, the CalDAV and CardDAV modules should be considered beta. The RSS module has been running in production at CMU for over a year and has proven the main HTTP code to be stable. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
Cyrus SASL 2.1.26 Released
I'd like to announce the release of Cyrus SASL 2.1.26 on ftp.cyrusimap.org Major changes in Cyrus SASL 2.1.26: * Modernize SASL malloc/realloc callback prototypes * Added sasl_config_done() to plug a memory leak when using an application specific config file * Fixed PLAIN/LOGIN authentication failure when using saslauthd with no auxprop plugins (bug # 3590). * unlock the mutex in sasl_dispose if the context was freed by another thread * MINGW32 compatibility patches * Fixed broken logic in get_fqhostname() when abort_if_no_fqdn is 0 * Fixed some memory leaks in libsasl * GSSAPI plugin: - Fixed a segfault in gssapi.c introduced in 2.1.25. - Code refactoring - Added support for GSS-SPNEGO SASL mechanism (Unix only), which is also HTTP capable * GS2 plugin: - Updated GS2 plugin not to lose minor GSS-API status codes on errors * DIGEST-MD5 plugin: - Correctly send stale directive to prevent clients from (re)promtping for password - Better handling of HTTP reauthentication cases - fixed some memory leaks * SASLDB plugin: - Added support for BerkleyDB 5.X or later * OTP plugin: - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent TLS from failing in calling applications * SRP plugin: - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent TLS from failing in calling applications * saslauthd: - auth_rimap.c: qstring incorrectly appending the closing double quote, which might be causing crashes - auth_rimap.c: read the whole IMAP greeting - better error reporting from some drivers - fixed some memory leaks Many thanks to Alexey Melnikov and Dan White who did most of the work preparing this release. Please send any feedback either to cyrus-s...@lists.andrew.cmu.edu (public list) or to cyrus-b...@andrew.cmu.edu. Download at: ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
Cyrus SASL 2.1.26 Released
I'd like to announce the release of Cyrus SASL 2.1.26 on ftp.cyrusimap.org Major changes in Cyrus SASL 2.1.26: * Modernize SASL malloc/realloc callback prototypes * Added sasl_config_done() to plug a memory leak when using an application specific config file * Fixed PLAIN/LOGIN authentication failure when using saslauthd with no auxprop plugins (bug # 3590). * unlock the mutex in sasl_dispose if the context was freed by another thread * MINGW32 compatibility patches * Fixed broken logic in get_fqhostname() when abort_if_no_fqdn is 0 * Fixed some memory leaks in libsasl * GSSAPI plugin: - Fixed a segfault in gssapi.c introduced in 2.1.25. - Code refactoring - Added support for GSS-SPNEGO SASL mechanism (Unix only), which is also HTTP capable * GS2 plugin: - Updated GS2 plugin not to lose minor GSS-API status codes on errors * DIGEST-MD5 plugin: - Correctly send stale directive to prevent clients from (re)promtping for password - Better handling of HTTP reauthentication cases - fixed some memory leaks * SASLDB plugin: - Added support for BerkleyDB 5.X or later * OTP plugin: - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent TLS from failing in calling applications * SRP plugin: - Removed calling of EVP_cleanup() on plugin shutdown in order to prevent TLS from failing in calling applications * saslauthd: - auth_rimap.c: qstring incorrectly appending the closing double quote, which might be causing crashes - auth_rimap.c: read the whole IMAP greeting - better error reporting from some drivers - fixed some memory leaks Many thanks to Alexey Melnikov and Dan White who did most of the work preparing this release. Please send any feedback either to cyrus-s...@lists.andrew.cmu.edu (public list) or to cyrus-b...@andrew.cmu.edu. Download at: ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University 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
Cyrus NNTP/newspostuser
Is anybody using Cyrus NNTP and the newspostuser option in imapd.conf? I'm considering changing the behavior of newspostuser so that it constructs a To: header rather than a Reply-To: header but I don't want to break any existing installs. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus NNTP/newspostuser
Ken Murchison wrote: Is anybody using Cyrus NNTP and the newspostuser option in imapd.conf? I'm considering changing the behavior of newspostuser so that it constructs a To: header rather than a Reply-To: header but I don't want to break any existing installs. Never mind. After further thought and in-house discussion, I believe that Reply-To is still the best header to use. The only change that I am going to make it to append defaultdomain (if set) to any email addresses that get created from Newsgroups: -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus SASL 2.1.25 Released
I'd like to announce the release of Cyrus SASL 2.1.25 on ftp.cyrusimap.org Major changes in Cyrus SASL 2.1.25: Added support for channel bindings Added support for ordering SASL mechanisms by strength (on the client side), or using the client_mech_list option. Allow DIGEST-MD5 plugin to be used for client-side and server-side HTTP Digest, including running over non-persistent connections (RFC 2617) New SASL plugin: SCRAM New SASL plugin: GS2 Updated config to the latest GNU snapshot Major fixes in Cyrus SASL 2.1.25: * Fixed a crash caused by aborted SASL authentication and initiation of another one using the same SASL context. * (Windows) Fixed the random number generator to actually produce random output on each run * Various improvements to DIGEST-MD5 to improve interoperability with some slightly broken clients For a complete list look at the NEWS file in the distribution. Many thanks to Alexey Melnikov who did most of the work preparing this release. Please send any feedback either to cyrus-s...@lists.andrew.cmu.edu (public list) or to cyrus-b...@andrew.cmu.edu. Download at: ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.25.tar.gz -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAPd 2.4.0 Released
I am pleased to announce the release of Cyrus IMAPd 2.4.0. This release should be considered production quality but hasn't yet been widely tested. Major changes in the release are the following: - All databases are now skiplist by default - Charset subsystem has been rewritten - Unicode 5.2 and UTF-8 in Sieve - Core mailbox handling code has largely been rewritten - Replication code largely rewritten - Several LEMONADE extensions have been implemented - Added support for marking QoS on traffic For full details, please see: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.0/changes.php http://www.cyrusimap.org/docs/cyrus-imapd/2.4.0/install-upgrade.php URL for this release: ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.0.tar.gz Special thanks go to Bron Gondwana whose stellar work on redesigning and refactoring the code has been instrumental in making this release possible. Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. -- Kenneth Murchison Principle Systems Software Engineer Carnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Sieve and encoded Headers
Bron Gondwana wrote: On Mon, Feb 08, 2010 at 11:29:22AM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Mon, Feb 08, 2010 at 07:53:21AM +0100, Garry wrote: Hi, after wondering for a while why occasionally my sieve script rules wouldn't work, I just found the reason (I guess) - Sieve doesn't (correctly?) decode utf encoded header lines which e.g. are in a format like this: Subject: =?utf-8?B?W0xPR10gV2F0Y2hsaXN0OiBzbWVhZ29sIGZvdW5kIEdydcOfIGF1cyBkZXIgVW50ZXJ3ZWx0IChVbmtub3duIENhY2hlKQ==?= I'm using version: Cyrus timsieved v2.2.13-Debian-2.2.13-19 ... is it something that is fixed in a newer version? I tried finding something on the net, but at least the first couple of results pages didn't yield any insight ... No - it's not fixed in any released version. It is fixed in the FastMail Cyrus patches - but it's a very invasive change to the charset encoding, so it's been kept out of the stable line for now. I've CC'd Ken on this - I wonder if it's worth going back and doing a minimal still compatible set of patches that fixes charset encoding in sieve without actually changing the on disk format of the cyrus.cache It might be worth doing this for 2.3. Done! I've put lots of testing in to it too :) Added to the cyrus-imapd-2_3-tail branch. Are you planning on re-comitting your charset changes to 2.4 soon? -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: Sieve and encoded Headers
Bron Gondwana wrote: On Mon, Feb 08, 2010 at 07:53:21AM +0100, Garry wrote: Hi, after wondering for a while why occasionally my sieve script rules wouldn't work, I just found the reason (I guess) - Sieve doesn't (correctly?) decode utf encoded header lines which e.g. are in a format like this: Subject: =?utf-8?B?W0xPR10gV2F0Y2hsaXN0OiBzbWVhZ29sIGZvdW5kIEdydcOfIGF1cyBkZXIgVW50ZXJ3ZWx0IChVbmtub3duIENhY2hlKQ==?= I'm using version: Cyrus timsieved v2.2.13-Debian-2.2.13-19 ... is it something that is fixed in a newer version? I tried finding something on the net, but at least the first couple of results pages didn't yield any insight ... No - it's not fixed in any released version. It is fixed in the FastMail Cyrus patches - but it's a very invasive change to the charset encoding, so it's been kept out of the stable line for now. I've CC'd Ken on this - I wonder if it's worth going back and doing a minimal still compatible set of patches that fixes charset encoding in sieve without actually changing the on disk format of the cyrus.cache It might be worth doing this for 2.3. But - I can tell you that we're not going to be backporting this sort of thing to the 2.2 series, so you'll certainly need to upgrade! Correct. 2.2 has basically been moth-balled. -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: Future Ideas wiki page
Thanks for adding this to the wiki. As I've said before, I'm comfortable with most, if not all, of this. I'm still working on completing the BODYPARTSTRUCTURE piece of URLAUTH=BINARY in 2.4. I'm trying to decide if I want to search through the preformatted BODYSTRUCTURE response in cyrus.cache for the requested part, or re-parse the MIME headers for the requested part on the fly. Or perhaps there is some other slick way of doing this that hasn't occurred to me yet. Bron Gondwana wrote: Hi All, I've set up a new wiki page here: http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/FutureIdeas Linked from the roadmap: http://cyrusimap.web.cmu.edu/twiki/bin/view/Cyrus/RoadMap I've updated the Roadmap with the items I have ready right now for 2.4, and put everything else into the bright future under 2.5 for now, subject to actually gets finished and stable, obviously. Most of these ideas have been fleshed out in some detail already in my postings to the devel mailing list. Some are still a little bit raw (like having the mailbox path on disk depend on the uniqueid rather than the actual mailbox name. I'll expand on this another time... and it's not yet mentioned on the wiki, but it makes a lot of things nicer!) Anyway, I'd love feedback on any or all of it, and if there are other things that you feel are really important for the future viability of Cyrus I'd love to hear about them as well. I haven't yet had a chance to look at the QRESYNC stuff that Ken's already done for 2.4, and we might wind up releasing a 2.4 without a lot of these changes just because there's a lot of work in there! That said, I'm pushing myself pretty aggressively to have that list finished by April of THIS YEAR. Particularly the low bandwidth replication, which depends on all pretty much all of the others! Regards, Bron. ___ Cyrus-project mailing list cyrus-proj...@lists.andrew.cmu.edu https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-project -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: Cyrus IMAPd 2.3.16 Released
Bron Gondwana wrote: On Mon, Jan 04, 2010 at 09:11:10AM +0100, Simon Matter wrote: Or you can use a dummy backend. It's a backend which always says « OK » when you try to write in it, and always says « not in db » when you read in it. This backend was never committed into cyrus-imapd... Here is an up-to-date version. Then add this in imapd.conf : duplicate_db: dummy Ken, Bron : do you plan to include this backend into cyrus-imapd ? It's very handy when we don't want to use a database (here we often use dummy for annotations). It looks really useful to me. Any chance this will go into upstream? I'd prefer to include it in my RPMs if I know it's also in upstream. It certainly will! There's a bit of 2.3 vs 2.4 uncertainty about where to put code. I think we've pretty much put 2.3 into maintainence mode. I'm telling everyone that we're releasing 2.4 in April on the theory that if you repeat something often enough it becomes true! Do we really need a dummy backend, or should we just rewrite the code so that non-critical DBs can be specified as nil/none/null and just not make the database calls? Also, in the case of disabling annotation_db, we shouldn't be advertising ANNOTATEMORE/METADATA in the IMAP capabilities. In the case of disabling duplicate_db, we shouldn't be allowing the Sieve Vacation extension, and we can't prevent mail loops caused by Sieve Redirect. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: prevent stuck processes with large folder manipulations
I'm wondering if because the COPY might be taking a long time before
responding, that the client thinks that the server has hung or gone
away. The attached (untested) patch might solve the problem.
Paul Dekkers wrote:
Hi,
From time to time (but mostly at the start of the year ;-)), I notice a
lot of load caused by people archiving their mail-folders. Maybe this is
mostly caused by Thunderbird going mad, but I was wondering if I could
do anything on the server-side to prevent things from going bad. Because
now I see memory (and swap) exhaustion and the side-effects of that
(Linux kernel killing processes)...
One example: someone was moving tens of thousands of messages from 2009
to a new 2009 folder. Apparently Thunderbird was stuck, maybe because
these things don't happen instantly moving this number of messages so
the server doesn't finish quickly: but Thunderbird created a lot (~100)
of sessions / imapd-processes for this user, maybe after timeouts.
(I think) Only one process was active doing the link's, it looked like
the others were mostly waiting for a write lock (fortunately), waiting
to do the same thing. (Inspected with strace.) But when the process that
hogged the CPU was killed, the next process took over, until all similar
processes were killed. And the new archive-folder now ended up with
several duplicates, taking about millions instead of tens of thousands.
(We'll have to see how to dedup that, any ideas are appreciated
otherwise I'll write something for that.)
It just happened, but it happened before. This mail-server is not that
busy, 100 users, but it happens at least a few times per year.
Any idea how to prevent things like this? Judging from the man-pages I
don't think I could do this from within cyrus, but that I would have to
prevent from linux's ulimit or so and tune that (sounds like a tough
job)... or could I actually do this with cyrus parameters?
Curious if people have similar experiences :-)
Regards,
Paul
P.S. This specific machine is running Red Hat 4 and a version of Simon's
(s)rpm.
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
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
Index: append.c
===
RCS file: /afs/andrew/system/cvs/src/cyrus/imap/append.c,v
retrieving revision 1.109.2.2
diff -u -r1.109.2.2 append.c
--- append.c28 Dec 2009 21:51:28 - 1.109.2.2
+++ append.c4 Jan 2010 15:36:28 -
@@ -828,7 +828,8 @@
struct appendstate *as,
int nummsg,
struct copymsg *copymsg,
- int nolink)
+ int nolink,
+ struct protstream *pout)
{
struct mailbox *append_mailbox = as-m;
int msg;
@@ -841,6 +842,7 @@
int r, n;
int flag, userflag, emptyflag;
struct body *body = NULL;
+time_t start, now;
assert(append_mailbox-format == MAILBOX_FORMAT_NORMAL);
@@ -854,7 +856,15 @@
xmalloc(nummsg * sizeof(struct index_record));
/* Copy/link all files and cache info */
-for (msg = 0; msg nummsg; msg++) {
+for (start = time(0), msg = 0; msg nummsg; msg++) {
+ /* Send progress update to client every 30 sec */
+ if (pout (now = time(0)) start + 30) {
+ start = now;
+ prot_printf(pout, * OK copied %d of %d messages\r\n,
+ msg, nummsg);
+ prot_flush(pout);
+ }
+
zero_index(message_index[msg]);
message_index[msg].uid = append_mailbox-last_uid + 1 + as-nummsg;
if (append_mailbox-options OPT_IMAP_CONDSTORE) {
Index: append.h
===
RCS file: /afs/andrew/system/cvs/src/cyrus/imap/append.h,v
retrieving revision 1.28.2.2
diff -u -r1.28.2.2 append.h
--- append.h28 Dec 2009 21:51:28 - 1.28.2.2
+++ append.h4 Jan 2010 15:36:28 -
@@ -139,7 +139,8 @@
extern int append_copy(struct mailbox *mailbox,
struct appendstate *append_mailbox,
- int nummsg, struct copymsg *copymsg, int nolink);
+ int nummsg, struct copymsg *copymsg, int nolink,
+ struct protstream *pout);
extern int append_collectnews(struct appendstate *mailbox,
const char *group, unsigned long feeduid);
Index: index.c
===
RCS file: /afs/andrew/system/cvs/src/cyrus/imap/index.c,v
retrieving revision 1.219.2.10
diff -u -r1.219.2.10 index.c
--- index.c 28 Dec 2009 21:51:33 - 1.219.2.10
+++ index.c 4 Jan 2010 15:36:29 -
@@ -1814,7 +1814,7 @@
docopyuid = (append_mailbox.m.myrights ACL_READ);
r = append_copy(mailbox, append_mailbox,
Cyrus development update 12/29/09
I spent a couple of days reviving the stale 2.4 development branch by merging all of the 2.3 changes into it. This branch will now be where the most active development will be taking place. Any activity on the 2.3 branch will be mostly bugfixes. New features that are already in 2.4 are extensions that came out of the IETF Lemonade WG (for resource/bandwidth restricted devices): - LIST-EXTENDED - ESEARCH - WITHIN - ENABLE - QRESYNC - URLAUTH=BINARY With the exception of URLAUTH=BINARY, all extensions were compliant with the current I-D at the time they were implemented. I will be spending time going through the published RFCs and making sure that the implementations are complete/correct. Other features that are expected to be on the short-term roadmap are: - Bron's CHARSET changes - Morphing legacy ANNOTATEMORE extension into current METADATA extension (this will allow us to add other METADATA-dependent extensions from Lemonade WG) - Several features/exhancements that are already running in production at Fastmail (I'll let Bron elaborate). I'm sure I'm forgetting something in one of the above lists, but I'll continue to update as I see fit. Happy New Year! -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus IMAPd 2.3.16 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.16. This release should be considered production quality. Major changes in the release are the following: - Added 'user_deny.db' to be able to selectively deny users access to Cyrus services. - Added 'popuseimapflags' option which enables setting and obeying IMAP flags in the POP server. - Added optimized method of handling an empty maildrop in pop3d. (based on work of Cyril Servant elfejoy...@gmail.com) - Added 'annotation_definitions' option for specifying external (third-party) annotations. (courtesy of Thomas Viehmann t...@beamnet.de) - Added COMPRESSion to replication protocol. (courtesy of Bron Gondwana br...@fastmail.fm) For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.16.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.16.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. Happy Holidays! -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.16 Released
Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.16. This release should be considered production quality. Major changes in the release are the following: - Added 'user_deny.db' to be able to selectively deny users access to Cyrus services. While upgrading my rpms I wanted to see where the db is so I can handle it in the package. But I can't find it and even stracing didn't show that the file was searched for. Do we have to enable it at compile time or are there other options beside userdeny_db to configure it? Thanks for any hint. Its in configdir, along with the rest of the dbs. Its not created by default, since its not required for normal operation. Actually, its not the most efficient implementation right now, since it does an open/read/close per login. I need to rework it so that it does the open at service init time, leaves the db open for reading for the each process reuse, and closes it at service shutdown time. This will take a little work, because we plan on using a remote MySQL database at CMU, so the actual read function will also have to reconnect if necessary. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: ANNOTATEMORE = METADATA and rfc 5464
What is your new format proposal? Bron Gondwana wrote: I'm in the process of implementing rfc 5464, which is what the ANNOTATEMORE drafts turned into. Unfortunately, Cyrus' support is an early draft, before the paths to everything were changed and the commands were renamed. It would be great to be complient, and there is software out there like Kolab which would benefit from it. Also, the database format is pretty nasty - complete with nulls embedded in keys and other fun stuff (like platform dependent type lengths codified in the format, ick) So I'm thinking: create a new metadata.db, require a conversion on upgrade from annotations.db. I had a look, and none of our servers had ANY annotations until I added a /comment to my INBOX for testing. Does anybody out there use annotations much? Does anybody know any code that would be broken by changing the way annotations are done? Thanks, Bron. -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: ANNOTATEMORE = METADATA and rfc 5464
Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: ANNOTATEMORE = METADATA and rfc 5464
Bron Gondwana wrote: On Tue, Nov 17, 2009 at 04:17:51PM -0500, Ken Murchison wrote: Bron Gondwana wrote: On Tue, Nov 17, 2009 at 09:03:11AM -0500, Ken Murchison wrote: What is your new format proposal? I'll see :) Not sure yet - but mainly not sizeof(unsigned long)! If we make a wholesale change to the database, perhaps this might be something we put in the 2.4 branch. It already has some partial/complete extensions like QRESYNC, LIST-EXTENDED, URLAUTH=BINARY and COMPRESS (which I backported to 2.3). I was also thinking that although the charset changes have been fully tested at Fastmail that it too might be a candidate for 2.4. Yeah, fair enough! I did commit them to CVS, but it's easy enough to back them out and commit to a branch instead. Do we have a roadmap for what else people want on the 2.4 branch? I'd be happy to put a bit more effort into polishing up those features that are there so we can ship a 2.4 soonish. Say by April next year, which gives us 6 months to prepare. My original vision for 2.4 was to be compliant with the LEMONADE v2 profile. At this point is can morph into anything we want. Some of the 2.4 features required changes that I felt were too in depth to put into a relatively stable 2.3. I'm pretty close to having the time to dive back into the 2.4 code. The first thing that needs to be done is to merge all of the new 2.3 stuff into 2.4. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus IMAPd 2.2.13p1 2.3.15 Released
I'd like to announce the releases of Cyrus IMAPd 2.2.13p1 and 2.3.15. These releases should both be considered production quality. These releases are being made at this time to fix the potential buffer overflow vulnerability described in CERT VU#336053: http://www.kb.cert.org/vuls/id/336053 The 2.2.13p1 release is no different from 2.2.13 other than the buffer overflow fix. The 2.3.15 release contains several other non-critical bugfixes and feature enhancements. For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. I'd personally like to thank Bron Gondwana of Fastmail.fm for finding and fixing the buffer overflow, as well as his numerous other contributions to the 2.3.15 release. URLs for these releases: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.13p1.tar.gz ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.15.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.13p1.tar.gz http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.15.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus SASL 2.1.24 RC1 Released
I'd like to announce the release of Cyrus SASL 2.1.24 RC1 on ftp.andrew.cmu.edu. This release candidate includes numerous bugfixes and several minor feature enhancements. For a complete list, look at the NEWS file in the distribution. I'd like to get some independent testing of this code before I make a final release. Please send any feedback either to cyrus-s...@lists.andrew.cmu.edu (public list) or to cyrus-b...@andrew.cmu.edu. Download at: ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-2.1.24rc1.tar.gz -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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
Cyrus SASL 2.1.23 Released
I'd like to announce the release of Cyrus SASL 2.1.23 on ftp.andrew.cmu.edu. This version includes a fix for a potential buffer overflow in sasl_encode64() (see http://www.kb.cert.org/vuls/id/238019), otherwise it is identical to 2.1.22. Please note that while this fixes vulnerable code, non-vulnerable code may break if the buffer passed to sasl_encode64() is the exact size of the encoded data and doesn't include space for the trailing NUL. Please send any feedback either to cyrus-s...@lists.andrew.cmu.edu (public list) or to cyrus-b...@andrew.cmu.edu. Download at: ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-2.1.23.tar.gz -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: Why do lmtpd processes accumulate?
Have you done an strace on one of the lmtpd on the backend to see what it is doing? Gary Mills wrote: We have a fairly conventional Cyrus server with one front-end and one back-end. Recently, I've noticed that when the number of lmtpd processes on the back-end server increases to the 400 range, performance drops to a crawl, including local deliveries. When I put an upper limit of 128 or 64 to these processes on the front-end, which requires a Cyrus restart, all of the local deliveries succeed in a short time. Performance also comes back to normal. I can't tell if it's the restart that fixes the problem or if it's the limit on lmtpd children. I'm wondering, though, if the lmtpd processes are all waiting on some Cyrus database, so that more of them just makes it worse. These are the databases, from imapd.conf: annotation_db: skiplist duplicate_db: berkeley-nosync mboxkey_db: skiplist mboxlist_db:skiplist quota_db: quotalegacy seenstate_db: skiplist subscription_db:flat tlscache_db:berkeley-nosync I believe those are current recommendations. Which ones might be causing the problem? Is there tuning that can be done on them? -- Kenneth Murchison Systems Programmer Carnegie Mellon University 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: Weekly/Monthly record-keeping / maintenance?
I can guarantee that I had nothing to do with writing this code. Other
than updating the copyright blurb as Bron noted, I'm fairly certain I've
never even looked at it. Since its only example code, use it at your
own risk. If you fix it or improve it, feel free to pass us the changes.
Bron Gondwana wrote:
On Thu, Apr 02, 2009 at 10:42:23AM -0400, Jeff Blaine wrote:
Okay, well, for what it's worth, I fixed all of the
problems prohibiting me from running a quota -f
to completion.
The problem: imapdu.pl is buggy
Doh.
It fails to do the right thing with mailboxes containing
a space in the name.
Yeah, that's not entirely a surprise. Spaces in names
confuse lots of stuff.
...
1.46 MB 114 msgs INBOX.BMP
1.46 MB 114 msgs INBOX.Bio Stuff
0.00 bytes 0 msgs INBOX.Drafts
1.25 MB 36 msgs INBOX.HLT
1.25 MB 36 msgs INBOX.Information Retrieval
...
# $Id: imapdu.pl,v 1.9 2008/04/04 12:47:14 murch Exp $
I don't suppose 'murch', the author of the code reads
this list?
Yeah, he's around, though he doesn't always see stuff as quickly
if it's only sent to the list. I've CC'd him.
That said, he's likely not the author - just the last person that
changed things. Given that he did a giant sweeping copyright
update of nearly every file in the tree a couple of months ago...
my ($rc, $msg) = $cyrus-send('', '', EXAMINE $mb);
if ($rc eq 'OK') {
} else {
print failed: $mb: $msg\n;
}
Apart from being icky perl, that will fail to change mailboxes
because the EXAMINE command will have dodgy syntax. I'm not
entirely sure why you're not seeing the 'failed' messages
though... The $mb needs to be at least quoted - which is
why I generally use something like Mail::IMAPTalk that can
do correct protocol quoting.
Ahh - it probably does output the failed stuff further up.
Bron.
--
Kenneth Murchison
Systems Programmer
Carnegie Mellon University
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
Cyrus IMAPd 2.3.14 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.14. This release should be considered production quality. This is mostly a bugfix release. For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.14.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.14.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or cyrus-b...@andrew.cmu.edu. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Elusive replication bug in 2.3.13
Committed to CVS. Thnaks! Bron Gondwana wrote: On Wed, Jan 14, 2009 at 07:49:40AM +0100, Simon Matter wrote: http://github.com/brong/cyrus-imapd/commit/1de9d758aeb360714236388c4e1689db0522c21e Maybe it's just the lack of caffeine in the early morning, but, isn't there a way to simply _download_ a single diff from github.com? Thanks for any insights. Man, I see your point. They don't seem to have a get this as a plain diff file. How rude. I've attached it. Pretty easy within git. Bron ( still enjoying all the other stuff github gives you! ) -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: CONDSTORE and replication in production?
Bron Gondwana wrote: Hi, So - I've been playing with CONDSTORE a bit. Specifically, I'm looking at supporting cross folder searching through our web interface, and it would kind of suck to have to re-run the search on every folder every time we have a new query. So I figured that checking HIGHESTMODSEQ would probably be more reliable than a bunch of dodgy heuristics for guaranteeing that the cache isn't stale. Attached is a patch that makes rolling out condstore less painful, though the interface is a little unfriendly: mailbox_default_options: 2 My question - is anyone actually using CONDSTORE and Cyrus replication in production? For that matter, is anyone using CONDSTORE in production anywhere? Any client gotchas to be aware of? I'm not aware of any CONDSTORE clients other than Polymer, written by Dave Cridland. He may have written a similar client for a cell phone m manufacturer. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Disable SSLv2 ?
Wesley Alan Wright wrote: Using cyrus-imapd-2.2.12-9.RHEL4.i386 and cyrus-sasl-2.1.19-14.i386, trying to disable sslV2 to satisfy silly PCI (Purchase Card Industry) requirements yet keep ports 993 and 995 open. Tried 37 different variations of tls_cipher_list includin draconian tls_cipher_list: -ALL: +HIGH:-SSLv2m yet openssl s_client -ssl2 -connect localhost:993 Still yields SSL handshake has read 987 bytes and written 239 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1024 bit SSL-Session: Protocol : SSLv2 Cipher: DES-CBC3-MD5 I beginning to think it can't be done.\? I've used this in the past and it works just fine: tls_cipher_list: DEFAULT:!SSLv2:!LOW:!EXPORT -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: INBOX folder not available
Laurent G wrote:
Hi list,
under Linux Debian Etch and Cyrus Imap 2.2.13-10, I planned to
synchronize ACLs between too IMAP servers, using imap. This works fine
for almost mailboxes, except for very few of them.
Symptoms :
-1- the IMAP command SELECT does not work on the INBOX folder. (when
it works for the huge majority).
Non working example :
02 SELECT INBOX
02 NO Mailbox does not exist
If you're sure that the mailbox exists in mailboxes.db and on disk, then
the authenticated/authorized user doesn't have permission to see the
mailbox ('l' right).
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
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
Cyrus IMAPd 2.3.13 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.13. This release should be considered production quality. Noteworthy changes: * Added an experimental sql backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. * Added sieve_sasl_send_unsolicited_capability and sieve_sasl_expect_unsolicited_capability options. * Several 32/64-bit compatibility fixes. For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.13.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.13.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or [EMAIL PROTECTED] -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Upcoming Cyrus 2.3.13 Release
Folks, I'm planning on releasing 2.3.13 late Friday afternoon EDT unless someone reports a bug that we would consider a blocker. So, if there is anyone planning on doing testing on RC3, please do it soon. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus 2.3.13 RC3
I just put together a third and hopefully FINAL release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc3.tar.gz http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc3.tar.gz.sig Noteworthy changes: * Added an experimental sql backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. * Added sieve_sasl_send_unsolicited_capability and sieve_sasl_expect_unsolicited_capability options. * Several 32/64-bit compatibility fixes. Check doc/changes.html and doc/install-upgrade.html for a complete list of changes. If there are any outstanding critical issues that you believe still need to be addressed in 2.3.13, please let me know. This code has been in feature freeze for a while, so no new requests please. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus 2.3.13 RC2
Ian G Batten wrote: On 08 Oct 08, at 0536, Bron Gondwana wrote: On Mon, Oct 06, 2008 at 11:33:18AM -0400, Ken Murchison wrote: I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. Sorry about the delay in testing - we've had a few exciting issues here that had to be fixed first. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. No, it's looking good. I just removed the patches that have gone into CVS from my build tree and it built fine. Running on our test server now with no problems. All the patches that have gone upstream have been running happily on our production machines for a bit too. I think now's a good time to release a 2.3.13. What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. Minimal. My boss asked if we could try to get away from BDB and move to something like SQlite. I dusted off an old SQL patch that I wrote while working for my old employer and ported it to the 2.3 code. We set it up on a test machine and threw a couple of low volume users on it and the campus didn't burn down. We haven't done any kind of load testing or performance testing yet. That's why its listed as experimental -- use at your own risk. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus 2.3.13 RC2
Ian G Batten wrote: On 08 Oct 08, at 1119, Bron Gondwana wrote: On Wed, 8 Oct 2008 09:24:49 +0100, Ian G Batten [EMAIL PROTECTED] said: What's the testing status of the SQL backend for cyrusdb? I'll switch batten.eu.org over to it, but that only has a dozen or so users; ftel.co.uk's 1000+ users might be a little tenser. I'm keen to switch as the ability to replicate cyrusdb as well as replicating the entire mailsystem is attractive. You are aware that cyrus replication replicates DB records for all the important things as well, aren't you? Yes, of course. It's just that having, many years ago, experienced the loss of a cyrusdb, being able to keep up-to-date copies of it which I can use without the nuclear option of failing over to my off-site replica is a good thing. So I will shortly have my whole Cyrus instance (~60K mailboxes, ~1000 users, ~4TB of mail) replicated via GigE to a remote site. But if my local instance went south just because Cyrus DB had gone, being able to simply switch cyrusdb to a MySQL/PostgresQL replica while keeping mail service on the master is preferable to doing a full off-site failover. We were only looking at SQL to replace BDB (deliver.db, tls_sessions.db), because we still think that skiplist is superior from mailboxes.db and seen.db. If you do some heavy testing with the BDB code we'd be interested in your results. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: ACL to deny move mailbox/folder
tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken Murchison wrote: tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I got a shared folder where I want users to be able to create subfolders, but where I want to restrict the users so they do not move or delete the shared folder. The folder is a top level shared folder. I read through the cyradm documentation, but it wasn't very clear on how to do this. Is it possible? What version of Cyrus? If you're using 2.3.x, removing the 'x' right from your users will prevent them from deleting the mailbox. I'd have to check the ACL RFC, but I believe it will also prevent renaming (I think RENAME need delete on the source and create on the destination). 2.3.7. Interestingly enough, it seems that removing the 'x' right isn't possible : localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain sam Fag anyone write localhost.localdomain lam Fag anyone lrswipkxtecd localhost.localdomain sam Fag anyone lrswipktecda localhost.localdomain lam Fag anyone lrswipkxtecda localhost.localdomain After some fooling around, I found out that the problem is that if you give the user the a right, then you also grant the e and t rights. This would only be the case if you have 'deleteright' set to 'a'. Also, cyradm doesn't document what the c and d rights are. They are legacy rights macros that are now macros. If the 'deleteright' option in imapd.conf is set to the default of 'c', the c='kx' and d='et'. By explicitly granting 'd' above, you're implicitly granting 'x'. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus 2.3.13 RC2
Kenneth Marshall wrote: On Tue, Oct 07, 2008 at 12:18:01PM +0200, Simon Matter wrote: I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig Noteworthy changes: * Added an experimental sql backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. Check doc/changes.html for a complete list of changes. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. I did some test builds on different systems and found that postgresql support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error below. I understand that these are old versions but if there is an easy workaround for the problem it would still be nice. One question to the new sieve_utf8fileinto options, is the default that it behaves like old cyrus versions? Thanks, Simon There have been 5 major releases of PostgreSQL since 7.2 was released and 7.2 is EOL in the next few months. I think it is completely reasonable to not support version 7.1/7.2 in a new system considering that 7.1 is EOL and 7.2 will be shortly. I wasn't aware of the release history, thanks for that. Given this, I agree that support for 7.1/7.2 isn't necessary, especially since the cyrusdb_sql.c code is experimental and not built by default. If somebody really wants/needs 7.1/7.2 for Cyrus, they can send a patch. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus 2.3.13 RC2
Simon Matter wrote: I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig Noteworthy changes: * Added an experimental sql backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. Check doc/changes.html for a complete list of changes. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. I did some test builds on different systems and found that postgresql support doesn't work with postgresql 7.1.x and 7.2.x as shown in the error below. I understand that these are old versions but if there is an easy workaround for the problem it would still be nice. Do you happen to have a workaround? One question to the new sieve_utf8fileinto options, is the default that it behaves like old cyrus versions? Yes. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: ACL to deny move mailbox/folder
tarjei wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I got a shared folder where I want users to be able to create subfolders, but where I want to restrict the users so they do not move or delete the shared folder. The folder is a top level shared folder. I read through the cyradm documentation, but it wasn't very clear on how to do this. Is it possible? What version of Cyrus? If you're using 2.3.x, removing the 'x' right from your users will prevent them from deleting the mailbox. I'd have to check the ACL RFC, but I believe it will also prevent renaming (I think RENAME need delete on the source and create on the destination). -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus 2.3.13 RC2
I just put together a second release candidate for Cyrus 2.3.13. I'd appreciate any independent testing before I release this to the masses. http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz http://www.contrib.andrew.cmu.edu/~murch/cyrus-imapd-2.3.13rc2.tar.gz.sig Noteworthy changes: * Added an experimental sql backend for cyrusdb. Currently MySQL, PostgreSQL, and SQLite are supported. * Added support for IMAP [CAPABILITY] response code to client-side of Murder proxies. * Added support for ManageSieve auto-capability response after STARTTLS and after AUTH with a SASL security layer. * Made MAXWORD and MAXQUOTED sizes configurable via imapd.conf * Rewrote cyrusdb_quotalegacy.c to use readir() rather than glob.c. This avoids a potential crash due to conflicts between glibc and Heimdal implementations of glob(). * Added support for fulldirhash to 'ctl_mboxlist -v' * Several skiplist transaction bugfixes. * cyr_expire no longer has a default of 0 (zero) for -X and -D. These options must be used explicitly in order to have the desired effect. * Added sieve_utf8fileinto option. Check doc/changes.html for a complete list of changes. If there are any outstanding issues that you believe still need to be addressed in 2.3.13, please let me know. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12p2 Released
Hajimu UMEMOTO wrote: Hi, On Fri, 25 Apr 2008 14:39:20 -0400 Ken Murchison [EMAIL PROTECTED] said: murch Hajimu UMEMOTO wrote: Hi, On Fri, 25 Apr 2008 13:48:54 -0400 Ken Murchison [EMAIL PROTECTED] said: murch Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12p2. This release should be considered production quality. I was careless in applying the memory corruption patch in 2.3.12p1 and it didn't actually solve the problem. It should be fixed now. Ken, I can't see any difference between p1 and p2 apart from the create dates in the html docs. Are you sure the right tarball got to the download site? murch This is the only diff: murch https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/lib/libconfig.c.diff?r1=1.18.2.1;r2=1.18.2.2;sortby=date;f=h Unfortunately, I cannot see the diff between 2.3.12p1 and 2.3.12p2, and it seems the problem is still not fixed by 2.3.12p2. murch I have re-uploaded and checked the tarball, which now contains the fix. Thank you. It seems there are more diffs than the fix between the previous 2.3.12p2 and the new one. Is it intentional? The previous tarball was packaged in correctly. It had code from the trunk of CVS rather than the 2.3.12-patches branch. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12p2 Released
Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12p2. This release should be considered production quality. I was careless in applying the memory corruption patch in 2.3.12p1 and it didn't actually solve the problem. It should be fixed now. Ken, I can't see any difference between p1 and p2 apart from the create dates in the html docs. Are you sure the right tarball got to the download site? This is the only diff: https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/lib/libconfig.c.diff?r1=1.18.2.1;r2=1.18.2.2;sortby=date;f=h -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12p2 Released
Hajimu UMEMOTO wrote: Hi, On Fri, 25 Apr 2008 13:48:54 -0400 Ken Murchison [EMAIL PROTECTED] said: murch Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12p2. This release should be considered production quality. I was careless in applying the memory corruption patch in 2.3.12p1 and it didn't actually solve the problem. It should be fixed now. Ken, I can't see any difference between p1 and p2 apart from the create dates in the html docs. Are you sure the right tarball got to the download site? murch This is the only diff: murch https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/lib/libconfig.c.diff?r1=1.18.2.1;r2=1.18.2.2;sortby=date;f=h Unfortunately, I cannot see the diff between 2.3.12p1 and 2.3.12p2, and it seems the problem is still not fixed by 2.3.12p2. I have re-uploaded and checked the tarball, which now contains the fix. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12 Released
Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12. This release should be considered production quality. Noteworthy changes: * Added statuscache.db to cache IMAP STATUS data which significantly reduces the amount of I/O necessary when neither the mailbox nor \Seen state has changed -- courtesy of Fastmail.fm While upgrading my RPM packages I found that logging is too noisy for my taste. I get alot of syslog messages like so: Apr 24 11:35:30 test imap[10457]: statuscache, 'user.simix', 'simix', '0x13', 'yes' These messages are at the DEBUG level. Do you usually ship your RPM with the logging set to DEBUG? I don't really see a problem leaving these messages alone, since I would expect most production systems to be logging at INFO or higher. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12 Released
Simon Matter wrote: Simon Matter wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12. This release should be considered production quality. Noteworthy changes: * Added statuscache.db to cache IMAP STATUS data which significantly reduces the amount of I/O necessary when neither the mailbox nor \Seen state has changed -- courtesy of Fastmail.fm While upgrading my RPM packages I found that logging is too noisy for my taste. I get alot of syslog messages like so: Apr 24 11:35:30 test imap[10457]: statuscache, 'user.simix', 'simix', '0x13', 'yes' These messages are at the DEBUG level. Do you usually ship your RPM with the logging set to DEBUG? I don't really see a problem leaving these messages alone, since I would expect most production systems to be logging at INFO or higher. The RPM logs to mail facility and priority of mail is * by default on RedHat. That means out of the box we get quite alot messsages in maillog now. With statuscache enabled the number of log entries is about 10 times higher than without. I understand that others may want those logs at the DEBUG level, it's only a problem in my situation. Don't you also get a ton of transaction log messages, regardless of the statuscache code? -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus IMAPd 2.3.12p1 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.12p1. This release should be considered production quality. The only change from 2.3.12 is a patch to fix a memory corruption in the imapd.conf parsing code which could cause segfaults on certain platforms. Noteworthy changes from 2.3.11: * Added statuscache.db to cache IMAP STATUS data which significantly reduces the amount of I/O necessary when neither the mailbox nor \Seen state has changed -- courtesy of Fastmail.fm * Added option to unexpunge to restore messages by time interval -- courtesy of David Carter * Implemented undocumented IMAP SCAN extension, which allows Pine/Alpine to do cross-mailbox searches -- based on work of David Carter * Implemented incremental squat updates (see squatter.8) -- courtesy of David Carter * Fixed major bugs in reconstruct -k implementation -- courtesy of David Carter For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12p1.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12p1.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or [EMAIL PROTECTED] -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus IMAPd 2.3.12p2 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.12p2. This release should be considered production quality. I was careless in applying the memory corruption patch in 2.3.12p1 and it didn't actually solve the problem. It should be fixed now. Noteworthy changes from 2.3.11: * Added statuscache.db to cache IMAP STATUS data which significantly reduces the amount of I/O necessary when neither the mailbox nor \Seen state has changed -- courtesy of Fastmail.fm * Added option to unexpunge to restore messages by time interval -- courtesy of David Carter * Implemented undocumented IMAP SCAN extension, which allows Pine/Alpine to do cross-mailbox searches -- based on work of David Carter * Implemented incremental squat updates (see squatter.8) -- courtesy of David Carter * Fixed major bugs in reconstruct -k implementation -- courtesy of David Carter For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12p2.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12p2.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or [EMAIL PROTECTED] -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
Cyrus IMAPd 2.3.12 Released
I am pleased to announce the release of Cyrus IMAPd 2.3.12. This release should be considered production quality. Noteworthy changes: * Added statuscache.db to cache IMAP STATUS data which significantly reduces the amount of I/O necessary when neither the mailbox nor \Seen state has changed -- courtesy of Fastmail.fm * Added option to unexpunge to restore messages by time interval -- courtesy of David Carter * Implemented undocumented IMAP SCAN extension, which allows Pine/Alpine to do cross-mailbox searches -- based on work of David Carter * Implemented incremental squat updates (see squatter.8) -- courtesy of David Carter * Fixed major bugs in reconstruct -k implementation -- courtesy of David Carter For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. URLs for this release: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12.tar.gz Questions and comments can be directed to info-cyrus@lists.andrew.cmu.edu (public list), or [EMAIL PROTECTED] -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12 Released
Is this a clean build and a fresh restart? Antoine Jacoutot wrote: On Mon, 21 Apr 2008, Ken Murchison wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12. This release should be considered production quality. I'm getting a regression here: (gdb) run Starting program: /usr/local/libexec/cyrus-imapd/master Program received signal SIGSEGV, Segmentation fault. 0x0040773c in config_read_file (filename=0x44df /etc/imapd.conf) at libconfig.c:347 347 libconfig.c: No such file or directory. in libconfig.c This is on OpenBSD-current (tested on different archs with different configurations. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Cyrus IMAPd 2.3.12 Released
Antoine Jacoutot wrote: On Mon, 21 Apr 2008, Ken Murchison wrote: I am pleased to announce the release of Cyrus IMAPd 2.3.12. This release should be considered production quality. I'm getting a regression here: (gdb) run Starting program: /usr/local/libexec/cyrus-imapd/master Program received signal SIGSEGV, Segmentation fault. 0x0040773c in config_read_file (filename=0x44df /etc/imapd.conf) at libconfig.c:347 347 libconfig.c: No such file or directory. in libconfig.c This is on OpenBSD-current (tested on different archs with different configurations. I don't have an OpenBSD system to test on, and I don't have any problem on Linux or Solaris. I'd be happy to accept a patch if you can find the problem. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Patch to avoid mailboxesdb corruption on concurrent renames
Bron Gondwana wrote: On Fri, Apr 04, 2008 at 07:10:27AM -0400, Ken Murchison wrote: Bron Gondwana wrote: Bron ( P.S. isn't it about time for a 2.3.12? I'm getting sick of posting skiplist patches to people running the lastest and having issues! ) Yes, it probably is. Perhaps I'll make a pre-release today while I troll bugzilla for any showstoppers. That would be nice. Also, I'll check it against our patch list and see if there's anything bugfixy in there that I haven't pushed to you yet. By the way - would you prefer me to push things through Bugzilla? So far I've just been posting patches to the mailing list, but I'm happy to use whatever process is easiest for you. If you use bugzilla, its a lot less likely that I won't forget it. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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: Sync_client error Hit upload limit 0
Bron Gondwana wrote: On Wed, Apr 02, 2008 at 07:19:07AM -0400, Ken Murchison wrote: Bron Gondwana wrote: On Wed, Apr 02, 2008 at 09:51:50PM +1100, Bron Gondwana wrote: On Wed, Apr 02, 2008 at 11:28:07AM +1030, Stephen Carr wrote: I get the following type of error (see below) during replication that appeared after upgrading from 2.3.8 to 2.3.11. BAH - upload_messages_from() is broken. Will reply shortly with a patch, Ken - CCing you on this one since you'll want this for CVS. I have compile tested this - haven't rolled it out anywhere, but it's pretty trivial. I understand the missing check for max_count's value, but is there a reason why you're not checking that its negative? unsigned Ah, right. Since config_getint() returns signed, we should probably make max_count signed -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University 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
