Re: [dmarc-ietf] Eliminating From Munging from this list

[Alessandro Vesely]

On Fri 21/Jul/2023 09:35:32 +0200 OLIVIER HUREAU wrote:
  Instead, I see language that drives people to fixate on the 1% of traffic 

that has a DMARC policy with p=reject.


Indeed: I caution everyone about making assumptions based on what we
think we know, and extending those assumptions to the entire Internet.
There are things we can study (by, for example, doing DNS queries and
analyzing results), and there are things about which we just say, "I
don't know anyone who does [or doesn't do] this, so that must be the
case overall."  The latter is hazardous.


According to September 2020 scans 
(https://ieeexplore.ieee.org/abstract/document/9375477/ 


41% of them have p=reject, 9.3% have p=quarantine, and 39.6% have p=none.



To quote the whole paragraph:

Regarding DMARC, only 310,185 out of 236 million do-
mains have DMARC corresponding to approximately 0.13%
of the population. For the domains with a DMARC rule,
41% of them have p=reject , 9.3% have p=quarantine ,
and 39.6% have p=none rule. These figures are also far
different from the 5.1% of the domain names in the Alexa top
1M domains with DMARC rules [9], which again confirms
that more popular domain names deploy email anti-spoofing
schemes on a wider scale.


Granted we don't (and cannot) know reality as a whole.  Efforts to achieve some 
knowledge are welcome, though.



Best
Ale
--





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

Re: [dmarc-ietf] Eliminating From Munging from this list

[OLIVIER HUREAU]

> Instead, I see language that drives people to fixate on the 1% of traffic 
> that has a DMARC policy with p=reject. 

> Indeed: I caution everyone about making assumptions based on what we 
think we know, and extending those assumptions to the entire Internet. 
There are things we can study (by, for example, doing DNS queries and 
analyzing results), and there are things about which we just say, "I 
don't know anyone who does [or doesn't do] this, so that must be the 
case overall." The latter is hazardous. 

