Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Sun 11/Feb/2024 01:47:12 +0100 Scott Kitterman wrote:

On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:

On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton  wrote:


This actually concerns me a bit. If having multiple From: addresses causes 
a message to be out of scope for DMARC and therefore bypass a p=reject 
policy, that sounds like a reason that attackers might start sending 
messages with multiple From: addresses in order to accomplish that.


[...]

If we decide we need to make DMARC bulletproof even in this case, then 
perhaps the move is indeed to codify the "check them all" logic that's been 
suggested.  But I don't think we can say in this document that multi-valued 
From is no longer valid; that's perhaps in EMAILCORE's scope, not in ours.


[...]

I suggest we put in some non-normative words about check them all and move on. 
Let's throw this thing over the finish line.



The text in RFC 7489 is clear and terse.  I suggest we copy that paragraph 
verbatim.


Additionally, we could add a note about the max number of domains, for example:

To limit potential denial-of-service attacks, Verifiers MAY limit
the total number of domains they will attempt to verify.

(That is similar to what DKIM says about signatures,
 https://datatracker.ietf.org/doc/html/rfc6376#section-4.2)


Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

I have been thinking about the other way that an attacker could have two
>From addresses:  by having two From headers.Not a problem as long as
the evaluator rejects the message based on standards violation.

But what if the evaluator does not test for dual headers because the
configuration is so unexpected?   The DKIM logic will evaluate the
bottommost From hader, and may be able to produce DMARC PASS or NoPolicy
based on that From address.   But then the MUA might display the
uppermost From address, or a combination of the two, allowing the recipient
to be deceived.

Google prevents this type of attack by oversigning the From header, which
is a best practice, but it is not a universal practice.

Therefore, I suggest that a sentence is worthwhile to remind evaluators to
enforce uniqueness of unique headers.

D.F.


On Sat, Feb 10, 2024 at 7:47 PM Scott Kitterman 
wrote:

> On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:
> > On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton 
> wrote:
> > > > No, it's perfectly fine to declare that DMARC only applies to certain
> > > > classes of messages.
> > >
> > > This actually concerns me a bit. If having multiple From: addresses
> causes
> > > a message to be out of scope for DMARC and therefore bypass a p=reject
> > > policy, that sounds like a reason that attackers might start sending
> > > messages with multiple From: addresses in order to accomplish that.
> >
> > What we said in RFC 7489, and what I think we're saying here, is that
> > experience (at the time of that RFC, at least) suggests that such
> messages,
> > even though they're legal by RFC 5322, tend to get dropped or rejected
> > before they get to any DMARC engine because they're considered unusual or
> > dangerous or some other concerning adjective, so it was sufficient to
> call
> > them out of scope.  I believe Gmail has indicated that messages that do
> > have a multi-valued From tend to clearly be spam or other abuse.
> >
> > What that tells me is that it would be reasonable for a receiver to
> discard
> > or reject them before they even get to DMARC, meaning we don't have to
> > worry about it in DMARC directly.
> >
> > If we decide we need to make DMARC bulletproof even in this case, then
> > perhaps the move is indeed to codify the "check them all" logic that's
> been
> > suggested.  But I don't think we can say in this document that
> multi-valued
> >
> > >From is no longer valid; that's perhaps in EMAILCORE's scope, not in
> ours.
>
> Are we waiting for anything else before WGLC?
>
> I suggest we put in some non-normative words about check them all and move
> on.
> Let's throw this thing over the finish line.
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Benny Pedersen]

Murray S. Kucherawy skrev den 2024-02-11 01:39:


-MSK, participating


Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

avoid this on maillists please

why is stupid mua using quoted-printable while its html ?, i dont blame 
anyone from make silly msg standards for webpages



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Scott Kitterman]

On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote:
> On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton  wrote:
> > > No, it's perfectly fine to declare that DMARC only applies to certain
> > > classes of messages.
> > 
> > This actually concerns me a bit. If having multiple From: addresses causes
> > a message to be out of scope for DMARC and therefore bypass a p=reject
> > policy, that sounds like a reason that attackers might start sending
> > messages with multiple From: addresses in order to accomplish that.
> 
> What we said in RFC 7489, and what I think we're saying here, is that
> experience (at the time of that RFC, at least) suggests that such messages,
> even though they're legal by RFC 5322, tend to get dropped or rejected
> before they get to any DMARC engine because they're considered unusual or
> dangerous or some other concerning adjective, so it was sufficient to call
> them out of scope.  I believe Gmail has indicated that messages that do
> have a multi-valued From tend to clearly be spam or other abuse.
> 
> What that tells me is that it would be reasonable for a receiver to discard
> or reject them before they even get to DMARC, meaning we don't have to
> worry about it in DMARC directly.
> 
> If we decide we need to make DMARC bulletproof even in this case, then
> perhaps the move is indeed to codify the "check them all" logic that's been
> suggested.  But I don't think we can say in this document that multi-valued
> 
> >From is no longer valid; that's perhaps in EMAILCORE's scope, not in ours.

Are we waiting for anything else before WGLC?

I suggest we put in some non-normative words about check them all and move on.  
Let's throw this thing over the finish line.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton  wrote:

> > No, it's perfectly fine to declare that DMARC only applies to certain
> > classes of messages.
>
> This actually concerns me a bit. If having multiple From: addresses causes
> a message to be out of scope for DMARC and therefore bypass a p=reject
> policy, that sounds like a reason that attackers might start sending
> messages with multiple From: addresses in order to accomplish that.
>

What we said in RFC 7489, and what I think we're saying here, is that
experience (at the time of that RFC, at least) suggests that such messages,
even though they're legal by RFC 5322, tend to get dropped or rejected
before they get to any DMARC engine because they're considered unusual or
dangerous or some other concerning adjective, so it was sufficient to call
them out of scope.  I believe Gmail has indicated that messages that do
have a multi-valued From tend to clearly be spam or other abuse.

What that tells me is that it would be reasonable for a receiver to discard
or reject them before they even get to DMARC, meaning we don't have to
worry about it in DMARC directly.

If we decide we need to make DMARC bulletproof even in this case, then
perhaps the move is indeed to codify the "check them all" logic that's been
suggested.  But I don't think we can say in this document that multi-valued
>From is no longer valid; that's perhaps in EMAILCORE's scope, not in ours.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Jim Fenton]

On 5 Feb 2024, at 22:22, Murray S. Kucherawy wrote:

> No, it's perfectly fine to declare that DMARC only applies to certain
> classes of messages.

This actually concerns me a bit. If having multiple From: addresses causes a 
message to be out of scope for DMARC and therefore bypass a p=reject policy, 
that sounds like a reason that attackers might start sending messages with 
multiple From: addresses in order to accomplish that.

-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Tue 06/Feb/2024 07:22:49 +0100 Murray S. Kucherawy wrote:

On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely  wrote:

On 05/02/2024 00:29, Murray S. Kucherawy wrote:

On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:


RFC 7489 says this:

In order to be processed by DMARC, a message typically needs to
contain exactly one 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.

So I don't know what's different now versus when this was written to compel 
a change in posture.  So yes, I interpret this as saying "DMARC ignores it 
(if it even gets there)", and some other piece of the receiving engine can 
deal with it.


To me the more important thing is that this citation and yours:


The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.


...are in conflict, and that's what needs resolution.



The conflict is mitigated by the term "typically".  I understand it as 
referring to the subset of email messages that are typically dealt with by 
DMARC.  If, instead, a filter is going to authenticate /all/ messages, then it 
knows how to do it.



In DMARCbis (Section 5.7.1) we appear to have resolved that conflict and 
consider such messages out of scope, and DMARC processing ends.  I think 
that's a reasonable choice.


That choice poses a limit on DMARC that can be used as an attack surface.  I'm 
asking that we reconsider it.  I don't think that would take an immeasurable 
amount of time.  Why are we so reluctant?



What I don't think is that DMARC is the right place to make any 
proclamation that a multi-valued From should be rejected out of hand, or 
for any reason that is not derived from the DMARC algorithm.



