cc-18003.xml

<?xml version="1.0" encoding="UTF-8"?>
<csd-standard xmlns="https://www.calconnect.org/standards/csd">
<bibdata type="standard">
  <title language="en" format="text/plain">Calendar operator practices — Guidelines to protect against calendar abuse</title>
  <docidentifier type="csd">CC/R 18003:2019</docidentifier>
  <docnumber>18003</docnumber>
  <date type="published">
    <on>2019-01-18</on>
  </date>
  <contributor>
    <role type="author"/>
    <organization>
      <name>CalConnect</name>
    </organization>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      <name>
        <completename>Thomas Schäfer, 1&amp;amp;1 Mail&amp;amp;Media Development and Technology GmbH</completename>
      </name>
    </person>
  </contributor>
  <contributor>
    <role type="author"/>
    <person>
      <name>
        <completename>Jesse Thompson, University of Wisconsin-Madison</completename>
      </name>
    </person>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      <name>CalConnect</name>
    </organization>
  </contributor>
  <edition>1</edition>
  <version>
    <revision-date>2019-01-18</revision-date>
  </version>
  <language>en</language>
  <script>Latn</script>
  <status>
    <stage>published</stage>
  </status>
  <copyright>
    <from>2019</from>
    <owner>
      <organization>
        <name>CalConnect</name>
      </organization>
    </owner>
  </copyright>
  <ext>
    <doctype>report</doctype>
    <editorialgroup>
      <technical-committee>CALSPAM</technical-committee>
    </editorialgroup>
  </ext>
</bibdata>
<preface><foreword obligation="informative"><title>Foreword</title><p id="_f55a5371-eff9-4850-bcff-a36e57fc977e">The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit
organization with the aim of facilitating interoperability of technologies across
user-centric systems and applications.</p>
<p id="_057510d4-8b4b-434c-a67e-83fd1cdb5e49">CalConnect works closely with liaison partners including international
organizations such as ISO, OASIS and M3AAWG.</p>
<p id="_934f338b-dba0-42da-b3a8-952b7bac92e4">The procedures used to develop this document and those intended for its further
maintenance are described in the CalConnect Directives, and in this case, also aligned
with the procedures used at M3AAWG.</p>
<p id="_6547aeb1-18f1-4df5-83ad-b795e7e1b2cd">In particular the different approval criteria needed for the different types of
CalConnect documents should be noted. This document was drafted in accordance with the
editorial rules of the CalConnect Directives.</p>
<p id="_377e6cdd-8c92-40a4-805e-c21f93061b3a">Attention is drawn to the possibility that some of the elements of this
document may be the subject of patent rights. CalConnect shall not be held responsible
for identifying any or all such patent rights. Details of any patent rights
identified during the development of the document will be in the Introduction
and/or on the CalConnect list of patent declarations received (see
www.calconnect.com/patents).</p>
<p id="_95c84a37-fabd-4c88-b378-0b642fc7067b">Any trade name used in this document is information given for the convenience
of users and does not constitute an endorsement.</p>
<p id="_7e303f14-6c96-4f04-9220-787b94e2f6a2">This document was prepared by Technical Committee <em>CALSPAM</em>.</p></foreword><introduction id="_introduction" obligation="informative"><title>Introduction</title><clause id="_rise_of_calendar_spam" obligation="informative"><title>Rise of calendar spam</title><p id="_62286895-024a-4211-b00c-d92bb22de04d">“Calendar spam” — unsolicited, or otherwise unwanted, calendar events and meeting
invitations — is a recently exploited channel for abuse aimed at users of
calendaring &amp; scheduling systems.</p>
<p id="_225c39d9-6000-430d-b56c-ac37db9c38f2">It is a new form of application-specific spam which takes advantage of the application
layer across multiple technologies that spans scheduling, calendaring and messaging
systems.</p>
<p id="_2ba8759b-5bef-4157-8545-e2a302b0a44f">As is the case with email spam, calendar spam is not only used to deliver unwanted
information, but can also be used for malicious purposes such as phishing attempts
and delivering dangerous payloads.</p>
<p id="_4b11da1e-1103-433b-8d30-209fe360ede5">Because calendar events and meeting invitations are often (but not exclusively)
transported and delivered via email, combatting calendar spam requires awareness,
intervention and integration with email systems and services.</p></clause>
<clause id="_impact_of_calendar_spam" obligation="informative"><title>Impact of calendar spam</title><p id="_fe4b7b39-c8ae-4077-88ee-5a027f660e2c">Calendar spam is unique in a number of ways:</p>
<ol id="_a27994f0-924a-4555-98e0-a0ebe854a146" type="arabic">
  <li>
    <p id="_278bd90b-bec1-4a5b-a168-198e2abdabc9">Calendar spam, unlike email, can be placed chronologically anywhere in calendars, in
the past or the future, not just the present, making it difficult for the end-user to
detect at the time of delivery.</p>
  </li>
  <li>
    <p id="_975e588a-a645-4ef6-aa71-8527cb56b263">Spam meeting invitations, may automatically see these unwanted invitations added to
their calendar without their consent, with notifications sent to all their devices.
These invitations are not only difficult to find, but in some cases there is no way for
the user to remove these events short of deleting the entire calendar.</p>
  </li>
  <li>
    <p id="_c6eb0b0f-1c62-40da-b680-3fc7c4c2bd6f">Calendar events and meeting invitations do not yet carry the rich provenance which today
accompanies email (detailed header information), making it difficult to ascertain
where and when events originated and were delivered.</p>
  </li>
  <li>
    <p id="_983ab5ea-9b1d-42bc-9cfd-ac633b26e6b1">Calendar events often contain notifications/alarms which are propagated across
a user’s desktop and mobile calendaring clients. It is common for users to have multiple
calendaring clients which exacerbates the abuse.</p>
  </li>
  <li>
    <p id="_5dcb8c02-df86-41c7-86b5-baf69064b47d">Calendar events can include recurrence meaning that one event can show up in the user’s
