FreeBusy with RFC6638 "Scheduling Extensions to CalDAV": 5.1; Service unavailable

Sat Apr 25 03:19:19 EDT 2020

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:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <C:schedule-response xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
>>   <C:response>
>>     <C:recipient>
>>       <D:href>mailto:xxx at yyy.zzz</D:href>
>>     </C:recipient>
>>     <C:request-status>5.3;No scheduling support for user</C:request-status>
>>     <C:request-status>3.7;Invalid calendar user</C:request-status>
>>   </C:response>
>> </C:schedule-response>
>>
>> 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<POST /dav/calendars/user/aaa%40bbb.xyz/Outbox/ HTTP/1.1
>>>> 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
>>>>
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <C:schedule-response xmlns:C="urn:ietf:params:xml:ns:caldav"
>>>> xmlns:D="DAV:">
>>>>    <C:response>
>>>>      <C:recipient>
>>>>        <D:href>mailto:ttt at bbb.xyz</D:href>
>>>>      </C:recipient>
>>>>      <C:request-status>5.1;Service unavailable</C:request-status>
>>>>    </C:response>
>>>> </C:schedule-response>
>>>
>>>
>>> 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
>>>
>>>