What should a programmer who is following the RFC to code a DMARC filter do, 
then?  Exit with a return code saying "out of scope"?  I think a spec should 
say how to use.



Specify -> Implement -> Devise attacks.  It is not circular, although 
you can then have DMARCter...


I would prefer to iterate via a future DMARCter than continue to iterate 
on, and possibly never ship, DMARCbis.



After some doubts, it is clear that the 2nd RFC 7489 citation above is the only 
way to do multi-valued From:s.  It doesn't seem to need very long discussions 
to be reinserted in the I-D.  What problems would that cause?


Excluding multi-valued From: is a gratuitous limitation on DMARC's 
applicability.


RFC7489 seems to imply that DMARC is only used for a fraction of email 
messages, such as bank transactions.


Where do you observe such an implication?



For example, in the 1st RFC 7489 citation above ("typically").  The limitation 
is also anticipated in Section 5, where it talks about "the sorts of mail 
typically protected by DMARC participants".  It implies there are other sorts 
of mail.



If you as a receiver don't like the possible gap that creates, you're 
free to do something about it, but you're not doing so under any 
normative guidance from DMARC.


Isn't that a specification hole?


No, it's perfectly fine to declare that DMARC only applies to certain 
classes of messages.



If we confirm this choice, it must be said loud and clear at the top of the 
document.   (And you just asked where I observed the implication that DMARC is 
only used for a fraction of email...)



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 10:56 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> The evidence from Google is that multi-valued From DOES have usage and is
> usually malicious.   That should be sufficient evidence to conclude l that
> the security hole must be plugged, not ignored.
>

Perhaps, but you'll note that this has nothing to do with DMARC, making
this the wrong place to solve that problem.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely  wrote:

> On 05/02/2024 00:29, Murray S. Kucherawy wrote:
> > On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:
> >
> >>> What do we think has changed since then that warrants reconsidering
> that
> >>> position?  Have we started to see multi-value From attacks?
> >>
> >> A DMARC filter has to do something when it sees a multi-value From:.
> >
> > Why?  It hasn't so far (i.e., ~10 years).
>
> Not sure what you mean.  Certainly, a multi-value From: won't halt the
> filter process, so it has to do something.  What?  Skip the message as
> it is out of DMARC scope, which substantially means pass it?
>

RFC 7489 says this:

   In order to be processed by DMARC, a message typically needs to
   contain exactly one 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.

So I don't know what's different now versus when this was written to compel
a change in posture.  So yes, I interpret this as saying "DMARC ignores it
(if it even gets there)", and some other piece of the receiving engine can
deal with it.

To me the more important thing is that this citation and yours:


> The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
> policy selected among the checks that fail.
>

...are in conflict, and that's what needs resolution.  In DMARCbis (Section
5.7.1) we appear to have resolved that conflict and consider such messages
out of scope, and DMARC processing ends.  I think that's a reasonable
choice.

What I don't think is that DMARC is the right place to make any
proclamation that a multi-valued From should be rejected out of hand, or
for any reason that is not derived from the DMARC algorithm.

>> AFAIK, we just anticipated such attacks.  Their becoming trendy
> >> depends on how DMARC filters are going to be implemented.  The
> >> latter, in turn, depends on how we specify DMARC. >
> >
> > Is it just me, or does that sound like a circular dependency graph?
>
> Specify -> Implement -> Devise attacks.  It is not circular, although
> you can then have DMARCter...
>

I would prefer to iterate via a future DMARCter than continue to iterate
on, and possibly never ship, DMARCbis.

RFC7489 seems to imply that DMARC is only used for a fraction of email
> messages, such as bank transactions.


Where do you observe such an implication?


> > If you as a receiver don't like the possible gap that creates, you're
> > free to do something about it, but you're not doing so under any
> > normative guidance from DMARC.
>
> Isn't that a specification hole?
>

No, it's perfectly fine to declare that DMARC only applies to certain
classes of messages.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

The volume of  current attacks should not be a consideration, and
speculation about future risks is vacuous.  The industry routinely raises
C.V.Es against newly discovered and not-yet-exploited security holes, and
we should act the same way.

The evidence from Google is that multi-valued From DOES have usage and is
usually malicious.   That should be sufficient evidence to conclude l that
the security hole must be plugged, not ignored.

Doug

On Mon, Feb 5, 2024, 1:23 PM Alessandro Vesely  wrote:

> On 05/02/2024 00:29, Murray S. Kucherawy wrote:
> > On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:
> >
> >>> What do we think has changed since then that warrants reconsidering
> that
> >>> position?  Have we started to see multi-value From attacks?
> >>
> >> A DMARC filter has to do something when it sees a multi-value From:.
> >
> > Why?  It hasn't so far (i.e., ~10 years).
>
>
> Not sure what you mean.  Certainly, a multi-value From: won't halt the
> filter process, so it has to do something.  What?  Skip the message as
> it is out of DMARC scope, which substantially means pass it?
>
>
> > What's the evidence that we have something to fix here?  That is, why
> > is Section 6.6.1 of RFC 7489 suddenly inadequate?
>
> It is not:
>
> The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
> policy selected among the checks that fail.
>
> We're missing that statement in DMARCbis, aren't we?
>
>
> >> AFAIK, we just anticipated such attacks.  Their becoming trendy
> >> depends on how DMARC filters are going to be implemented.  The
> >> latter, in turn, depends on how we specify DMARC. >
> > Is it just me, or does that sound like a circular dependency graph?
>
>
> Specify -> Implement -> Devise attacks.  It is not circular, although
> you can then have DMARCter...
>
>
> >> Another concern is how acceptable it is to specify a standard which
> >> does not admit input which is perfectly valid according to a lower
> >> layer standard. Are they conflicting? >
> > I would argue that they are not.  DMARC can assert that it only acts on
> a
> > profile of the layers below it, and anything outside of that profile is
> > simply not within scope.
>
>
> RFC7489 seems to imply that DMARC is only used for a fraction of email
> messages, such as bank transactions.  Nowadays some domains are voicing
> to require authentication for each and every message.  A rather
> different scenario.
>
>
> > If you as a receiver don't like the possible gap that creates, you're
> > free to do something about it, but you're not doing so under any
> > normative guidance from DMARC.
>
>
> Isn't that a specification hole?
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On 05/02/2024 00:29, Murray S. Kucherawy wrote:

On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:

What do we think has changed since then that warrants reconsidering that 
position?  Have we started to see multi-value From attacks?


A DMARC filter has to do something when it sees a multi-value From:.


Why?  It hasn't so far (i.e., ~10 years).



Not sure what you mean.  Certainly, a multi-value From: won't halt the 
filter process, so it has to do something.  What?  Skip the message as 
it is out of DMARC scope, which substantially means pass it?



What's the evidence that we have something to fix here?  That is, why 
is Section 6.6.1 of RFC 7489 suddenly inadequate?


It is not:

   The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
   policy selected among the checks that fail.

We're missing that statement in DMARCbis, aren't we?


AFAIK, we just anticipated such attacks.  Their becoming trendy 
depends on how DMARC filters are going to be implemented.  The 
latter, in turn, depends on how we specify DMARC. >

Is it just me, or does that sound like a circular dependency graph?



Specify -> Implement -> Devise attacks.  It is not circular, although 
you can then have DMARCter...



Another concern is how acceptable it is to specify a standard which 
does not admit input which is perfectly valid according to a lower 
layer standard. Are they conflicting? >
I would argue that they are not.  DMARC can assert that it only acts on a 
profile of the layers below it, and anything outside of that profile is 
simply not within scope.



RFC7489 seems to imply that DMARC is only used for a fraction of email 
messages, such as bank transactions.  Nowadays some domains are voicing 
to require authentication for each and every message.  A rather 
different scenario.



If you as a receiver don't like the possible gap that creates, you're 
free to do something about it, but you're not doing so under any 
normative guidance from DMARC.



Isn't that a specification hole?


Best
Ale
--