calendar multiple times with multiple notifications/alarms being triggered over time.</p>
  </li>
</ol></clause></introduction></preface><sections>

<clause id="_scope" obligation="normative"><title>Scope</title><p id="_0bd7dbae-ecaa-4c14-8c0e-c3aa5563fb86">This document specifies guidelines for calendar and mail system operators to:</p>
<ul id="_adf63c62-7501-4d23-9b5d-f77b775a2190">
  <li>
    <p id="_7bf174b4-650f-40a5-8e0c-6ea7adbf2599">detect the occurrence of calendar abuse;</p>
  </li>
  <li>
    <p id="_ec1a7f7f-f0ca-45df-b393-7b064c3d2900">consider processes and procedures to mitigate calendar abuse; and</p>
  </li>
  <li>
    <p id="_7e15409a-e682-47ea-9879-b224515b52e8">suggest acceptable (non-abusive) practices with calendar usage.</p>
  </li>
</ul></clause>

<clause id="terms" obligation="normative"><title>Terms and definitions</title><p>For the purposes of this document, 
    the following terms and definitions apply.</p>
<terms id="_terms_and_definitions" obligation="normative"><title>Terms and definitions</title><term id="calendar-spam">
  <preferred>calendar spam</preferred>
  <definition><p id="_e5676525-4e1d-46ba-be2b-a18fafbc460c">calendar events and meeting invitations containing <em>spam</em> (<xref target="term-spam"/>) delivered
through <em>calendar systems</em> (<xref target="term-calendar-system"/>)</p></definition>
</term>
<term id="term-calendar-abuse">
  <preferred>calendar abuse</preferred>
  <definition><p id="_e97c5bb5-87f5-4dfc-a88e-a19cd87adcf0">malicious usage of a <em>calendar system</em> (<xref target="term-calendar-system"/>),
possibly leading to an <em>attack</em> (<eref type="inline" bibitemid="ISO27000" citeas="ISO/IEC 27000:2018"><locality type="clause"><referenceFrom>3.2</referenceFrom></locality></eref>)
on the receiving user</p></definition>
</term>
<term id="term-spam">
  <preferred>spam</preferred>
  <definition><p id="_ad6850a6-1aba-4388-8c49-7e3a3ef0647c">unsolicited or unwanted information</p></definition>
</term>
<term id="attack"><preferred>attack</preferred><definition><p id="_8d2ee601-d80f-4d2d-aa7f-57a202ae8e5f">attempt to destroy, expose, alter, disable, steal or gain unauthorized
access to or make unauthorized use of an asset</p></definition>
<termsource status="identical">
  <origin bibitemid="ISO27000" type="inline" citeas="ISO/IEC 27000:2018"/>
</termsource></term>
<term id="term-calendar-system">
  <preferred>calendar system</preferred>
  <definition><p id="_119a28e1-64e1-41ac-933b-807b6fe32a0b">information system that provides calendar and scheduling functionality for user
accounts</p></definition>
</term>
<term id="mail-system">
  <preferred>mail system</preferred>
  <definition><p id="_9c37e89d-7a00-46c6-b64d-be25a0fa2a54">information system that provides electronic mail functionality</p></definition>
</term>
<term id="user-system">
  <preferred>user system</preferred>
  <definition><p id="_c2d5dd26-cd8c-47d7-8e0f-321c512913a8">information system that provides authentication and authorization functionality</p></definition>
</term></terms>
<definitions id="abbrev">
  <title>Abbreviations</title>
  <dl id="_f32e0942-ed1c-4a99-8e2c-fd51047bfa06">
  <dt>iMIP</dt>
  <dd>
    <p id="_595e40f3-3eea-4a69-a88a-c5c9daef1f3c">iCalendar Message-Based Interoperability Protocol (see <eref type="inline" bibitemid="iMIP" citeas="RFC 6047"/>)</p>
  </dd>
  <dt>iTIP</dt>
  <dd>
    <p id="_f8dba07c-4e86-4ad1-b4b3-27042541300d">iCalendar Transport-Independent Interoperability Protocol (see <eref type="inline" bibitemid="iTIP" citeas="RFC 5546"/>)</p>
  </dd>
  <dt>SMTP</dt>
  <dd>
    <p id="_4c6642bd-8902-4f33-adeb-4d7b8784c44a">Simple Mail Transfer Protocol (see <eref type="inline" bibitemid="SMTP" citeas="RFC 2821"/>)</p>
  </dd>
  <dt>DNSBL</dt>
  <dd>
    <p id="_ec3d746d-64b4-4717-9f9a-170be37e8084">Domain Name System-based Blackhole List</p>
  </dd>
  <dt>URIBL</dt>
  <dd>
    <p id="_11e58273-dea5-4c92-9e90-fad95261b28f">Realtime URI Blacklist</p>
  </dd>
  <dt>ARF</dt>
  <dd>
    <p id="_ad986433-2967-4aa5-8c6f-10c145dbbf22">Abuse Reporting Format</p>
  </dd>
</dl>
</definitions></clause>
<clause id="_calendar_spam_and_its_delivery_path" obligation="normative"><title>Calendar spam and its delivery path</title><clause id="_general" obligation="normative"><title>General</title><p id="_5141a2a7-a4de-4e0b-b0f6-9b088277e155">Calendar spam and calendar abuse originates at the OSI application layer
but also travels across multiple application layer technologies
through networked hosts.</p>
<p id="_de56e640-d862-433e-a3d9-340ccd95beec">Best practices used at the various checkpoints
that a calendar spam instance encounters within its delivery path
are described in clauses that follow.</p></clause>
<clause id="_information_systems_involved_in_calendar_abuse" obligation="normative"><title>Information systems involved in calendar abuse</title><clause id="_calendar_system" obligation="normative"><title>Calendar system</title><p id="_de03ae4e-5f9e-415c-8d38-6a28e205363f">The calendar system plays a crucial role in calendar abuse, where
it allows creating, editing and deleting events as well as scheduling
events between different user accounts, including user accounts from
other calendaring systems.</p>
<p id="_d6e54c92-ba6a-4342-a254-84f5aa6748dc">The calendar system should apply state-of-the-art methods to prevent
calendar spam being sent from and received by user accounts on their
system.</p>
<note id="_bf0a3a33-317d-43e8-be93-03a9b73232fa">
  <p id="_a4fae39c-9e47-43d9-a5ca-b5d99050fc29">The term “calendar system” in this document specifically refers
