No subject

Mon Jan 28 08:41:14 PST 2013

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

--Boundary_(ID_bJvTy9kQhpFrYP5nFK1eiA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Sep 18, 2013, at 5:35 AM, Frank =
Keller &lt;<a =
href=3D"mailto:fkeller at datameer.com">fkeller at datameer.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Dear list,<br><br>we are running an OSX lion server and =
using caldav on it. <br><br>Server:<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>System Version: 10.7.4 (Build =
11E53)<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Kernel: Darwin 11.4.0<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Services: Mail, Open Directory, =
iCal<br><br>Clients are running OSX 10.7.x and 10.8.x<br><br>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<br>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<br>refresh rate for calendars from =
push to a fixed value. It seems that these changes solved the problems =
with the 500 error. <br></blockquote><div><br></div><div>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.</div><br><blockquote type=3D"cite">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&nbsp;<br>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. =
<br></blockquote><div><br></div><div>It does sound like a separate =
problem.</div><br><blockquote type=3D"cite">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?&nbsp;<br>If you need =
any further information, please let me know. =
<br></blockquote><div><br></div><div>=46rom your debug error.log, I =
think the problem is:</div><div><br></div><div>2013-09-16 21:25:16+0200 =
[-] [caldav-3] &nbsp;[-] [twistedcaldav.directory.principal#debug] No =
principal for calendar user address: '<a =
href=3D"mailto:someuser at otherdomain.com">mailto:someuser at otherdomain.com</=
a>'<br></div><div><br></div><div>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 '<a =
href=3D"http://otherdomain.com">otherdomain.com</a>' 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>HTH,</div><div>-dre</div><br><blockquote =
type=3D"cite"><br>Any help would be appreciated. <br><br>Best =
Regards<br>Frank =
<br>_______________________________________________<br>calendarserver-user=
s mailing list<br><a =
href=3D"mailto:calendarserver-users at lists.macosforge.org">calendarserver-u=
sers at lists.macosforge.org</a><br>https://lists.macosforge.org/mailman/list=
info/calendarserver-users<br></blockquote></div><br></body></html>=

--Boundary_(ID_bJvTy9kQhpFrYP5nFK1eiA)--