Subject: [dmarc-ietf] 5.7.1 - Mulitple FROM

From: Douglas Foster <[email-masked]>
Date: Thu, 9 Dec 2021 06:27:08 -0500

I have trouble with this statement in section 5.7.1:

"Multi-valued RFC5322.From header fields with multiple domains MUST be
exempt from DMARC checking."

This language will serve as an invite for spammers to create multiple-from
messages to ensure that they will evade DMARC.   To avoid creating security
holes, we need to bring this configuration within scope.   Here is a
proposal:

To ensure DMARC PASS, senders MUST ensure that each RFC5322.From address
evaluates to a PASS result independently.   Evaluators may choose to
evaluate one, some, or all of the addresses.   For example, evaluators may
choose to evaluate to the first Fail result, and then
disposition the message based on that failure.   RFC5322 does not specify a
maximum number of allowed From addresses, but evaluators may choose to
impose a limit to prevent abuse of evaluator resources.  DMARC reporting is
based on the single RFC5322.From address which is most important for the
evaluator's disposition decision.

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Thu, 9 Dec 2021 11:12:49 -0500

> evaluator's disposition decision.
The entire paragraph from which that sentence was pulled reads:

The case of a syntactically valid multi-valued RFC5322.From header field
presents a particular challenge. When a single RFC5322.From header field
contains multiple addresses, it is possible that there may be multiple
domains used in those addresses. The process in this case is to only
proceed with DMARC checking if the domain is identical for all of the
addresses in a multi-valued RFC5322.From header field. Multi-valued
RFC5322.From header fields with multiple domains MUST be exempt from DMARC
checking.

In the case where DMARC checking is not performed, there will be no DMARC
pass.

If you believe DMARC to be a security tool, why do you deem a case with no
DMARC pass to be a security hole, when the absence of a pass should put the
message in a weaker position than one where there is a pass?

The text at issue here is, as I recall, designed to address concerns
regarding this text in RFC 7489:

6.6.1 <https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1>.
Extract Author Domain

   The domain in the RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field is
extracted as the domain to be
   evaluated by DMARC.  If the domain is encoded with UTF-8, the domain
   name must be converted to an A-label, as described in Section 2.3 of
   [IDNA <https://datatracker.ietf.org/doc/html/rfc7489#ref-IDNA>],
for further processing.

   In order to be processed by DMARC, a message typically needs to
   contain exactly one RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From domain (a single
From: field with a
   single domain in it).  Not all messages meet this requirement, and
   handling of them is outside of the scope of this document.  Typical
   exceptions, and the way they have been historically handled by DMARC
   participants, are as follows:

   o  Messages with multiple RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From fields are
typically rejected,
      since that form is forbidden under RFC 5322
<https://datatracker.ietf.org/doc/html/rfc5322> [MAIL
<https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>];

   o  Messages bearing a single RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field containing
multiple
      addresses (and, thus, multiple domain names to be evaluated) are
      typically rejected because the sorts of mail normally protected by
      DMARC do not use this format;

   o  Messages that have no RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field at all are
typically
      rejected, since that form is forbidden under RFC 5322
<https://datatracker.ietf.org/doc/html/rfc5322> [MAIL
<https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>];

   o  Messages with an RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field that
contains no meaningful
      domains, such as RFC 5322
<https://datatracker.ietf.org/doc/html/rfc5322> [MAIL
<https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>]'s "group"
syntax, are typically
      ignored.

   The case of a syntactically valid multi-valued RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field
   presents a particular challenge.  The process in this case is to
   apply the DMARC check using each of those domains found in the
   RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field
as the Author Domain and apply the most strict
   policy selected among the checks that fail.

That final paragraph opens up DMARC supporting receivers to denial of
service attacks, since a bad guy could possibly construct a From: header
field that is syntactically valid with many many domains, causing the DMARC
validator to attempt to look up each domain, just as you're proposing here.
What if there were ten, twenty, or one hundred domains?

To mitigate the risk of the denial of service, the text was proposed that
the only time to support multiple From addresses is when all domains are
the same.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2021 11:46:58 -0500

