Whenever an appointment is created, changed or deleted, the server may send out mails about it — invitations, cancellations, replies, and informational notifications. This article explains, for operators and support, when such a mail is sent and why, what it looks like (who it appears to come from, and whether it is a full iMIP mail or a plain notification), and how configuration and user preferences influence the result.

This is the outgoing counterpart to the iTIP article, which covers the protocol itself and the incoming side (parsing, analyzing and auto-processing received mails). It is also closely related to the Suppress Scheduling Messages section there, which describes the client-side controls referenced below.

Two kinds of outgoing mail

Every outgoing calendar mail is one of two kinds:

• iMIP mail — a full iTIP message: it carries a text/calendar body and an iCalendar (.ics) attachment with a METHOD (e.g. REQUEST, REPLY, CANCEL). This is what other calendaring systems need in order to interoperate, and it is what a recipient's mail/calendar client can act on (accept, decline, import).
• Notification mail — a light-weight informational mail (text + HTML, no iCalendar attachment). It only tells the user what happened; their calendar copy is already kept up to date by the server.

As a rule of thumb: external recipients always get iMIP mails, while internal recipients get notification mails unless configured otherwise (see iMIP vs. notification).

What triggers a mail

Outgoing mails are a side effect of group-scheduled appointment operations that reach the server through either the HTTP API (App Suite UI and other API clients, chronos module) or CalDAV. The relevant operations are:

• creating an appointment with attendees,
• changing an appointment (rescheduling, editing details, adding/removing attendees),
• deleting / cancelling an appointment,
• an attendee changing their participation status (accept / decline / tentative),
• an organizer declining a counter proposal.

Manual iCalendar import does not trigger any messages, and appointments without (other) attendees produce nothing to send.

What contributes to the decision

Several independent inputs decide whether a mail is sent, to whom, and of which kind. They are evaluated together.

1. Which calendar was acted on (the folder view)

The calendar in which the operation happens — and therefore which copy of the event is being acted on — implicitly defines the acting user's role in the event, and that role determines the direction of the messages. Each participant holds their own copy: the organizer holds the organizer copy, every attendee holds an attendee copy. Acting on the organizer copy means acting as the organizer; acting on an attendee copy means acting as that attendee. (For how these copies are stored and kept in sync, see Organizer and Attendee Copies in the implementation details article.)

• The organizer's calendar (organizer view/copy) → the user acts as organizer, so messages go out to the attendees (REQUEST on create/change, CANCEL on delete).
• An attendee's calendar (attendee view/copy) → the user acts as that attendee, so messages go to the organizer as a REPLY (and, for internal appointments, informational replies to the other attendees).

When a user works on behalf of another user — e.g. a secretary acting in a shared calendar, a deputy, or an administrator impersonating a user — the messages are attributed to the calendar owner, while the acting user is recorded as the one who actually performed the action (see Who the mail comes from).

2. Whether the recipient is internal or external

A recipient is internal if they are a user (or resource) in the same context, and external otherwise. This governs two things: external recipients are always notified (their personal notification preferences are unknown to the server) and always receive full iMIP mails; internal recipients are subject to their notification preferences and normally receive notification mails.

The reason external recipients always get iMIP is that the iMIP mail is their only channel: the server keeps the event copies of internal participants in sync automatically, but it has no access to an external participant's calendar. An external attendee's copy is created and kept up to date solely by the iMIP messages they receive — the initial REQUEST establishes their copy, later REQUESTs update it, and a CANCEL removes it. If these messages are suppressed or never delivered, the external participant's calendar will silently drift out of sync, which is why iMIP delivery to external recipients must not be turned off and the sending account must be reliable.

3. The appointment details

• Appointments that end in the past never produce mails. For recurring appointments the end of the whole series is considered (an open-ended series is never "in the past").
• Resource attendees (rooms, equipment) are a special case — see Resources & booking delegates.
• For a change, the kind of change influences the subject and wording (e.g. "New appointment" vs. "Appointment changed").

4. User notification preferences

Internal recipients only receive a mail if their personal notification settings allow it. These are the standard per-user mail notification settings (configurable by the user, and pre-settable by the admin). They never affect external recipients. Their default values are:

• notify when invited to / when an attended appointment is created, changed or deleted — default on,
• notify the organizer when an attendee replies — default on,
• notify other attendees when an attendee replies — default off.

If a recipient has the relevant setting disabled, no mail is sent to them. Note in particular that, by default, attendees are not notified about other attendees' accept/decline replies; only the organizer is.

5. Server configuration

Administrators can influence the outcome through configuration (see the full reference):

