Re: What happened to normalizeuid?

On 01/19/2017 04:04 PM, Bron Gondwana via Info-cyrus wrote: On Fri, 20 Jan 2017, at 03:31, Sebastian Hagedorn via Info-cyrus wrote: --On 19. Januar 2017 um 17:18:06 +0100 Simon Matter wrote: We and others had this as a patch in our RPMs but I think it has never been

Re: Valid annotations and calendar/addressbook "Dispaly Name"

Hi Nic, On 11/01/2016 11:43 AM, Nic Bernstein via Info-cyrus wrote: Friends, Further questions for our effort to abandon our aging DaviCal server. How does one set the Display Name for a collection in Cyrus? Is this handled via annotations? We can see from the sources (annotate.h, line

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

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

Re: cyradm "info" behavior after cyrus-imapd-2.3.16 -> 2.5.9 upgrade

Are you sure that you are using the cyradm from 2.5.9? IIRC, older cyradm doesn't like the responses sent by 2.5.x servers. On 08/26/2016 10:47 AM, Tod A. Sandman via Info-cyrus wrote: I noticed after upgrading from cyrus-imapd-2.3.16 to cyrus-imapd-2.5.9 that the "info" cyradm command no

Re: 2.5.9 build issues

I'm guessing we should steal json_support.h from master and add it to the 2.5 branch. On 08/20/2016 10:40 AM, Wolfgang Breyha via Info-cyrus wrote: After modifying my spec file from 2.5.8 to 2.5.9 I ended up with two new issues: *) jcal.c can't be compiled with jansson < 2.7 (eg. every RHEL)

Re: thread=refs

INTERNALDATE throughout. On 07/12/2016 04:44 PM, Ken Murchison via Info-cyrus wrote: Gabriele, The attached patch is what I was thinking in terms of implementation. It skips the grouping by subject for REFS, but I didn't do the REFS-specific date ha

Re: thread=refs

n 07/12/2016 04:44 PM, Ken Murchison via Info-cyrus wrote: Gabriele, The attached patch is what I was thinking in terms of implementation. It skips the grouping by subject for REFS, but I didn't do the REFS-specific date handling. Contrary to what the THREAD=REFS draft

Re: thread=refs

are still sorted by SENTDATE. I confirmed that THREAD=REFERENCES is still correct, but I have nothing to compare THREAD=REFS results to. The current threading in Thunderbird is close, but it might be using INTERNALDATE throughout. On 07/12/2016 04:44 PM, Ken Murchison via Info-cyrus wrote

Re: thread=refs

Gabriele, The attached patch is what I was thinking in terms of implementation. It skips the grouping by subject for REFS, but I didn't do the REFS-specific date handling. Contrary to what the THREAD=REFS draft says, I'm not sure if the special date handling should be done in step 4 or 6.

Re: thread=refs

On 07/08/2016 11:08 AM, Gabriele Bulfon wrote: Ok, sure, but still two issues remain other than the draft: - we need to get rid of subject grouping in REFS, it only brings disorder, merging stuff that is not related I believe that the parameterization of the core functions should be able

Re: thread=refs

Is there an actual RFC? All I find is draft-ietf-morg-inthread-01. Looking at that draft, the only difference between REFS ad REFERENCES is this: THREAD=REFS sorts threads by the most recent INTERNALDATE in each thread, replacing THREAD=REFERENCES step (4). This means that when a

Re: thread=refs

On 07/07/2016 02:03 PM, Gabriele Bulfon via Info-cyrus wrote: I can finally get back to this after so many months! I checked the sources, and I actually see it doesn't look very hard. Looks like: - renaming all functions like "index_thread_ref" into "index_thread_references" - duplicate

Re: httpd/carddav from git sources

> On Jun 29, 2016, at 9:30 AM, Johan Hattne wrote: > > >>> On Jun 29, 2016, at 09:11, Ken Murchison wrote: >>> >>> On Jun 29, 2016, at 8:55 AM, Johan Hattne wrote: >>> >>> Hi Ellie & Ken; >>> On Jun 28, 2016, at 20:47, ellie

Re: httpd/carddav from git sources

> On Jun 29, 2016, at 8:55 AM, Johan Hattne wrote: > > Hi Ellie & Ken; > >> On Jun 28, 2016, at 20:47, ellie timoney wrote: >> >> Hi Johan, >> >>> In the unpatched code, a sasl_http_request_t structure is created on the >>> stack and a pointer to it is

Re: StartTLS log issues

This means that the client didn't present a valid TLS certificate to be used for authentication during the TLS exchange. I'm guessing very few clients are configured for TLS auth, so what you're seeing is normal and nothing to be concerned about. On 05/19/2016 02:05 AM, Johannes Eckhardt

Re: ACL inheritance in Shared Namespace

Unless someone other than me changed the code, ACL inheritance only applies to mailbox creation. Once a mailbox exists, its ACL is independent of all others. On 04/13/2016 12:27 PM, Chris via Info-cyrus wrote: All, is ACL inheritance possible in shared namespace? If I revoke access for

Re: CalDAV / CardDAV issues

The client should be doing the PUT on /dav/addressbooks/... On 03/10/2016 11:01 AM, Vincent DEFERT via Info-cyrus wrote: Hi, I've been struggling for several days to install cyrus-imapd 2.5.7.9 on Ubuntu 15.10. The IMAP part works quite well, but I cannot get CardDAV to work. I use

Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]