>In the case where DMARC checking is not performed, there will be no DMARC

We ratholed on this the last time around.  Non-malicious messages with
multiple From addresses are very rare, and messages with addresses in
different domains are rarer still.  I agree it makes sense to punt
on the latter, since they basically don't exist.

I wouldn't mind even saying that messages with more than one address
on the From: line are never aligned, but there are so few it's a tiny
corner case.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Dec 2021 08:56:05 -0800

On Thu, Dec 9, 2021 at 3:27 AM Douglas Foster <
[email-masked]> wrote:

> messages to ensure that they will evade DMARC.
>

As Todd points out, the best an attacker can hope for in this situation is
to earn a DMARC "none".  It can't get them a "pass".

I can see "exempt" as indicating to some readers a bypass of some kind,
however.  Underscoring the distinction between "none" and "pass" might be
useful.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Thu, 9 Dec 2021 23:11:28 -0500

Thanks for your comments.

The language in the quoted document about "multiple from messages are
usually rejected" was interesting.   It reflects what I would intend to do,
and what I think others should do, but I assumed that we could not
explicitly advocate for that, since we could be accused of rewriting
RFC5322.   That language does not appear to have been repeated, so I guess
we have successfully danced around that part of the problem.

I flinch at using MUST or SHOULD on instructions about how evaluators can
collect and use data for purposes of message evaluation.   These directives
should be used for situations where a violation has a high likelihood of
hurting the actor ("You MUST NOT publish DKIM private keys in DNS") or hurt
others ("You MUST NOT operate as an open relay.")   If we are going to
constrain with good reason, we need to be clear about the reason.  For this
case, I would add something to explain the directive, such as:

"Any attempt to evaluate multiple author domains would create excessively
complexity in software while introducing a denial of service attack
vector.  Therefore, evaluators SHOULD not do so."

For result classification, I would punt this way:
"Local policy can choose whether to treat such messages as NONE, PERMERROR,
or FAIL."

Doug

On Thu, Dec 9, 2021 at 11:13 AM Todd Herr <todd.herr=
[email-masked]> wrote:

>> This language will serve as an invite for spammers to create
>> multiple-from messages to ensure that they will evade DMARC.   To avoid
>> creating security holes, we need to bring this configuration within scope.
>>  Here is a proposal:
>>
> The case of a syntactically valid multi-valued RFC5322.>From header field
> 6.6.1 <https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1>.  Extract Author Domain
>
>    The domain in the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field is extracted as the domain to be
>    [IDNA <https://datatracker.ietf.org/doc/html/rfc7489#ref-IDNA>], for further processing.
>
>    contain exactly one RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain (a single From: field with a
>    o  Messages with multiple RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From fields are typically rejected,
>       since that form is forbidden under RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>];
>
>    o  Messages bearing a single RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field containing multiple
>    o  Messages that have no RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field at all are typically
>       rejected, since that form is forbidden under RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>];
>
>    o  Messages with an RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field that contains no meaningful
>       domains, such as RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>]'s "group" syntax, are typically
>       ignored.
>
>    The case of a syntactically valid multi-valued RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field
>    RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field as the Author Domain and apply the most strict
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Dec 2021 19:46:34 +0100

On Fri 10/Dec/2021 05:11:28 +0100 Douglas Foster wrote:
> 
> The language in the quoted document about "multiple from messages are usually 
> rejected" was interesting.   It reflects what I would intend to do, and what I 
> think others should do, but I assumed that we could not explicitly advocate for 
> that, since we could be accused of rewriting RFC5322.

Indeed!  RFC5322 explicitly allows multiple mailboxes:

    from            =   "From:" mailbox-list CRLF

    sender          =   "Sender:" mailbox CRLF

To completely disallow that syntax seems too harsh.  It is true that finding 
multiple authors is extremely improbable.  However, it may happen to have to 
compose a message with multiple authors, possibly because of legal attribution. 
  In that case, being at a loss for proper authentication makes DMARC look like 
a sort of toy specification.

We can be very stern.  For example, we can require that the domain of the first 
author coincides with the domain of the Sender:, and validate the message as if 
that was the only author domain.  Very stern, but not overly stern.