___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:
>
>> > What do we think has changed since then that warrants reconsidering that
>> > position?  Have we started to see multi-value From attacks?
>>
>> A DMARC filter has to do something when it sees a multi-value From:.
>
>
>Why?  It hasn't so far (i.e., ~10 years).  What's the evidence that we have
>something to fix here?  That is, why is Section 6.6.1 of RFC 7489 suddenly
>inadequate?

As I recall, large mail systems have told us that the number of
messages with multiple From: addreses is evtremely small, and nearly
all of them are broken or malicious.

I'm with you, multiple From: addresses have never been a problem and
never will be a problem. If this is all we have left to argue about we
must be done.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely  wrote:

> > What do we think has changed since then that warrants reconsidering that
> > position?  Have we started to see multi-value From attacks?
>
> A DMARC filter has to do something when it sees a multi-value From:.


Why?  It hasn't so far (i.e., ~10 years).  What's the evidence that we have
something to fix here?  That is, why is Section 6.6.1 of RFC 7489 suddenly
inadequate?

  AFAIK, we
> just anticipated such attacks.  Their becoming trendy depends on how DMARC
> filters are going to be implemented.  The latter, in turn, depends on how
> we
> specify DMARC.
>

Is it just me, or does that sound like a circular dependency graph?  We'll
never finish if we're prepared to say we're willing to wait for that to
resolve before deciding what should be in DMARC.

Another concern is how acceptable it is to specify a standard which does
> not
> admit input which is perfectly valid according to a lower layer standard.
> Are
> they conflicting?
>

I would argue that they are not.  DMARC can assert that it only acts on a
profile of the layers below it, and anything outside of that profile is
simply not within scope.  If you as a receiver don't like the possible gap
that creates, you're free to do something about it, but you're not doing so
under any normative guidance from DMARC.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

I see no conflict.

A domain with DMARC enforcement asserts that it sends only authenticated
messages.   Since multiple-From messages cannot be fully authenticated,
such messages are inconsistent with the domain owner's stated practices
Therefore, the domain owner's published Failure disposition recommendation
is applicable.

For all messages, the evaluator has no obligation to accept or reject any
message, and can do so based on any criteria that suits his purposes.
 There is nothing in RFC5322 that requires a message to pass
authentication.   Any decision to reject a message based on lack of
authentication becomes a matter of local policy.

Doug

On Sun, Feb 4, 2024 at 8:26 AM Alessandro Vesely  wrote:

> On Sat 03/Feb/2024 21:44:42 +0100 Murray S. Kucherawy wrote:
> > On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely 
> wrote:
> >
> >>> I think this point about alignment of Sender is definitely correct,
> >>
> >> Let's also recall there was a proposal to consider Sender: anyway.
> >
> > And also let's recall that the community has previously rejected the
> idea
> > of involving Sender in DMARC evaluations.  Some text about why can be
> found
> > in DMARC itself, i.e., RFC 7489, Appendix A.3.
>
>
> Sorry I reconsidered that possibility.  It was after Todd recalled that
> multi-valued From: require Sender:.  Please forget it.  I agree DMARC
> doesn't
> need to consider Sender:.
>
>
> > What do we think has changed since then that warrants reconsidering that
> > position?  Have we started to see multi-value From attacks?
>
>
> A DMARC filter has to do something when it sees a multi-value From:.
> AFAIK, we
> just anticipated such attacks.  Their becoming trendy depends on how DMARC
> filters are going to be implemented.  The latter, in turn, depends on how
> we
> specify DMARC.
>
> Another concern is how acceptable it is to specify a standard which does
> not
> admit input which is perfectly valid according to a lower layer standard.
> Are
> they conflicting?
>
>
> Best
> Ale
> --
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Sat 03/Feb/2024 21:44:42 +0100 Murray S. Kucherawy wrote:

On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely  wrote:


I think this point about alignment of Sender is definitely correct,


Let's also recall there was a proposal to consider Sender: anyway.


And also let's recall that the community has previously rejected the idea 
of involving Sender in DMARC evaluations.  Some text about why can be found 
in DMARC itself, i.e., RFC 7489, Appendix A.3.



Sorry I reconsidered that possibility.  It was after Todd recalled that 
multi-valued From: require Sender:.  Please forget it.  I agree DMARC doesn't 
need to consider Sender:.



What do we think has changed since then that warrants reconsidering that 
position?  Have we started to see multi-value From attacks?



A DMARC filter has to do something when it sees a multi-value From:.  AFAIK, we 
just anticipated such attacks.  Their becoming trendy depends on how DMARC 
filters are going to be implemented.  The latter, in turn, depends on how we 
specify DMARC.


Another concern is how acceptable it is to specify a standard which does not 
admit input which is perfectly valid according to a lower layer standard.  Are 
they conflicting?



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

Checking each domain poses some restrictions on adding more authors on the 
From: line.  As you say, even if a message is being written four hands, current 
MSA standards only allow one author to authenticate.  Depending on outgoing 
filters capabilities, the message will likely get a dmarc=pass in the following 
cases:


* all author domains have p=none,
* all authors belong to the same domain and a DKIM signatures validates it,
* the MSA has the keys of each author domain, and adds each signature,
* some author domains are covered by DKIM signatures, the rest have p=none.

If those conditions sound too harsh, they're still more permissive than banning 
multiple From: altogether.


Receivers checking each author domain means that they apply the worse policy 
found in the set of non-authenticated domains.  That way there's no way you can 
impersonate a strict policy domain.



Best
Ale


On Sun 04/Feb/2024 10:50:25 +0100 Douglas Foster wrote:



Even in the unlikely event that all From addresses can be authenticated
with DKIM, the result still cannot be trusted.   It would be easy for an
attacker to anticipate signatures that will be added in transit, and use
those signatures to create false authentication.

RFC 7489 treats a multiple-domain FROM address as if all listed domains
returned NO POLICY.   This is clearly a security hole.   I have no trouble
imagining a successful phishing attack that uses two high-visibility
p=reject brands to trigger users to open a link or an attachment, but I
will omit elaboration since these discussion archives are
publicly available.   The assertion that such attacks are not yet known is
not a reason to conclude that they will never happen in the future.

Below is some proposed language for the document.
Doug Foster

Multiple From
-
A basic characteristic of email systems is that messages are generated in
the context of a single authentication event, validating either a user
account within a mail store domain, or a single client account within a
service provider domain.   As such, DMARC can validate at most one From
address, because at most one authenticated account was used to initiate the
message.

Malicious actors may anticipate DKIM signatures that will be added during
routine message processing, in an attempt to make a multiple-domain From
header appear to have multiple authorizations, but this only hides the fact
that every message begins with a single authentication event.

Consequently, the DMARC result for any multiple-address From header is
always FAIL.   DMARC policies for each listed domain may be consulted to
determine recommended failure handling, and to determine reporting
destinations.


On Sat, Feb 3, 2024 at 8:08 AM Alessandro Vesely  wrote:


On Sun 28/Jan/2024 14:39:55 +0100 I wrote:

[...]
To handle appropriately means receivers are on their own w.r.t DMARC.)

It

is a hole: >
 From: presid...@whitehouse.gov ,

user@attackdomain


[...]
For Sender:, instead, we need to also require that the aligned domain be

the

one of the _first_ From: mailbox.



That was an hallucination:

  From: "_" , presid...@whitehouse.gov

So the only solution, AFAICS, is to check each From: domain.  Possibly put
a
limit on the maximum number of domains accepted by policy.  Setting such
limit
to 1 would be disagreeable as it breaks SMTP; but, from a security POV,
still
better than skipping the message in such cases.


Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

Even in the unlikely event that all From addresses can be authenticated
with DKIM, the result still cannot be trusted.   It would be easy for an
attacker to anticipate signatures that will be added in transit, and use
those signatures to create false authentication.

RFC 7489 treats a multiple-domain FROM address as if all listed domains
returned NO POLICY.   This is clearly a security hole.   I have no trouble
imagining a successful phishing attack that uses two high-visibility
p=reject brands to trigger users to open a link or an attachment, but I
will omit elaboration since these discussion archives are
publicly available.   The assertion that such attacks are not yet known is
not a reason to conclude that they will never happen in the future.

