Calendar spam and calendar abuse originates at the OSI application layer but also travels across multiple application layer technologies through networked hosts.

Best practices used at the various checkpoints that a calendar spam instance encounters within its delivery path are described in clauses that follow.

Calendar spam may be produced by innocent calendar systems when:

• its users were compromised;

• it contains abusive users (such as a free-of-charge hosting provider).

In the latter case, approaches such as automation (“bots”) can exacerbate the issue with the automated creation of free accounts.

Such user accounts can be readily used to create calendar spam events:

1. The malicious user account inserts spam content into a newly created calendar event;

2. The calendar system uses templating to send an email invitation with the calendar event attached;

3. The event content, which contains spam, will be inserted into body of the email.

The “source” calendar system provider should take steps to detect and mitigate such internal abuse, by placing detection mechanisms and automated responses at its calendar system and its email system associated with calendar event delivery.

The source calendar system is where an calendar abuse instance originates from.

The source calendar system can apply the following best practices:

1. abuse detection should be performed, through channels such as:

   1. user interface and input detection, such as user agent checks;

   2. network origination, such as network addresses and IPs; and

   3. user behavior such as click rate.

2. detection of malicious content for typical spam patterns, before event creation and the subsequent sending of email invitations, by checking event content, such as:

   1. subject;

   2. description;

   3. recurrence;

   4. number of attendees; and

   5. links.

A number of potential actions can be invoked once potential spam is detected, such as:

1. deny the sending of the calendar invite;

2. display of errors and feedback at the user interface;

3. alert the owner of the user account in case the user account has been hijacked;

4. application of rate limiting to prevent automated spamming;

5. implement automation detection measures, such as usage of a CAPTCHA prior to sending an invitation; and

6. blocking the user account altogether.

The source electronic mail system is where the calendar system delivers an event invitation to for its forwarding.

The following mitigation measures should be taken at the electronic mail system:

1. abuse detection for SMTP access should be performed based on input, such as:

   1. network patterns of the originator;

   2. DNSBL checks against the originating IP.

2. detection of spam content patterns of the email message, using standard email anti-spam scanning applications:

   1. scanning for malicious content;

   2. detection of blacklisted and/or known phishing URLs.

A number of potential actions can be invoked once potential spam is detected, such as:

1. bounce the email that contains suspected calendar spam;

2. silently discard the email with suspected calendar spam;

3. communicate with the upstream calendar provider to indicate potential abuse; and

4. communicate with downstream email providers who will be receive the potential spam.

Calendar spam events are typically received by recipients in two ways:

1. via email from an external email system; or

2. directly from another account within the same calendar system the recipient resides on.
   

   The case of a same-system account abuse can apply when the calendar system contains compromised accounts.

Calendar spam events originating from a calendar system may be propagated back to its own accounts through different channels, depending on their method of integration, such as:

• from within the calendar system, where the event did not leave the calendar system; or

• delivered through email, where the event was sent by the calendar system to an internal email system, and re-routed back to the originating calendar system.

System providers at the receiving end should therefore take steps to detect and mitigate abuse originating from both external and internal calendar and mail systems.

The following best practices apply:

1. abuse detection for receiving email by analyzing input, such as:

   1. originating network addresses;

   2. content of the mail header and its structure.

2. analysis of email spam content patterns using standard email anti-spam scanning applications, such as through:

   1. checking of DNSBLs; and

   2. checking of URIBLs.

3. checking email header content against internal and external sources, such as:

   1. verification of sender address reputation using the From: address;

   2. detection of known malicious addresses from security advisories;

   3. determining whether the organizer has been whitelisted.

Actions to be taken when potential spam is detected are provided below:

1. bounce the message;

2. silently discard the message;

3. pick out the message into quarantaine;

4. moving the message into the spam folder.

When potential spam is detected, “interaction” (e.g. adding the event to the end-user’s calendar) between the recipient and the sender at the calendar system shall not proceed.

Certain mitigation actions, such as the silent discard of an email, do not provide any feedback to the originating calendar system. This means that there will be no method for the originator of the calendar event to learn of these events and handle them in the case of false positives.

Therefore, these actions should only be taken if the electronic mail system is very certain about the calendar invitation being an abuse instance or spam.

For some of the milder actions (e.g. putting in spam folder), the calendar system should provide options to the recipient user. For example, the recipient user can mark such emails as false positives, and are able to manually insert them into the user’s calendar.

The calendar user application, as part of the “calendar system”, should offer the following functionality relating to calendar abuse:

1. allow the user to delete unwanted events (e.g. “Mark as spam”), without notifying the organizer as normally performed with calendar events;

2. submission of ARF reports to report calendar abuse;

3. store information on how a particular calendar event was inserted into the users calendar (e.g. by tracking the Message-ID attribute), to be able to inform the user such information and provide additional information to the originating calendar system on abuse.

In addition, further actions can be taken to detect calendar spam at the calendar user application, such as:

1. sending an email feedback loop if the original email that carried the calendar invitation and its MailID is still available.

Malicious events can end up in user calendars through shared calendars.

Shared calendars are have a single origin and users are subscribed to its events, and therefore manipulation of the calendar source will impact all its subscribers.

Popular calendars, such as official calendars (e.g. public and bank holidays), schedules of shows and sports teams, are valuable targets for malicious actors.

Disturbingly, very often calendar applications do not allow deletion of such shared events if the subscription is set to “read-only”. This means that malicious events propagated through such calendars may not even be eligible for recipient removal, which adds salt to injury.

The only approach for users of these calendar applications are to unsubscribe the entire calendar, even though all previous events will be deleted from the user’s calendar when unsubscribed. More robust controls are certainly needed for calendar subscribers.