ics works but '$mail_settings['organizer']' in config breaks it in our mail system

[jberanek]

The email confirmation and bookings.ics file works well except bookings.ics says "ORGANIZER;CN="Admin Staff Scheduling System":mailto:mrbs@your.org".
If I uncomment $mail_settings['organizer'] = 'myemail@sfu.ca'; the confirmation email contains two identical files in a zipped attachment, one Unknown <text/calendar>, the second booking.ics and our Zimbra email system does not recognize it as a calendar item. (But they contain the proper "ORGANIZER;CN="Admin Staff Scheduling System":mailto:adminemail@sfu.ca"

Any suggestions for troubleshooting?

MRBS 1.5.0/ MySQL 5.1.54-log/ RedHat 6.7 / PHP: 5.6.3

Reported by: carmean

Original Ticket: mrbs/support-requests/905

[jberanek]

I'll set up a Zimbra client and see if I can reproduce this.

Original comment by: campbell-m

[jberanek]

Well, I can reproduce the problem so I can investigate it.

Original comment by: campbell-m

[jberanek]

Strange. If I create an event in Google calendar and invite somebody from Zimbra, then the event email looks just the same in Zimbra, ie two attachments one being "Unknown <text/calendar>" and the other being a .ics attachment. But if I accept the Google event it then appears in the Zimbra calendar, but if I accept the MRBS event it doesn't. However Zimbra obviously recognises it as an event because it gives me the Accept/Decline options and the booking details are correct.

(If I create an event in Outlook and invite a Zimbra participant it all works seamlessly and I don't even get the Unknown attachment.)

I'll keep investigating.

Original comment by: campbell-m

[jberanek]

If I change line 957 in functions_ical.inc from

              $role = "REQ-PARTICIPANT";

to

              $role = "REQ-PARTICIPANT;RSVP=TRUE";

it seems to fix the problem. Can you try this and see if it fixes the problem you are seeing?

However, I think there's really a bug in Zimbra. As far as I can see from reading RFC 5545 it shouldn't be necessary to have RSVP=TRUE. According to the RFC:

This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the expectation of a reply from the calendar user specified by the property value. This parameter is used by the "Organizer" to request a participation status reply from an "Attendee" of a group-scheduled event or to-do.

If this cures the problem I'll report the bug to Zimbra and also put the circumvention in MRBS, as long as it doesn't fo any harm when using other calendar apps. (I found this by narrowing down the differences between a Google calendar .ics file and an MRBS one. Google seems to put RSVP=TRUE in as a matter of course).

Original comment by: campbell-m

[jberanek]

I've now raised this as a Zimbra bug

Original comment by: campbell-m

[jberanek]

Changing line 957 in functions_ical.inc as suggested does not seem to have any affect in our Zimbra (8.0.7_GA_6021).

(I tried several times in two different directories, and changing minor things in config.inc.php- I assume the location of " $mail_settings['organizer'] = 'email@sfu.ca'; " does not make a difference (though I have it in mail settings, line 304 of 597 lines).

I used to vote for bugs in Zimbra bugzilla- could not find that function.

Many thanks for your help. If you quickly think of any thing else, please suggest it. I appreciate your time (and don't expect you to spend it on Zimbra!).

Original comment by: carmean

Attachments: https://sourceforge.net/p/mrbs/support-requests/_discuss/thread/78833264/3fed/cd4c/attachment/alternate

[jberanek]

A few comments and questions:

(1) I was testing with Zimbra Desktop for Windows 7.2.7 GA_12059, which seems to be the latest version of Zimbra Desktop that you can download. I tried downloading 8.0.7 but that seems to give the server side only. When I filed the bug report there seemed to be later versions of the desktop that one could choose in the version drop-down, but I can't work out how to get hold of them - even so, they didn't include 8.0.7

(2) I guess it's too much of an upheaval/outside your control to upgrade to the latest version of Zimbra (which seems to be 8.6.0) and see if you still get the problem?

(3) I wasn't quite clear from your original description whether everything works OK in some circumstances, and if so when? It seemed that there is some sensitivity to the value of ORGANIZER? If, so can you give more details.

(4) No, it doesn't matter where in the config file $mail_settings['organizer'] comes

(5) Can you post a sample .ics attachment that fails? Obviously remove any sensitive data or replace it by 'xxx' or something, but keep the basic structure there. In particular I did think at one point that Zimbra didn't like the double quoting of the common name, as in 'ORGANIZER;CN="Admin Staff Scheduling System":mailto:mrbs@your.org' - but I couldn't reproduce this. When I was trying to narrow down the differences between a successful Google calendar invitation and an MRBS invitation, that seemed to be one of the differences. Google just uses CN=me@mydomain.com and when I put in a double quoted common name, eg CN="John Doe", which I think is what the RFC says you should do, it failed, but then I couldn't make it do it again.

(6) If you want to see yourself if you can work out what makes the difference then I was using a modified version of the function create_icalendar() in functions_ical.inc and returning a known working invitation (eg a Google calendar invitation) and modifying it to look like a failing MRBS one until I found what broke it. Don't forget to manually change the UID each time you test so that it's unique, otherwise Zimbra will think it's an existing entry. My test code looked like this:

function create_icalendar($method, $components)
{
   $string = 'BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
....
';

  $results = explode("\n", $string);  // Substitute whatever line ending your editor uses instead of \n
  $result = implode(ICAL_EOL, $results);
  $result .= ICAL_EOL;  // Has to end with a CRLF

  $result = ical_fold($result);

  return $result;

}

(7) It's possible that there's a bug in MRBS somewhere and it is producing .ics files that don't conform to the RFC. My experience though is that other calendar apps all have their own quirks when interpreting the RFC and even if MRBS is producing a valid .ics file it may be that Zimbra isn't quite following the RFC. In which case it's usually possible to modify MRBS to keep the calendar app happy - in this case Zimbra.

Original comment by: campbell-m