Below is some proposed language for the document.
Doug Foster

Multiple From
-
A basic characteristic of email systems is that messages are generated in
the context of a single authentication event, validating either a user
account within a mail store domain, or a single client account within a
service provider domain.   As such, DMARC can validate at most one From
address, because at most one authenticated account was used to initiate the
message.

Malicious actors may anticipate DKIM signatures that will be added during
routine message processing, in an attempt to make a multiple-domain From
header appear to have multiple authorizations, but this only hides the fact
that every message begins with a single authentication event.

Consequently, the DMARC result for any multiple-address From header is
always FAIL.   DMARC policies for each listed domain may be consulted to
determine recommended failure handling, and to determine reporting
destinations.


On Sat, Feb 3, 2024 at 8:08 AM Alessandro Vesely  wrote:

> On Sun 28/Jan/2024 14:39:55 +0100 I wrote:
> > [...]
> > To handle appropriately means receivers are on their own w.r.t DMARC.)
> It
> > is a hole: >
> >  From: presid...@whitehouse.gov ,
> user@attackdomain
> >
> > [...]
> > For Sender:, instead, we need to also require that the aligned domain be
> the
> > one of the _first_ From: mailbox.
>
>
> That was an hallucination:
>
>   From: "_" , presid...@whitehouse.gov
>
> So the only solution, AFAICS, is to check each From: domain.  Possibly put
> a
> limit on the maximum number of domains accepted by policy.  Setting such
> limit
> to 1 would be disagreeable as it breaks SMTP; but, from a security POV,
> still
> better than skipping the message in such cases.
>
>
> Best
> Ale
> --
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Sun, Jan 28, 2024 at 5:40 AM Alessandro Vesely  wrote:

> > I think this point about alignment of Sender is definitely correct,
>
> Let's also recall there was a proposal to consider Sender: anyway.
>

And also let's recall that the community has previously rejected the idea
of involving Sender in DMARC evaluations.  Some text about why can be found
in DMARC itself, i.e., RFC 7489, Appendix A.3.

What do we think has changed since then that warrants reconsidering that
position?  Have we started to see multi-value From attacks?


> > Having to evaluate Sender for DMARC adds a pile of complexity for very
> minimal
> > benefit.
>
> Yes.
>

+1.

> We should leave this where it is and move on.
>
> No: substantially, /where it is/ is to ignore.  To handle appropriately
> means
> receivers are on their own w.r.t DMARC.)  It is a hole:
>
>  From: presid...@whitehouse.gov ,
> user@attackdomain
>

As we described in that appendix, the main reason we care about From and
nothing else is because it is the main identifier shown to end users and
upon which human trust evaluations are done.  Sender is not.  If we start
including Sender in the check, but From and Sender don't align, we create
at least confusion if not an attack vector.

Here be dragons.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Sun 28/Jan/2024 14:39:55 +0100 I wrote:

[...]
To handle appropriately means receivers are on their own w.r.t DMARC.)  It
is a hole: >
     From: presid...@whitehouse.gov , user@attackdomain

[...]
For Sender:, instead, we need to also require that the aligned domain be the 
one of the _first_ From: mailbox.



That was an hallucination:

 From: "_" , presid...@whitehouse.gov

So the only solution, AFAICS, is to check each From: domain.  Possibly put a 
limit on the maximum number of domains accepted by policy.  Setting such limit 
to 1 would be disagreeable as it breaks SMTP; but, from a security POV, still 
better than skipping the message in such cases.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

Ale is right, the document needs to address the problem.

I agree with Google that multiple-From has no important use-case, and
therefore a wise evaluator should simply reject the message.   For the same
reason, I believe the RFC5322.bis group should have deprecated the
feature.But since that is not happening, we need to plug the security
hole that it creates.

A domain that publishes p=reject needs to be protected from all
impersonation attacks, whether the malicious attacker uses one From address
or multiple.   Consequently, an evaluator must take one of two actions on a
multiple-domain From header:

   1. Reject the message,.   If the message is rejected on other criteria,
   such as suspicious content, DMARC evaluation is optional.
   2. Evaluate DMARC on all listed domains, taking the most restrictive
   result.
   3. Take any action based on local policy.

Multi-domain From addresses MAY be omitted from aggregate reports by
evaluators who are unwilling to code for this additional complexity.

Doug Foster


On Sun, Jan 28, 2024 at 8:40 AM Alessandro Vesely  wrote:

> On Sat 27/Jan/2024 16:13:08 +0100 Scott Kitterman wrote:
> > On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:
> >>
> >> Ignoring, as Section 11.5 points out, exposes an attack vector that
> must be
> >> taken into consideration.  That section says:
> >>
> >>  [C]are must be taken by the receiving MTA to recognize such
> messages
> >>  as the threats they might be and handle them appropriately.
> >>
> >> What does it mean "appropriately" in that context?  It looks to me as a
> >> neatly carved hole in a security filter.
> >
> > I think this point about alignment of Sender is definitely correct,
>
>
> Let's also recall there was a proposal to consider Sender: anyway.
>
>
> > but it leads me to a different conclusion:
> >
> > Having to evaluate Sender for DMARC adds a pile of complexity for very
> minimal
> > benefit.
>
>
> Yes.
>
>
> > We should leave this where it is and move on.
>
>
> No: substantially, /where it is/ is to ignore.  To handle appropriately
> means
> receivers are on their own w.r.t DMARC.)  It is a hole:
>
>  From: presid...@whitehouse.gov ,
> user@attackdomain
>
>
> > Personally, I would prefer we say to do a DMARC evaluation for each From
> and
> > leave it to the receiver to evaluate multiple policies (if there are two
> From
> > values and the result for one is pass and the other is fail with a
> reject
> > policy, it seems pretty straightforward to decide to reject).  It would
> be
> > substantially less complex than adding another header field to the
> process
>
>
> I'm not sure which one is more complex.  Evaluating each From: implies a
> tree
> walk for each domain, while verifying Sender: alignment can reduce that
> number.
>
> However, it is probably better to choose a solution based on semantics
> rather
> than on complexity.  Your solution solves the example above, which is good.
>
> For Sender:, instead, we need to also require that the aligned domain be
> the
> one of the _first_ From: mailbox.  Such additional requirement preserves
> the
> principle of end user visibility that led to choose From: in the first
> place,
> and definitely reduces complexity.
>
>
> Best
> Ale
> --
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Sat 27/Jan/2024 16:13:08 +0100 Scott Kitterman wrote:

On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:


Ignoring, as Section 11.5 points out, exposes an attack vector that must be 
taken into consideration.  That section says:


 [C]are must be taken by the receiving MTA to recognize such messages
 as the threats they might be and handle them appropriately.

What does it mean "appropriately" in that context?  It looks to me as a 
neatly carved hole in a security filter.


I think this point about alignment of Sender is definitely correct,



Let's also recall there was a proposal to consider Sender: anyway.



but it leads me to a different conclusion:

Having to evaluate Sender for DMARC adds a pile of complexity for very minimal 
benefit.



Yes.



We should leave this where it is and move on.



No: substantially, /where it is/ is to ignore.  To handle appropriately means 
receivers are on their own w.r.t DMARC.)  It is a hole:


From: presid...@whitehouse.gov , user@attackdomain


Personally, I would prefer we say to do a DMARC evaluation for each From and 
leave it to the receiver to evaluate multiple policies (if there are two From 
values and the result for one is pass and the other is fail with a reject 
policy, it seems pretty straightforward to decide to reject).  It would be 
substantially less complex than adding another header field to the process



I'm not sure which one is more complex.  Evaluating each From: implies a tree 
walk for each domain, while verifying Sender: alignment can reduce that number.


However, it is probably better to choose a solution based on semantics rather 
than on complexity.  Your solution solves the example above, which is good.