to calendaring systems that fulfill the requirements of
calendaring standards.</p>
</note></clause>
<clause id="_email_system" obligation="normative"><title>Email system</title><p id="_7c586f58-a288-4479-9789-450379f7d8a1">The email system is an important factor in calendar abuse as a
delivery mechanism.</p>
<p id="_f0b3cb38-bae7-479f-a87b-f5f5913984db">In calendar systems, the most common method to send calendar invitations
to user recipients is iMIP (<eref type="inline" bibitemid="iMIP" citeas="RFC 6047"/>), a way of exchanging iTIP (<eref type="inline" bibitemid="iTIP" citeas="RFC 5546"/>)
messages through email.</p>
<p id="_b399091d-498f-4199-8c33-e8edf71c1c49">iTIP (and iTIP) are mechanisms that allow users of different
calendar systems to communicate with one another, by delivering
calendar event information through email.</p>
<example id="_d18a99bc-c7f0-4268-adfc-2f890a54a3c1">
  <p id="_70b61dab-b792-42df-a106-6ba508781879">User A on a calendar system can invite another user B that does not
belong to the same calendar system, to a calendar event, where the
invitation information is sent through email to user B, either
by user A or user A’s calendar system.</p>
</example>
<p id="_b9b6969e-85a2-4eb1-9b53-6a7c0e64a058">Email systems are also used to transport information relevant to
the calendar event from organizers to attendees of events.</p>
<p id="_052e1b6f-b40a-4d37-9a8c-2f83b620c67e">The email system should apply state-of-the-art methods to prevent
calendar spam being sent by and received from user accounts on
their system.</p></clause>
<clause id="_related_systems" obligation="normative"><title>Related systems</title><p id="_19a29a3c-6e82-43ac-9e34-aeb6dd896207">Calendar and email systems are often connected with, and rely on,
other information systems, such as identity management systems
for authentication and authorization.</p>
<p id="_f4c466b4-dc33-4fb8-bc5b-eecb440425bc">When a system depended on by the calendar system is compromised,
such as through the creation of malicious user accounts,
the dependent calendar (and perhaps email) systems are also
affected. For example, the malicious user accounts may be used
to send out calendar abuse.</p>
<p id="_e1895872-5c68-4462-90f6-f0520080059e">These related systems should implement security best practices to
protect systems that are dependent on them, such as,
the calendar system.</p>
<example id="_44591f3a-e8a0-47bf-a9dd-f6c90ac4c570">
  <p id="_2d74ecc9-1c46-4c6d-b454-3db5b6efd52e">An identity management system should protect its user accounts
from malicious actors; prevent registration of fake, bot or
spam user accounts; and adopt strong authentication methods
such as two-factor authentication.</p>
</example></clause></clause></clause>
<clause id="_mitigating_calendar_abuse_at_source" obligation="normative"><title>Mitigating calendar abuse at source</title><clause id="_general_2" obligation="normative"><title>General</title><p id="_4c474b85-13cf-48aa-be88-3db7d176677b">Calendar spam may be produced by innocent calendar systems when:</p>
<ul id="_5080f83d-b9a9-430c-845c-cc6c6c859db4">
  <li>
    <p id="_42706752-2603-43bf-8d46-42e14c137b64">its users were compromised;</p>
  </li>
  <li>
    <p id="_34445b16-8235-4857-8663-e581e843c9e0">it contains abusive users (such as a free-of-charge hosting provider).</p>
  </li>
</ul>
<p id="_ce1dba68-d297-44b8-929d-1ba52839cfad">In the latter case, approaches such as automation (“bots”) can exacerbate
the issue with the automated creation of free accounts.</p>
<p id="_a4dc9f92-541e-4abe-90d0-7433a75442e6">Such user accounts can be readily used to create calendar spam events:</p>
<ol id="_fb9606ae-50f2-4fb0-bf93-f481a8a7b550" type="arabic">
  <li>
    <p id="_da4f21ac-cbb5-4697-89c0-609f777f9838">The malicious user account inserts spam content into a newly created calendar event;</p>
  </li>
  <li>
    <p id="_711a98e6-421f-4687-958c-d085664e32fe">The calendar system uses templating to send an email invitation with the calendar event
attached;</p>
  </li>
  <li>
    <p id="_a9fd2c46-fbf6-4831-97b2-825505969294">The event content, which contains spam, will be inserted into body of the email.</p>
  </li>
</ol>
<p id="_0f80cea5-53dc-4ecb-b27a-2603acd81028">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.</p></clause>
<clause id="_source_calendar_system" obligation="normative"><title>Source calendar system</title><p id="_427b9df1-829a-4f94-b7cc-0bb0fbd78d0d">The source calendar system is where an calendar abuse instance originates from.</p>
<p id="_0283391d-f209-4681-84d9-05cd45b7b53a">The source calendar system can apply the following best practices:</p>
<ol id="_9b1134c0-0451-45c4-9363-dd84b8b6071c" type="arabic">
  <li>
    <p id="_1e77d250-83fa-41e8-b578-ed78f30dfc1a">abuse detection should be performed, through channels such as:</p>
    <ol id="_cdb4f668-b518-4abe-86e8-f0452641aab5" type="alphabet">
  <li>
    <p id="_6ca83638-99ef-4363-9015-06f91fe887a0">user interface and input detection, such as user agent checks;</p>
  </li>
  <li>
    <p id="_ae1d80b8-56c2-460c-a366-04118e696290">network origination, such as network addresses and IPs; and</p>
  </li>
  <li>
    <p id="_ac956aee-fafe-4f32-a277-5a474bbc96a6">user behavior such as click rate.</p>
  </li>
