Changes have been made in Git (master):

commit cbceb0a9a2e3c735dbffa31fff072c494756edd4
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Aug 28 15:43:25 2012 -0600

     [mms] Allow certain iCalendar events to be configured to 
automatically update the local user's calendar (Request #11376).

  imp/config/mime_drivers.php  |   32 +++++++++++++++++++++++-
  imp/docs/CHANGES             |    2 +
  imp/lib/Mime/Viewer/Itip.php |   56 +++++++++++++++++++++++++++++++++--------
  imp/package.xml              |    2 +
  4 files changed, 80 insertions(+), 12 deletions(-)

http://git.horde.org/horde-git/-/commit/cbceb0a9a2e3c735dbffa31fff072c494756edd4

What do people think about this implementation?  I added both 
free/busy replies and publish requests also.

Made the config for all three separate since an admin could 
conceivably be ok with 1 or 2 but not all 3 (i.e. solicited free/busy 
= ok; unsolicited [PUBLISH] free/busy = not ok).

Changes have been made in Git (develop):

commit cbceb0a9a2e3c735dbffa31fff072c494756edd4
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Tue Aug 28 15:43:25 2012 -0600

     [mms] Allow certain iCalendar events to be configured to 
automatically update the local user's calendar (Request #11376).

  imp/config/mime_drivers.php  |   32 +++++++++++++++++++++++-
  imp/docs/CHANGES             |    2 +
  imp/lib/Mime/Viewer/Itip.php |   56 +++++++++++++++++++++++++++++++++--------
  imp/package.xml              |    2 +
  4 files changed, 80 insertions(+), 12 deletions(-)

http://git.horde.org/horde-git/-/commit/cbceb0a9a2e3c735dbffa31fff072c494756edd4

This was a potential solution that the client and I have discussed.   
Although I would disagree with the idea that it is "trivial" to 
prevent users from forging sender addresses.  Imagine an organization 
like a university that may have 100,000+ users, and these users may be 
in a variety of differently admin'd local networks (e.g. Physics 
department, Economics department, etc.).  Additionally, the 
e-mail/user the invite was sent to may not match the responding user 
(e.g. sent to slusarz@example.com but my mail is sent from 
Michael.Slusarz@department.example.com) so forging addresses becomes a 
more complicated situation.
That being said, I would agree that we should provide an option for 
the admin to allow auto-accepting of e-mails from within the same 
domain.  Or better still, allow the admin to provide a list of domains 
to auto-accept from.

That depends. Within an organization (for "local" addresses) it is 
trivial to prevent users from forging sender addresses. In that case 
there is no attack vector, since people will not be able to forge 
replies. But this is only the case for addresses we know are local, 
replies from external (non-local) users should probably never be 
auto-accepted. At the very least, there should be an option to treat 
local and non-local users differently.

I was originally going to suggest to put this in mime_drivers.php and 
make it a fully admin-based preference choice.  But I could see how 
some users would NOT want this as the default, even if an admin allows 
it, so it does make sense as a vanilla pref.  For security reasons, 
this should be a locked preference that is set to no auto-accept by 
default.
Sure.  An attacker needs to at least know the information that an 
event exists and the details of the event, so that rules out random 
auto-sent e-mails from being a concern.

But within a user's group of contacts (especially if an event has many 
potential attendees), this information is not difficult to obtain.  So 
it's not a tremendously difficult attack either.

I have considered this a few times already and never came to a final 
conclusion either. I share the same concerns, OTOH this a common 
feature of so called enterprise groupware solutions. I'm with Mike 
that we should implement this as a preference and lock it down as far 
as possible.

I actually wanted to implement this in the ActiveSync code that 
handles invitations as well. I didn't do this for the same reason (and 
the fact that it wouldn't be consistent with what the user currently 
expects from using Horde). Exchange *does* do this, but, if I 
understand correctly, only for responses from "local" exchange users.

I would really like this feature though since it would complete our 
ActiveSync invitation support (making us the only FOSS groupware that 
supports this completely without relying on MAPI libraries).

What about making this a user controlled pref disabled by default and 
at least performing a check against the From header and the response's 
email field? IMO, it would be a low risk since the malicious user 
would need all of the event details, including the UID, right?

A client would like to see auto-updating of the local calendar when a 
confirmation itip message is received (and read) by the user.   
Apparently, Gmail does this.

I am not comfortable with this because this is the classic "triggering 
an action via unauthenticated data" problem.  The concern is that 
because anybody can send a message accepting (if they have the 
original invite data), there is no guarantee it is from the user you 
originally sent the invite to.

Example: I send an invitation to  foo@example.com. However,   
bar@example.com sends back an acceptance for  foo@example.com. This is 
a case where I know something is up/screwy, so I won't accept that 
invitation and update  foo@example.com's status. Granted,   
bar@example.com will probably cover his tracks better (e.g. forging 
the from address), but this still shows the problem with auto-accepting.

What do people think about this?