According to September 2020 scans ( [ 
https://ieeexplore.ieee.org/abstract/document/9375477/ | 
https://ieeexplore.ieee.org/abstract/document/9375477/ ] ) 

41% of them have p=reject, 9.3% have p=quarantine, and 39.6% have p=none. 

However, my September 2022 measurements (not published) shows that only 38.3% 
have p != none. 
Even though, September 2020 scans resulted in only 310,185 organizational 
domain names with DMARC and my measurements 11M8. 

> Then we are disappointed if they don't look for exceptions, including mailing 
> list messages, 

One of our latest discussions was about domain owners having p=none who might 
enhance their infrastructure. 
>From my measurements, ~40% of domain owners have p=none but nor rua/ruf. 
I extrapolate that 40% of domain owners do not plan to have more restrictive 
handling policies. 

Thus what are the expectations of newcomers in DMARC? 
In my opinion, the current state of DMARC does not meet the expectations. 
I think that the task force should take a closer look at this problem and work 
towards a more user-friendly reporting system, and different, more customizable 
handling policies. 

Best 


De: "Douglas Foster"  
À: "IETF DMARC WG"  
Envoyé: Vendredi 21 Juillet 2023 01:40:49 
Objet: Re: [dmarc-ietf] Eliminating From Munging from this list 

It is not at all clear that my goals for this effort match with others, so I 
will state mine: 
My goal is to develop documents that help evaluators make better disposition 
decisions, to save civilization from as much malicious content as possible. An 
inference from my piece of reality is that this effort has a large upside 
potential. 

Sender authentication is the core of this effort because it is something that 
we can actually specify. Defining a standard for defenses against malicious 
content seems infeasible. For all its difficulties, sender authentication is 
relatively feasible. 

Verification of RFC5322.From is the linchpin to Sender Authentication because 
the RFC5322.From address links the user-visible content to the invisible 
document metadata and SMTP protocol parameters. DMARC defines a formula for 
declaring the RFC5322.From address verified, thereby separating a general 
mailstream into two sub-streams: the verified portion and the unverified 
portion. 

This group has taken the position that a message is only verified if the domain 
owner has published a DMARC policy and the message produces DMARC PASS. From my 
data, that works out to about 40% of the traffic, most of which is Gmail. My 
results seem roughly consistent with data from other sources. This means that 
60% of the traffic has no defined method for detecting possible impersonation, 
so network safety depends entirely on the strength of your content filtering. 

However, it is easy to note that the DMARC concept of Aligned SPF PASS or 
Aligned DKIM PASS is applicable to any message, with or without a DMARC policy. 
There is a minor complication about choosing between relaxed and strict 
authentication, which is solvable by local policy. Applying the DMARC formula 
to a general mailstream, the DMARC-equivalent PASS percentage suddenly jumps 
into the vicinity of 85%. 

The remaining 15% of mail has uncertain impersonation risk, but is much more 
manageable than 60%. It has been a fertile field for investigation. When I ask, 
"Why is this message not impersonated?", the investigation produces one of 
three answers: 


* The message stream is acceptable, but needs a local policy to allow 
future messages to appear authenticated. 
* The message stream is unwanted even though it is not an impersonation, so 
this and future messages from this sender should be blocked. 
* The message stream is from a malicious impersonator, so this and future 
messages from this sender should be blocked. 
Whichever conclusion is reached, investigation is a one-time effort per message 
source. So a technical path exists for ensuring 100% authentication of all 
allowed messages, and quarantining the uncertain messages for investigation. In 
my experience, the middle result dominates. As my recurring and wanted traffic 
gets an authentication rule, and unwanted traffic gets blocked, the volume of 
investigations goes down while the percentage of block results goes up. 

When I examine the language of RFC 7489 and our proposed documents, I find no 
path toward 100% authe

Re: [dmarc-ietf] Eliminating From Munging from this list

[Douglas Foster]

It is not at all clear that my goals for this effort match with others, so
I will state mine:

My goal is to develop documents that help evaluators make better
disposition decisions, to save civilization from as much malicious
content as possible.   An inference from my piece of reality is that this
effort has a large upside potential.

Sender authentication is the core of this effort because it is something
that we can actually specify.   Defining a standard for defenses against
malicious content seems infeasible.  For all its difficulties, sender
authentication is relatively feasible.

Verification of RFC5322.From is the linchpin to Sender Authentication
because the RFC5322.From address links the user-visible content to the
invisible document metadata and SMTP protocol parameters.   DMARC defines a
formula for declaring the RFC5322.From address verified, thereby separating
a general mailstream into two sub-streams:   the verified portion and the
unverified portion.

This group has taken the position that a message is only verified if the
domain owner has published a DMARC policy and the message produces DMARC
PASS.   From my data, that works out to about 40% of the traffic, most of
which is Gmail.  My results seem roughly consistent with data from
other sources.This means that 60% of the traffic has no defined method
for detecting possible impersonation, so network safety depends entirely on
the strength of your content filtering.

However, it is easy to note that the DMARC concept of Aligned SPF PASS or
Aligned DKIM PASS is applicable to any message, with or without a DMARC
policy.  There is a minor complication about choosing between relaxed and
strict authentication, which is solvable by local policy.Applying the
DMARC formula to a general mailstream, the DMARC-equivalent PASS percentage
suddenly jumps into the vicinity of 85%.

The remaining 15% of mail has uncertain impersonation risk, but is much
more manageable than 60%.   It has been a fertile field for investigation.
  When I ask, "Why is this message not impersonated?", the
investigation produces one of three answers:

   - The message stream is acceptable, but needs a local policy to allow
   future messages to appear authenticated.
   - The message stream is unwanted even though it is not an impersonation,
   so this and future messages from this sender should be blocked.
   - The message stream is from a malicious impersonator, so this and
   future messages from this sender should be blocked.

Whichever conclusion is reached, investigation is a one-time effort per
message source.   So a technical path exists for ensuring 100%
authentication of all allowed messages, and quarantining the uncertain
messages for investigation.  In my experience, the middle result
dominates.   As my recurring and wanted traffic gets an authentication
rule, and unwanted traffic gets blocked, the volume of investigations goes
down while the percentage of block results goes up.

When I examine the language of RFC 7489 and our proposed documents, I find
no path toward 100% authentication.   Instead, I see language that drives
people to fixate on the 1% of traffic that has a DMARC policy with
p=reject.  Then we are disappointed if they don't look for exceptions,
including mailing list messages, within the Failure subset of the 1% subset.

If we don't change strategy, nothing will change.   Desperate evaluators
will continue to read our document as a ticket to unconditionally block
that tiny portion of their mailstream which produces Fail with p=reject,
and more importantly, will continue to be vulnerable to impersonation
attacks buried in the other 99%.

Doug Foster






On Thu, Jul 20, 2023 at 3:53 PM Jan Dušátko  wrote:

> Dne 20. 7. 2023 v 14:46 Barry Leiba napsal(a):
> >> I think that it shouldn't affect the answer about what to put in the
> document.  Those of us here are a
> >> miniscule slice of the overall user base for email, I think it's a
> serious mistake to think peculiarities of
> >> the exact lists we use is relevant to anything.
> > Indeed: I caution everyone about making assumptions based on what we
> > think we know, and extending those assumptions to the entire Internet.
> > There are things we can study (by, for example, doing DNS queries and
> > analyzing results), and there are things about which we just say, "I
> > don't know anyone who does [or doesn't do] this, so that must be the
> > case overall."  The latter is hazardous.
> >
> > Barry
> >
> >
> I couldn't agree more. Thinking and knowing are two different things.
> Assuming what others want on the Internet is another thing.
> For that reason, I would also like to ask. What are that technologies
> supposed to be for? The ability to define a domain owner's policy?
> Covering tools to provide protection against counterfeiting? Or a
> meta-tool for authenticity?
> In my opinion, this is an effort to secure what email technology lacks.
> The ability to protect against communication co

Re: [dmarc-ietf] Eliminating From Munging from this list

[Jan Dušátko]

Dne 20. 7. 2023 v 14:46 Barry Leiba napsal(a):

I think that it shouldn't affect the answer about what to put in the document.  
Those of us here are a
miniscule slice of the overall user base for email, I think it's a serious 
mistake to think peculiarities of
the exact lists we use is relevant to anything.

Indeed: I caution everyone about making assumptions based on what we
think we know, and extending those assumptions to the entire Internet.
There are things we can study (by, for example, doing DNS queries and
analyzing results), and there are things about which we just say, "I
don't know anyone who does [or doesn't do] this, so that must be the
case overall."  The latter is hazardous.

Barry


I couldn't agree more. Thinking and knowing are two different things. 
Assuming what others want on the Internet is another thing.
For that reason, I would also like to ask. What are that technologies 
supposed to be for? The ability to define a domain owner's policy? 
Covering tools to provide protection against counterfeiting? Or a 
meta-tool for authenticity?
In my opinion, this is an effort to secure what email technology lacks. 
The ability to protect against communication counterfeiting and, under 
tight conditions, to verify the authenticity of the source. The problem 
is the wide mutual possibilities of communication, which have been 
designed with accessibility and flexibility in mind.
I apologize for such a broad response. I'm trying to understand what 
your goals are to avoid misunderstanding. Sometimes I'm lost in translation.


Regards

Jan

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Barry Leiba]

> I think that it shouldn't affect the answer about what to put in the 
> document.  Those of us here are a
> miniscule slice of the overall user base for email, I think it's a serious 
> mistake to think peculiarities of
> the exact lists we use is relevant to anything.

Indeed: I caution everyone about making assumptions based on what we
think we know, and extending those assumptions to the entire Internet.
There are things we can study (by, for example, doing DNS queries and
analyzing results), and there are things about which we just say, "I
don't know anyone who does [or doesn't do] this, so that must be the
case overall."  The latter is hazardous.

Barry

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Scott Kitterman]

