[CalendarServer-users] Problems with external invites

Mon Oct 7 05:48:51 PDT 2013

Hello Andre,

thanks for the reply!  

'otherdomain.com' is not configured on our server at all, its completely external. We have seen this with several invitations from different systems (exchange, notes, …) 
Everything with *domain.com is configured on our server.

Please find below the body of one invitation that is causing the 403 error (removed ids, mail addresses, names and timestamps):

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:00000000T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:00000000T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="OtherUser01":MAILTO:otheruser01 at otherdomain.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=user01 at domain.com:MAILTO:user01 at domain.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="otheruser02 at otherdomain.com":MAILTO:otheruser02 at otherdomain.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=user03 (user03 at domain.com):MAILTO:user03 at domain.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=user04 (user04 at domain.com):MAILTO:user04 at domain.com
ATTACH:CID:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at otherdomain.com
DESCRIPTION;LANGUAGE=de-DE:sometext in description\n\n
SUMMARY;LANGUAGE=de-DE:summary
DTSTART;TZID=W. Europe Standard Time:20130000T100000
DTEND;TZID=W. Europe Standard Time:20130000T160000
UID:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20130000T105316Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=de-DE:location
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:xxxxxxxxxx
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR

The above is the content of an ics file that was attached to an email. 

Upgrading our server will be the last option at the moment, as there is no guarantee that this will solve our problems and also there is no guarantee that all our configurations
will work the same way after the upgrade. 

Thanks for your help! 
Frank 

On Oct 2, 2013, at 7:56 PM, Andre LaBranche wrote:

> 
> On Sep 18, 2013, at 5:35 AM, Frank Keller <fkeller at datameer.com> wrote:
> 
>> Dear list,
>> 
>> we are running an OSX lion server and using caldav on it. 
>> 
>> Server:
>> 	System Version: 10.7.4 (Build 11E53)
>> 	Kernel: Darwin 11.4.0
>> 	Services: Mail, Open Directory, iCal
>> 
>> Clients are running OSX 10.7.x and 10.8.x
>> 
>> We had problems in the past with errors when refreshing calendars. It happened often that an error message 500 was shown when refreshing, especially if the user had more calendar delegations
>> configured. After a long journey with the the apple support a workaround was mentioned to change the port from 'auto' to '8443' in the server settings for iCal on the client machines. We also changed the
>> refresh rate for calendars from push to a fixed value. It seems that these changes solved the problems with the 500 error. 
> 
> Changing the port would have the effect of allowing the clients to speak directly with Calendar Server, instead of going through the Apache reverse proxy that binds port 443 in OS X Server.
> 
>> Now we are facing a new error when receiving calendar invites as a attached ics file, mainly from outside our organization. When opening the attached ics file, an error 403 is shown and it is not possible to 
>> accept the invite. Contacting Apple support again was not successful because they are saying it is a different error and we need to purchase a new support case to get help from them. 
> 
> It does sound like a separate problem.
> 
>> So the question is, can anybody give us a hint on how to solve these issue? Maybe someone already has a fix or a workaround for this error? 
>> If you need any further information, please let me know. 
> 
> From your debug error.log, I think the problem is:
> 
> 2013-09-16 21:25:16+0200 [-] [caldav-3]  [-] [twistedcaldav.directory.principal#debug] No principal for calendar user address: 'mailto:someuser at otherdomain.com'
> 
> That is a correctly formed obfuscation of the actual mailto: URI, however if the real version was somehow invalid, that might cause this error. Also, if 'otherdomain.com' is at all related to your server's domain, or if you have any local users with that email address in their user record, that might be related. In that case, try receiving an invitation with a CalDAV account that has no email address configured (in it's OS X Server user record), to see if it works.
> 
> It's also possible that the incoming invitation is somehow invalid; we've seen this before. All calendar invitations are not created equal. We'd need to see the full body of the invitation attachment received by email to know for sure. Try receiving email invitations from other sources, for example iCloud. This seems not too likely given that the invitation has to be parsed correctly to get to the error you received.
> 
> Another possibility is that it's our bug and we fixed it, but you're still running Lion Server so you don't have the fix. Yet another possibility is that it's our bug but we haven't fixed it because nobody has filed it. In this case, we'd need a bug to be filed so we can get all the info we need to determine what's going on; and you would need to be prepared to upgrade in order to get any fixes that are made. In general, the only fixes you get in a previous major version are security fixes. For the same reason, filing bugs against a previous major version isn't usually terribly helpful, because that's the point of upgrades: things change, so a problem report on an old version isn't as useful as a problem report against the current version. In this case, the machinery behind email invitations didn't change *that* much since Lion Server, so we may be able to come to a resolution with your report after a little back and forth.
> 
> HTH,
> -dre
> 
>> 
>> Any help would be appreciated. 
>> 
>> Best Regards
>> Frank 
>> _______________________________________________
>> calendarserver-users mailing list
>> calendarserver-users at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20131007/3cb6956f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20131007/3cb6956f/attachment.sig>