For Sender:, instead, we need to also require that the aligned domain be the 
one of the _first_ From: mailbox.  Such additional requirement preserves the 
principle of end user visibility that led to choose From: in the first place, 
and definitely reduces complexity.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Scott Kitterman]

On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote:
> On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:
> >> On Jan 19, 2024, at 10:19 AM, Todd Herr
> >>  wrote:
> >> 
> >> Perhaps the way forward for DMARC is to look for a Sender header when
> >> there is more than one RFC5322.From domain and use that for DMARC
> >> processing, with the stipulation that messages that don't contain such a
> >> Sender header are invalid and should be rejected?> 
> > Todd,  +1
> > 
> > I like this idea.  The 5322.Sender is required for a 2+ address
> > Mailbox-list.
> +1 as well.  Let me note that, in such case, DMARC should require that the
> Sender: domain be aligned with at least one of the From: domains.
> 
> Otherwise, disallow should mean reject/ quarantine when at least one of the
> From: domains says so.  (Same complexity as previous case.)
> 
> Ignoring, as Section 11.5 points out, exposes an attack vector that must be
> taken into consideration.  That section says:
> 
>  [C]are must be taken by the receiving MTA to recognize such messages
>  as the threats they might be and handle them appropriately.
> 
> What does it mean "appropriately" in that context?  It looks to me as a
> neatly carved hole in a security filter.

I think this point about alignment of Sender is definitely correct, but it 
leads me to a different conclusion:

Having to evaluate Sender for DMARC adds a pile of complexity for very minimal 
benefit.  We should leave this where it is and move on.

Personally, I would prefer we say to do a DMARC evaluation for each From and 
leave it to the reciever to evaluate multiple policies (if there are two From 
values and the result for one is pass and the other is fail with a reject 
policy, it seems pretty straightforward to decide to reject).  It would be 
substantially less complex than adding another header field to the process, but 
even that is more than this topic deserves.

Let's focus on finishing the draft.

What's between the current revision and WGLC?

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

Assume this RFC5322 header:

 From: user@attackdomain, presid...@whitehouse.gov

For messages like this:

   - Verifying one identity (e.g. "user@attackdomain") does nothing to say
   that the unverified identity is used with authorization.
   - Technical issues mean that it will be rare, nearly impossible, for a
   multiple-domain address to authenticate all addresses.

We can ensure that sender policy is not ignored If we specify recipient
chose of these behaviors:

   - Test all domains for DMARC and follow the strictest resulting
   disposition advice, or
   - Reject the message as inherently inconsistent with being able to
   authenticate all addresses, and therefore not worth the trouble to attempt
   the calculation.

Ultimately, multiple-address From is an anachronism -- the early
specifications allowed it, but experience shows that nobody really needs or
uses it, and important participants have already dropped support for it.
The RFC5322 rewrite should deprecate it so that DMARCbis does not have to
dance around the subject.

Doug Foster



On Sat, Jan 27, 2024 at 8:01 AM Alessandro Vesely  wrote:

> On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:
> >> On Jan 19, 2024, at 10:19 AM, Todd Herr  40valimail@dmarc.ietf.org> wrote:
> >>
> >> Perhaps the way forward for DMARC is to look for a Sender header when
> there is more than one RFC5322.From domain and use that for DMARC
> processing, with the stipulation that messages that don't contain such a
> Sender header are invalid and should be rejected?
> >
> > Todd,  +1
> >
> > I like this idea.  The 5322.Sender is required for a 2+ address
> Mailbox-list.
>
>
> +1 as well.  Let me note that, in such case, DMARC should require that the
> Sender: domain be aligned with at least one of the From: domains.
>
> Otherwise, disallow should mean reject/ quarantine when at least one of
> the
> From: domains says so.  (Same complexity as previous case.)
>
> Ignoring, as Section 11.5 points out, exposes an attack vector that must
> be
> taken into consideration.  That section says:
>
>  [C]are must be taken by the receiving MTA to recognize such messages
>  as the threats they might be and handle them appropriately.
>
> What does it mean "appropriately" in that context?  It looks to me as a
> neatly
> carved hole in a security filter.
>
>
> Best
> Ale
> --
>
> PS:  Thunderbird, for one, allows editing From: and add more mailboxes, in
> the
> message composition window.
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote:

On Jan 19, 2024, at 10:19 AM, Todd Herr 
 wrote:

Perhaps the way forward for DMARC is to look for a Sender header when there is more than one RFC5322.From domain and use that for DMARC processing, with the stipulation that messages that don't contain such a Sender header are invalid and should be rejected? 


Todd,  +1

I like this idea.  The 5322.Sender is required for a 2+ address Mailbox-list.



+1 as well.  Let me note that, in such case, DMARC should require that the 
Sender: domain be aligned with at least one of the From: domains.


Otherwise, disallow should mean reject/ quarantine when at least one of the 
From: domains says so.  (Same complexity as previous case.)


Ignoring, as Section 11.5 points out, exposes an attack vector that must be 
taken into consideration.  That section says:


[C]are must be taken by the receiving MTA to recognize such messages
as the threats they might be and handle them appropriately.

What does it mean "appropriately" in that context?  It looks to me as a neatly 
carved hole in a security filter.



Best
Ale
--

PS:  Thunderbird, for one, allows editing From: and add more mailboxes, in the 
message composition window.







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Hector Santos]

> On Jan 19, 2024, at 10:19 AM, Todd Herr 
>  wrote:
> 
> 
> Perhaps the way forward for DMARC is to look for a Sender header when there 
> is more than one RFC5322.From domain and use that for DMARC processing, with 
> the stipulation that messages that don't contain such a Sender header are 
> invalid and should be rejected? 

Todd,  +1

I like this idea.  The 5322.Sender is required for a 2+ address Mailbox-list.

https://www.ietf.org/archive/id/draft-ietf-emailcore-rfc5322bis-09.html#section-3.6.2

This also feeds an RFC5322 validator with a new rule to make sure Sender exist 
for a 2+ address mailbox-list and also open the door to using Sender for DMARC 
purposes and if you could, reference RFC5322 section 3.6.2   

In the name of integration and codification of layered protocols, since 
RFC5322bis is still active, perhaps it can revisit the 5322.From ABNF and/or 
have something more strongly to say about it regarding 2+ address mailbox-list. 
 Perhaps it should be deprecated.  It would better match the current DMARCBis 
semantics and security-related concerns on 5322.From with multiple addresses.


All the best,
Hector Santos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Seth Blank]

On Fri, Jan 19, 2024 at 10:55 AM Dotzero  wrote:

> The problem with relying on the Sender header is that unless a Sender
> header matches the right hand side (domain) of the email address in the
> From field, you can't tell if there is a legitimate relationship between
> Sender and From.
>
> I think the correct approach is for DMARC to recognize this is a very tiny
> corner case that very rarely shows up in the real world and ignore it.
>

As an individual, I concur. DMARC is about aligning authentication to the
domain in the From. This doesn't make sense / gets far more complicated if
there are multiple domains in the From.

My two cents, loosely held: I think it's best to explicitly carve out, not
as a corner case, but as something explicitly disallowed. The same way
multiple DMARC records means no DMARC record, multiple Froms in a message
should mean that no DMARC PASS can be generated.

Seth


> Michael Hammer
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Dotzero]

On Fri, Jan 19, 2024 at 10:20 AM Todd Herr  wrote:

> On Thu, Jan 18, 2024 at 9:28 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> As a long time implementer and integrator of IETF protocols, my mail
>> engineering view ….
>>
>> The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header
>> to have multiple addresses:
>>
>> from = "From:" mailbox-list CRLF
>> mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
>>
>
> True, but in such cases, it requires that there be a Sender: header with
> exactly one mailbox as a value -
> https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2
>
>
> [snip]
>>
>
>
>>
>> However, if I have been following this thread, DMARCBis was updated to
>> ignore these multi-from messages for DMARC purposes because they
>> (erroneously) presumed they should be rejected, i.e. never make it to a
>> signer or verifier.
>>
>> I am not sure that is correct.
>>
>
> Perhaps the way forward for DMARC is to look for a Sender header when
> there is more than one RFC5322.From domain and use that for DMARC
> processing, with the stipulation that messages that don't contain such a
> Sender header are invalid and should be rejected?
>