On July 20, 2023 7:46:57 AM UTC, Alessandro Vesely  wrote:
>On Wed 19/Jul/2023 21:38:44 +0200 Scott Kitterman wrote:
>> 
>> 
>> On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely  wrote:
>>> On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote:
 On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely  wrote:
> On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:
>> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>> 
>>> 1) For evaluators that enforce DMARC against lists, are they willing to 
>>> consider any concessions to list traffic?   If so, do they favor an 
>>> exemption process where the list avoids munging, or an unmunging 
>>> solution implemented at their inbound gateway?
>> 
>> How do you determine that an evaluator is enforcing DMARC "against 
>> lists"?
> 
> That assumes there are lists that don't munge From:.  Is that real today?
 
 Most of my list mail is from lists that don't.
>>> 
>>> Oops, I had in mind that lists modify messages.  Some of them don't, that 
>>> way they don't need From: munging.  It is quite common too.
>>> 
>>> Let me reword the question:  Are there lists that modify messages and don't 
>>> munge From:?
>> 
>> Yes, although those are fewer.
>
>
>That's interesting.  Do they have different workarounds or ban p=reject? 
>Please describe something about them, or just share a pointer to their archive 
>if you prefer.
>
>I think it's crucial, since we're weighting how to word the theoretical 
>prohibition to use DMARC, to know what's the actual reality.  Many opponents 
>to MUST NOT argue about the usefulness of closing the stable door after the 
>horses have bolted out.  So, knowing there are some horses still in makes a 
>difference, doesn't it?  Presumably, they're never going to leave even if we 
>leave the doors open?  And why?
>

I really don't know.  These aren't lists I administer.

I think that it shouldn't affect the answer about what to put in the document.  
Those of us here are a miniscule slice of the overall user base for email, I 
think it's a serious mistake to think peculiarities of the exact lists we use 
is relevant to anything.

Scott K

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Alessandro Vesely]

On Wed 19/Jul/2023 21:38:44 +0200 Scott Kitterman wrote:



On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely  wrote:

On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote:

On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely  wrote:

On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:

On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

1) For evaluators that enforce DMARC against lists, are they willing to 
consider any concessions to list traffic?   If so, do they favor an 
exemption process where the list avoids munging, or an unmunging solution 
implemented at their inbound gateway?


How do you determine that an evaluator is enforcing DMARC "against lists"?


That assumes there are lists that don't munge From:.  Is that real today?


Most of my list mail is from lists that don't.


Oops, I had in mind that lists modify messages.  Some of them don't, that way 
they don't need From: munging.  It is quite common too.

Let me reword the question:  Are there lists that modify messages and don't 
munge From:?


Yes, although those are fewer.



That's interesting.  Do they have different workarounds or ban p=reject? 
Please describe something about them, or just share a pointer to their archive 
if you prefer.


I think it's crucial, since we're weighting how to word the theoretical 
prohibition to use DMARC, to know what's the actual reality.  Many opponents to 
MUST NOT argue about the usefulness of closing the stable door after the horses 
have bolted out.  So, knowing there are some horses still in makes a 
difference, doesn't it?  Presumably, they're never going to leave even if we 
leave the doors open?  And why?



Best
Ale
--







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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Tero Kivinen]

Douglas Foster writes:
> Baptiste's proposal is clearly the easiest to implement:   Admins inform the
> group that IETF is going to stop munging on a specific date.  After that date,
> subscribers are switched to digest mode if the MLM or the user detects
> problems.   Admins switch them back when the user reports that the list
> traffic has an exception in place by the subscriber's evaluator.  This
> approach may also be sufficient for this list, as I suspect that most of our
> evaluators will already have an exemption for IETF.

I do not think there is any need for admins to switch users back.
Users are already able to log in to list options page
(https://www.ietf.org/mailman/options/dmarc for this list) and change
Set Digest Mode option on or off.

So if the mailing list receives bounce from specific user, and that
user is not yet using digest mode, then mailing list would turn on
digest mode. If it gets bounce from the digest email sent to the user,
it would do whatever it now does when it receives bounces (I think
they temporarely disable deliver, and after some time they will try
again and after repeated failures they will remove user from the
list or something like that).

If user thinks his mail system is fixed so non digested emails works,
he can log in to options page for the mailing list and turn of digest
mode. If he was wrong and the non-digested emails do not work, then
there will be bounce, and digest mode gets automatically turned on
again.

There is no point of asking admins to do anything for specific users,
when users can do those operations themselves. 
-- 
kivi...@iki.fi

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Baptiste Carvello]

Hi,

Le 19/07/2023 à 19:38, Alessandro Vesely a écrit :
> 
> Oops, I had in mind that lists modify messages.  Some of them don't,
> that way they don't need From: munging.  It is quite common too.
> 
> Let me reword the question:  Are there lists that modify messages and
> don't munge From:?

What exactly is this question achieving? It looks to me, what you are
trying to assess is the level of resignation, after 10 years of
bullying, to a poor workaround that we know list users hate (because it
breaks the semantics of the conversation). Cynical at best.

We also know this workaround doesn't help DMARC in the long run, as it
undermines the significance of the From header. Which is why this group
never endorsed it.

So where do we go from here?

Cheers,
Baptiste

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Scott Kitterman]

On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely  wrote:
>On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote:
>> On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely  wrote:
>>> On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:
 On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
 dougfoster.emailstanda...@gmail.com> wrote:
 
> 1) For evaluators that enforce DMARC against lists, are they willing to
> consider any concessions to list traffic?   If so, do they favor an
> exemption process where the list avoids munging, or an unmunging solution
> implemented at their inbound gateway?
 
 How do you determine that an evaluator is enforcing DMARC "against lists"?
>>> 
>>> That assumes there are lists that don't munge From:.  Is that real today?
>> 
>> Most of my list mail is from lists that don't.
>
>
>Oops, I had in mind that lists modify messages.  Some of them don't, that way 
>they don't need From: munging.  It is quite common too.
>
>Let me reword the question:  Are there lists that modify messages and don't 
>munge From:?
>
Yes, although those are fewer.