</ol>
  </li>
  <li>
    <p id="_72d5b969-c2c6-4316-a38c-b6d807c2c737">detection of malicious content for typical spam patterns,
before event creation and the subsequent sending of email invitations,
by checking event content, such as:</p>
    <ol id="_1ae552e1-053b-495f-9ed4-02c2eb7862d5" type="alphabet">
  <li>
    <p id="_ba54bf1e-7686-4dd4-8a49-7793f0226327">subject;</p>
  </li>
  <li>
    <p id="_74c3e162-48d1-43c6-b7e3-ef474e89bf8f">description;</p>
  </li>
  <li>
    <p id="_6b46d6e0-0508-4960-b22b-1dcb808ad0c8">recurrence;</p>
  </li>
  <li>
    <p id="_93715b59-f595-4826-a12e-2ab030089a4b">number of attendees; and</p>
  </li>
  <li>
    <p id="_3dc390b6-9bd5-4fda-a80f-b1eb16d3c7fe">links.</p>
  </li>
</ol>
  </li>
</ol>
<p id="_52b4d697-5e96-411a-a108-4fe5ec844083">A number of potential actions can be invoked once potential spam
is detected, such as:</p>
<ol id="_0e584533-969a-4a2b-aa35-406315a8ca6f" type="arabic">
  <li>
    <p id="_a2fbe1e9-e107-4eba-858d-68b03ce04cff">deny the sending of the calendar invite;</p>
  </li>
  <li>
    <p id="_85ea5a09-988d-4b0c-8303-334853917914">display of errors and feedback at the user interface;</p>
  </li>
  <li>
    <p id="_c35be4df-ed0a-429d-ae60-12655806385d">alert the owner of the user account in case the user account has been hijacked;</p>
  </li>
  <li>
    <p id="_6a2ab4a2-1104-4e86-bba5-93109009a553">application of rate limiting to prevent automated spamming;</p>
  </li>
  <li>
    <p id="_86f64be7-3ce9-4524-8422-f3140ee846b5">implement automation detection measures, such as usage of a CAPTCHA prior to sending an
invitation; and</p>
  </li>
  <li>
    <p id="_05feb3fc-f9a4-4121-897b-ce6ba94689a7">blocking the user account altogether.</p>
  </li>
</ol></clause>
<clause id="_electronic_mail_system_smtp" obligation="normative"><title>Electronic mail system (SMTP)</title><p id="_5c9d50d0-e4be-41de-b6a9-9385bbc33c2e">The source electronic mail system is where the calendar system delivers
an event invitation to for its forwarding.</p>
<p id="_e6b022ac-f141-4b8a-8186-d83206efb44f">The following mitigation measures should be taken at the electronic mail system:</p>
<ol id="_8fce8bbc-4ba8-48e8-ae19-557ad34ce831" type="arabic">
  <li>
    <p id="_21fce1f6-79d9-4d63-89e9-423f08542959">abuse detection for SMTP access should be performed based on input, such as:</p>
    <ol id="_1b2a4751-d903-4174-b01d-d630191e9519" type="alphabet">
  <li>
    <p id="_85171373-3dc8-4edf-8749-ec797f2b8c33">network patterns of the originator;</p>
  </li>
  <li>
    <p id="_e1d3aab3-9fea-43d7-92f1-e5caf899efd0">DNSBL checks against the originating IP.</p>
  </li>
</ol>
  </li>
  <li>
    <p id="_f59d047e-2c55-469b-854d-d8e7323c4039">detection of spam content patterns of the email message, using standard email anti-spam
scanning applications:</p>
    <ol id="_58c03e54-b227-4a48-9acb-4eb0e611f738" type="alphabet">
  <li>
    <p id="_24f13b12-95b1-40d6-b0a4-ef048fa1e245">scanning for malicious content;</p>
  </li>
  <li>
    <p id="_b0fbe5e3-6bff-4a25-86ca-d60edd062e9c">detection of blacklisted and/or known phishing URLs.</p>
  </li>
</ol>
  </li>
</ol>
<p id="_c5c1d7d4-8cdf-4538-8e9f-b5439eeb407d">A number of potential actions can be invoked once potential spam
is detected, such as:</p>
<ol id="_21915f3d-39d0-47ef-a500-79edd88e8a19" type="arabic">
  <li>
    <p id="_e1d5fae3-6aa5-4196-960b-30b8b7ed75c5">bounce the email that contains suspected calendar spam;</p>
  </li>
  <li>
    <p id="_85a7a56a-03c6-4fe9-8ded-bbe6b1519180">silently discard the email with suspected calendar spam;</p>
  </li>
  <li>
    <p id="_09f482ef-2f6a-495e-b5b4-9388c307003d">communicate with the upstream calendar provider to indicate potential abuse; and</p>
  </li>
  <li>
    <p id="_26f0d128-5cc3-4024-a111-c6cccc7e6bdf">communicate with downstream email providers who will be receive the potential spam.</p>
  </li>
</ol></clause></clause>
<clause id="_mitigating_calendar_abuse_at_destination" obligation="normative"><title>Mitigating calendar abuse at destination</title><clause id="_general_3" obligation="normative"><title>General</title><p id="_65372797-be63-4dd2-aa37-3d796a44de26">Calendar spam events are typically received by recipients in two ways:</p>
<ol id="_47ef870d-12d5-4813-80b2-9fd408f2f3a1" type="arabic">
  <li>
    <p id="_fbf270eb-ab27-42fe-b55d-47928db080f4">via email from an external email system; or</p>
  </li>
  <li>
    <p id="_6e2ac994-ae42-4d25-9129-b85e3fe58dc4">directly from another account within the same calendar system the recipient resides on.<br/></p>
    <note id="_21505915-cb66-47c0-92a9-3bb100b6af77">
  <p id="_52cc5dd6-21a6-453f-8513-7119cdef0f67">The case of a same-system account abuse can apply when the calendar system