The problem with relying on the Sender header is that unless a Sender
header matches the right hand side (domain) of the email address in the
>From field, you can't tell if there is a legitimate relationship between
Sender and From.

I think the correct approach is for DMARC to recognize this is a very tiny
corner case that very rarely shows up in the real world and ignore it.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Todd Herr]

On Thu, Jan 18, 2024 at 9:28 PM Hector Santos  wrote:

> Hi,
>
> As a long time implementer and integrator of IETF protocols, my mail
> engineering view ….
>
> The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header
> to have multiple addresses:
>
> from = "From:" mailbox-list CRLF
> mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
>

True, but in such cases, it requires that there be a Sender: header with
exactly one mailbox as a value -
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.2


[snip]
>


>
> However, if I have been following this thread, DMARCBis was updated to
> ignore these multi-from messages for DMARC purposes because they
> (erroneously) presumed they should be rejected, i.e. never make it to a
> signer or verifier.
>
> I am not sure that is correct.
>

Perhaps the way forward for DMARC is to look for a Sender header when there
is more than one RFC5322.From domain and use that for DMARC processing,
with the stipulation that messages that don't contain such a Sender header
are invalid and should be rejected?

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Hector Santos]

Hi, 

As a long time implementer and integrator of IETF protocols, my mail 
engineering view ….

The thing is RFC 822, 2822 and 5322 allows for a single 5322.From header to 
have multiple addresses:

from = "From:" mailbox-list CRLF
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list

So it is intentional? Obviously, there was a time and  mail “group-ware” 
application scenario where it applied so it was engineered and written into the 
822 specification. 

But were there any client MUA that supports it?   I (Santronics Software) never 
added it in any of my MUAs, which were USER and SYSOP-based.  Even if not, it 
is still technically possible to create a legally formatted RFC822, 2822, 5322 
message and send it via SMTP.

Now comes DKIM and its DKIM Policy Modeling add-ons…..

DKIM signing requires the hash binding of the entire content of the 5322.From 
header.   There is no modifications expected before signing.  Note:  While 
Rewrite is a kludge solution to a domain redirection problem, it is not the 
same but I can see where it can fit here.

ALL DKIM Policy Models (the add-ons over DKIM-BASE) starting with SSP, DSAP, 
ADSP and now DMARC provided guidelines to support 1st party signature. 
Unfortunately, they failed on the authorization of a 3rd party signer scenario. 

So it means, at least one of the authors domain should match/align with the 
signer domain per DMARC logic.

This sounds logical to me, albeit more complexity in the codes that reads and 
processes the headers.  We don’t have any MUAs or bots that have a need or 
support for multiple authors.  That need is called Mailing List.  But for DKIM 
Policy models, it should be allowed as long as there is an aligned/matching 
signer domain in the From header mailbox-list.

However, if I have been following this thread, DMARCBis was updated to ignore 
these multi-from messages for DMARC purposes because they (erroneously) 
presumed they should be rejected, i.e. never make it to a signer or verifier.

I am not sure that is correct.


All the best,
Hector Santos


> On Jan 18, 2024, at 10:59 AM, Emil Gustafsson 
>  wrote:
> 
> I have a data point.
> When we (Google) did an experiment/analysis of this a couple of years ago the 
> conclusion was
> a) multi-value From are relatively rare and mostly look like abuse or 
> mistakes rather than intentional.
> b) Users generally don't care about those messages if they end up in spam.
> 
> So...
> Is the volume measurable? -  yes but very small
> Are there legitimate emails? - yes but users don't seem to care about these 
> messages
> 
> Based on the data I have, I would be in favor of an update that essentially 
> makes multivalued From Invalid rather than a corner case that needs to be 
> handled.
> 
> /E
> 
> On Thu, Jan 18, 2024 at 12:41 AM Steven M Jones  wrote:
> On 1/17/24 2:56 AM, Alessandro Vesely wrote:
> > [ Discussion of  what to do with multi-valued From: in messages ]
> >
> > However, since DMARC bears the blame of banning multi-valued From:, it 
> > is appropriate for it to say something about the consequences and 
> > possible workarounds.
> 
> DMARC doesn't ban multi-valued From:, but the language of section 6.6.1 
> is confusing because we were documenting the practice of implementers up 
> to that time as much as being prescriptive. If anything, it highlights 
> the need for the clearer language that Todd quoted earlier in this thread.
> 
> Has a measurable volume of legitimate messages with multi-valued From: 
> headers been reported in the wild? Is there a real-world problem that 
> needs to be solved?
> 
> --Steve.
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Emil Gustafsson]

I have a data point.
When we (Google) did an experiment/analysis of this a couple of years ago
the conclusion was
a) multi-value From are relatively rare and mostly look like abuse or
mistakes rather than intentional.
b) Users generally don't care about those messages if they end up in spam.

So...
Is the volume measurable? -  yes but very small
Are there legitimate emails? - yes but users don't seem to care about these
messages

Based on the data I have, I would be in favor of an update that essentially
makes multivalued From Invalid rather than a corner case that needs to be
handled.

/E

On Thu, Jan 18, 2024 at 12:41 AM Steven M Jones  wrote:

> On 1/17/24 2:56 AM, Alessandro Vesely wrote:
> > [ Discussion of  what to do with multi-valued From: in messages ]
> >
> > However, since DMARC bears the blame of banning multi-valued From:, it
> > is appropriate for it to say something about the consequences and
> > possible workarounds.
>
> DMARC doesn't ban multi-valued From:, but the language of section 6.6.1
> is confusing because we were documenting the practice of implementers up
> to that time as much as being prescriptive. If anything, it highlights
> the need for the clearer language that Todd quoted earlier in this thread.
>
> Has a measurable volume of legitimate messages with multi-valued From:
> headers been reported in the wild? Is there a real-world problem that
> needs to be solved?
>
> --Steve.
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Steven M Jones]

On 1/17/24 2:56 AM, Alessandro Vesely wrote:

[ Discussion of  what to do with multi-valued From: in messages ]

However, since DMARC bears the blame of banning multi-valued From:, it 
is appropriate for it to say something about the consequences and 
possible workarounds.


DMARC doesn't ban multi-valued From:, but the language of section 6.6.1 
is confusing because we were documenting the practice of implementers up 
to that time as much as being prescriptive. If anything, it highlights 
the need for the clearer language that Todd quoted earlier in this thread.


Has a measurable volume of legitimate messages with multi-valued From: 
headers been reported in the wild? Is there a real-world problem that 
needs to be solved?


--Steve.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Steven M Jones]

On 1/11/24 10:46 AM, Murray S. Kucherawy wrote:


What I recall from when we wrote that was that the first paragraph 
really means "Most MTAs reject this anyway so it shouldn't even get to 
your DMARC filter" and the second means "If it does get to you, here's 
how you should probably react."



+1, matches my recollection.

--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

As with the mailing list problem, when the recipient expects authentication
but the sender cannot provide it, the sender is disadvantaged.

Nor an I concerned about the limitations of a particular MSA product.

However, we know that mailing list posts almost always start as authorized
messages, so ARC is able to communicate that prior state.

With dual from, there is no reason to conclude that the MSA reliably knows
that the message was authorized by all authors, so there is no reason for
the evaluators to impute that trust.

Doug

On Wed, Jan 17, 2024, 6:14 PM Murray S. Kucherawy 
wrote:

> On Wed, Jan 17, 2024 at 2:56 AM Alessandro Vesely  wrote:
>
>> Since email format allows multi-valued From:, its meaning is
>> straightforward.
>>
>
> Syntax, yes, but meaning?  That seems debatable.  Does the order of values
> matter, for example?
>
> As John says, it can also be the result of some kind of mistake.  Yet,
>> presuming that a properly formatted input is correct is not such an
>> elaborate
>> conjecture to put the output in jeopardy.
>>
>
> I know what "properly formatted" means in this context, but not what
> "correct" means.
>
>
>> > As I recall, with milter in particular, the MTA will add a missing Date
>> > field, which the filter never actually sees and thus cannot sign.  The
>> > filter only sees the message exactly as it was presented to the MTA.
>> As a
>> > result, if the message is signed, Date is not, and any verifier that
>> thinks
>> > it ought to be will consider the signature invalid.
>>
>> That can well be considered a flaw of the Milter architecture.  To wit, I
>> named
>> my filter "zdkimfilter" because Courier applies filters in lexicographic
>> order,
>> whereby each filter can see any changes applied by the previous ones, as
>> in a
>> pipeline.
>>
>
> In milter, filters later in the configured sequence can see changes made
> by those earlier.  But as I recall, none of them see a Date field added by
> the MTA after the milter sequence has completed, nor any other header
> changes made by the MTA.
>
>
>> If the MSA handled DKIM natively, you wouldn't have to insert a filter to
>> do it.
>>
>
> Well, sure, but that wasn't the point.
>
> However, since DMARC bears the blame of banning multi-valued From:, it is
>> appropriate for it to say something about the consequences and possible
>> workarounds.
>
>
> I didn't know DMARC had banned multi-valued From.  It simply says we
> largely punt on how to evaluate it since it's sufficiently rare that it's
> not worth teasing out meaning.  It doesn't render the message generally
> invalid.
>
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Wed, Jan 17, 2024 at 2:56 AM Alessandro Vesely  wrote:

> Since email format allows multi-valued From:, its meaning is
> straightforward.
>

Syntax, yes, but meaning?  That seems debatable.  Does the order of values
matter, for example?

As John says, it can also be the result of some kind of mistake.  Yet,
> presuming that a properly formatted input is correct is not such an
> elaborate
> conjecture to put the output in jeopardy.
>

I know what "properly formatted" means in this context, but not what
"correct" means.


> > As I recall, with milter in particular, the MTA will add a missing Date
> > field, which the filter never actually sees and thus cannot sign.  The
> > filter only sees the message exactly as it was presented to the MTA.  As
> a
> > result, if the message is signed, Date is not, and any verifier that
> thinks
> > it ought to be will consider the signature invalid.
>
> That can well be considered a flaw of the Milter architecture.  To wit, I
> named
> my filter "zdkimfilter" because Courier applies filters in lexicographic
> order,
> whereby each filter can see any changes applied by the previous ones, as
> in a
> pipeline.
>

In milter, filters later in the configured sequence can see changes made by
those earlier.  But as I recall, none of them see a Date field added by the
MTA after the milter sequence has completed, nor any other header changes
made by the MTA.


> If the MSA handled DKIM natively, you wouldn't have to insert a filter to
> do it.
>

Well, sure, but that wasn't the point.

However, since DMARC bears the blame of banning multi-valued From:, it is
> appropriate for it to say something about the consequences and possible
> workarounds.


I didn't know DMARC had banned multi-valued From.  It simply says we
largely punt on how to evaluate it since it's sufficiently rare that it's
not worth teasing out meaning.  It doesn't render the message generally
invalid.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Tue 16/Jan/2024 19:24:29 +0100 Murray S. Kucherawy wrote:

On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely  wrote:

On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:

It appears that Scott Kitterman   said:
I don't think that's sensible at all.  It's not the place of a signing 

filter to modify the message.

A signing filter, as part of an MSA _has to_ modify the message in order 
to enhance the possibility that it is transmitted correctly.  Besides 
usual changes belonging to the core MSA, such as setting Date:, a signing 
filter shall take care of signature breaking cases, such as lines 
beginning with "from ". >
I also disagree.  A signing filter (or an MSA, for that matter) can also 
decline to sign a message that fails to meet certain criteria like, say, 
RFC5322.  I would contend that this is the right action, since what we're 
doing here is securing the message, and a filter in that position shouldn't 
be presuming what the author meant to say.



Since email format allows multi-valued From:, its meaning is straightforward. 
As John says, it can also be the result of some kind of mistake.  Yet, 
presuming that a properly formatted input is correct is not such an elaborate 
conjecture to put the output in jeopardy.



As I recall, with milter in particular, the MTA will add a missing Date 
field, which the filter never actually sees and thus cannot sign.  The 
filter only sees the message exactly as it was presented to the MTA.  As a 
result, if the message is signed, Date is not, and any verifier that thinks 
it ought to be will consider the signature invalid.



That can well be considered a flaw of the Milter architecture.  To wit, I named 
my filter "zdkimfilter" because Courier applies filters in lexicographic order, 
whereby each filter can see any changes applied by the previous ones, as in a 
pipeline.



There's another thread of concern here: For a signature to survive transit, 
the signing filter needs to anticipate any rewrites that will happen to the 
message.  If "Date" is missing and it gets added, that's one thing; if 
"From" is rewritten outbound by the MTA (which is not uncommon), say from 
$HOST.$DOMAIN to just $DOMAIN, the signature may be immediately invalidated.



Yes, these are architectural problems that local implementations have to solve.



There's a lot of complexity here that I think filter authors would just as
soon leave to the MTA/MSA.



If the MSA handled DKIM natively, you wouldn't have to insert a filter to do it.


A use case is when submitting co-authored articles or notes.  Yes, it is 
rare to type a message four hands, but it can happen, and banning the 
possibility to correctly identify the authors is harsh. >>
Thinking twice, saving the original multi-value to Author: is not enough 
to have replies reach every author.  Better also use Reply-To:.


This strikes me as something that needs to be codified outside of DMARC, 
rather than by it.



Agreed.  The problem needs to be handled on DKIM signing, one layer below.

However, since DMARC bears the blame of banning multi-valued From:, it is 
appropriate for it to say something about the consequences and possible 
workarounds.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Tue, Jan 16, 2024 at 10:24 AM Murray S. Kucherawy 
wrote:

> As I recall, with milter in particular, the MTA will add a missing Date
> field, which the filter never actually sees and thus cannot sign.  The
> filter only sees the message exactly as it was presented to the MTA.  As a
> result, if the message is signed, Date is not, and any verifier that thinks
> it ought to be will consider the signature invalid.
>

In fact, if you configure your filter to oversign Date but don't actually
give it a Date field, and then the MSA adds one, then the signature
attached to the message is dead before it hits the first hop.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Murray S. Kucherawy]

On Tue, Jan 16, 2024 at 2:03 AM Alessandro Vesely  wrote:

> On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
> > It appears that Scott Kitterman   said:
> >>I don't think that's sensible at all.  It's not the place of a signing
> filter to modify the message.
>
> A signing filter, as part of an MSA _has to_ modify the message in order
> to
> enhance the possibility that it is transmitted correctly.  Besides usual
> changes belonging to the core MSA, such as setting Date:, a signing filter
> shall take care of signature breaking cases, such as lines beginning with
> "from ".
>

I also disagree.  A signing filter (or an MSA, for that matter) can also
decline to sign a message that fails to meet certain criteria like, say,
RFC5322.  I would contend that this is the right action, since what we're
doing here is securing the message, and a filter in that position shouldn't
be presuming what the author meant to say.

As I recall, with milter in particular, the MTA will add a missing Date
field, which the filter never actually sees and thus cannot sign.  The
filter only sees the message exactly as it was presented to the MTA.  As a
result, if the message is signed, Date is not, and any verifier that thinks
it ought to be will consider the signature invalid.

There's another thread of concern here: For a signature to survive transit,
the signing filter needs to anticipate any rewrites that will happen to the
message.  If "Date" is missing and it gets added, that's one thing; if
"From" is rewritten outbound by the MTA (which is not uncommon), say from
$HOST.$DOMAIN to just $DOMAIN, the signature may be immediately invalidated.

There's a lot of complexity here that I think filter authors would just as
soon leave to the MTA/MSA.

A use case is when submitting co-authored articles or notes.  Yes, it is
> rare
> to type a message four hands, but it can happen, and banning the
> possibility to
> correctly identify the authors is harsh.
>
> Thinking twice, saving the original multi-value to Author: is not enough
> to
> have replies reach every author.  Better also use Reply-To:.
>