Can we fix this inadequacy?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Dec 2021 13:58:48 -0500

On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote:
> > usually rejected" was interesting.   It reflects what I would intend to
> > do, and what I think others should do, but I assumed that we could not
> > RFC5322.
> multiple authors is extremely improbable.  However, it may happen to have
> to compose a message with multiple authors, possibly because of legal
> attribution. In that case, being at a loss for proper authentication makes
> DMARC look like a sort of toy specification.
> 
> We can be very stern.  For example, we can require that the domain of the
> first author coincides with the domain of the Sender:, and validate the
> message as if that was the only author domain.  Very stern, but not overly
> stern.
> 

Ordering isn't guaranteed to be preserved.  I think the options are:

1.  Do not test for DMARC (current, no backward compatibility issues, but 
incomplete coverage).

2.  Test both and one must not fail (not clear if there are backward 
compatibility or reporting issues, doesn't solve incomplete coverage)

3.  Test both and both must not fail (probably not backward compatible, would 
need to figure out reporting, but does solve the "inadequacy").

Given the rarity of multi-From messages and that anything with backward 
compatibility issues should have a high hurdle to clear for inclusion, I don't 
think there's a good case for anything other than leave it as is.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Dec 2021 20:14:36 +0100

On Fri 10/Dec/2021 19:58:48 +0100 Scott Kitterman wrote:
>> RFC5322 explicitly allows multiple mailboxes:
>> 
> Ordering isn't guaranteed to be preserved.  

Requiring that it be preserved is part of being stern.  The attack path would 
consist in putting a second, validated author in such a way that it goes 
unnoticed in a (specific) MUA display.  The first author is unlikely to get 
unnoticed, and we require it to be confirmed by the Sender: field (half the way 
toward Dave's proposal.)

> need to figure out reporting, but does solve the "inadequacy").

Case 3 is the most complete and secure choice, but it complicates 
implementations and, given the rarity, will likely be buggy.

Backward compatibility is not a worry in this case.

> think there's a good case for anything other than leave it as is.

Leaving it as is, case 0, is the worst option.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Fri, 10 Dec 2021 14:18:47 -0500

> think there's a good case for anything other than leave it as is.
To be clear, what's "current" is what's in RFC 7489, which reads:

Option 1 above is proposed in DMARCbis as a way to mitigate the risk of a
DoS attack by a bad guy inserting a From: header with umpteen domains, each
of which would have to be checked.

--

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Dec 2021 14:24:12 -0500

On Friday, December 10, 2021 2:14:36 PM EST Alessandro Vesely wrote:
> >> To completely disallow that syntax seems too harsh.  It is true that
> >> finding multiple authors is extremely improbable.  However, it may
> >> happen to have to compose a message with multiple authors, possibly
> >> because of legal attribution. In that case, being at a loss for proper
> >> authentication makes DMARC look like a sort of toy specification.
> >> 
> Requiring that it be preserved is part of being stern.  The attack path
> would consist in putting a second, validated author in such a way that it
> goes unnoticed in a (specific) MUA display.  The first author is unlikely
> to get unnoticed, and we require it to be confirmed by the Sender: field
> (half the way toward Dave's proposal.)

That's outside the scope of DMARC.  This effort needs to work with email the 
way it's specified now, not how we wish it to be specified.  If you want to 
change the specification of the 5322.From, this isn't the working group you 
want.  Emailcore is over there --->.

> > 3.  Test both and both must not fail (probably not backward compatible,
> > would need to figure out reporting, but does solve the "inadequacy").
> 

Yes, it is.  You don't know if anyone is relying on the fact that RFC 7489 
specifies that DMARC is not checked on multi-from messages, so you have no idea 
what you would break.
> > compatibility issues should have a high hurdle to clear for inclusion, I
> > don't think there's a good case for anything other than leave it as is.
> 

As I understand it, this "hole" in the specification has existed for years and 
it's not commonly used to "bypass" DMARC.  If that's not correct, let's see 
some data to that effect.  If it is correct, why do you think it will change 
and this will become a problem in the future?

We have enough actual problems to solve without getting diverted fixing things 
that aren't a problem.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Dec 2021 14:26:08 -0500

On Friday, December 10, 2021 2:18:47 PM EST Todd Herr wrote:
> > would
> > don't

Thanks.  I had lost track of that.

In that case it might be better to impose a limit (two maybe) to check rather 
than toss out the check entirely?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Dec 2021 14:27:58 -0500

On Friday, December 10, 2021 2:24:12 PM EST Scott Kitterman wrote:
> specifies that DMARC is not checked on multi-from messages, so you have no
> idea what you would break.
> 
> As I understand it, this "hole" in the specification has existed for years
> and it's not commonly used to "bypass" DMARC.  If that's not correct, let's
> see some data to that effect.  If it is correct, why do you think it will
> change and this will become a problem in the future?
> 
> We have enough actual problems to solve without getting diverted fixing
> things that aren't a problem.

So, based on Todd's email that I failed to read before I sent this, please 
ignore this.  It's wrong.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Dec 2021 14:45:29 -0500

>than toss out the check entirely?

Seems like a quality of implmentation issue.  Given the volume of mail that flows through
servers these days, it seems very implausible that you could cause any new damage by putting
a few more domains to test in a From header.  DMARC has been around for the better part of a
decade so I think we can assume someone will already have tried any useful attack.

As a practical matter, I have seen very few messages with more than one address and I don't
think I've ever seen a message with more than two other than as to prove it's possible.  So if
one decided to toss anything with three addresses into the bin without even doing other checks,
I suspect nobody would even notice.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Dec 2021 17:33:09 -0500

On Friday, December 10, 2021 2:45:29 PM EST John Levine wrote:
> >In that case it might be better to impose a limit (two maybe) to check
> >rather than toss out the check entirely?
> 
> Seems like a quality of implmentation issue.  Given the volume of mail that
> flows through servers these days, it seems very implausible that you could
> cause any new damage by putting a few more domains to test in a From
> header.  DMARC has been around for the better part of a decade so I think
> we can assume someone will already have tried any useful attack.
> 
> As a practical matter, I have seen very few messages with more than one
> address and I don't think I've ever seen a message with more than two other
> than as to prove it's possible.  So if one decided to toss anything with
> three addresses into the bin without even doing other checks, I suspect
> nobody would even notice.

I agree.  I think we should go back to the RFC 7489 text and call it done.  If 
someone is really worried they can write something for the security 
considerations to remind people not to let themselves get DOS'ed.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Fri, 10 Dec 2021 23:29:22 -0500

I suggest that it is time to propose that RFC 5322 section 3.6.2 be revised
to drop support for multiple From fields.   The market has clearly spoken
that there the feature is not needed.   Every MUA that I have used is
designed to solicit From and Friendly Name as separate and
single-occurrence fields.   Similarly, those MUAs present Friendly Name and
>From as separate fields, with no evidence that they are designed or tested
for lists.

On the technical side, From headers are difficult to parse even with a
single address.   The address is not consistently enclosed in angle
brackets, and the Friendly Name is not reliability enclosed in quotes.
Then one has to add the complexity associated with internationalization,
and the possibility of local-parts that are quoted strings.   I cannot help
expecting that some multi-address From lists will simply be mistaken as a
complex Friendly Name with a single From address.

Of course, an RFC 5322 revision will not happen quickly if ever, and we do
not wish to hold our document or our breath waiting for that to happen.
But I would like the issue documented.

For our document, I think the chairs need to answer the question, can we
mimic RFC 7489 by having text that deprecates address lists, as long as we
don't prohibit it?   I am thinking something like this

"Senders should be aware that although RFC5322 allows a message list, few
messages actually have more than one address, and as a result recipients
may not recognize or accept messages with multiple From addresses."

For evaluators that want to both accept such messages and fully evaluate
them, it is impossible to argue against checking every address as the most
complete security review.   In that since RFC 7489 is correct.

But I prefer language that says to evaluators, "if you want to accept these
messages, do it any way you want since it is at your own risk"   Otherwise,
product developers may put a lot of effort into code that is rarely used
and poorly tested, simply to comply with the specification.

For reporting purposes, I think we can require that only one address be
used per message, if such messages are reported at all.

Doug

I

---

From: Alessandro Vesely <[email-masked]>, Coauthor Test <[email-masked]>
Date: Mon, 13 Dec 2021 11:42:24 +0100

Hi Doug,

On Sat 11/Dec/2021 05:29:22 +0100 Douglas Foster wrote:
> I suggest that it is time to propose that RFC 5322 section 3.6.2 be revised to 
> drop support for multiple From fields.

As Scott noted, Emailcore mailing list is next door.

> The market has clearly spoken that there the feature is not needed.

No, the market didn't speak.  The fact that most messages have a single From: 
address happens because of the typical typing context of one author using one 
device.

Occasionally, it happens to share authoring with a coauthor.  Even then, unless 
it is important for formal attribution of authorship, the typing author often 
omits to add the coauthor in the proper field.  If it /is/ important, however, 
it'd better be supported.

> Every MUA that I have used is designed to solicit From and Friendly Name as 
> separate and single-occurrence fields. Similarly, those MUAs present 
> Friendly Name and From as separate fields, with no evidence that they are 
> designed or tested for lists.

I'm using a stock Thunderbird package with average settings.  It allows adding 
coauthor, as in this case, and presents it by appending "et al." to the 
friendly name in the message list pane.

> On the technical side, From headers are difficult to parse even with a single 
> address.   The address is not consistently enclosed in angle brackets, and the 
> Friendly Name is not reliability enclosed in quotes.    Then one has to add the 
> complexity associated with internationalization, and the possibility of 
> local-parts that are quoted strings.   I cannot help expecting that some 
> multi-address From lists will simply be mistaken as a complex Friendly Name 
> with a single From address.

That's right.  Typos happen every time.

> Of course, an RFC 5322 revision will not happen quickly if ever, and we do not 
> wish to hold our document or our breath waiting for that to happen.  But I 
> would like the issue documented.

See also RFC 6854, Update to Internet Message Format to Allow Group Syntax in 
the "From:" and "Sender:" Header Fields.

> For our document, I think the chairs need to answer the question, can we mimic 
> RFC 7489 by having text that deprecates address lists, as long as we don't 
> prohibit it?   I am thinking something like this
> 
>     "Senders should be aware that although RFC5322 allows a message list,
>      few messages actually have more than one address, and as a result
>      recipients may not recognize or accept messages with multiple From
>      addresses."

That's cheating!  Recipients seem to recognize messages with multiple From: 
addresses very well.  It is our protocol which is lacking.

> For evaluators that want to both accept such messages and fully evaluate them, 
> it is impossible to argue against checking every address as the most complete 
> security review.   In that since RFC 7489 is correct.
> 
> product developers may put a lot of effort into code that is rarely used and 
> poorly tested, simply to comply with the specification.

To minimize changes is why I propose to validate only the first address.  The 
validating software may recognize that there's a comma, presumably followed by 
other mailboxes, and just disregard it.  Much like the usual path.

Still, focusing on the first mailbox is consistent with the DMARC choice of 
From: for its visibility.  Thunderbird, for example, requires extra clicks to 
display further addresses.

> For reporting purposes, I think we can require that only one address be used 
> per message, if such messages are reported at all.

As long as only one domain per message is authenticated, no change is needed 
for reporting.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Mon, 13 Dec 2021 08:36:13 -0500

On Fri, Dec 10, 2021 at 11:29 PM Douglas Foster <
[email-masked]> wrote:

> I suggest that it is time to propose that RFC 5322 section 3.6.2 be
> revised to drop support for multiple From fields.   The market has clearly
> spoken that there the feature is not needed.   Every MUA that I have used
> is designed to solicit From and Friendly Name as separate and

The IETF emailcore working group is actively engaged in updates to RFCs
5321 and 5322. It would be much more appropriate for your suggestion to be
documented there, I think.

https://datatracker.ietf.org/wg/emailcore/about/

--