contains compromised accounts.</p>
</note>
  </li>
</ol>
<p id="_a9110341-98d9-49f8-ad11-ae6b763e4f0f">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:</p>
<ul id="_e1f8c621-c408-4375-a52f-540254a1374a">
  <li>
    <p id="_65480b6e-fcd1-4109-ae23-aefec9725e8a">from within the calendar system, where the event did not leave the calendar system; or</p>
  </li>
  <li>
    <p id="_e4dbe5cb-d19c-4143-ae82-e408e8cc5aeb">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.</p>
  </li>
</ul>
<p id="_6bb433d0-2368-40ce-826c-982d8e507bc1">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.</p></clause>
<clause id="_electronic_mail_system" obligation="normative"><title>Electronic mail system</title><p id="_a04bb31a-db46-4c5e-9963-06b8f56aebc8">The following best practices apply:</p>
<ol id="_e3fcda4a-219c-4e72-8766-70a3e9123416" type="arabic">
  <li>
    <p id="_128fd3c7-6c2c-4a44-a869-a6067483dc93">abuse detection for receiving email by analyzing input, such as:</p>
    <ol id="_e86d3620-7f92-4de0-96ed-68d60eb088f2" type="alphabet">
  <li>
    <p id="_0652c6e8-49ca-4eed-8ad8-f06daecb97da">originating network addresses;</p>
  </li>
  <li>
    <p id="_ed6e77c1-b790-4348-90b8-e3e5f7d5cb9b">content of the mail header and its structure.</p>
  </li>
</ol>
  </li>
  <li>
    <p id="_45e078e5-abc5-4a5f-b493-1c958221272c">analysis of email spam content patterns using standard email anti-spam scanning
applications, such as through:</p>
    <ol id="_cca91aaf-1d1e-4fc1-b5ac-f41fd54f2475" type="alphabet">
  <li>
    <p id="_1e83af53-ef09-483d-ae1c-825fe7689bc8">checking of DNSBLs; and</p>
  </li>
  <li>
    <p id="_f4786895-5e05-4c72-82fd-c9dee50fc883">checking of URIBLs.</p>
  </li>
</ol>
  </li>
  <li>
    <p id="_6577b3d0-b212-4a3c-8232-dc34cdf38ac9">checking email header content against internal and external sources, such as:</p>
    <ol id="_d68c5506-504c-40b5-9f65-67201e7da399" type="alphabet">
  <li>
    <p id="_359adb15-4721-4f38-ae78-caed04f33a4b">verification of sender address reputation using the <tt>From:</tt> address;</p>
  </li>
  <li>
    <p id="_b0bd1dba-442b-4731-aced-0a4ee2ad4040">detection of known malicious addresses from security advisories;</p>
  </li>
  <li>
    <p id="_a72555f9-a47d-40e5-b7a8-53a0e0c93789">determining whether the organizer has been whitelisted.</p>
  </li>
</ol>
  </li>
</ol>
<p id="_2bbdddf5-48f8-4af3-9899-c63aa22209f6">Actions to be taken when potential spam is detected are provided below:</p>
<ol id="_fe44c0ff-f2cc-4899-a90b-3f08ff785df1" type="arabic">
  <li>
    <p id="_97965a30-a26d-44cf-b3f2-95acb87ec790">bounce the message;</p>
  </li>
  <li>
    <p id="_70209bd6-6a5a-4fad-a98a-0027dfb00c9a">silently discard the message;</p>
  </li>
  <li>
    <p id="_4152cb7c-5064-4c5a-9df7-88fb4cc8b4e2">pick out the message into quarantaine;</p>
  </li>
  <li>
    <p id="_97868dd7-7bf7-499a-b249-6b25c48d1ac3">moving the message into the spam folder.</p>
  </li>
</ol>
<p id="_27c7426b-292c-4607-86da-2551a7c41102">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.</p>
<p id="_d586fdfc-caba-486c-b0b6-d62df18ab219">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.</p>
<p id="_e9cfb55b-276c-44e8-9cf3-e6f1c6abc4dd">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.</p>
<p id="_8672d6a8-797c-4a56-b1a2-1a1cdc367803">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.</p></clause></clause>
<clause id="_interactions_between_the_calendar_system_and_the_mail_system" obligation="normative"><title>Interactions between the calendar system and the mail system</title><p id="_e464eec4-863e-47ff-96ad-446aa29457a3">Interaction between the electronic mail and calendar systems
should follow these principles:</p>
<ol id="_d881922d-8c7c-4e00-87cc-83c18c03d700" type="arabic">
  <li>
    <p id="_98975dc5-4e95-4af7-aada-64534df14879">interaction between these systems should only be triggered for emails
not already identified as spam, i.e. anti-abuse measures have already
been applied on both systems independently;</p>
  </li>
  <li>
    <p id="_4db84ea1-1161-445f-9d61-87d65983c47f">calendar invitations should be analyzed and categorized by the
calendar system to leverage its domain knowledge on calendar event information,
which is necessary for a detailed analysis that takes into account
calendar event data structures not understandable to electronic mail systems;</p>
  </li>
  <li>
    <p id="_842deb49-f17d-452e-8e79-6b5655823c21">calendar event content should be checked for spam patterns in its text fields,
such as the fields of subject, description, recurrence and links,
to determine the likelihood of it being spam;</p>
  </li>
  <li>
    <p id="_1cd337d8-efa2-44f7-8398-99f835425c96">depending on the likelihood of being spam, spam handling options should be
offered to the user directly, such as:</p>
    <ul id="_7939b44a-e999-4c5e-8b85-14ac9d46e47c">
  <li>
    <p id="_adc62900-4cb6-4013-be4c-805b43ff4a43">the automatic insertion of organizers on a whitelist or address book;</p>
  </li>
  <li>
    <p id="_2f971b84-1daa-4a23-9453-541fabe3a10f">the state of this event in availability of calendar (e.g. free,
conditional or blocked).</p>
  </li>
