From 9b4d64dbf0e1104cfcb02cc1594b31f7e81af13f Mon Sep 17 00:00:00 2001
From: jamiehynds <62879768+jamiehynds@users.noreply.github.com>
Date: Mon, 5 Oct 2020 10:35:54 +0100
Subject: [PATCH 1/7] Create 0008-email.md

---
 rfcs/text/0008-email.md | 144 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 144 insertions(+)
 create mode 100644 rfcs/text/0008-email.md

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
new file mode 100644
index 0000000000..46256f3d54
--- /dev/null
+++ b/rfcs/text/0008-email.md
@@ -0,0 +1,144 @@
+# 0008: Email
+<!-- Leave this ID at 0000. The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC. -->
+
+- Stage: **1** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
+- Date: **Oct 5th 2020** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
+
+This RFC proposes a new top-level field to facilitate email use cases. 
+
+<!--
+As you work on your RFC, use the "Stage N" comments to guide you in what you should focus on, for the stage you're targeting.
+Feel free to remove these comments as you go along.
+-->
+
+<!--
+Stage 0: Provide a high level summary of the premise of these changes. Briefly describe the nature, purpose, and impact of the changes. ~2-5 sentences.
+-->
+
+## Fields
+
+<!--
+Stage 1: Describe at a high level how this change affects fields. Which fieldsets will be impacted? How many fields overall? Are we primarily adding fields, removing fields, or changing existing fields? The goal here is to understand the fundamental technical implications and likely extent of these changes. ~2-5 sentences.
+-->
+
+| field | type | description |
+| --- | --- | --- |
+| `email.action` | keyword | Action take by the source device, e.g. delivered, blocked, quarantined, deleted |
+| `email.bcc.address` | keyword | Addresses of Bcc's |
+| `email.bcc.domain` | keyword | Domains of the Bcc's |
+| `email.cc.address` | keyword | Addresses of Cc's |
+| `email.cc.domain` | keyword | Domains of Cc addresses |
+| `email.cipher` | keyword | Cipher used e.g. TLS |
+| `email.file.count` | value | Number of attachments included in the message |
+| `email.file.extension` | keyword | Extensions of attachment, e.g. .zip, .docx |
+| `email.file.hash` | keyword | Hash of attachments |
+| `email.file.name` | keyword | File name of attachements |
+| `email.file.size` | keyword | Total size of all attachements in bytes |
+| `email.direction` | keyword | Direction of the message based on the sending and receving domains |
+| `email.from.address` | keyword | Senders email address |
+| `email.from.domain` | keyword | Senders domain |
+| `email.latency` | keyword | The time, in milliseconds, the delivery attempt took |
+| `email.message_id` | keyword | Internet message ID of the message |
+| `email.process` | keyword | Name of the executable that carried out the transaction, e.g. outlook, sendmail |
+| `email.protocol` | keyword | The email protocol used, e.g. SMTP, IMAP |
+| `email.reply_to.address` | keyword | Reply-to address |
+| `object.return.address` | keyword | The return address for the message |
+| `email.size` | keyword | Total size of the message, in bytes, including attachments |
+| `email.subject` | keyword | Subject of the message |
+| `email.to` | keyword | Recipieint address |
+| `email.to.domain` | keyword | Recipient domain |
+
+## Usage
+
+<!--
+Stage 1: Describe at a high-level how these field changes will be used in practice. Real world examples are encouraged. The goal here is to understand how people would leverage these fields to gain insights or solve problems. ~1-3 paragraphs.
+-->
+
+Email use cases stretch across all three Elastic solutions - Search, Observe, Protect. Whether it's searching for content within email, ensuring email infrastrucure is operational or detecting email based attacks, there are many possibilities for email fields within ECS.
+
+## Source data
+
+<!--
+Stage 1: Provide a high-level description of example sources of data. This does not yet need to be a concrete example of a source document, but instead can simply describe a potential source (e.g. nginx access log). This will ultimately be fleshed out to include literal source examples in a future stage. The goal here is to identify practical sources for these fields in the real world. ~1-3 sentences or unordered list.
+-->
+
+- **Email Analytics**: [Hubspot](https://legacydocs.hubspot.com/docs/methods/email/email_events_overview), Marketo, Salesforce Pardot
+- **Email Server**: [O365 Message Tracing](https://docs.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results), [Postfix](https://nxlog.co/documentation/nxlog-user-guide/postfix.html)
+- **Email Security**: [Barracuda](https://campus.barracuda.com/product/emailsecuritygateway/doc/12193950/syslog-and-the-barracuda-email-security-gateway/), [Forcepoint](https://www.websense.com/content/support/library/email/v85/email_siem/siem_log_map.pdf), [Mimecast](https://www.mimecast.com/tech-connect/documentation/tutorials/understanding-siem-logs/), [Proofpoint](https://help.proofpoint.com/Threat_Insight_Dashboard/API_Documentation/SIEM_API)
+
+<!--
+Stage 2: Included a real world example source document. Ideally this example comes from the source(s) identified in stage 1. If not, it should replace them. The goal here is to validate the utility of these field changes in the context of a real world example. Format with the source name as a ### header and the example document in a GitHub code block with json formatting.
+-->
+
+<!--
+Stage 3: Add more real world example source documents so we have at least 2 total, but ideally 3. Format as described in stage 2.
+-->
+
+## Scope of impact
+
+<!--
+Stage 2: Identifies scope of impact of changes. Are breaking changes required? Should deprecation strategies be adopted? Will significant refactoring be involved? Break the impact down into:
+ * Ingestion mechanisms (e.g. beats/logstash)
+ * Usage mechanisms (e.g. Kibana applications, detections)
+ * ECS project (e.g. docs, tooling)
+The goal here is to research and understand the impact of these changes on users in the community and development teams across Elastic. 2-5 sentences each.
+-->
+
+## Concerns
+
+<!--
+Stage 1: Identify potential concerns, implementation challenges, or complexity. Spend some time on this. Play devil's advocate. Try to identify the sort of non-obvious challenges that tend to surface later. The goal here is to surface risks early, allow everyone the time to work through them, and ultimately document resolution for posterity's sake.
+-->
+
+<!--
+Stage 2: Document new concerns or resolutions to previously listed concerns. It's not critical that all concerns have resolutions at this point, but it would be helpful if resolutions were taking shape for the most significant concerns.
+-->
+
+<!--
+Stage 3: Document resolutions for all existing concerns. Any new concerns should be documented along with their resolution. The goal here is to eliminate the risk of churn and instability by resolving outstanding concerns.
+-->
+
+<!--
+Stage 4: Document any new concerns and their resolution. The goal here is to eliminate risk of churn and instability by ensuring all concerns have been addressed.
+-->
+
+## Real-world implementations
+
+<!--
+Stage 4: Identify at least one real-world, production-ready implementation that uses these updated field definitions. An example of this might be a GA feature in an Elastic application in Kibana.
+-->
+
+People
+
+The following are the people that consulted on the contents of this RFC.
+
+Jamie Hynds | author
+TBD | Sponsor
+
+<!--
+Who will be or has been consulted on the contents of this RFC? Identify authorship and sponsorship, and optionally identify the nature of involvement of others. Link to GitHub aliases where possible. This list will likely change or grow stage after stage.
+
+e.g.:
+
+* @Yasmina | author
+* @Monique | sponsor
+* @EunJung | subject matter expert
+* @JaneDoe | grammar, spelling, prose
+* @Mariana
+-->
+
+
+## References
+
+<!-- Insert any links appropriate to this RFC in this section. -->
+
+### RFC Pull Requests
+
+<!-- An RFC should link to the PRs for each of it stage advancements. -->
+
+* Stage 0: https://github.com/elastic/ecs/pull/NNN
+
+<!--
+* Stage 1: https://github.com/elastic/ecs/pull/NNN
+...
+-->

From 1a4c2fd0dd886aba17ef126f6ada3d4979d3382b Mon Sep 17 00:00:00 2001
From: P1llus <pillus@chasenet.org>
Date: Mon, 9 Nov 2020 17:18:15 +0100
Subject: [PATCH 2/7] updating the RFC based on PR comments

---
 rfcs/text/0008-email.md | 55 ++++++++++++++++++++++-------------------
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index 46256f3d54..20a8c61957 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -1,10 +1,10 @@
 # 0008: Email
 <!-- Leave this ID at 0000. The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC. -->
 
-- Stage: **1** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
+- Stage: **1 (proposal)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
 - Date: **Oct 5th 2020** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
 
-This RFC proposes a new top-level field to facilitate email use cases. 
+This RFC proposes a new top-level field to facilitate email use cases.
 
 <!--
 As you work on your RFC, use the "Stage N" comments to guide you in what you should focus on, for the stage you're targeting.
@@ -21,32 +21,35 @@ Stage 0: Provide a high level summary of the premise of these changes. Briefly d
 Stage 1: Describe at a high level how this change affects fields. Which fieldsets will be impacted? How many fields overall? Are we primarily adding fields, removing fields, or changing existing fields? The goal here is to understand the fundamental technical implications and likely extent of these changes. ~2-5 sentences.
 -->
 
+Email specific fields:
+
 | field | type | description |
 | --- | --- | --- |
-| `email.action` | keyword | Action take by the source device, e.g. delivered, blocked, quarantined, deleted |
-| `email.bcc.address` | keyword | Addresses of Bcc's |
-| `email.bcc.domain` | keyword | Domains of the Bcc's |
-| `email.cc.address` | keyword | Addresses of Cc's |
-| `email.cc.domain` | keyword | Domains of Cc addresses |
-| `email.cipher` | keyword | Cipher used e.g. TLS |
-| `email.file.count` | value | Number of attachments included in the message |
-| `email.file.extension` | keyword | Extensions of attachment, e.g. .zip, .docx |
-| `email.file.hash` | keyword | Hash of attachments |
-| `email.file.name` | keyword | File name of attachements |
-| `email.file.size` | keyword | Total size of all attachements in bytes |
+| `email.bcc.addresses` | wildcard | Addresses of Bcc's |
+| `email.cc.addresses` | wildcard | Addresses of Cc's |
+| `email.attachments_count` | long | A field outside the flattened structure to control how many attachments are included in the email |
+| `email.attachments` | flattened | A flattened field for anything related to attachments. This allows objects being stored with all information for each file when you have multiple attachments |
 | `email.direction` | keyword | Direction of the message based on the sending and receving domains |
-| `email.from.address` | keyword | Senders email address |
-| `email.from.domain` | keyword | Senders domain |
-| `email.latency` | keyword | The time, in milliseconds, the delivery attempt took |
+| `email.sender.address` | wildcard | Senders email address |
+| `email.sender.top_level_domain` | keyword | Senders email address |
 | `email.message_id` | keyword | Internet message ID of the message |
-| `email.process` | keyword | Name of the executable that carried out the transaction, e.g. outlook, sendmail |
-| `email.protocol` | keyword | The email protocol used, e.g. SMTP, IMAP |
-| `email.reply_to.address` | keyword | Reply-to address |
-| `object.return.address` | keyword | The return address for the message |
+| `email.reply_to.address` | wildcard | Reply-to address |
+| `email.return.address` | wildcard | The return address for the message |
 | `email.size` | keyword | Total size of the message, in bytes, including attachments |
-| `email.subject` | keyword | Subject of the message |
-| `email.to` | keyword | Recipieint address |
-| `email.to.domain` | keyword | Recipient domain |
+| `email.subject` | wildcard | Subject of the message |
+| `email.recipients.addresses` | keyword | Recipient addresses |
+| `email.domains` | keyword | domains related to the email |
+
+
+Other ECS fields used together with email usecases:
+| field | description |
+| --- | --- |
+| `event.duration` | The duration related to the email event. Could be the total duration in Quarantine, how long the email tok to send from source to destination etc |
+| `process.name` | When the event is related to a server or client. Does not take MTA into account which is part of a ongoing discussion |
+| `network.protocol` | Type of email protocol used |
+| `tls.*` | Used for TLS related information for the connection to for example a SMTP server over TLS |
+
+
 
 ## Usage
 
@@ -112,8 +115,8 @@ People
 
 The following are the people that consulted on the contents of this RFC.
 
-Jamie Hynds | author
-TBD | Sponsor
+Marius Iversen | Author
+Jamie Hynds | Sponsor
 
 <!--
 Who will be or has been consulted on the contents of this RFC? Identify authorship and sponsorship, and optionally identify the nature of involvement of others. Link to GitHub aliases where possible. This list will likely change or grow stage after stage.
@@ -136,7 +139,7 @@ e.g.:
 
 <!-- An RFC should link to the PRs for each of it stage advancements. -->
 
-* Stage 0: https://github.com/elastic/ecs/pull/NNN
+* Stage 0: https://github.com/elastic/ecs/pull/999
 
 <!--
 * Stage 1: https://github.com/elastic/ecs/pull/NNN

From 6a8af8fa05b0b9074aab38d6684205adb4c71124 Mon Sep 17 00:00:00 2001
From: P1llus <pillus@chasenet.org>
Date: Tue, 10 Nov 2020 21:54:30 +0100
Subject: [PATCH 3/7] adding different topics under concerns

---
 rfcs/text/0008-email.md | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index 20a8c61957..a760b65e93 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -34,7 +34,7 @@ Email specific fields:
 | `email.sender.top_level_domain` | keyword | Senders email address |
 | `email.message_id` | keyword | Internet message ID of the message |
 | `email.reply_to.address` | wildcard | Reply-to address |
-| `email.return.address` | wildcard | The return address for the message |
+| `email.return_path.address` | wildcard | The return address for the message |
 | `email.size` | keyword | Total size of the message, in bytes, including attachments |
 | `email.subject` | wildcard | Subject of the message |
 | `email.recipients.addresses` | keyword | Recipient addresses |
@@ -44,7 +44,7 @@ Email specific fields:
 Other ECS fields used together with email usecases:
 | field | description |
 | --- | --- |
-| `event.duration` | The duration related to the email event. Could be the total duration in Quarantine, how long the email tok to send from source to destination etc |
+| `event.duration` | The duration related to the email event. Could be the total duration in Quarantine, how long the email took to send from source to destination etc |
 | `process.name` | When the event is related to a server or client. Does not take MTA into account which is part of a ongoing discussion |
 | `network.protocol` | Type of email protocol used |
 | `tls.*` | Used for TLS related information for the connection to for example a SMTP server over TLS |
@@ -92,6 +92,12 @@ The goal here is to research and understand the impact of these changes on users
 <!--
 Stage 1: Identify potential concerns, implementation challenges, or complexity. Spend some time on this. Play devil's advocate. Try to identify the sort of non-obvious challenges that tend to surface later. The goal here is to surface risks early, allow everyone the time to work through them, and ultimately document resolution for posterity's sake.
 -->
+Current concerns or topics still being discussed from stage 1:
+
+- Whether we want to add specific fields for email protocols, either as a root field or nested under email.* (SMTP, IMAP, POP etc).
+- Need to make sure that the ECS fieldset for email catches all common usecases, for example spam, metrics and deliverables and logging.
+- Whether we want to create a new event.category field (email) and which event.type it should be combined with.
+- The email RFC will be the first ECS fieldset that uses the flattened datatype (for attachments), need to ensure that there will be major issues related to this.
 
 <!--
 Stage 2: Document new concerns or resolutions to previously listed concerns. It's not critical that all concerns have resolutions at this point, but it would be helpful if resolutions were taking shape for the most significant concerns.
@@ -115,8 +121,8 @@ People
 
 The following are the people that consulted on the contents of this RFC.
 
-Marius Iversen | Author
-Jamie Hynds | Sponsor
+@p1llus | Author
+@jamiehynds | Sponsor
 
 <!--
 Who will be or has been consulted on the contents of this RFC? Identify authorship and sponsorship, and optionally identify the nature of involvement of others. Link to GitHub aliases where possible. This list will likely change or grow stage after stage.

From a92a9d3fb1981d14d355fb7e7c94ff2f96bec289 Mon Sep 17 00:00:00 2001
From: P1llus <pillus@chasenet.org>
Date: Tue, 10 Nov 2020 23:51:25 +0100
Subject: [PATCH 4/7] adding event.start and event.end

---
 rfcs/text/0008-email.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index a760b65e93..62fe718677 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -45,6 +45,8 @@ Other ECS fields used together with email usecases:
 | field | description |
 | --- | --- |
 | `event.duration` | The duration related to the email event. Could be the total duration in Quarantine, how long the email took to send from source to destination etc |
+| `event.start` | When the email event started
+| `event.end` | When the email event ended
 | `process.name` | When the event is related to a server or client. Does not take MTA into account which is part of a ongoing discussion |
 | `network.protocol` | Type of email protocol used |
 | `tls.*` | Used for TLS related information for the connection to for example a SMTP server over TLS |

From f11dea090d918ed2119968195fe4c4c43955bbc3 Mon Sep 17 00:00:00 2001
From: P1llus <pillus@chasenet.org>
Date: Wed, 11 Nov 2020 13:24:54 +0100
Subject: [PATCH 5/7] updating field type and adding new domain fields for
 sender

---
 rfcs/text/0008-email.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index 62fe718677..de2012ba13 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -31,11 +31,14 @@ Email specific fields:
 | `email.attachments` | flattened | A flattened field for anything related to attachments. This allows objects being stored with all information for each file when you have multiple attachments |
 | `email.direction` | keyword | Direction of the message based on the sending and receving domains |
 | `email.sender.address` | wildcard | Senders email address |
-| `email.sender.top_level_domain` | keyword | Senders email address |
+| `email.sender.domain` | wildcard | Domain of the sender |
+| `email.sender.top_level_domain` | keyword | Top level domain of the sender |
+| `email.sender.registered_domain` | wildcard | Registered domain of the sender |
+| `email.sender.subdomain` | keyword | Subdomain of the sender |
 | `email.message_id` | keyword | Internet message ID of the message |
 | `email.reply_to.address` | wildcard | Reply-to address |
 | `email.return_path.address` | wildcard | The return address for the message |
-| `email.size` | keyword | Total size of the message, in bytes, including attachments |
+| `email.size` | long | Total size of the message, in bytes, including attachments |
 | `email.subject` | wildcard | Subject of the message |
 | `email.recipients.addresses` | keyword | Recipient addresses |
 | `email.domains` | keyword | domains related to the email |

From fe4e18bbb18a5d3a03e38ca2402febec3d2295f6 Mon Sep 17 00:00:00 2001
From: P1llus <pillus@chasenet.org>
Date: Thu, 26 Nov 2020 06:20:31 +0100
Subject: [PATCH 6/7] updating rfc based on comments from @webmat to push it
 into stage 2

---
 rfcs/text/0008-email.md | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index de2012ba13..f53fef80bf 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -25,8 +25,8 @@ Email specific fields:
 
 | field | type | description |
 | --- | --- | --- |
-| `email.bcc.addresses` | wildcard | Addresses of Bcc's |
-| `email.cc.addresses` | wildcard | Addresses of Cc's |
+| `email.bcc.addresses` | `wildcard[]` | Addresses of Bcc's |
+| `email.cc.addresses` | `wildcard[]` | Addresses of Cc's |
 | `email.attachments_count` | long | A field outside the flattened structure to control how many attachments are included in the email |
 | `email.attachments` | flattened | A flattened field for anything related to attachments. This allows objects being stored with all information for each file when you have multiple attachments |
 | `email.direction` | keyword | Direction of the message based on the sending and receving domains |
@@ -40,8 +40,8 @@ Email specific fields:
 | `email.return_path.address` | wildcard | The return address for the message |
 | `email.size` | long | Total size of the message, in bytes, including attachments |
 | `email.subject` | wildcard | Subject of the message |
-| `email.recipients.addresses` | keyword | Recipient addresses |
-| `email.domains` | keyword | domains related to the email |
+| `email.recipients.addresses` | `keyword[]` | Recipient addresses |
+| `email.domains` | `keyword[]` | domains related to the email |
 
 
 Other ECS fields used together with email usecases:
@@ -122,12 +122,12 @@ Stage 4: Document any new concerns and their resolution. The goal here is to eli
 Stage 4: Identify at least one real-world, production-ready implementation that uses these updated field definitions. An example of this might be a GA feature in an Elastic application in Kibana.
 -->
 
-People
+## People
 
 The following are the people that consulted on the contents of this RFC.
 
-@p1llus | Author
-@jamiehynds | Sponsor
+* @p1llus | Author
+* @jamiehynds | Sponsor
 
 <!--
 Who will be or has been consulted on the contents of this RFC? Identify authorship and sponsorship, and optionally identify the nature of involvement of others. Link to GitHub aliases where possible. This list will likely change or grow stage after stage.
@@ -146,11 +146,19 @@ e.g.:
 
 <!-- Insert any links appropriate to this RFC in this section. -->
 
+- [Hubspot](https://legacydocs.hubspot.com/docs/methods/email/email_events_overview)
+- [O365 Message Tracing](https://docs.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/run-a-message-trace-and-view-results)
+- [Postfix](https://nxlog.co/documentation/nxlog-user-guide/postfix.html)
+- [Barracuda](https://campus.barracuda.com/product/emailsecuritygateway/doc/12193950/syslog-and-the-barracuda-email-security-gateway/)
+- [Forcepoint](https://www.websense.com/content/support/library/email/v85/email_siem/siem_log_map.pdf)
+- [Mimecast](https://www.mimecast.com/tech-connect/documentation/tutorials/understanding-siem-logs/)
+- [Proofpoint](https://help.proofpoint.com/Threat_Insight_Dashboard/API_Documentation/SIEM_API)
+
 ### RFC Pull Requests
 
 <!-- An RFC should link to the PRs for each of it stage advancements. -->
 
-* Stage 0: https://github.com/elastic/ecs/pull/999
+* Stage 1: https://github.com/elastic/ecs/pull/999
 
 <!--
 * Stage 1: https://github.com/elastic/ecs/pull/NNN

From f10cf036034f4a9f42254400514e05e89e156f3e Mon Sep 17 00:00:00 2001
From: Mathieu Martin <webmat@gmail.com>
Date: Mon, 30 Nov 2020 10:57:05 -0500
Subject: [PATCH 7/7] Set the merge date

---
 rfcs/text/0008-email.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/text/0008-email.md b/rfcs/text/0008-email.md
index f53fef80bf..e7c15c8f7e 100644
--- a/rfcs/text/0008-email.md
+++ b/rfcs/text/0008-email.md
@@ -2,7 +2,7 @@
 <!-- Leave this ID at 0000. The ECS team will assign a unique, contiguous RFC number upon merging the initial stage of this RFC. -->
 
 - Stage: **1 (proposal)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
-- Date: **Oct 5th 2020** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
+- Date: **2020-11-30** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
 
 This RFC proposes a new top-level field to facilitate email use cases.