When we added calendaring support to FastMail, we placed all the iMIP processing externally in our perl middleware rather than using the Cyrus server.
One of the reasons for this was to support our multiple-personality disorder. FastMail has Personalities (found under "Accounts" in our settings screens) which allow you to set up different signatures, full name and of course email address. They are generally used for aliases on our system, but can also be used for addresses that redirect to you via forwarding services, or which are sluped in by our POP3 fetching daemon. To determine which personality is being used for a particular message, we first try the default personality, then any other explicit personality, then any catchall personality (*@example.com). The first match in @Attendees becomes the "IsYou". And (bug alert!) the Organizer gets calculated separately, so we have events with an IsYou in the Attendees and a different Organizer who also matches IsYou. We'll fix that one today at least... We store this fact as an X-FM-IsYou property on the attendee and organizer in the vcard. Anyway, there is a problem once you mix in CalDAV, because the client doesn't know which address "IsYou". We'll get better at this by setting the calendar-user-address-set and displayname properties on the principal whenever the Default Personality is changed, so that clients at least share the same default value with our interface. But the problem comes with deleting events and sending cancels. If the cancel is coming from Cyrus, then it doesn't know which personality to send from. THE PLAN[tm] ============ I'm going to create a per message annotation on the event resource at the point at which a scheduling response is made - either by the web interface or a CalDAV client. >From that point, the server will reject any attempt to make a scheduling >response to any other address for the same resource. So once you've made a >response as one personality, that's it - that's the attendee associated with >that resource forever. Likewise for any organizer which matches the >calendar-address-set or for events created by our interface, the address will >match the organizer and is forced to remain that way forever. We will no longer need or create the X-FM-IsYou property. ===== While I'm at it, we're not going to send scheduling responses for events that are completed (based on the DTEND of the final recurrence). This might get codified into Cyrus, or it might be a filter in the notifyd at FastMail to start off with. -- Bron Gondwana br...@fastmail.fm