</ul>
  </li>
</ol>
<p id="_f1e547e5-a0b7-42ce-ad9b-272be9a442c7">When spam is detected during the interaction stage, a number of mitigation
actions can be taken, such as:</p>
<ol id="_9ecd9628-8845-44ef-b1f3-1942397b3881" type="arabic">
  <li>
    <p id="_b4953710-c9a8-4abe-939b-03529e9641b4">do not automatically insert the calendar event into the user’s calendar; or</p>
  </li>
  <li>
    <p id="_170e9690-cf02-432b-9b8a-ed149d1922b7">deactivate calendar event notifications for this calendar event.</p>
  </li>
</ol>
<clause id="_calendar_user_application" obligation="normative"><title>Calendar user application</title><p id="_ad252858-9948-4faa-b446-f0ceafc2f283">The calendar user application, as part of the “calendar system”,
should offer the following functionality relating to calendar abuse:</p>
<ol id="_c4202ec0-5545-45c1-9f33-32d5c100afdd" type="arabic">
  <li>
    <p id="_622827eb-be26-4784-88fc-74906990631f">allow the user to delete unwanted events (e.g. “Mark as spam”),
without notifying the organizer as normally performed with calendar
events;</p>
  </li>
  <li>
    <p id="_e396b5d7-f2de-484a-b7a0-ae01dd1c2764">submission of ARF reports to report calendar abuse;</p>
  </li>
  <li>
    <p id="_c00f6862-b78d-4b0e-8768-3b0f471544ad">store information on how a particular calendar event was inserted
into the users calendar (e.g. by tracking the <tt>Message-ID</tt> attribute),
to be able to inform the user such information and provide additional
information to the originating calendar system on abuse.</p>
  </li>
</ol>
<p id="_0294fe3e-3992-46b6-acc7-a3fba7068af9">In addition, further actions can be taken to detect calendar spam at the
calendar user application, such as:</p>
<ol id="_3d3224e0-2508-428a-ba87-4a658ec8fa71" type="arabic">
  <li>
    <p id="_d45cabac-cb76-45be-aa87-223452e92921">sending an email feedback loop if the original email that carried
the calendar invitation and its <tt>MailID</tt> is still available.</p>
  </li>
</ol></clause></clause>
<clause id="_other_ways_calendar_spam_occur" obligation="normative">
  <title>Other ways calendar spam occur</title>
  <clause id="_subscription_to_shared_calendars" obligation="normative"><title>Subscription to shared calendars</title><p id="_650c9bc4-efff-4113-869b-3ce0e62ed39c">Malicious events can end up in user calendars through shared calendars.</p>
<p id="_40454418-0ec2-470c-9ee5-12fd85545175">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.</p>
<p id="_bf2f57af-b38b-4cd5-974e-aa88b5600aed">Popular calendars, such as official calendars (e.g. public and bank holidays),
schedules of shows and sports teams, are valuable targets for malicious actors.</p>
<p id="_b64eedd5-c31c-4cc4-b626-0fd7f68fcb6b">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.</p>
<p id="_fa5277a7-b2cb-45da-9960-272f1a922f07">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.</p>
<clause id="_itip" obligation="normative">
  <title>iTIP</title>
  <p id="_ef680ddc-17f3-448a-8b90-fc2f5d483181">Calendar systems using iTIP for direct communication between each other, e.g. within
the same calendar system, should consider and implement anti-abuse best practices as
described above.</p>
</clause></clause>
</clause>
<clause id="_conclusion" obligation="normative"><title>Conclusion</title><p id="_14911708-833e-41cd-bc97-5d80fd3ca4e7">Spam is a long-standing and well-known email problem. Because email is a commonly used
transport for calendar (“meeting”) invitations and events, spammers are now using these
calendar events and invitations as a spam vector. Consequently, knowledge of both domains
is required to develop defenses against these attacks.</p>
<p id="_48b101ae-213f-47c1-9861-0842ba28c4e3">This document provides email and calendar system operators with an introduction to
calendar spam, and highlights best practices for identifying and mitigating calendar spam.
Implementation details will largely be system-specific.</p>
<p id="_e3d85577-edbf-41aa-8164-fe803497460c">The “war” against malware, including spam, is dynamic and ever-changing. As a result,
email and calendar system experts will need to share their expertise and experiences with
each other on an ongoing basis. CalConnect’s collaboration with M3AAWG represents the first
formal collaboration in this area.</p></clause>
<clause id="_acknowledgements" obligation="normative"><title>Acknowledgements</title><p id="_c3f57d67-74f4-4731-9bb8-7c1ab7798c1b">The authors of this document wishes to thank the experts of
CalConnect — the Calendaring and Scheduling Consortium and
attendees of the M3AAWG conference sessions about the topic,
as well as the following individuals who have participated in
the drafting, review and discussion of this document:</p>
<ul id="_8268a6a8-9c4d-4df0-9871-80321dd9d0ce">
  <li>
    <p id="_948ab1eb-c9dc-4afa-9914-a4723002b07d">Arne Allisat</p>
  </li>
  <li>
    <p id="_fb3d1733-013f-4f5e-98d2-12f89ea67a43">Bron Gondwana</p>
  </li>
  <li>
    <p id="_02cd245f-ac62-4ba6-985f-d6f995919327">Andrew Laurence</p>
  </li>
  <li>
    <p id="_f11bb950-e6ac-4c38-93f0-247e56a8be79">Andrey Maevsky</p>
  </li>
  <li>
    <p id="_42e7b634-488d-41ba-8f43-8c473d4df159">Gary Schwartz</p>
  </li>
  <li>
    <p id="_bdb3c8d9-8135-4ded-a40c-3017f18e0079">Dave Thewlis</p>
  </li>
  <li>
    <p id="_84d2a650-1afa-4231-a8a8-ad39580c185c">Ronald Tse</p>
  </li>