Done. On 11/17/2015 03:29 AM, Michael Menge wrote: Hi Ken thanks. Do you intend to patch 2.4.x and 2.5.x ? I am a bit confused by the recent changes of cyrusimap and cyrus.fondation. Is the bugtracker https://bugzilla.cyrusimap.org still used by the project? If yes, you should close

Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]

I committed a revised version just a little while ago: https://git.cyrus.foundation/rI0fd86ca759ffa32e8d22dbdde78ea82d63650827 On 11/16/2015 04:41 AM, Michael Menge via Info-cyrus wrote: Hi, is there anything missing from my side, or something that I can do to help that my patch can be

Re: CalDAV and virtual domains

I haven't done any testing myself, but I *believe* it has been fixed and Fastmail is using virtdomains. I will let Bron confirm. On 11/11/2015 07:00 AM, Andrea Venturoli via Info-cyrus wrote: Hello. What's the status of CardDAV/CalDav and virtual domains? I read some messages about this

Re: caldav and carddav in murder environment?

On 11/11/2015 04:33 AM, Khalid Mehmood via Info-cyrus wrote: Is it possible to enable caldav/carddav support in a murder environment? Yes. We are running it in our Murder at CMU. I highly recommend that you use the 3.x code since its much more robust and had more testing than the

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 03:34 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 21:26 schrieb Ken Murchison: Can you get a backtrace from a lmtpd core dump? if you tell me what to do ;) I am not that experienced in doing that, sorry. Is lmtpd dumping core anywhere? You can look in the directory that

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 03:16 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 20:06 schrieb Dave McMurtrie via Info-cyrus: On Mon, 2015-11-02 at 19:11 +0100, Stefan G. Weichinger via Info-cyrus wrote: Am 2015-11-02 um 14:06 schrieb Stefan G. Weichinger via Info-cyrus: gentoo server here, yesterday I

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 04:33 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 22:28 schrieb Ken Murchison: You shouldn't have to run master in gdb. Do something like this: cd /tmp ulimit -c unlimited /usr/lib64/cyrus/master & Hopefully any lmtpd cores will end up in /tmp they do! how to interpret

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 04:25 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 21:45 schrieb Ken Murchison: On 11/02/2015 03:34 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 21:26 schrieb Ken Murchison: Can you get a backtrace from a lmtpd core dump? if you tell me what to do ;) I am not that

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 04:42 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 22:38 schrieb Ken Murchison: gdb /usr/local/cyrus/lmtpd /tmo/core.XXX (use proper locations) At the (gdb) prompt run the backtrace command (bt) It should give you info that you can post here. tmp # gdb

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 04:58 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 22:53 schrieb Ken Murchison: You could try changing the sievedir option in imapd.conf to something other than where your sieve scripts currently reside. more than 10 hrs of fiddling ... and now mails are getting delivered.

Re: Upgraded cyrus 2.5.6: lmtpd segfaults

On 11/02/2015 04:51 PM, Stefan G. Weichinger wrote: Am 2015-11-02 um 22:47 schrieb Ken Murchison: lmtpd is crashing inside of the sieve code. It looks like its trying to compile a regular expression that appears in the recipient's sieve script. I don't know if this is a bug, a bad sieve