From me at anatoli.ws Tue Apr 14 22:22:54 2020 From: me at anatoli.ws (Anatoli) Date: Tue, 14 Apr 2020 23:22:54 -0300 Subject: FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable Message-ID: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> Hi All, I'm experimenting with freebusy support in Cyrus paired with Thunderbird. The manual [1] details the freebusy URL functionality and it works correctly (if retrieved manually). But TB, AFAICU, doesn't support it. Instead, it supports rfc6638 "Scheduling Extensions to CalDAV" (https://wiki.mozilla.org/Lightning_implementing_RFC6638). The Cyrus documentation doesn't say explicitly if any of this is supported, but when enabled: httpmodules: webdav caldav freebusy ischedule I can't make Cyrus return the correct info. Instead it replies with "5.1;Service unavailable" (below goes an example exchange). Is this rfc supported? If yes, why may it not work as expected? I'm testing it now with v3.0.5 as this is what I have at one deployment. I can update it if there were relevant changes in later versions. Thanks, Anatoli [1] https://www.cyrusimap.org/dev/imap/download/installation/http/caldav.html#freebusy-url <15869141701586914170>HTTP/1.1 200 OK Date: Wed, 15 Apr 2020 01:29:30 GMT Strict-Transport-Security: max-age=600 Cache-Control: no-cache Content-Type: application/xml; charset=utf-8 Content-Length: 317 mailto:ttt at bbb.xyz 5.1;Service unavailable From murch at fastmail.com Wed Apr 15 08:31:34 2020 From: murch at fastmail.com (Ken Murchison) Date: Wed, 15 Apr 2020 08:31:34 -0400 Subject: FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable In-Reply-To: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> References: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> Message-ID: On 4/14/20 10:22 PM, Anatoli wrote: > Hi All, > > I'm experimenting with freebusy support in Cyrus paired with Thunderbird. > > The manual [1] details the freebusy URL functionality and it works > correctly (if retrieved manually). But TB, AFAICU, doesn't support it. > Instead, it supports rfc6638 "Scheduling Extensions to CalDAV" > (https://wiki.mozilla.org/Lightning_implementing_RFC6638). > > The Cyrus documentation doesn't say explicitly if any of this is > supported, but when enabled: > > httpmodules: webdav caldav freebusy ischedule > > I can't make Cyrus return the correct info. Instead it replies with > "5.1;Service unavailable" (below goes an example exchange). > > Is this rfc supported? If yes, why may it not work as expected? I'm > testing it now with v3.0.5 as this is what I have at one deployment. I > can update it if there were relevant changes in later versions. > > Thanks, > Anatoli > > [1] > https://www.cyrusimap.org/dev/imap/download/installation/http/caldav.html#freebusy-url > > > <1586914170 Accept: text/xml > Content-type: text/calendar; charset=utf-8 > Connection: keep-alive > Accept-charset: utf-8,*;q=0.1 > Recipient: mailto:ttt at bbb.xyz > Content-length: 396 > Host: mail.bbb.xyz > User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 > Thunderbird/60.9.1 Lightning/6.2.5 > Pragma: no-cache > Originator: mailto:aaa at bbb.xyz > Accept-language: en-GB,en;q=0.5 > Authorization: Basic ... > Cache-control: no-cache > Accept-encoding: gzip, deflate, br > > BEGIN:VCALENDAR > PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN > VERSION:2.0 > METHOD:REQUEST > BEGIN:VFREEBUSY > DTSTAMP:20200415T012930Z > ORGANIZER:mailto:aaa at bbb.xyz > DTSTART:20200417T030000Z > DTEND:20200503T030000Z > UID:e7381fb8-f437-4772-b0ec-b019b909c50f > ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail > to:ttt at bbb.xyz > END:VFREEBUSY > END:VCALENDAR >> 1586914170>HTTP/1.1 200 OK > Date: Wed, 15 Apr 2020 01:29:30 GMT > Strict-Transport-Security: max-age=600 > Cache-Control: no-cache > Content-Type: application/xml; charset=utf-8 > Content-Length: 317 > > > > > > mailto:ttt at bbb.xyz > > 5.1;Service unavailable > > This response looks like Cyrus thinks that ttt at bbb.xyz is a remote user and is trying to send the free/busy request over email. Try adding the following option to imapd.conf: calendar_user_address_set: bbb.xyz -- Ken Murchison Cyrus Development Team Fastmail US LLC From me at anatoli.ws Wed Apr 15 18:27:40 2020 From: me at anatoli.ws (Anatoli) Date: Wed, 15 Apr 2020 19:27:40 -0300 Subject: FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable In-Reply-To: References: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> Message-ID: <67c84c6d-a0fc-2b0c-c254-59454fdd6af3@anatoli.ws> Ken, Thanks for the explanation, it was part of the problem! Now I get this reply: mailto:xxx at yyy.zzz 5.3;No scheduling support for user 3.7;Invalid calendar user And the user is also on the server. Even more, it returns the same for the same user that makes the request. At the same time, the freebusy URL returns the scheduling info correctly for any user on the system. What could be wrong now? Thanks, Anatoli On 15/4/20 09:31, Ken Murchison wrote: > > On 4/14/20 10:22 PM, Anatoli wrote: >> Hi All, >> >> I'm experimenting with freebusy support in Cyrus paired with Thunderbird. >> >> The manual [1] details the freebusy URL functionality and it works >> correctly (if retrieved manually). But TB, AFAICU, doesn't support it. >> Instead, it supports rfc6638 "Scheduling Extensions to CalDAV" >> (https://wiki.mozilla.org/Lightning_implementing_RFC6638). >> >> The Cyrus documentation doesn't say explicitly if any of this is >> supported, but when enabled: >> >> httpmodules: webdav caldav freebusy ischedule >> >> I can't make Cyrus return the correct info. Instead it replies with >> "5.1;Service unavailable" (below goes an example exchange). >> >> Is this rfc supported? If yes, why may it not work as expected? I'm >> testing it now with v3.0.5 as this is what I have at one deployment. I >> can update it if there were relevant changes in later versions. >> >> Thanks, >> Anatoli >> >> [1] >> https://www.cyrusimap.org/dev/imap/download/installation/http/caldav.html#freebusy-url >> >> >> >> <1586914170> Accept: text/xml >> Content-type: text/calendar; charset=utf-8 >> Connection: keep-alive >> Accept-charset: utf-8,*;q=0.1 >> Recipient: mailto:ttt at bbb.xyz >> Content-length: 396 >> Host: mail.bbb.xyz >> User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 >> Thunderbird/60.9.1 Lightning/6.2.5 >> Pragma: no-cache >> Originator: mailto:aaa at bbb.xyz >> Accept-language: en-GB,en;q=0.5 >> Authorization: Basic ... >> Cache-control: no-cache >> Accept-encoding: gzip, deflate, br >> >> BEGIN:VCALENDAR >> PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN >> VERSION:2.0 >> METHOD:REQUEST >> BEGIN:VFREEBUSY >> DTSTAMP:20200415T012930Z >> ORGANIZER:mailto:aaa at bbb.xyz >> DTSTART:20200417T030000Z >> DTEND:20200503T030000Z >> UID:e7381fb8-f437-4772-b0ec-b019b909c50f >> ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail >> >> ? to:ttt at bbb.xyz >> END:VFREEBUSY >> END:VCALENDAR >>> 1586914170>HTTP/1.1 200 OK >> Date: Wed, 15 Apr 2020 01:29:30 GMT >> Strict-Transport-Security: max-age=600 >> Cache-Control: no-cache >> Content-Type: application/xml; charset=utf-8 >> Content-Length: 317 >> >> >> > xmlns:D="DAV:"> >> ?? >> ???? >> ?????? mailto:ttt at bbb.xyz >> ???? >> ???? 5.1;Service unavailable >> ?? >> > > > This response looks like Cyrus thinks that ttt at bbb.xyz is a remote user > and is trying to send the free/busy request over email. > > Try adding the following option to imapd.conf: > > calendar_user_address_set: bbb.xyz > > From me at anatoli.ws Tue Apr 21 06:20:21 2020 From: me at anatoli.ws (Anatoli) Date: Tue, 21 Apr 2020 07:20:21 -0300 Subject: FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable In-Reply-To: <67c84c6d-a0fc-2b0c-c254-59454fdd6af3@anatoli.ws> References: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> <67c84c6d-a0fc-2b0c-c254-59454fdd6af3@anatoli.ws> Message-ID: Ken, I was checking imap/http_caldav_sched.c. There are these lines: 921 /* XXX - BROKEN WITH DOMAIN SPLIT, POS */ 922 /* Check ACL of ORGANIZER on attendee's Scheduling Inbox */ 923 snprintf(mailboxname, sizeof(mailboxname), 924 "user.%s.%s.Inbox", userid, calendarprefix); 925 926 r = mboxlist_lookup(mailboxname, NULL, NULL); 927 if (r) { 928 syslog(LOG_INFO, "mboxlist_lookup(%s) failed: %s", 929 mailboxname, error_message(r)); 930 xmlNewChild(resp, NULL, BAD_CAST "request-status", 931 BAD_CAST REQSTAT_REJECTED); 932 } And later there's one more request-status error reply that together with the one from line 930 match the reply I'm getting (in my previous mail below). And in the log the error message appears (result of the line 928): mboxlist_lookup(user.aaa at bbb.ccc.#calendars.Inbox) failed: Mailbox does not exist But in cyradm the mailbox actually exists, though it has the following format: user/aaa/#calendars/Inbox at bbb.ccc. Could the problem be that the format of the path of the mailbox differs from the path of the lookup? It looks like the XXX comment implies exactly this. And then I'm not sure iSchedule also requires special permissions for the lookup, like freebusy URL service. Could you please give your feedback on all this? Regards, Anatoli On 15/4/20 19:27, Anatoli wrote: > Ken, > > Thanks for the explanation, it was part of the problem! Now I get this > reply: > > > > > > mailto:xxx at yyy.zzz > > 5.3;No scheduling support for user > 3.7;Invalid calendar user > > > > And the user is also on the server. Even more, it returns the same for > the same user that makes the request. At the same time, the freebusy URL > returns the scheduling info correctly for any user on the system. > > What could be wrong now? > > Thanks, > Anatoli > > On 15/4/20 09:31, Ken Murchison wrote: >> >> On 4/14/20 10:22 PM, Anatoli wrote: >>> Hi All, >>> >>> I'm experimenting with freebusy support in Cyrus paired with Thunderbird. >>> >>> The manual [1] details the freebusy URL functionality and it works >>> correctly (if retrieved manually). But TB, AFAICU, doesn't support it. >>> Instead, it supports rfc6638 "Scheduling Extensions to CalDAV" >>> (https://wiki.mozilla.org/Lightning_implementing_RFC6638). >>> >>> The Cyrus documentation doesn't say explicitly if any of this is >>> supported, but when enabled: >>> >>> httpmodules: webdav caldav freebusy ischedule >>> >>> I can't make Cyrus return the correct info. Instead it replies with >>> "5.1;Service unavailable" (below goes an example exchange). >>> >>> Is this rfc supported? If yes, why may it not work as expected? I'm >>> testing it now with v3.0.5 as this is what I have at one deployment. I >>> can update it if there were relevant changes in later versions. >>> >>> Thanks, >>> Anatoli >>> >>> [1] >>> https://www.cyrusimap.org/dev/imap/download/installation/http/caldav.html#freebusy-url >>> >>> >>> >>> <1586914170>> Accept: text/xml >>> Content-type: text/calendar; charset=utf-8 >>> Connection: keep-alive >>> Accept-charset: utf-8,*;q=0.1 >>> Recipient: mailto:ttt at bbb.xyz >>> Content-length: 396 >>> Host: mail.bbb.xyz >>> User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 >>> Thunderbird/60.9.1 Lightning/6.2.5 >>> Pragma: no-cache >>> Originator: mailto:aaa at bbb.xyz >>> Accept-language: en-GB,en;q=0.5 >>> Authorization: Basic ... >>> Cache-control: no-cache >>> Accept-encoding: gzip, deflate, br >>> >>> BEGIN:VCALENDAR >>> PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN >>> VERSION:2.0 >>> METHOD:REQUEST >>> BEGIN:VFREEBUSY >>> DTSTAMP:20200415T012930Z >>> ORGANIZER:mailto:aaa at bbb.xyz >>> DTSTART:20200417T030000Z >>> DTEND:20200503T030000Z >>> UID:e7381fb8-f437-4772-b0ec-b019b909c50f >>> ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail >>> >>> ? to:ttt at bbb.xyz >>> END:VFREEBUSY >>> END:VCALENDAR >>>> 1586914170>HTTP/1.1 200 OK >>> Date: Wed, 15 Apr 2020 01:29:30 GMT >>> Strict-Transport-Security: max-age=600 >>> Cache-Control: no-cache >>> Content-Type: application/xml; charset=utf-8 >>> Content-Length: 317 >>> >>> >>> >> xmlns:D="DAV:"> >>> ?? >>> ???? >>> ?????? mailto:ttt at bbb.xyz >>> ???? >>> ???? 5.1;Service unavailable >>> ?? >>> >> >> >> This response looks like Cyrus thinks that ttt at bbb.xyz is a remote user >> and is trying to send the free/busy request over email. >> >> Try adding the following option to imapd.conf: >> >> calendar_user_address_set: bbb.xyz >> >> From me at anatoli.ws Tue Apr 21 15:06:44 2020 From: me at anatoli.ws (Anatoli) Date: Tue, 21 Apr 2020 16:06:44 -0300 Subject: IMAP NOTIFY (RFC 5465) ? In-Reply-To: References: Message-ID: <804d298f-5b42-fc78-efb4-0e7ede2dd7e1@anatoli.ws> ?????, Is there any IMAP NOTIFY capable client? Have you investigated it further? And AFAIK notifyd is for another purpose (incomplete in the opensource version, but used for things like push notifications which are under NDAs from Apple). Regards, Anatoli On 4/3/20 10:39, ????? ???????? wrote: > Hello, > > is RFC 5465 (IMAP NOTIFY (https://tools.ietf.org/html/rfc5465.html) supported in 3.0 as stated at > https://www.cyrusimap.org/imap/rfc-support.html ? > > Per RFC 5465 page 7, the server-side support is announced with ? S: * OK [CAPABILITY IMAP4REV1 NOTIFY]?. The CAPABILITY > answer is generated in imap/imapd.c using ?static struct capa_struct base_capabilities[]? in capa_response(). The > latter contains no code to generate NOTIFY. > > Moreover, the event_notifier in imapd.conf suggests utilizing it for EVENT NOTIFICATIONS,but the possible options for > notifyd(8) https://www.cyrusimap.org/imap/reference/manpages/systemcommands/notifyd.html are null, log, mailto, zephyr > and external: none of which is applicable to IMAP NOTIFY as substitution of IMAP IDLE. > > That leaves me with the impression that the documentation is misleading about IMAP NOTIFY support. > > Greetings > ????? > From dilyan.palauzov at aegee.org Thu Apr 23 07:53:32 2020 From: dilyan.palauzov at aegee.org (=?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?=) Date: Thu, 23 Apr 2020 11:53:32 +0000 Subject: cyrus-devel@lists.andrew.cmu.edu does not do DMARC From-mungling Message-ID: <66d2315054f326c5774857d0c1d11bb4f244b1ae.camel@aegee.org> Hello, recently on this mailing list (cyrus-devel at lists.andrew.cmu.edu) there were messages From: Anatoli . For that domain DMARC policy=reject applies. So the MLM is supposed to mungle the From: domain, but it does not do so. In turns the emails from that recepient over the mailing are subject to reject at the final mailboxes. It is pure accident that I found this out (just seeing replies from Ken to emails which I have not received, more emails in the online archives, which I have not received; generated DMARC failure reports, which were sent nowhere, as the DMARC report has no rua= and ruf= tags). I can offer mailing list hosting at @lists.aegee.org with DMARC mungling for free. RFC 5465 IMAP NOTIFY capable client is Gnome Evolution: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/183#note_730696 Greetings Dilyan From seb2lille at gmail.com Thu Apr 23 12:56:31 2020 From: seb2lille at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Michel?=) Date: Thu, 23 Apr 2020 18:56:31 +0200 Subject: IMAP NOTIFY (RFC 5465) ? In-Reply-To: References: Message-ID: Hi, Le mer. 4 mars 2020 ? 14:40, ????? ???????? a ?crit : > > Hello, > > is RFC 5465 (IMAP NOTIFY (https://tools.ietf.org/html/rfc5465.html) supported in 3.0 as stated at > https://www.cyrusimap.org/imap/rfc-support.html ? I don't see any reference to such RFC 5465 in the code source or in the documentation, where do you find it ? Cyrus only supports RFC 5423 Internet Message Store Events (https://tools.ietf.org/html/rfc5423) and this RFC just defines semantics for event notification on mailbox store, it defines no protocol and no content format. When at Worldline we contributed the code for event notification we made the choice of a JSON format based on this RFC. You have to configure event_notifier with a supported notifyd method in imapd.conf to enable this feature. Here we have our own method to publish in kafka topics. But I think it is not what you want because this is not server to client notification but server to server. > Per RFC 5465 page 7, the server-side support is announced with ? S: * OK [CAPABILITY IMAP4REV1 NOTIFY]?. The CAPABILITY > answer is generated in imap/imapd.c using ?static struct capa_struct base_capabilities[]? in capa_response(). The > latter contains no code to generate NOTIFY. > > Moreover, the event_notifier in imapd.conf suggests utilizing it for EVENT NOTIFICATIONS,but the possible options for > notifyd(8) https://www.cyrusimap.org/imap/reference/manpages/systemcommands/notifyd.html are null, log, mailto, zephyr > and external: none of which is applicable to IMAP NOTIFY as substitution of IMAP IDLE. When I worked on event notification at this time I had in mind to prepare the work for implementing IMAP NOTIFY in Cyrus. My opinion is to have a single notification scheme in the source code for EVENT NOTIFICATIONS, for IMAP NOTIFY and for cyrus replication, so avoiding 3 notification schemes. But at this time (pre Cyrus 2.5) the organization of the source code of cyrus was awful and the impact was to huge, and I couldn't do this alone (as an external developper not involved in the community). Regards, S?bastien From ellie at fastmail.com Thu Apr 23 20:19:21 2020 From: ellie at fastmail.com (ellie timoney) Date: Fri, 24 Apr 2020 10:19:21 +1000 Subject: IMAP NOTIFY (RFC 5465) ? In-Reply-To: References: Message-ID: <44a308d8-263f-4396-9522-1eabed9b79c4@www.fastmail.com> On Fri, Apr 24, 2020, at 2:56 AM, S?bastien Michel wrote: > Hi, > > Le mer. 4 mars 2020 ? 14:40, ????? ???????? > a ?crit : > > > > Hello, > > > > is RFC 5465 (IMAP NOTIFY (https://tools.ietf.org/html/rfc5465.html) supported in 3.0 as stated at > > https://www.cyrusimap.org/imap/rfc-support.html ? > > I don't see any reference to such RFC 5465 in the code source or in > the documentation, where do you find it ? You don't see it now, because it was already fixed. ????? sent us a pull request to correct it a few days after sending the original mail: https://github.com/cyrusimap/cyrus-imapd/pull/3003 From me at anatoli.ws Sat Apr 25 03:19:19 2020 From: me at anatoli.ws (Anatoli) Date: Sat, 25 Apr 2020 04:19:19 -0300 Subject: FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable In-Reply-To: References: <8e769022-976c-f0d2-6bf2-e489afeade87@anatoli.ws> <67c84c6d-a0fc-2b0c-c254-59454fdd6af3@anatoli.ws> Message-ID: <967ec1b6-a798-65ef-58fe-4f0857723de2@anatoli.ws> Ken, Ellie, After analyzing it more, I discovered that the code mentioned in my previous mail was fixed by Bron in commit df55024a623fd6a8f5da55a2e14774c12cc52550. It was included in 3.1.5, but not in 3.0 branch (3.0.13 still has the broken code). The abovementioned commit fixes the problem and freebusy works as expected (tested by patching and recompiling 3.0.5). The patch applies cleanly (with minimal offsets) in both 3.0.5 and 3.0.13. Ellie, is it possible to cherry-pick the commit for the upcoming 3.0.14 as at this moment it's the latest stable branch and this is rather important bug for those who need freebusy scheduling support? The change itself is rather small. Regards, Anatoli On 21/4/20 07:20, Anatoli wrote: > Ken, > > I was checking imap/http_caldav_sched.c. There are these lines: > > 921 /* XXX - BROKEN WITH DOMAIN SPLIT, POS */ > 922 /* Check ACL of ORGANIZER on attendee's Scheduling Inbox */ > 923 snprintf(mailboxname, sizeof(mailboxname), > 924 "user.%s.%s.Inbox", userid, calendarprefix); > 925 > 926 r = mboxlist_lookup(mailboxname, NULL, NULL); > 927 if (r) { > 928 syslog(LOG_INFO, "mboxlist_lookup(%s) failed: %s", > 929 mailboxname, error_message(r)); > 930 xmlNewChild(resp, NULL, BAD_CAST "request-status", > 931 BAD_CAST REQSTAT_REJECTED); > 932 } > > And later there's one more request-status error reply that together with > the one from line 930 match the reply I'm getting (in my previous mail > below). And in the log the error message appears (result of the line 928): > > mboxlist_lookup(user.aaa at bbb.ccc.#calendars.Inbox) failed: Mailbox does > not exist > > But in cyradm the mailbox actually exists, though it has the following > format: user/aaa/#calendars/Inbox at bbb.ccc. > > Could the problem be that the format of the path of the mailbox differs > from the path of the lookup? It looks like the XXX comment implies > exactly this. > > And then I'm not sure iSchedule also requires special permissions for > the lookup, like freebusy URL service. > > Could you please give your feedback on all this? > > Regards, > Anatoli > > On 15/4/20 19:27, Anatoli wrote: >> Ken, >> >> Thanks for the explanation, it was part of the problem! Now I get this >> reply: >> >> >> >> >> >> mailto:xxx at yyy.zzz >> >> 5.3;No scheduling support for user >> 3.7;Invalid calendar user >> >> >> >> And the user is also on the server. Even more, it returns the same for >> the same user that makes the request. At the same time, the freebusy URL >> returns the scheduling info correctly for any user on the system. >> >> What could be wrong now? >> >> Thanks, >> Anatoli >> >> On 15/4/20 09:31, Ken Murchison wrote: >>> >>> On 4/14/20 10:22 PM, Anatoli wrote: >>>> Hi All, >>>> >>>> I'm experimenting with freebusy support in Cyrus paired with Thunderbird. >>>> >>>> The manual [1] details the freebusy URL functionality and it works >>>> correctly (if retrieved manually). But TB, AFAICU, doesn't support it. >>>> Instead, it supports rfc6638 "Scheduling Extensions to CalDAV" >>>> (https://wiki.mozilla.org/Lightning_implementing_RFC6638). >>>> >>>> The Cyrus documentation doesn't say explicitly if any of this is >>>> supported, but when enabled: >>>> >>>> httpmodules: webdav caldav freebusy ischedule >>>> >>>> I can't make Cyrus return the correct info. Instead it replies with >>>> "5.1;Service unavailable" (below goes an example exchange). >>>> >>>> Is this rfc supported? If yes, why may it not work as expected? I'm >>>> testing it now with v3.0.5 as this is what I have at one deployment. I >>>> can update it if there were relevant changes in later versions. >>>> >>>> Thanks, >>>> Anatoli >>>> >>>> [1] >>>> https://www.cyrusimap.org/dev/imap/download/installation/http/caldav.html#freebusy-url >>>> >>>> >>>> >>>> <1586914170>>> Accept: text/xml >>>> Content-type: text/calendar; charset=utf-8 >>>> Connection: keep-alive >>>> Accept-charset: utf-8,*;q=0.1 >>>> Recipient: mailto:ttt at bbb.xyz >>>> Content-length: 396 >>>> Host: mail.bbb.xyz >>>> User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 >>>> Thunderbird/60.9.1 Lightning/6.2.5 >>>> Pragma: no-cache >>>> Originator: mailto:aaa at bbb.xyz >>>> Accept-language: en-GB,en;q=0.5 >>>> Authorization: Basic ... >>>> Cache-control: no-cache >>>> Accept-encoding: gzip, deflate, br >>>> >>>> BEGIN:VCALENDAR >>>> PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN >>>> VERSION:2.0 >>>> METHOD:REQUEST >>>> BEGIN:VFREEBUSY >>>> DTSTAMP:20200415T012930Z >>>> ORGANIZER:mailto:aaa at bbb.xyz >>>> DTSTART:20200417T030000Z >>>> DTEND:20200503T030000Z >>>> UID:e7381fb8-f437-4772-b0ec-b019b909c50f >>>> ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL:mail >>>> >>>> ? to:ttt at bbb.xyz >>>> END:VFREEBUSY >>>> END:VCALENDAR >>>>> 1586914170>HTTP/1.1 200 OK >>>> Date: Wed, 15 Apr 2020 01:29:30 GMT >>>> Strict-Transport-Security: max-age=600 >>>> Cache-Control: no-cache >>>> Content-Type: application/xml; charset=utf-8 >>>> Content-Length: 317 >>>> >>>> >>>> >>> xmlns:D="DAV:"> >>>> ?? >>>> ???? >>>> ?????? mailto:ttt at bbb.xyz >>>> ???? >>>> ???? 5.1;Service unavailable >>>> ?? >>>> >>> >>> >>> This response looks like Cyrus thinks that ttt at bbb.xyz is a remote user >>> and is trying to send the free/busy request over email. >>> >>> Try adding the following option to imapd.conf: >>> >>> calendar_user_address_set: bbb.xyz >>> >>>