</ul></clause>

</sections><annex id="AnnexA" obligation="informative">
  <title>Technical information</title>
  <clause id="_structure_of_a_best_practice_imip_message_containing_an_event" obligation="informative"><title>Structure of a best practice iMIP message containing an event</title><p id="_ed9ac2bc-3add-438f-bb36-848edbe1c926">An email message should only contain a single iCalendar attachment (an iMIP file).<note id="_3da656a2-4ace-43b2-81ea-1f3b1a66c484">
  <p id="_3c0479ae-bb1e-41a4-bbfa-cbd1ef7b9c82">Current practice allows attaching multiple iCalendar attachments
to a single email.</p>
</note></p>

<p id="_0e2e23f7-bcba-4fcc-b412-5dfa227dbf43">The recommended MIME/<tt>multipart</tt> structure of an email that contains
a calendar event invitation, optimized for interoperability,
is provided as follows:</p>
<ul id="_e3b9129a-7cd4-4f24-9fcc-347655f5856b">
  <li>
    <p id="_b9c27dd8-609f-4c6b-ac14-67f134d72c9f">a single <tt>multipart/mixed</tt> part, which contains:</p>
    <ul id="_bc11ded6-138e-4166-b3ab-488b44b5f41b">
  <li>
    <p id="_bbd33247-d95c-487d-b323-ddaa6da801f4">a single <tt>multipart/alternative</tt> part, which contains:</p>
    <ul id="_abb65258-4cef-4136-90e1-e53ee7c32fb9">
  <li>
    <p id="_4a6c0cd0-feef-4e01-adbc-4ca8908320ff">a <tt>text/plain</tt> part; and</p>
  </li>
  <li>
    <p id="_b5b69d13-4dc4-4855-9805-2b89783767eb">a <tt>text/html</tt> part;</p>
  </li>
</ul>
  </li>
  <li>
    <p id="_98fdeefa-a147-4a59-989d-0db755ab5c0d">a <tt>text/calendar</tt> part with <tt>method=REQUEST</tt>; and</p>
  </li>
  <li>
    <p id="_e8a51182-1ef9-4eef-96f4-22fa54e1cedd">an <tt>application/ics</tt> part, with a <tt>content-disposition:attachment</tt>, in <tt>BASE64</tt> encoding</p>
  </li>
</ul>
  </li>
</ul>
<p id="_f115a3b5-8b74-4388-8e02-949dadbcf2b8">This recommended structure was devised through interoperability testing with
multiple existing implementations.<note id="_e7379ceb-73f0-43b3-8da0-d4530b960913">
  <p id="_0f970204-3d89-4568-a49f-2e8e7bd3b721">A calendar system that conforms to calendaring standards produces
an email structure similar to that above.</p>
</note></p>

<p id="_5d54cbbf-0a12-4767-a1b8-8dccf72d25f5">Guidelines on this structure:</p>
<ul id="_622ddd6a-4182-4359-a710-cc936f6d7a69">
  <li>
    <p id="_bc4e778f-cc83-474a-b46d-5523b706a3d3">The filename of the <tt>application/ics</tt> part should end with the <tt>.ics</tt> file extension.</p>
  </li>
  <li>
    <p id="_7983426e-9c75-445b-9e42-d31a1fb2c54a">Some calendar user applications will only see the part with the standard <tt>text/calendar</tt>
<tt>content-type</tt> and the <tt>method</tt> header.</p>
  </li>
  <li>
    <p id="_81beb617-8631-487f-b766-6aeea24d21b5">Some calendar user applications are only able to see attached parts with
<tt>application/ics</tt> (this is non-standard behavior).</p>
  </li>
  <li>
    <p id="_c33ccb31-6f48-4d73-be87-af37408fcc8a">Some calendar systems automatically insert links within the HTML part,
which can be used by email clients that are not calendar-aware to accept
or decline an invitation without having to process the calendar parts.
In this case, the server simply updates the <tt>ORGANIZER</tt>‘s copy of the
event based on the link clicked.</p>
  </li>
  <li>
    <p id="_679a1d8a-1a4e-4f40-b862-3ea8818114ad">The <tt>text/plain</tt> and <tt>text/html</tt> part of the message in the body will
include information of the event, such as its subject and description.</p>
  </li>
  <li>
    <p id="_55c241f0-0de8-46d5-a7be-0aa2d00e87ed">An email using the provide structure does not preclude spammers from
inserting malicious content outside of the attached files — all parts of the email should still be parsed to detect malicious content.</p>
  </li>
</ul></clause>
</annex><bibliography><references id="_normative_references" obligation="informative"><title>Normative References</title><p>The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.</p>
<bibitem id="iMIP">
  <fetched>2020-06-16</fetched>
  <title format="text/plain" language="en" script="Latn">iCalendar Message-Based Interoperability Protocol (iMIP)</title>
  <uri type="src">https://www.rfc-editor.org/info/rfc6047</uri>
  <docidentifier type="IETF">RFC 6047</docidentifier>
  <docidentifier type="DOI">10.17487/RFC6047</docidentifier>
  <date type="published">
    <on>2010-12</on>
  </date>
  <contributor>
    <role type="editor"/>
    <person>
      <name>
        <completename language="en">A. Melnikov</completename>
      </name>
      <affiliation>
        <organization>
          <name>IETF</name>
          <abbreviation>IETF</abbreviation>
        </organization>
      </affiliation>
    </person>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract format="text/plain" language="en" script="Latn">This document, “iCalendar Message-Based Interoperability Protocol (iMIP)”, specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP.  [STANDARDS-TRACK]</abstract>
  <series type="main">
    <title format="text/plain" language="en" script="Latn">RFC</title>
    <number>6047</number>
  </series>
</bibitem>

<bibitem id="iTIP">
  <fetched>2020-06-16</fetched>
  <title format="text/plain" language="en" script="Latn">iCalendar Transport-Independent Interoperability Protocol (iTIP)</title>
  <uri type="src">https://www.rfc-editor.org/info/rfc5546</uri>
  <docidentifier type="IETF">RFC 5546</docidentifier>
  <docidentifier type="DOI">10.17487/RFC5546</docidentifier>
  <date type="published">
    <on>2009-12</on>
  </date>
  <contributor>
    <role type="editor"/>
    <person>
      <name>
        <completename language="en">C. Daboo</completename>
      </name>
      <affiliation>
        <organization>
          <name>IETF</name>
          <abbreviation>IETF</abbreviation>
        </organization>
      </affiliation>
    </person>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract format="text/plain" language="en" script="Latn">This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems.  This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems.  Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems.  These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling.  [STANDARDS-TRACK]</abstract>
  <series type="main">
    <title format="text/plain" language="en" script="Latn">RFC</title>
    <number>5546</number>
  </series>
</bibitem> </references><references id="_bibliography" obligation="informative"><title>Bibliography</title><bibitem id="ISO27000" type="standard">
  <fetched>2020-06-16</fetched>
  <title type="title-intro" format="text/plain" language="en" script="Latn">Information technology</title>
  <title type="title-main" format="text/plain" language="en" script="Latn">Security techniques</title>
  <title type="title-part" format="text/plain" language="en" script="Latn">Information security management systems – Overview and vocabulary</title>
  <title type="main" format="text/plain" language="en" script="Latn">Information technology – Security techniques – Information security management systems – Overview and vocabulary</title>
  <title type="title-intro" format="text/plain" language="fr" script="Latn">Technologies de l’information</title>
  <title type="title-main" format="text/plain" language="fr" script="Latn">Techniques de sécurité</title>
  <title type="title-part" format="text/plain" language="fr" script="Latn">Systèmes de management de la sécurité de l’information – Vue d’ensemble et vocabulaire</title>
  <title type="main" format="text/plain" language="fr" script="Latn">Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité de l’information – Vue d’ensemble et vocabulaire</title>
  <uri type="src">https://www.iso.org/standard/73906.html</uri>
  <uri type="obp">https://www.iso.org/obp/ui/#!iso:std:73906:en</uri>
  <uri type="rss">https://www.iso.org/contents/data/standard/07/39/73906.detail.rss</uri>
  <docidentifier type="ISO">ISO/IEC 27000:2018</docidentifier>
  <docnumber>27000</docnumber>
  <date type="published">
    <on>2018</on>
  </date>
  <contributor>
    <role type="publisher"/>
    <organization>
      <name>International Organization for Standardization</name>
      <abbreviation>ISO</abbreviation>
      <uri>www.iso.org</uri>
    </organization>
  </contributor>
  <contributor>
    <role type="publisher"/>
    <organization>
      <name>International Electrotechnical Commission</name>
      <abbreviation>IEC</abbreviation>
      <uri>www.iec.ch</uri>
    </organization>
  </contributor>
  <edition>5</edition>
  <language>en</language>
  <language>fr</language>
  <script>Latn</script>
  <abstract format="text/plain" language="en" script="Latn">ISO/IEC 27000:2018 provides the overview of information security management systems (ISMS). It also provides terms and definitions commonly used in the ISMS family of standards. This document is applicable to all types and sizes of organization (e.g. commercial enterprises, government agencies, not-for-profit organizations).The terms and definitions provided in this document-      cover commonly used terms and definitions in the ISMS family of standards;-      do not cover all terms and definitions applied within the ISMS family of standards; and-      do not limit the ISMS family of standards in defining new terms for use.</abstract>
  <abstract format="text/plain" language="fr" script="Latn">ISO/IEC 27000:2018 offre une vue d’ensemble des systèmes de management de la sécurité de l’information (SMSI). Il comprend également les termes et définitions d’usage courant dans la famille de normes du SMSI. Le présent document est applicable à tous les types et à toutes les tailles d’organismes (par exemple: les entreprises commerciales, les organismes publics, les organismes à but non lucratif).Les termes et les définitions fournis dans le présent document:-      couvrent les termes et les définitions d’usage courant dans la famille de normes du SMSI;-      ne couvrent pas l’ensemble des termes et des définitions utilisés dans la famille de normes du SMSI;-      ne limitent pas la famille de normes du SMSI en définissant de nouveaux termes à utiliser.</abstract>
  <status>
    <stage>60</stage>
    <substage>60</substage>
  </status>
  <copyright>
    <from>2018</from>
    <owner>
      <organization>
        <name>ISO/IEC</name>
      </organization>
    </owner>
  </copyright>
  <relation type="obsoletes">
    <bibitem type="standard">
      <formattedref format="text/plain">ISO/IEC 27000:2016</formattedref>
    </bibitem>
  </relation>
</bibitem><bibitem id="SMTP">
  <fetched>2020-06-16</fetched>
  <title format="text/plain" language="en" script="Latn">Simple Mail Transfer Protocol</title>
  <uri type="src">https://www.rfc-editor.org/info/rfc2821</uri>
  <docidentifier type="IETF">RFC 2821</docidentifier>
  <docidentifier type="DOI">10.17487/RFC2821</docidentifier>
  <date type="published">
    <on>2001-04</on>
  </date>
  <contributor>
    <role type="editor"/>
    <person>
      <name>
        <completename language="en">J. Klensin</completename>
      </name>
      <affiliation>
        <organization>
          <name>IETF</name>
          <abbreviation>IETF</abbreviation>
        </organization>
      </affiliation>
    </person>
  </contributor>
  <language>en</language>
  <script>Latn</script>
  <abstract format="text/plain" language="en" script="Latn">This document is a self-contained specification of the basic protocol for the Internet electronic mail transport.  [STANDARDS-TRACK]</abstract>
  <series type="main">
    <title format="text/plain" language="en" script="Latn">RFC</title>
    <number>2821</number>
  </series>
</bibitem>


 </references></bibliography>
</csd-standard>