Scott K

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[John Levine]

It appears that Scott Kitterman   said:
>>That assumes there are lists that don't munge From:.  Is that real today?
>
>Most of my list mail is from lists that don't.
>
>Scott K

Even for lists that do change the From: they do it in a zillion
different ways that depend on the goals of the list and the kind of
infrastructure they have.

Since message munging is out of scope for DMARC, it should
would be nice if people interested in this topic could find some other
place to argue about it.

R's,
John



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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Benny Pedersen]

Alessandro Vesely skrev den 2023-07-19 19:38:


Let me reword the question:  Are there lists that modify messages and
don't munge From:?


Authentication-Results: mx.junc.eu (amavisd-new); dkim=pass (1024-bit 
key)

header.d=ietf.org header.b="M78Nxm+h"; dkim=pass (1024-bit key)
header.d=ietf.org header.b="KUhOcaZu"; dkim=neutral
reason="invalid (unsupported algorithm ed25519-sha256)"
header.d=tana.it header.b="sAKZ9jA7"; dkim=fail (1152-bit key)
reason="fail (body has been altered)" header.d=tana.it
header.b="Axzjfts6"

i really don't know :)


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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Alessandro Vesely]

On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote:

On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely  wrote:

On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:

On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:


1) For evaluators that enforce DMARC against lists, are they willing to
consider any concessions to list traffic?   If so, do they favor an
exemption process where the list avoids munging, or an unmunging solution
implemented at their inbound gateway?


How do you determine that an evaluator is enforcing DMARC "against lists"?


That assumes there are lists that don't munge From:.  Is that real today?


Most of my list mail is from lists that don't.



Oops, I had in mind that lists modify messages.  Some of them don't, that way 
they don't need From: munging.  It is quite common too.


Let me reword the question:  Are there lists that modify messages and don't 
munge From:?



Best
Ale
--




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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Mark Alley]

On 7/19/2023 8:10 AM, Murray S. Kucherawy wrote:

On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely  wrote:

> How do you determine that an evaluator is enforcing DMARC
"against lists"?

That assumes there are lists that don't munge From:.  Is that real
today?


I wasn't aware that this munging had become a standard, or even 
common.  It's a popular solution to DMARC specifically, to be sure.
Anecdotal example, but most lists I've been a part of personally, or 
worked with domains that had users on various different lists, almost 
all of them used munging for domains with p=reject. Without data from 
all lists that exists in totality on the internet it's hard to really 
say how common statistically, but my experience has seemed that it is 
more common, than uncommon.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Eliminating From Munging from this list

[Scott Kitterman]

On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely  wrote:
>On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:
>> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>> 
>>> 1) For evaluators that enforce DMARC against lists, are they willing to
>>> consider any concessions to list traffic?   If so, do they favor an
>>> exemption process where the list avoids munging, or an unmunging solution
>>> implemented at their inbound gateway?
>> 
>> How do you determine that an evaluator is enforcing DMARC "against lists"?
>
>
>That assumes there are lists that don't munge From:.  Is that real today?

Most of my list mail is from lists that don't.

Scott K

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Murray S. Kucherawy]

On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely  wrote:

> > How do you determine that an evaluator is enforcing DMARC "against
> lists"?
>
> That assumes there are lists that don't munge From:.  Is that real today?
>

I wasn't aware that this munging had become a standard, or even common.
It's a popular solution to DMARC specifically, to be sure.

> How can one definitively identify list traffic?
>
> Certainly not by List-* headers.  In particular, List-Unsubscribe: seems
> to be
> required in most mail messages.
>

They may be common, but they are not required.

> Also, I imagine that if munging is to be considered reversible, either the
> > munging itself, or a way to describe it, needs to be standardized in some
> > form.
>
> Hasn't that ship sailed already?
>

Can you please point me to the specification?

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Douglas Foster]

Trying to stay within Barry's guidelines, my original comment was about
this list, but with an eye to how it can be generalized.

In any specific case, the message stream from a  list like our own should
be identifiable by seeing expected values for:

- MailFrom address = list bounce address
- DKIM signature with DKIM PASS (to retain authentication after secondary
forwarding)
- List ID
- To address = list's posting address
- SPF PASS or SPF NONE at first hop after list forwarding
- ARC data that identifies the forwarding point and affirms the author
identity

I do not suggest that a general mail stream can be parsed to detect a
previously unknown list.  Nor do not suggest that an automated detection
process can be safely used to grant the privileged status needed by lists.
I do think ARC will need additional tokens to describe tools other than SPF
and DKIM which a list may use to authenticate a post's author.

Options for our specific list:

We have alternatives to the current munging behavior, and this group is
highly motivated to see munging go away.   So something should be done.

Baptiste's proposal is clearly the easiest to implement:   Admins inform
the group that IETF is going to stop munging on a specific date.  After
that date, subscribers are switched to digest mode if the MLM or the user
detects problems.   Admins switch them back when the user reports that the
list traffic has an exception in place by the subscriber's evaluator.  This
approach may also be sufficient for this list, as I suspect that most of
our evaluators will already have an exemption for IETF.

Emanuel's approach requires software development by every evaluator or
their software providers.   The Intranet has a decreasing number of
software providers and hosting services,, but this scope seems problematic
even for the limited scale of this list.  The larger problem is that the
software implementation still needs human guidance about which messages
should be un-munged.   Malicious actors will add un-munging signals if they
think it will enhance their attacks and permit impersonation.

So I keep coming back to the most difficult proposal, which is my own.   An
evaluator needs to be able to identify specific list traffic using
information provided by the list, probably through a disclosure statement
or service agreement document.  To facilitate automation, the disclosure
could eventually be standardized as an XML document, perhaps supplemented
by free-form content for human consumption.  We need an initial list, our
own, to work out that standard.  Ultimately, my approach still requires a
transaction where a human decides to trust the list and restore it to
"privileged" status, typically in response to a support ticket from a
subscriber to his own email administration.

I admit that my approach also has scaling problems, because each list must
be considered individually.  For the moment, the scope is one list, not all
lists.

Being a trustworthy list is also very important to me.  Baptiste's approach
does not require the list to make any promises, so it does not require the
list to undertake any security improvements.   I want to see this list
implement 100% sender authentication even more badly than I want munging
removed.  I want that level of authentication to become the norm when the
concept scales upward.   Disclosure statements only work when they are not
announcing vulnerabilities.

Doug Foster







On Wed, Jul 19, 2023 at 2:20 AM Murray S. Kucherawy 
wrote:

> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> 1) For evaluators that enforce DMARC against lists, are they willing to
>> consider any concessions to list traffic?   If so, do they favor an
>> exemption process where the list avoids munging, or an unmunging solution
>> implemented at their inbound gateway?
>>
>
> How do you determine that an evaluator is enforcing DMARC "against
> lists"?  How can one definitively identify list traffic?
>
> Also, I imagine that if munging is to be considered reversible, either the
> munging itself, or a way to describe it, needs to be standardized in some
> form.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Eliminating From Munging from this list

[Alessandro Vesely]

On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote:

On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:


1) For evaluators that enforce DMARC against lists, are they willing to
consider any concessions to list traffic?   If so, do they favor an
exemption process where the list avoids munging, or an unmunging solution
implemented at their inbound gateway?


How do you determine that an evaluator is enforcing DMARC "against lists"?



That assumes there are lists that don't munge From:.  Is that real today?



How can one definitively identify list traffic?



Certainly not by List-* headers.  In particular, List-Unsubscribe: seems to be 
required in most mail messages.




Also, I imagine that if munging is to be considered reversible, either the
munging itself, or a way to describe it, needs to be standardized in some
form.



Hasn't that ship sailed already?



Best
Ale
--






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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Murray S. Kucherawy]

On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> 1) For evaluators that enforce DMARC against lists, are they willing to
> consider any concessions to list traffic?   If so, do they favor an
> exemption process where the list avoids munging, or an unmunging solution
> implemented at their inbound gateway?
>

How do you determine that an evaluator is enforcing DMARC "against lists"?
How can one definitively identify list traffic?

Also, I imagine that if munging is to be considered reversible, either the
munging itself, or a way to describe it, needs to be standardized in some
form.

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Douglas Foster]

The question was about this list, because Murray has advised that every
specification needs a working prototype.   Barry has said that we will not
bloat DMARCbis with advice to mailing lists, but it could be in a companion
document.   The topic is closely tied to DMARCbis so there is no other
group which is well positioned to explore the options.

The first conclusion from this discussion is that options exist.   The best
option depends on the evaluators involved.

A variant of Baptiste's proposal is to announce and send a test message
that violates DMARC.   As he said, rejects and bounces tell you which
evaluators distrust the list.Positive replies ("I got the test")
indicates a domain that is not enforcing DMARC against the list.   Negative
responses ("When are you sending the test?") also indicate blocks.
 Recipients with no response are ambiguous, but suggest a block.  Of
course, an organization's security posture may change over time, so this
result is not stable.

To Ale's point, un-munging should be very simple with an ARC set that
documents the original RFC5322.From value.   This still requires that the
evaluator recognize the list as a sender for whom un-munging is desirable.
 This desire implies some level of trust in the list and an ability to
distinguish trusted lists from all other traffic,   To support that trust
decision, I come back to the need for an operating practices disclosure
document.   Essentially, the negotiation still occurs:   the evaluator is
unlikely to do anything until requested by a subscriber in his domain, and
then the evaluator will look to the list's published documentation to
decide whether to un-mung.

Questions to consider:

1) For evaluators that enforce DMARC against lists, are they willing to
consider any concessions to list traffic?   If so, do they favor an
exemption process where the list avoids munging, or an unmunging solution
implemented at their inbound gateway?

Although inbound gateways routinely add content to inbound messages, I am
fearful of adding custom code to do so myself.   So I would prefer a
solution that avoids munging at the source, rather than a solution based on
double changes to mung at the list and unmung at the gateway.

Eventually, we can hope that the optimal solution becomes a standard part
of product offerings, so the fear is diminished.   The un-munging solution
requires identifying the list traffic and reversing the changes, but may
have  added trust if un verified signatures can be made verifiable.  The
negotiated solution requires only the ability to identify the list traffic,
but has no expectation of restoring broken signature.

2) For evaluators that do not enforce DMARC against lists, would a
mung-free solution for mailing lists allow them to enforce DMARC against
other traffic to improve their security posture?   It seems like they have
a double whammy:   Their users get munged mail because of what other
domains might do, but they are afraid of using DMARC results because of
lists that do not mung.

Doug








On Tue, Jul 18, 2023 at 6:04 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> Le 17/07/2023 à 03:50, Emanuel Schorsch a écrit :
> >
> > - By default FromMunging remains the practice without special
> > information.
> > - MailingLists add ARC Headers and an additional header for what the
> > unmunged FromHeader was
> > […]
> > This gives the information needed to evaluators to undo the fromMunging
> on
> > their end.
>
> Well, call me a pessimist if you will, but I parse this as: generalize
> FromMunging now in the hope for a future, "potential", solution. It
> looks like a trap: if FromMunging gets even more normalized, evaluators
> will have even less incentive to work towards an actual fix.
>
> The best outcome I see is that power users will be able to undo the
> munging client-side with a MUA-plugin. Which is nice, but only solves
> the problem for a very small part of the community.
>
> Cheers,
> Baptiste
>
> ___
> 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] Eliminating From Munging from this list

[Alessandro Vesely]

On Tue 18/Jul/2023 12:04:19 +0200 Baptiste Carvello wrote:

Hi,

Le 17/07/2023 à 03:50, Emanuel Schorsch a écrit :


- By default FromMunging remains the practice without special
information.
- MailingLists add ARC Headers and an additional header for what the
unmunged FromHeader was 
[…]

This gives the information needed to evaluators to undo the fromMunging on
their end.


Well, call me a pessimist if you will, but I parse this as: generalize
FromMunging now in the hope for a future, "potential", solution. It
looks like a trap: if FromMunging gets even more normalized, evaluators
will have even less incentive to work towards an actual fix.

The best outcome I see is that power users will be able to undo the
munging client-side with a MUA-plugin. Which is nice, but only solves
the problem for a very small part of the community.



Restoring the original From: is already possible.  The filter I use does it on 
about 50% of cases, because it tries to verify the original signature, which 
not always succeeds.  If, instead of a generic approach, one authenticates this 
list's messages by IP, mail.ietf.org [50.223.129.194], it can then just replace 
X-Original-From:.  Different lists save the original From: in different places. 
 If FromMunging were more normalized, it'd be easier.



Best
Ale
--






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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Baptiste Carvello]

Hi,

Le 17/07/2023 à 03:50, Emanuel Schorsch a écrit :
> 
> - By default FromMunging remains the practice without special
> information.
> - MailingLists add ARC Headers and an additional header for what the
> unmunged FromHeader was 
> […]
> This gives the information needed to evaluators to undo the fromMunging on
> their end.

Well, call me a pessimist if you will, but I parse this as: generalize
FromMunging now in the hope for a future, "potential", solution. It
looks like a trap: if FromMunging gets even more normalized, evaluators
will have even less incentive to work towards an actual fix.

The best outcome I see is that power users will be able to undo the
munging client-side with a MUA-plugin. Which is nice, but only solves
the problem for a very small part of the community.

Cheers,
Baptiste

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Wei Chuang]

On Sun, Jul 16, 2023 at 6:50 PM Emanuel Schorsch  wrote:

> Having negotiations between senders, evaluators and lists sounds
> difficult. I agree the dream would be to have at least a semi-automated
> solution which works. I'd be interested to hear what you think of the
> following rough idea (with the assumption that most lists today are
> currently doing FromMunging on p=reject domains):
>
>- By default FromMunging remains the practice without special
>information.
>- MailingLists add ARC Headers and an additional header for what the
>unmunged FromHeader was (with some agreed on standard, e.g. Wei's
>proposal
>
> 
>  to
>use `Prior-From`).
>
> Apologies that the draft-chuang-mailing-list-modifications I-D is in rough
-00 form i.e. there's some more clean up needed.  And agree in hindsight
that the draft should be based in ARC (RFC8617) and separately call out how
it modifies draft-chuang-replay-resistant-arc.

-Wei


> This gives the information needed to evaluators to undo the fromMunging on
> their end. Evaluators can check the original authentication in case the
> list does not enforce authentication checks. More importantly, evaluators
> can undo the fromMunging and restore the original header within the
> evaluators system. This can be based on an explicit system (user manually
> adds a setting that this list is trusted), or an implicit system (evaluator
> sees that the list is trustworthy in general, or that is implicitly trusted
> by the specific recipient).
>
> This would place a burden on MailingLists (to add Arc headers and original
> FromHeader) and would place a burden on evaluators (to have a refined
> evaluation method with a nuanced understanding of "trust" in lists). It
> seems if both parties showed interest it would be a tractable solution. A
> nice aspect of this solution is that I don't believe these changes would
> break non-participants, and gradual adoption by individual lists /
> evaluators would show benefits.
>
> Emanuel Schorsch
>
> On Sun, Jul 16, 2023 at 1:51 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As long as the unsympathetic evaluator produces a reject or bounce, the
>> automatic digest approach will work well.   if digest mode failover is
>> implemented as an operator function, it could be implemented quickly
>> without software changes .   Automating the process seems like a minor
>> undertaking as well.   If the evaluator does silent discard, your approach
>> depends on the evaluator noting that messages are missing.
>>
>> To get out of digest mode, the user still needs to negotiate with his
>> evaluator.   You are despondent on that point, I am more hopeful,
>> especially for this particular list's participants.   For the negotiation
>> to be successful, I think the user will need the information I discussed,
>> including:   a commitment of 100% sender authentication prior to
>> forwarding, a definition of how the evaluator can identify list traffic,
>> and clarity about what content filtering is or is not done before
>> forwarding.   We don't want the list to be blacklisted simply because the
>> evaluator has stricter content filtering than the list provides.
>>
>> Both your approach and mine will isolate the problem to unsympathetic
>> evaluators and their unfortunate users.   Both approaches know that we must
>> either modify the evaluator's filtering rules or live within those rules.
>>  Neither of these two approaches requires asking senders to lower their
>> security posture from p=reject to p=none., and both eliminate From munging,
>> which is a big win.
>>
>> Doug Foster
>>
>>
>> On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello <
>> devel2...@baptiste-carvello.net> wrote:
>>
>>> Hi,
>>>
>>> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
>>> > [...]
>>> > Track 2: Exception Request
>>> > [...]
>>> > Track 2 benefits:
>>> > [...]
>>> > - Elimination of From munging is potentially available to all
>>> > participants, even those from p=reject domains
>>>
>>> This important word here is "potentially". In practice, only an
>>> insignificant part of this potential can be achieved, because your plan
>>> heavily relies on non-automatable human work, and on end users being
>>> able to weight into their providers' policies.
>>>
>>> Thus for all practical purposes, "conditional munging" is equivalent to
>>> plain munging.
>>>
>>> Therefore I propose Track 3:
>>>
>>> 1) We undo existing munging.
>>>
>>> 2) We inform end users that, if they do not receive messages from
>>> certain senders (especially those senders whose addresses were
>>> previously munged), they can regain them by switching their subscription
>>> mode to "digests", at least temporarily while their mailbox provider
>>> fixes their DMARC handling.
>>>
>>> 3) Whenever we get bounces, we configure our software to forcibly switch
>>> the offending users (I mean the receive

Re: [dmarc-ietf] Eliminating From Munging from this list

[Emanuel Schorsch]

Having negotiations between senders, evaluators and lists sounds difficult.
I agree the dream would be to have at least a semi-automated solution which
works. I'd be interested to hear what you think of the following rough idea
(with the assumption that most lists today are currently doing FromMunging
on p=reject domains):

   - By default FromMunging remains the practice without special
   information.
   - MailingLists add ARC Headers and an additional header for what the
   unmunged FromHeader was (with some agreed on standard, e.g. Wei's
   proposal
   

to
   use `Prior-From`).

This gives the information needed to evaluators to undo the fromMunging on
their end. Evaluators can check the original authentication in case the
list does not enforce authentication checks. More importantly, evaluators
can undo the fromMunging and restore the original header within the
evaluators system. This can be based on an explicit system (user manually
adds a setting that this list is trusted), or an implicit system (evaluator
sees that the list is trustworthy in general, or that is implicitly trusted
by the specific recipient).

This would place a burden on MailingLists (to add Arc headers and original
FromHeader) and would place a burden on evaluators (to have a refined
evaluation method with a nuanced understanding of "trust" in lists). It
seems if both parties showed interest it would be a tractable solution. A
nice aspect of this solution is that I don't believe these changes would
break non-participants, and gradual adoption by individual lists /
evaluators would show benefits.

Emanuel Schorsch

On Sun, Jul 16, 2023 at 1:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> As long as the unsympathetic evaluator produces a reject or bounce, the
> automatic digest approach will work well.   if digest mode failover is
> implemented as an operator function, it could be implemented quickly
> without software changes .   Automating the process seems like a minor
> undertaking as well.   If the evaluator does silent discard, your approach
> depends on the evaluator noting that messages are missing.
>
> To get out of digest mode, the user still needs to negotiate with his
> evaluator.   You are despondent on that point, I am more hopeful,
> especially for this particular list's participants.   For the negotiation
> to be successful, I think the user will need the information I discussed,
> including:   a commitment of 100% sender authentication prior to
> forwarding, a definition of how the evaluator can identify list traffic,
> and clarity about what content filtering is or is not done before
> forwarding.   We don't want the list to be blacklisted simply because the
> evaluator has stricter content filtering than the list provides.
>
> Both your approach and mine will isolate the problem to unsympathetic
> evaluators and their unfortunate users.   Both approaches know that we must
> either modify the evaluator's filtering rules or live within those rules.
>  Neither of these two approaches requires asking senders to lower their
> security posture from p=reject to p=none., and both eliminate From munging,
> which is a big win.
>
> Doug Foster
>
>
> On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
>> > [...]
>> > Track 2: Exception Request
>> > [...]
>> > Track 2 benefits:
>> > [...]
>> > - Elimination of From munging is potentially available to all
>> > participants, even those from p=reject domains
>>
>> This important word here is "potentially". In practice, only an
>> insignificant part of this potential can be achieved, because your plan
>> heavily relies on non-automatable human work, and on end users being
>> able to weight into their providers' policies.
>>
>> Thus for all practical purposes, "conditional munging" is equivalent to
>> plain munging.
>>
>> Therefore I propose Track 3:
>>
>> 1) We undo existing munging.
>>
>> 2) We inform end users that, if they do not receive messages from
>> certain senders (especially those senders whose addresses were
>> previously munged), they can regain them by switching their subscription
>> mode to "digests", at least temporarily while their mailbox provider
>> fixes their DMARC handling.
>>
>> 3) Whenever we get bounces, we configure our software to forcibly switch
>> the offending users (I mean the receivers) to "digests". We inform the
>> impacted users that they can try resetting their subscription mode to
>> plain messages after a few months, in case their provider fixed their
>> handling in between.
>>
>> 4) We publicize our rules widely, so mailbox providers know how to avoid
>> inconveniencing their users.
>>
>> Track 3 benefits:
>> - fully automatable
>> - doesn't break the semantics of conversations (digests correctly embed
>> the messages instead of improperl

Re: [dmarc-ietf] Eliminating From Munging from this list

[Douglas Foster]

As long as the unsympathetic evaluator produces a reject or bounce, the
automatic digest approach will work well.   if digest mode failover is
implemented as an operator function, it could be implemented quickly
without software changes .   Automating the process seems like a minor
undertaking as well.   If the evaluator does silent discard, your approach
depends on the evaluator noting that messages are missing.

To get out of digest mode, the user still needs to negotiate with his
evaluator.   You are despondent on that point, I am more hopeful,
especially for this particular list's participants.   For the negotiation
to be successful, I think the user will need the information I discussed,
including:   a commitment of 100% sender authentication prior to
forwarding, a definition of how the evaluator can identify list traffic,
and clarity about what content filtering is or is not done before
forwarding.   We don't want the list to be blacklisted simply because the
evaluator has stricter content filtering than the list provides.

Both your approach and mine will isolate the problem to unsympathetic
evaluators and their unfortunate users.   Both approaches know that we must
either modify the evaluator's filtering rules or live within those rules.
 Neither of these two approaches requires asking senders to lower their
security posture from p=reject to p=none., and both eliminate From munging,
which is a big win.

Doug Foster


On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
> > [...]
> > Track 2: Exception Request
> > [...]
> > Track 2 benefits:
> > [...]
> > - Elimination of From munging is potentially available to all
> > participants, even those from p=reject domains
>
> This important word here is "potentially". In practice, only an
> insignificant part of this potential can be achieved, because your plan
> heavily relies on non-automatable human work, and on end users being
> able to weight into their providers' policies.
>
> Thus for all practical purposes, "conditional munging" is equivalent to
> plain munging.
>
> Therefore I propose Track 3:
>
> 1) We undo existing munging.
>
> 2) We inform end users that, if they do not receive messages from
> certain senders (especially those senders whose addresses were
> previously munged), they can regain them by switching their subscription
> mode to "digests", at least temporarily while their mailbox provider
> fixes their DMARC handling.
>
> 3) Whenever we get bounces, we configure our software to forcibly switch
> the offending users (I mean the receivers) to "digests". We inform the
> impacted users that they can try resetting their subscription mode to
> plain messages after a few months, in case their provider fixed their
> handling in between.
>
> 4) We publicize our rules widely, so mailbox providers know how to avoid
> inconveniencing their users.
>
> Track 3 benefits:
> - fully automatable
> - doesn't break the semantics of conversations (digests correctly embed
> the messages instead of improperly claiming authorship)
> - gives mailbox providers an incentive to move to a more sophisticated
> DMARC handling.
> - doesn't rely on the sending side to fix their practices, as the
> consensus here seems to be that it will never happen.
>
> Cheers,
> Baptiste
>
> ___
> 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] Eliminating From Munging from this list

[Baptiste Carvello]

Hi,

Le 15/07/2023 à 12:22, Douglas Foster a écrit :

[...]
Track 2: Exception Request
[...]
Track 2 benefits:
[...]
- Elimination of From munging is potentially available to all 
participants, even those from p=reject domains


This important word here is "potentially". In practice, only an 
insignificant part of this potential can be achieved, because your plan 
heavily relies on non-automatable human work, and on end users being 
able to weight into their providers' policies.


Thus for all practical purposes, "conditional munging" is equivalent to 
plain munging.


Therefore I propose Track 3:

1) We undo existing munging.

2) We inform end users that, if they do not receive messages from 
certain senders (especially those senders whose addresses were 
previously munged), they can regain them by switching their subscription 
mode to "digests", at least temporarily while their mailbox provider 
fixes their DMARC handling.


3) Whenever we get bounces, we configure our software to forcibly switch 
the offending users (I mean the receivers) to "digests". We inform the 
impacted users that they can try resetting their subscription mode to 
plain messages after a few months, in case their provider fixed their 
handling in between.


4) We publicize our rules widely, so mailbox providers know how to avoid 
inconveniencing their users.


Track 3 benefits:
- fully automatable
- doesn't break the semantics of conversations (digests correctly embed 
the messages instead of improperly claiming authorship)
- gives mailbox providers an incentive to move to a more sophisticated 
DMARC handling.
- doesn't rely on the sending side to fix their practices, as the 
consensus here seems to be that it will never happen.


Cheers,
Baptiste

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

Re: [dmarc-ietf] Eliminating From Munging from this list

[Douglas Foster]

We have two tracks that we can pursue for eliminating From munging from
this list:   They can be pursued in parallel:

Track 1:   Downgrade Request
We identify the small number of domains and subscribers who participate
from p=reject domains, and consequently have their submissions munged.
We develop a document which explains all the reasons why p=reject is a bad
idea because of its impact on mailing lists.
We ask the p=reject participants to ask their domains to change their DMARC
status from p=reject to p=none.
We see if the participants are willing to submit the request.
We evaluate responses from those domains.

This track could have been done a long time ago.

Track 2: Exception Request
1) We fix our incoming filtering so that all submissions have verified
identities.   This is much easier for a list like this one than for a
general mailstream.

2) We implement conditional munging.

3) We document and explain the list's operating practices, to include:
- The techniques we use to achieve 100% identity verification
- The message changes made by the list, with a special emphasis on the
security benefits of forcing all body content to text mode.
- Other content controls, such as attachment policy.
- All of the ways that list messages can be distinguished from all other
messages, so that a filtering exemption can be applied successfully
Then we explain that because of these controls, DMARC enforcement is not
needed because sender authentication has already been enforced.  Because
the beneficial content changes, DMARC enforcement at final delivery is
actually counter-productive.

4) Finally, we ask all participants to submit an Exception Request to their
email policies, to bypass DMARC enforcement for list messages.   Our
operating practices document is intended as supporting material for the
exception request.

5) For any participant that receives a favorable response to his submission
request, we skip From munging on messages sent to that that domain.

Track 2 requires actual "Internet Engineering"
- We SHOULD be doing 100% sender authentication.  Undertaking the effort
will identify technical obstacles that need to be overcome.   The technical
obstacles may be different for different list types.   The effort will
almost certainly identify authentication techniques that are effective for
authentication purposes but not currently configured as an A-R or ARC
authentication result.
- We SHOULD provide better documentation of our operating practices.
Undertaking the effort will provide a model for other lists to follow.

Track 2 benefits:
- From munging can be eliminated for a participant with only the
cooperation of their domain administration.   The solution does not require
the cooperation of any other domains.
- Elimination of From munging is potentially available to all participants,
even those from p=reject domains
- We are not fighting a battle to convince domains to lower their security
posture.
- Results can be obtained in months, possibly a year, based on development
complexity and available resources.   We have been trying some version of
Track 1 for over a decade, with poor results.

Can we please get started on Track 2?

Doug Foster






On Thu, Jul 13, 2023 at 10:55 AM Barry Leiba 
wrote:

> > The issue is not about lists being second class.  What lists do to a
> message is a privileged function, because
> > modifying a message can be done maliciously as easily as it can be done
> innocently.   So the real problem
> > is that DMARC demoted them from privileged to non-privileged by exposing
> the risk inherent in their message
> > modifications.   Non-privileged parricipants do not have permission to
> modify messages that they did not author.
>
> I do mostly agree with this, and it's a good point.
>
> Let me note two things:
>
> (1) As I've said before, telling mailing lists how they might deal
> with this situation is out of scope for THIS DOCUMENT.
>
> (2) Telling mailing lists how they might deal with this situation is
> absolutely in scope for this working group.
>
> Apart from rewriting the From header, which you seem to be presenting
> as the only or best thing that mailing lists can do, there are other
> solutions that mailing lists could adopt.  For example, they could
> bounce posts from p=reject domains.  They could simply not modify
> messages that are posted from p=reject domains.  Ale has a proposal
> that we will surely discuss at some point that sets up an automated
> allow-list system so that receiving domains can adjust based on
> information from the mailing list and the subscriber.
>
> We can and should discuss these and consider an update to RFC 7960,
> perhaps as a BCP for mailing list managers about dealing with DMARC.
>
> In this document, specifying the DMARC protocol, we should say how we
> think DMARC should work.  I believe that means we need to say,
> regardless of who we think will not pay attention, that p=reject is
> not intended for domains that give out general-