• whether internal recipients get full iMIP mails instead of notifications,
• whether internal resource attendees are notified at all,
• whether the no-reply account is used for internal notifications and/or external iMIP mails,
• the no-reply account itself.

6. Client request controls

The client that issues the operation can suppress or scope the messages per request. These are described in detail in the Suppress Scheduling Messages section of the iTIP article; in short:

• Scheduling header (CalDAV) / scheduling parameter (HTTP API): none sends nothing, internal-only skips external recipients, external-only skips internal recipients, all is the default behavior.
• Schedule-Reply: F (CalDAV): suppresses the reply that would otherwise go to the organizer (e.g. when deleting an unsolicited/spam invitation).
• SCHEDULE-AGENT parameter (CalDAV): when set to something other than SERVER (i.e. CLIENT or NONE) on the organizer or an attendee, the server sends no message for that party (the client takes over).

The outcome

iMIP vs. notification

A full iMIP mail is sent in the following cases. The first group is enforced by the server itself, regardless of any configuration; the last case is the only one governed by the useIMipForInternalUsers property:

• Always (independent of configuration):
  1. the recipient is external, or
  2. the mail goes to a resource booking delegate, or
  3. the mail comes from a resource booking delegate, or
  4. the mail is a server-initiated forward of an appointment to someone who is not (yet) a participant.
• By configuration:
  1. the recipient is an ordinary internal user and com.openexchange.calendar.useIMipForInternalUsers is enabled.

In all other cases an internal recipient gets a notification mail.

What the useIMipForInternalUsers property does (and does not) control: the cases in the first group above are enforced programmatically and do not depend on this property — booking-delegate and forward mails are always full iMIP. The property only affects ordinary internal individual recipients, who would otherwise receive a notification mail. Enable it when internal users access their calendars through external/third-party client applications, or to ease manually forwarding received invitations to others. (For the "on behalf" / deputy use case, see the iTIP article.)

Which iTIP method (the METHOD in the .ics)

The server only produces REQUEST, CANCEL, REPLY and DECLINECOUNTER. Other iTIP methods defined by the protocol — ADD, REFRESH, COUNTER, PUBLISH — are not generated. In particular, adding an occurrence (a new exception) to an existing series is not sent as an ADD; client support for ADD is inconsistent, so the server instead sends a regular REQUEST for the whole series.

The subject

The subject is localized to the recipient and reflects what happened, for example:

• new invitation → "New appointment: <summary>"
• change → "Appointment changed: <summary>"
• cancellation → "Appointment canceled: <summary>"
• reply → an accept/decline/tentative-specific subject
• a forwarded invitation → "Fwd: <summary>"

Resource bookings use dedicated variants (e.g. "Resource booking accepted").

Who the mail comes from

Three address-related aspects of the mail matter, and together they express the "on behalf of" relationship:

So for a secretary creating an appointment in their manager's calendar, attendees see From: manager and Sender: secretary. The same relationship appears as the SENT-BY property inside the iCalendar data.

Why From and Sender are set this way. The split follows the standard author-vs.-transmitter distinction of RFC 5322, section 3.6.2: From names the author (here the organizer/attendee the action belongs to), while Sender names "the agent responsible for the actual transmission" — using exactly the secretary-sending-for-another-person example from that section. At the iCalendar layer the same pair is expressed by the SENT-BY parameter (RFC 5545, section 3.2.18, e.g. ORGANIZER;SENT-BY="mailto:secretary":mailto:owner), so the header and the payload stay consistent. Keeping From equal to the organizer also matters for interoperability: although iMIP treats the ORGANIZER/ATTENDEE properties in the iCalendar body as authoritative rather than the headers (RFC 6047, sections 2.2–2.3), receiving systems commonly cross-check the From address against the organizer, so a mismatch looks like spoofing or an unsolicited forward. Reply-To is set to the originator for the same reason — so replies reach the organizer, who is the party that collects them.

Two cases change the sender handling:

• Guest users (e.g. via federated sharing) usually have no access to the calendar owner's mail account, so their scheduling mails are sent through the no-reply account. The mail headers are still filled from the calendar user's data (e.g. From = calendar owner) because iMIP validates them strictly.
• When the no-reply account is used (see below), the Sender header is omitted. The no-reply account is used only as the transport channel — the From header still shows the calendar user and is not replaced by the no-reply address.

Which account sends the mail

Mails are sent either through the user's own mail (SMTP) account or through the shared no-reply account. The no-reply account is used when:

• the acting user is a guest, has no webmail permission, or the session is otherwise not allowed to send mail on the user's behalf (e.g. a restricted app-password session); or
• the operation runs under a synthetic (impersonation) session, which carries no personal mail credentials of its own — except for shared accounts (see Mails from shared accounts); or
• the relevant prefer no-reply property is enabled for the recipient kind (...preferNoReplyForNotifications for internal, ...preferNoReplyForIMip for external).

If sending through the selected account — the user's own account, or a shared account's mail account — fails because it is unavailable or misconfigured, the server automatically falls back to the no-reply account once, so the message can still be delivered. A correctly configured no-reply account is therefore important for reliable delivery.

Mails from shared accounts

When the operation happens in a shared account, the mail is sent through the shared account's own mail (SMTP) account — not the acting user's personal account, and not the no-reply account. It is transported under the acting user's session; how it authenticates against the shared mailbox depends on the shared account's configured secondary-account authentication (authentication type, login source, password source) — depending on the mode this may pass through the acting user's OAuth access token or session password, or use a configured master or per-account password. See Authentication in the shared accounts article for the available modes; note that with an OAuth mode (xoauth2 / oauthbearer) the acting user's session must carry a valid access token. The From header is the shared account in both send modes; only the Sender header differs (see Who the mail comes from):

• send as the shared account — From = shared account, no distinct Sender;
• send on behalf of the shared account — From = shared account, Sender = the acting user.

If the shared account has no mail access (calendar-only), or the acting user's mail session cannot be resolved, the mail is sent through the no-reply account instead (keeping the shared account in the From header); likewise, a failed transport through the shared mailbox is retried once via no-reply, as described above.

Headers visible in the mail

When inspecting an outgoing calendar mail, the following headers can help support:

• X-OX-ITIP — present on all calendar scheduling mails; marks the mail as generated by the App Suite calendar and lets a receiving App Suite recognize its own messages.
• X-Open-Xchange-* (e.g. -Type = "New" / "Modified" / "Deleted" / "Accepted" / "Declined" / …) and X-OX-Reminder — set only for internal recipients; used by the App Suite UI. Their absence on a mail indicates it was addressed to an external recipient (or sent as full iMIP).
• Auto-Submitted: auto-generated — marks the mail as machine-generated so auto-responders don't reply to it.
• Sender — present when someone acted on behalf of another user (see above).
• Sensitivity — added when the appointment's classification is not PUBLIC: Private for a PRIVATE classification and Company-Confidential for a CONFIDENTIAL one (the same mapping Microsoft Outlook uses between its sensitivity indicator and the iCalendar CLASS property). Ordinary (PUBLIC) appointments carry no such header.

Log levels for troubleshooting

When investigating why a message was (or was not) sent, or whether delivery succeeded, raising the log level on the two classes that drive the decision and the transport gives the most insight:

Setting the whole com.openexchange.chronos.scheduling package to DEBUG additionally surfaces the transport details.

Levels can be changed at runtime with the logconf command-line tool, or persistently in logback.xml, e.g.:

<logger name="com.openexchange.chronos.impl.performer.SchedulingHelper" level="TRACE"/>
<logger name="com.openexchange.chronos.scheduling.impl.transport.AllServingTransportProvider" level="DEBUG"/>
<logger name="com.openexchange.chronos.provider.sharedaccount.SharedAccountTransportProvider" level="DEBUG"/>

Note that TRACE on SchedulingHelper can be verbose on busy systems; enable it temporarily and ideally scope it to a single user/context with a logback turbo filter when reproducing a specific case.

Configuration reference

Calendar properties

Defined in calendar.properties; config-cascade-aware and reloadable.

No-reply account

Defined in noreply.properties; required if the no-reply account is used (guests, the prefer no-reply properties, or the delivery fallback).

User notification preferences

The per-recipient notification settings are the standard user mail-notification settings (also pre-settable by the admin). They gate mails to internal recipients only:

• notify on appointment create / change / delete — default on,
• notify the organizer when an attendee replies — default on,
• notify other attendees when an attendee replies — default off.

Resources & booking delegates

Resources (rooms, equipment) get special treatment:

• Whether internal resource attendees receive notification mails is controlled by com.openexchange.calendar.notifyResourceAttendees (default true); external resources are always notified.
• The resource's booking delegates (the users who manage the resource) additionally receive a message about the booking. Mails to and from booking delegates are always sent as full iMIP so the delegate's client can act on the request, and the acting user is recorded as the sender on behalf of the resource.

Quick reference: who gets what

References / further reading

1. iTIP article — protocol background, incoming handling, auto-processing, client-side suppression
2. RFC 5546 iTIP  ·  RFC 6047 iMIP
3. com.openexchange.calendar.* properties
4. com.openexchange.noreply.* properties