This strikes me as something that needs to be codified outside of DMARC,
rather than by it.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Douglas Foster]

The purpose of DMARC is to demonstrate that the purported author (From) is
either the actual author or the authorized agent of the actual author.

Because of practical difficulties, this is an indirect process:   DMARC
PASS demonstrates that a specific sending domain is authorized to speak on
behalf of the purported author's domain.

We then presume that the local-part is authorized at origination.   This
occurs either
(a) because the Mail From account was authenticated by the MSA and we have
SPF alignment, or
(b) because the Mail From account was authenticated by the MSA and its
administrative controls ensure that other-domain signatures are only
applied to Mail From accounts that have been duly authorized to use it.

For forwarding, we accept aligned DKIM PASS because it implies that those
criteria were met at origination, and the signature was preserved during
transit.

All of this falls apart with multiple From domains.SPF-alignment can
only authenticate one Mail From account to one domain.   ESPs have the
sophistication to generate different DKIM signatures for different clients,
but they only serve one client per message

Every way I look at the problem, I conclude that:
- If an MSA thinks it has reason to send a message with multiple From
domains, it will either lack the ability or lack the controls to ensure
that this is done with proper authorization.
- If an MSA has the ability to authenticate multiple authors, it is an ESP
which has no reason to send messages from multiple author domains because
it only serves one client per message.

Email is not a legal document.  If someone wants to assert multiple
authorship, they should use the Friendly Name and Body closing to assert
this information.  If someone insists on sending messages with multiple
>From domains, the message will be received as not fully authenticated and
will be at the mercy of the receiving system to decide whether that
incomplete authentication is acceptable.

Doug Foster

On Tue, Jan 16, 2024 at 5:03 AM Alessandro Vesely  wrote:

> On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:
> > It appears that Scott Kitterman   said:
> >>I don't think that's sensible at all.  It's not the place of a signing
> filter to modify the message.
>
>
> A signing filter, as part of an MSA _has to_ modify the message in order
> to
> enhance the possibility that it is transmitted correctly.  Besides usual
> changes belonging to the core MSA, such as setting Date:, a signing filter
> shall take care of signature breaking cases, such as lines beginning with
> "from ".
>
>
> >> I think it would be reasonable to either add a signature for each from
> >> domain or to decline to sign it at all, but since DKIM doesn't care
> about
> >> from domain at all, I think it would be up to whatever calls the
> signing
> >> filter to specify.
>
> Not signing and/or leaving a multi-valued From: as is certainly is not a
> good
> service for the users, if they meant their message to be delivered.
>
> Some receivers reject messages with multi-valued From: —after DMARC.
> OTOH,
> MUAs allow it, rightly following the RFCs.  What's the way out?
>
>
> > I agree but I'd be more inclined to say don't sign at all, since
> > multi-valued From headers are rare and as likely as not to be a
> > mistake.
>
>
> A use case is when submitting co-authored articles or notes.  Yes, it is
> rare
> to type a message four hands, but it can happen, and banning the
> possibility to
> correctly identify the authors is harsh.
>
>
> Thinking twice, saving the original multi-value to Author: is not enough
> to
> have replies reach every author.  Better also use Reply-To:.
>
>
> Best
> Ale
> --
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On Mon 15/Jan/2024 20:49:35 +0100 John Levine wrote:

It appears that Scott Kitterman   said:

I don't think that's sensible at all.  It's not the place of a signing filter 
to modify the message.



A signing filter, as part of an MSA _has to_ modify the message in order to 
enhance the possibility that it is transmitted correctly.  Besides usual 
changes belonging to the core MSA, such as setting Date:, a signing filter 
shall take care of signature breaking cases, such as lines beginning with "from ".



I think it would be reasonable to either add a signature for each from 
domain or to decline to sign it at all, but since DKIM doesn't care about 
from domain at all, I think it would be up to whatever calls the signing 
filter to specify.


Not signing and/or leaving a multi-valued From: as is certainly is not a good 
service for the users, if they meant their message to be delivered.


Some receivers reject messages with multi-valued From: —after DMARC.  OTOH, 
MUAs allow it, rightly following the RFCs.  What's the way out?




I agree but I'd be more inclined to say don't sign at all, since
multi-valued From headers are rare and as likely as not to be a
mistake.



A use case is when submitting co-authored articles or notes.  Yes, it is rare 
to type a message four hands, but it can happen, and banning the possibility to 
correctly identify the authors is harsh.



Thinking twice, saving the original multi-value to Author: is not enough to 
have replies reach every author.  Better also use Reply-To:.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[John Levine]

It appears that Scott Kitterman   said:
>I don't think that's sensible at all.  It's not the place of a signing filter 
>to modify the message.  I think it would be reasonable to either add a 
>signature for
>each from domain or to decline to sign it at all, but since DKIM doesn't care 
>about from domain at all, I think it would be up to whatever calls the signing 
>filter
>to specify.

I agree but I'd be more inclined to say don't sign at all, since
multi-valued From headers are rare and as likely as not to be a
mistake.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Scott Kitterman]

On January 15, 2024 4:49:10 PM UTC, Alessandro Vesely  wrote:
>On 11/01/2024 18:15, Todd Herr wrote:
>> On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:
>> 
>>> https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
>>> 
>>> "The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
>>> policy selected among the checks that fail.”
>>> [...]
>> 
>> DMARCbis has rewritten these sections and has text that you may find
>> helpful.
>> 
>>   The declaration in Section 5.7.1 and elsewhere in this document that
>>   messages that do not contain precisely one RFC5322.From domain are
>>   outside the scope of this document exposes an attack vector that must
>>   be taken into consideration. >
>>   Because such messages are outside the scope of this document, an attacker
>>   can craft messages with multiple RFC5322.From domains, including the
>>   spoofed domain, in an effort to bypass DMARC validation and get the
>>   fraudulent message to be displayed by the victim's MUA with the spoofed
>>   domain successfully shown to the victim. In those cases where such messages
>>   are not rejected due to other reasons (for example, many such messages
>>   would violate RFC5322's requirement that there be precisely one From:
>>   header), care must be taken by the receiving MTA to recognize such messages
>>   as the threats they might be and handle them appropriately.
>
>
>A sensible behavior for a signing filter would be to replace multi-valued 
>From: lines with ones having the first mailbox only and the phrase "et al." 
>added to the friendly name.  The original multi-valued From: can be saved to 
>Author:.  (Adding this to my TODO list).
>
I don't think that's sensible at all.  It's not the place of a signing filter 
to modify the message.  I think it would be reasonable to either add a 
signature for each from domain or to decline to sign it at all, but since DKIM 
doesn't care about from domain at all, I think it would be up to whatever calls 
the signing filter to specify.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

[Alessandro Vesely]

On 11/01/2024 18:15, Todd Herr wrote:

On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote:


https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1

"The case of a syntactically valid multi-valued 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.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.”
[...]


DMARCbis has rewritten these sections and has text that you may find
helpful.

  The declaration in Section 5.7.1 and elsewhere in this document that
  messages that do not contain precisely one RFC5322.From domain are
  outside the scope of this document exposes an attack vector that must
  be taken into consideration. >
  Because such messages are outside the scope of this document, an attacker
  can craft messages with multiple RFC5322.From domains, including the
  spoofed domain, in an effort to bypass DMARC validation and get the
  fraudulent message to be displayed by the victim's MUA with the spoofed
  domain successfully shown to the victim. In those cases where such messages
  are not rejected due to other reasons (for example, many such messages
  would violate RFC5322's requirement that there be precisely one From:
  header), care must be taken by the receiving MTA to recognize such messages
  as the threats they might be and handle them appropriately.



A sensible behavior for a signing filter would be to replace 
multi-valued From: lines with ones having the first mailbox only and the 
phrase "et al." added to the friendly name.  The original multi-valued 
From: can be saved to Author:.  (Adding this to my TODO list).



Best
Ale
--









___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc