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:otheruse...@otherdomain.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=use...@domain.com:MAILTO:use...@domain.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="otheruse...@otherdomain.com":MAILTO:otheruse...@otherdomain.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=user03 (use...@domain.com):MAILTO:use...@domain.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=user04 (use...@domain.com):MAILTO:use...@domain.com ATTACH:CID:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@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 <fkel...@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:someu...@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@lists.macosforge.org >> https://lists.macosforge.org/mailman/listinfo/calendarserver-users >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
