Add email.return_path.address

[ebeahan]

Overview

As described in #1934, security analysts find the Return-Path header useful for examining email events, and the field is a good addition to the email.* field set.

Open questions

RFC 5322 Return-Path holding a single value, so I've created email.return_path.address to expect only one value.

Any known use cases where Return-Path would hold more than one value, and would it benefit return_path.address to hold an array of values?

Resolves #1934

[ebeahan]

Any known use cases where Return-Path would hold more than one value, and would it benefit return_path.address to hold an array of values?

@MarkVanAcker, from your experiences, do Return-Path headers ever contains > 1 address?

[MarkVanAcker]

@ebeahan thank you for working on this so quickly. According to the RFC:

A message-originating SMTP system SHOULD NOT send a message that
already contains a Return-path header field. SMTP servers performing
a relay function MUST NOT inspect the message data, and especially
not to the extent needed to determine if Return-path header fields
are present. SMTP servers making final delivery MAY remove Return-
path header fields before adding their own.

It is not supposed to have > 1 addresses nor have I experienced this, but in theory a badly coded SMTP client could add it. For this reason allowing an array of values would be beneficial to detect anomalies.

[ebeahan]

Updated change to set normalize: [ 'array' ] for email.return_path.address. PR is ready for a review.

[djptek]

For this reason allowing an array of values would be beneficial to detect anomalies.

I'm not sure about this, it sets a theoretical precedent for permitting an Array of almost any field in order to detect anomalies.

@MarkVanAcker have you seen any example in the field where this occurs, otherwise would it be possible to detect such potential anomalies in the process of mapping to ECS rather than after the fact?

[MarkVanAcker]

@djptek As per RFC, a SMTP system should not send a message that already contains a return-path header and may remove the previous return-path before adding its own. Depending on how you interpret that last line, having multiple entries is thus not forbidden by the RFC, but rather not recommended. From a theoretical perspective, making this an array seems sound to me.

However, I have never seen any example of this behavior. I also don't know how modern mail servers behave when dealing with multiple return-paths.

We map our fields to ECS before they enter the Elastic SIEM, so detecting anomalies before that would be a bit tricky.

[MarkVanAcker]

@ebeahan Any updates on the progress of this change?

[github-actions]

This PR is stale because it has been open for 60 days with no activity.