Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

On 4/28/2023 5:19 AM, Alessandro Vesely wrote:
> On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote:
>> Mailing list changes to ameliorate damage due to DMARC are in no 
way an improvement.  Absent DMARC, they would not be needed at all.

>
> +1

In my view, when an incomplete protocol is introduced, it creates 
gaps. If there are no guidelines for addressing these gaps in a 
graceful and elegant manner, solutions can vary widely. As developers, 
it's important to have the ability to make adjustments to our software.


Here are a few suggestions to "ameliorate damages" caused by an 
incomplete protocol:


1) Address the gaps with proper protocol negotiation guidelines and a 
well-defined state machine. This includes addressing third-party 
signers and providing guidance for groupware, one-to-many, mailing 
lists, and newsletter distribution mailers. This would make the 
protocol more complete.


2) If option #1 is not viable and continues to be a non-starter with 
the editor of this standard track bis document, the document's status 
and endorsement become technically challenged in many ways. It then 
becomes critical to have a Field Operations status report on a) DMARC 
p=reject problems, b) current problem mitigations, and c) any new 
security threats introduced by the mitigations, particularly with a 
DMARC Security teardown.


There aren't many options for MLS developers when dealing with an 
incomplete protocol.


I have been developing mail software since the '80s, with products 
such as Silver Xpress, Platinum Xpress, Gold Xpress, and Wildcat! 
These early experiences have informed my current understanding of the 
challenges in integrating DMARC into systems.


Regarding rewrite, we don't want to promote it, but it may now be 
necessary to describe it as a new potential "Display Name" security 
threat. However, there are legitimate situations where a rewrite is 
both technically necessary and ethically acceptable. For example:


A MLM Newsletter list domain MUST have a From: domain example-biz.com 
for security. This is a read-only list, and only a few authorized 
submitters can post newsletters. They use their ESP's MUA to submit 
using their ESP's domain address.


In this case, it is about the content payload, not the submitter. This 
is a legitimate situation where a complete rewrite of the incoming 
header is warranted. In the case of DMARC, it becomes necessary. The 
ESP's headers are removed, and the RFC5322 is applied for a secure, 
unambiguous result. It would be as if the customer logged into wcWEB 
and posted the newsletter directly in their MLM List storage area, but 
they prefer to do it via ESP email.


Therefore, rewrite can be described as BAD when used intentionally to 
break down DMARC security or GOOD when used to create DMARC secured 
distribution.


Thanks

--
Hector Santos,
https://santronics.com
https://winserver.com



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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Sun 02/Apr/2023 20:13:48 +0200 Scott Kitterman wrote:

Mailing list changes to ameliorate damage due to DMARC are in no way an 
improvement.  Absent DMARC, they would not be needed at all.


+1


Best
Ale
--






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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On April 18, 2023 10:25:00 PM UTC, Jim Fenton  wrote:
>On 9 Apr 2023, at 11:33, Barry Leiba wrote:
>
>> There is an alternative, though: we can acknowledge that because of how
>> those deploying DMARC view their needs over interoperability, DMARC is not
>> appropriate as an IETF standard, and we abandon the effort to make it
>> Proposed Standard.
>>
>> I see that as the only way forward if we cannot address the damage that
>> improperly deployed DMARC policies do to mailing lists.
>
>Unfortunately, much of the world outside IETF sees an RFC number and assumes 
>Standards Track. We have RFC 7489, which is Informational, which then resulted 
>in a mandate [1] for all executive-branch US Government domains to publish 
>p=reject. I have to believe that they thought it was Standards Track when they 
>did this.
>
>-Jim
>
>[1] https://cyber.dhs.gov/assets/report/bod-18-01.pdf

It's not just in the US either.

That said, I don't think we should throw up our hands and go home.  I think 
what we have so far is enough improvement over RFC 7489 that it's worth getting 
published.  I also think we can appropriately describe the interoperability 
impacts associated with DMARC in a useful way that will provide overall 
benefits, even though we don't have it solved.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On April 18, 2023 10:00:45 PM UTC, Jim Fenton  wrote:
>On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote:
>
>> (Note, here, that Barry has in his proposed text limited the constraint to
>> those types of deployments where the damage is likely.  I concur.  DMARC,
>> as currently defined, works just fine when deployed in transactional
>> situations.  Or, at least, I haven't seen that identified as a problem
>> case.)
>
>I have been trying to point out a problem in even for transactional messages. 
>Some receive-side forwarders that people use break DKIM signatures, and of 
>course break SPF. So a transactional message sent to a forwarded address might 
>be rejected if the address to which it is forwarded enforces DMARC.
>
>IMO, receive-side forwarding is an important use case. It allows people to 
>maintain a consistent email address if they change mail providers. For people 
>whose email provider is their ISP, that keeps them from being locked into that 
>ISP.
>
>It’s possible that this might be solved if the forwarder implements ARC, but 
>only if the address to which it is forwarded knows how to implement ARC. I 
>suspect that many DMARC enforcers currently don’t.
>
I think this is correct, but I also think the consequences for these failures 
are different enough that they don't carry the same degree of importance.

1.  Unlike on mailing lists, if you have set up a forwarder and you decline to 
accept mail from the forwarder and the forwarder unsubscribes you from their 
service, that's entirely a local problem.  I realize that this may not be very 
tractable for users of large mail services, but the simple answer is either 
whitelist such sources from DMARC checks and use ARC data if it's available (or 
parse the AR header field the forwarder includes) to find out if the message 
was spoofed when received by the forwarder.

There's no third-party damages as there can be with between ADMD mediators.

2.  The forwarder is the receiver's ADMD boundary with the Internet.  Internal 
forwarding beyond the border MTA is really an Internal problem.  I don't think 
it's technically an Internet interoperability problem in the way the IETF would 
normally think of it for mail services.  You're free to lose your own mail and 
no RFC will save you.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Mark Alley]

I'm glad you brought up the binding operative, I had the same thought.

The federal mandate also pushed several state governments to follow 
suit, as there wasn't any pressure before (even though federal BO's 
don't technically apply to state governments.)


Examples:

Alabama - reject (alabama.gov, al.gov, state.al.us)
Hawaii - reject (hawaii.gov)
Missouri - reject (missouri.gov)
Montana - reject (montana.gov, mt.gov)
New Jersey - reject (state.nj.us, nj.gov)
Ohio - quarantine (state.oh.us, ohio.gov)
South Carolina - quarantine (state.sc.us)
Tennessee - reject (state.tn.us)
West Virginia - reject (wv.gov)


- Mark Alley

On 4/18/2023 5:25 PM, Jim Fenton wrote:

On 9 Apr 2023, at 11:33, Barry Leiba wrote:


There is an alternative, though: we can acknowledge that because of how
those deploying DMARC view their needs over interoperability, DMARC is not
appropriate as an IETF standard, and we abandon the effort to make it
Proposed Standard.

I see that as the only way forward if we cannot address the damage that
improperly deployed DMARC policies do to mailing lists.

Unfortunately, much of the world outside IETF sees an RFC number and assumes 
Standards Track. We have RFC 7489, which is Informational, which then resulted 
in a mandate [1] for all executive-branch US Government domains to publish 
p=reject. I have to believe that they thought it was Standards Track when they 
did this.

-Jim

[1]https://cyber.dhs.gov/assets/report/bod-18-01.pdf

___
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] Proposed text for p=reject and indirect mail flows

[Jim Fenton]

On 9 Apr 2023, at 11:33, Barry Leiba wrote:

> There is an alternative, though: we can acknowledge that because of how
> those deploying DMARC view their needs over interoperability, DMARC is not
> appropriate as an IETF standard, and we abandon the effort to make it
> Proposed Standard.
>
> I see that as the only way forward if we cannot address the damage that
> improperly deployed DMARC policies do to mailing lists.

Unfortunately, much of the world outside IETF sees an RFC number and assumes 
Standards Track. We have RFC 7489, which is Informational, which then resulted 
in a mandate [1] for all executive-branch US Government domains to publish 
p=reject. I have to believe that they thought it was Standards Track when they 
did this.

-Jim

[1] https://cyber.dhs.gov/assets/report/bod-18-01.pdf

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Jim Fenton]

On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote:

> (Note, here, that Barry has in his proposed text limited the constraint to
> those types of deployments where the damage is likely.  I concur.  DMARC,
> as currently defined, works just fine when deployed in transactional
> situations.  Or, at least, I haven't seen that identified as a problem
> case.)

I have been trying to point out a problem in even for transactional messages. 
Some receive-side forwarders that people use break DKIM signatures, and of 
course break SPF. So a transactional message sent to a forwarded address might 
be rejected if the address to which it is forwarded enforces DMARC.

IMO, receive-side forwarding is an important use case. It allows people to 
maintain a consistent email address if they change mail providers. For people 
whose email provider is their ISP, that keeps them from being locked into that 
ISP.

It’s possible that this might be solved if the forwarder implements ARC, but 
only if the address to which it is forwarded knows how to implement ARC. I 
suspect that many DMARC enforcers currently don’t.

-Jim

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Fri 14/Apr/2023 21:36:54 +0200 Dotzero wrote:

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins  wrote:

On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:
On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:

On 12 Apr 2023, at 12:21, Douglas Foster  
wrote:

Any form of security creates inconvenience.

Yes. And we make tradeoffs between that. In this case, the security is 
ensuring that users at specific domains can and should only send mail 
through approved channels managed by those domains. Many users have 
violated those security policies, by participating in mailing lists. This 
caused problems for other folks on the mailing lists - as they were the 
ones removed from the list due to the security policy. The lists responded 
by rewriting. This causes yet more inconvenience to other subscribers and, 
additionally, allows the users to bypass their domain security policy. 
I am not seeing how this creates an arena of security.


Security is not From: munging.  That's the workaround that security 
requires.


No security (at least in the viewpoint of some people) is using a p=reject 
for mail from their domain. In that context, From: munging is actively 
subverting the security  settings of domains.



I guess the subversion you mean is that From: munging gets people used to see 
such kind of fake.  I agree that incongruity between display-phrase and actual 
address can be a security threat.  However, there are innocent forms of it.



Based on the header rewriting done by IETF, I have a hard time seeing how 
its rewrite of Comcast addresses can cause any of the problems that you 
cite.


That’s how the IETF rewrites, it’s not how everyone rewrites.


Couldn't the IETF say how to rewrite?

There’s currently a deployed base where there are many different ways to 
munge. "It is a _fact_.”



Yes.  Yet, better munging can always be applied without altering 
functionalities.



But does your domain require even headers to be rewritten?Why doesn't
IETF ask you, and omit rewrite if that is what your domain wants?


Because that doesn’t scale for the IETF.


Mailman options do scale.  From: rewriting is going to fade off by first 
allowing single subscribers to disable it, for the posts directed to them, 
after their MX set up some kind of agreement with the MLM. >>>
The _fact_ still remains that From: rewriting is actively subverting the 
security of domains that choose to publish p=reject.



I'd rather call it training readers on the significance of the display-phrase 
part of a From: line.  Phishermen will keep on exploiting it in any case.



It is hard for me to cry over mailing lists when they cannot ensure that a 
post comes from the asserted poster and they cannot adapt their DMARC 
defenses to the preferences of the recipient domains.   Life is hard.   It 
only gets harder if I wait for someone else to solve problems that I can 
solve myself.


I don’t understand how header rewriting ensures the authenticity of a 
poster. Given the data is being modified by the MLM, it seems to me that 
rewriting compounds the problem.


It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE 
post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting 
for that, which is what they should have done.  We are suffering all the 
damage caused by DMARC but don't enjoy any of the advantages it could bring.


I encourage you to think very hard about why, after more than a decade, we 
still don’t see any of the advantages to DMARC.



Didn't get that.   I'd guess that implementing DMARC wasn't a priority for IETF 
mailing lists.



While the you part of "we" may not see any advantages, quite a few 
financials, greeting card sites, retailers AND many receivers have seen the 
advantages, including p=reject. One thing I've learned over the years is 
that it is presumptuous to speak on behalf of "everyone" when you don't 
actually have their authorization to speak on their behalf. It's kind of 
like sending email claiming to be from someone else's domain without their 
permission.



Michael obviously understood Laura's point better than me.  The only part I 
understood is that "we" are the ML subscribers.  We see no advantage because 
DMARC is not implemented on ietfa.amsl.com.


Oh, certainly until the only abusive messages we see are those straw men, there 
is no actual worry.  It's the principle...



Best
Ale
--





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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Laura Atkins]

On Apr 14, 2023, at 8:37 PM, Dotzero  wrote:On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins  wrote:On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:On 12 Apr 2023, at 12:21, Douglas Foster  wrote:Any form of security creates inconvenience.Yes. And we make tradeoffs between that. In this case, the security is ensuring that users at specific domains can and should only send mail through approved channels managed by those domains. Many users have violated those security policies, by participating in mailing lists. This caused problems for other folks on the mailing lists - as they were the ones removed from the list due to the security policy. The lists responded by rewriting. This causes yet more inconvenience to other subscribers and, additionally, allows the users to bypass their domain security policy.I am not seeing how this creates an arena of security.Security is not From: munging.  That's the workaround that security requires.No security (at least in the viewpoint of some people) is using a p=reject for mail from their domain. In that context, From: munging is actively subverting the security  settings of domains. Based on the header rewriting done by IETF, I have a hard time seeing how its rewrite of Comcast addresses can cause any of the problems that you cite.That’s how the IETF rewrites, it’s not how everyone rewrites.Couldn't the IETF say how to rewrite?There’s currently a deployed base where there are many different ways to munge. "It is a _fact_.” But does your domain require even headers to be rewritten?    Why doesn't IETF ask you, and omit rewrite if that is what your domain wants?Because that doesn’t scale for the IETF.Mailman options do scale.  From: rewriting is going to fade off by first allowing single subscribers to disable it, for the postsdirected to them, after their MX set up some kind of agreement with the MLM.The _fact_ still remains that From: rewriting is actively subverting the security of domains that choose to publish p=reject. It is hard for me to cry over mailing lists when they cannot ensure that a post comes from the asserted poster and they cannot adapt their DMARC defenses to the preferences of the recipient domains.   Life is hard.   It only gets harder if I wait for someone else to solve problems that I can solve myself.I don’t understand how header rewriting ensures the authenticity of a poster. Given the data is being modified by the MLM, it seems to me that rewriting compounds the problem.It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting for that, which is what they should have done.  We are suffering all the damage caused by DMARC but don't enjoy any of the advantages it could bring.I encourage you to think very hard about why, after more than a decade, we still don’t see any of the advantages to DMARC.While the you part of "we" may not see any advantages, quite a few financials, greeting card sites, retailers AND many receivers have seen the advantages, including p=reject. One thing I've learned over the years is that it is presumptuous to speak on behalf of "everyone" when you don't actually have their authorization to speak on their behalf. It's kind of like sending email claiming to be from someone else's domain without their permission.I was using the terminology of the poster I was replying to. Perhaps I should have been clearer and put “we” in quotes to ensure my reply was not misunderstood.LauraMichael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 9:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> These decisions are made in the light of ransomware attacks that have shut
> down critical social infrastructure like city governments and hospital
> systems.
>
> The proceeds from Internet-based fraud are funding groups like Boko Haram
> that kidnaps girls into sex slavery, boys into child soldiering, and then
> uses their weapons to burn Christians inside their churches.
>
> This is not about money for fat cats, it is about trying to stave off the
> darkness.
>
> Unless a mailing list has controls in place to ensure that EVERY post
> comes from the asserted participant, it is the height of hypocrisy to ask
> an evaluator to assume that the post is from the asserted participant.
>  IETF cannot do even the easiest part of that task, so I have no reason to
> expect better elsewhere.
>
> Societies depend on trust.   Impersonation in all it's forms undermines
> trust.
>
>
> Doug
>
>
>
>
> On Fri, Apr 14, 2023, 9:17 PM Murray S. Kucherawy 
> wrote:
>
>> On Fri, Apr 14, 2023 at 12:37 PM Dotzero  wrote:
>>
>>> While the you part of "we" may not see any advantages, quite a few
>>> financials, greeting card sites, retailers AND many receivers have seen the
>>> advantages, including p=reject. One thing I've learned over the years is
>>> that it is presumptuous to speak on behalf of "everyone" when you don't
>>> actually have their authorization to speak on their behalf. It's kind of
>>> like sending email claiming to be from someone else's domain without their
>>> permission.
>>>
>>
>> We need to tread carefully here.  Standards are supposed to improve
>> things for everyone, not just quite a few financials, greeting card sites,
>> retailers AND many receivers.  Presented that way, it sounds a lot like
>> we're saying these decisions should be biased in favor of those with
>> money.  I know we don't mean that.
>>
>> -MSK, participating
>>
>

Seeing the advantage does not mean that it only benefits the ones I listed.
I'm aware they see the advantage because people from those types of
organizations were involved in the original creation and testing and over
the years I've seen the data on abuse reduction. Not just the DMARC numbers
but the downstream impacts on abuse. Unfortunately organizations tend not
to provide data about its efficacy publicly because it involves providing
data about their business. It works. It could have been kept a private club
of "big boys" but people involved in the effort believed there was (is) an
ecosystem benefit in it being an open standard that anyone could implement.
>From start to publication, DMARC took roughly 18 months including testing.
The participating organizations spent a lot of resources and  money during
that period writing code and testing, including various meetings and
interop events. I'm not confident it would have happened and especially in
that time frame if it were a public effort. Now that also doesn't include
the initial time and work it took for the private parties to figure out how
to interact with each other.  It's smaller organizations and the average
person who benefits from that initial effort. If it weren't a published
standard, how could they take advantage and be able to participate? It was
handed over to IETF because of a belief that IETF would be the best steward
in moving it forward.

And yes, I fully recognize that there are tradeoffs DMARC involves. If only
transactional domains publish p=reject then I'd argue the benefits far
outweigh the downsides. The calculus changes with broader implementation
for other types of domains, but as others have pointed out, no death
penalty is imposed in those circumstances.

I've seen people suggest that policy should be gotten rid of but keep
reporting. Policy was/is the incentive for receivers to do reporting. It
allows sending domains to have visibility into mail flows claiming to be
theirs, whether theirs or not, from the receiver's perspective.This
presumably enables them to take steps to correct things they perceive to be
problematic if they so choose. And yes, that can include publishing
quarantine or reject as a policy request.

If it weren't for companies like !Yahoo and AOL pulling the trigger on
p=reject, we wouldn't be having this conversation. I'm not saying this to
blame them, rather I'm just recognizing facts. But we are where we are.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 6:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Unless a mailing list has controls in place to ensure that EVERY post
> comes from the asserted participant, it is the height of hypocrisy to ask
> an evaluator to assume that the post is from the asserted participant.
>  IETF cannot do even the easiest part of that task, so I have no reason to
> expect better elsewhere.
>

Nobody is asking the evaluator to assume anything.  That's what email
authentication is about; it shouldn't assume anything, and you only really
know something when you get a "pass".  Reacting harshly to a "fail" when
there are so many legitimate ways the current authentication schemes can
fail is folly.  But people are looking for silver bullets, so here we are.

A world free of fraudulent email is a laudable goal, of course.  But since
DMARC can only actually affect direct domain attacks, and makes no
discernible attempt to mitigate cousin domain or display name attacks to
which attackers can trivially switch, I think I'd like to see some proof
that it staves off enough of the darkness to be worth this level of defense.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

These decisions are made in the light of ransomware attacks that have shut
down critical social infrastructure like city governments and hospital
systems.

The proceeds from Internet-based fraud are funding groups like Boko Haram
that kidnaps girls into sex slavery, boys into child soldiering, and then
uses their weapons to burn Christians inside their churches.

This is not about money for fat cats, it is about trying to stave off the
darkness.

Unless a mailing list has controls in place to ensure that EVERY post comes
from the asserted participant, it is the height of hypocrisy to ask an
evaluator to assume that the post is from the asserted participant.   IETF
cannot do even the easiest part of that task, so I have no reason to expect
better elsewhere.

Societies depend on trust.   Impersonation in all it's forms undermines
trust.


Doug




On Fri, Apr 14, 2023, 9:17 PM Murray S. Kucherawy 
wrote:

> On Fri, Apr 14, 2023 at 12:37 PM Dotzero  wrote:
>
>> While the you part of "we" may not see any advantages, quite a few
>> financials, greeting card sites, retailers AND many receivers have seen the
>> advantages, including p=reject. One thing I've learned over the years is
>> that it is presumptuous to speak on behalf of "everyone" when you don't
>> actually have their authorization to speak on their behalf. It's kind of
>> like sending email claiming to be from someone else's domain without their
>> permission.
>>
>
> We need to tread carefully here.  Standards are supposed to improve things
> for everyone, not just quite a few financials, greeting card sites,
> retailers AND many receivers.  Presented that way, it sounds a lot like
> we're saying these decisions should be biased in favor of those with
> money.  I know we don't mean that.
>
> -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] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 12:37 PM Dotzero  wrote:

> While the you part of "we" may not see any advantages, quite a few
> financials, greeting card sites, retailers AND many receivers have seen the
> advantages, including p=reject. One thing I've learned over the years is
> that it is presumptuous to speak on behalf of "everyone" when you don't
> actually have their authorization to speak on their behalf. It's kind of
> like sending email claiming to be from someone else's domain without their
> permission.
>

We need to tread carefully here.  Standards are supposed to improve things
for everyone, not just quite a few financials, greeting card sites,
retailers AND many receivers.  Presented that way, it sounds a lot like
we're saying these decisions should be biased in favor of those with
money.  I know we don't mean that.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 4:25 PM John Levine  wrote:

> It appears that Dotzero   said:
> >While the you part of "we" may not see any advantages, quite a few
> >financials, greeting card sites, retailers AND many receivers have seen
> the
> >advantages, including p=reject. ...
>
> The advantages you see are certainly real but they're not about
> interoperability.
>
> DMARC prevents a lot of mail from being delivered, the exact opposite
> of interoperating. In your case at least, there are good reasons to
> believe that the recipients wouldn't have wanted the mail, but that's
> a separate question.
>

The vast majority of email messages emitted are prevented from being
delivered. Should the flood gates holding back those messages be opened in
the name of interoperability? My hunch is that this is not the desired
outcome by many/most people.

>
> I also think that you're kind of an edge case, with a mail stream that
> you can characterize very exactly and a clear understanding of the
> costs of the mail that gets lost.  People who know they have users
> on mailing lists and publish p=reject anyway, not so much.
>

DMARC was specifically created to address direct domain abuse with regard
to transactional mail. That hardly makes  financials, greeting card sites,
retailers AND many receivers edge cases.

>
> I'm with Scott, there's no question about the interop problem so
> document it and move on.
>

My response was orthogonal to any interop problems. Instead it was in
response to Laura claiming to speak on behalf of an all inclusive "we". It
may be that I was mistaken and it was instead an Imperial "we".

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[John Levine]

It appears that Dotzero   said:
>While the you part of "we" may not see any advantages, quite a few
>financials, greeting card sites, retailers AND many receivers have seen the
>advantages, including p=reject. ...

The advantages you see are certainly real but they're not about 
interoperability.

DMARC prevents a lot of mail from being delivered, the exact opposite
of interoperating. In your case at least, there are good reasons to
believe that the recipients wouldn't have wanted the mail, but that's
a separate question.  

I also think that you're kind of an edge case, with a mail stream that
you can characterize very exactly and a clear understanding of the
costs of the mail that gets lost.  People who know they have users
on mailing lists and publish p=reject anyway, not so much.

I'm with Scott, there's no question about the interop problem so
document it and move on.

R's,
John

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins 
wrote:

>
>
> On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:
>
> On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
>
> On 12 Apr 2023, at 12:21, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> Any form of security creates inconvenience.
>
> Yes. And we make tradeoffs between that. In this case, the security is
> ensuring that users at specific domains can and should only send mail
> through approved channels managed by those domains. Many users have
> violated those security policies, by participating in mailing lists. This
> caused problems for other folks on the mailing lists - as they were the
> ones removed from the list due to the security policy. The lists responded
> by rewriting. This causes yet more inconvenience to other subscribers and,
> additionally, allows the users to bypass their domain security policy.
> I am not seeing how this creates an arena of security.
>
>
>
> Security is not From: munging.  That's the workaround that security
> requires.
>
>
> No security (at least in the viewpoint of some people) is using a p=reject
> for mail from their domain. In that context, From: munging is actively
> subverting the security  settings of domains.
>
>
> Based on the header rewriting done by IETF, I have a hard time seeing how
> its rewrite of Comcast addresses can cause any of the problems that you
> cite.
>
> That’s how the IETF rewrites, it’s not how everyone rewrites.
>
>
> Couldn't the IETF say how to rewrite?
>
>
> There’s currently a deployed base where there are many different ways to
> munge. "It is a _fact_.”
>
>
> But does your domain require even headers to be rewritten?Why doesn't
> IETF ask you, and omit rewrite if that is what your domain wants?
>
> Because that doesn’t scale for the IETF.
>
>
> Mailman options do scale.  From: rewriting is going to fade off by first
> allowing single subscribers to disable it, for the posts
>
> directed to them, after their MX set up some kind of agreement with the
> MLM.
>
>
> The _fact_ still remains that From: rewriting is actively subverting the
> security of domains that choose to publish p=reject.
>
> It is hard for me to cry over mailing lists when they cannot ensure that a
> post comes from the asserted poster and they cannot adapt their DMARC
> defenses to the preferences of the recipient domains.   Life is hard.   It
> only gets harder if I wait for someone else to solve problems that I can
> solve myself.
>
> I don’t understand how header rewriting ensures the authenticity of a
> poster. Given the data is being modified by the MLM, it seems to me that
> rewriting compounds the problem.
>
>
>
> It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE
> post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting
> for that, which is what they should have done.  We are suffering all the
> damage caused by DMARC but don't enjoy any of the advantages it could bring.
>
>
> I encourage you to think very hard about why, after more than a decade, we
> still don’t see any of the advantages to DMARC.
>

While the you part of "we" may not see any advantages, quite a few
financials, greeting card sites, retailers AND many receivers have seen the
advantages, including p=reject. One thing I've learned over the years is
that it is presumptuous to speak on behalf of "everyone" when you don't
actually have their authorization to speak on their behalf. It's kind of
like sending email claiming to be from someone else's domain without their
permission.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Laura Atkins]

> On 14 Apr 2023, at 18:38, Alessandro Vesely  wrote:
> 
> On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
>>> On 12 Apr 2023, at 12:21, Douglas Foster 
>>>  wrote:
>>> Any form of security creates inconvenience.
>> Yes. And we make tradeoffs between that. In this case, the security is 
>> ensuring that users at specific domains can and should only send mail 
>> through approved channels managed by those domains. Many users have violated 
>> those security policies, by participating in mailing lists. This caused 
>> problems for other folks on the mailing lists - as they were the ones 
>> removed from the list due to the security policy. The lists responded by 
>> rewriting. This causes yet more inconvenience to other subscribers and, 
>> additionally, allows the users to bypass their domain security policy.
>> I am not seeing how this creates an arena of security.
> 
> 
> Security is not From: munging.  That's the workaround that security requires.

No security (at least in the viewpoint of some people) is using a p=reject for 
mail from their domain. In that context, From: munging is actively subverting 
the security  settings of domains. 


>>> Based on the header rewriting done by IETF, I have a hard time seeing how 
>>> its rewrite of Comcast addresses can cause any of the problems that you 
>>> cite.
>> That’s how the IETF rewrites, it’s not how everyone rewrites.
> 
> Couldn't the IETF say how to rewrite?

There’s currently a deployed base where there are many different ways to munge. 
"It is a _fact_.”
 
>>> But does your domain require even headers to be rewritten?Why doesn't 
>>> IETF ask you, and omit rewrite if that is what your domain wants?
>> Because that doesn’t scale for the IETF.
> 
> Mailman options do scale.  From: rewriting is going to fade off by first 
> allowing single subscribers to disable it, for the posts
> directed to them, after their MX set up some kind of agreement with the MLM.

The _fact_ still remains that From: rewriting is actively subverting the 
security of domains that choose to publish p=reject. 

>>> It is hard for me to cry over mailing lists when they cannot ensure that a 
>>> post comes from the asserted poster and they cannot adapt their DMARC 
>>> defenses to the preferences of the recipient domains.   Life is hard.   It 
>>> only gets harder if I wait for someone else to solve problems that I can 
>>> solve myself.
>> I don’t understand how header rewriting ensures the authenticity of a 
>> poster. Given the data is being modified by the MLM, it seems to me that 
>> rewriting compounds the problem.
> 
> 
> It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE post 
> had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting for that, 
> which is what they should have done.  We are suffering all the damage caused 
> by DMARC but don't enjoy any of the advantages it could bring.

I encourage you to think very hard about why, after more than a decade, we 
still don’t see any of the advantages to DMARC.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Friday, April 14, 2023 1:38:42 PM EDT Alessandro Vesely wrote:
> On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
> >> On 12 Apr 2023, at 12:21, Douglas Foster
> >>  wrote:
> >> 
> >> Any form of security creates inconvenience.
> > 
> > Yes. And we make tradeoffs between that. In this case, the security is
> > ensuring that users at specific domains can and should only send mail
> > through approved channels managed by those domains. Many users have
> > violated those security policies, by participating in mailing lists. This
> > caused problems for other folks on the mailing lists - as they were the
> > ones removed from the list due to the security policy. The lists
> > responded by rewriting. This causes yet more inconvenience to other
> > subscribers and, additionally, allows the users to bypass their domain
> > security policy.
> > 
> > I am not seeing how this creates an arena of security.
> 
> Security is not From: munging.  That's the workaround that security
> requires.
> >> Based on the header rewriting done by IETF, I have a hard time seeing how
> >> its rewrite of Comcast addresses can cause any of the problems that you
> >> cite.> 
> > That’s how the IETF rewrites, it’s not how everyone rewrites.
> 
> Couldn't the IETF say how to rewrite?
> 
> >> But does your domain require even headers to be rewritten?Why doesn't
> >> IETF ask you, and omit rewrite if that is what your domain wants?> 
> > Because that doesn’t scale for the IETF.
> 
> Mailman options do scale.  From: rewriting is going to fade off by first
> allowing single subscribers to disable it, for the posts directed to them,
> after their MX set up some kind of agreement with the MLM.
> 
> >> It is hard for me to cry over mailing lists when they cannot ensure that
> >> a post comes from the asserted poster and they cannot adapt their DMARC
> >> defenses to the preferences of the recipient domains.   Life is hard.  
> >> It only gets harder if I wait for someone else to solve problems that I
> >> can solve myself.> 
> > I don’t understand how header rewriting ensures the authenticity of a
> > poster. Given the data is being modified by the MLM, it seems to me that
> > rewriting compounds the problem.
> It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE
> post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting for
> that, which is what they should have done.  We are suffering all the damage
> caused by DMARC but don't enjoy any of the advantages it could bring.

I think that's a distinct case.  I don't think there's significant controversy 
that mail which fails DMARC at the MLM's MTA can be rejected.  I think this 
would be relatively safe as it's less common to have indirect mail flows going 
into mailing lists than it is going out of them.

I thought what was being suggested for the mailing list case was not that.  I 
thought the suggestion was that mailing lists should check prospectively and 
not accept mail that would fail DMARC checks performed by mailing list 
recipients.  It's not particularly novel (I implemented an equivalent check 
for SPF in 2008), but it's different than the garden variety reject on DMARC 
fail that's relevant to that message.

Scott K


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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:

On 12 Apr 2023, at 12:21, Douglas Foster  
wrote:

Any form of security creates inconvenience.


Yes. And we make tradeoffs between that. In this case, the security is ensuring 
that users at specific domains can and should only send mail through approved 
channels managed by those domains. Many users have violated those security 
policies, by participating in mailing lists. This caused problems for other 
folks on the mailing lists - as they were the ones removed from the list due to 
the security policy. The lists responded by rewriting. This causes yet more 
inconvenience to other subscribers and, additionally, allows the users to 
bypass their domain security policy.

I am not seeing how this creates an arena of security.



Security is not From: munging.  That's the workaround that security requires.



Based on the header rewriting done by IETF, I have a hard time seeing how its 
rewrite of Comcast addresses can cause any of the problems that you cite.


That’s how the IETF rewrites, it’s not how everyone rewrites.



Couldn't the IETF say how to rewrite?



But does your domain require even headers to be rewritten?Why doesn't IETF 
ask you, and omit rewrite if that is what your domain wants?


Because that doesn’t scale for the IETF.



Mailman options do scale.  From: rewriting is going to fade off by first 
allowing single subscribers to disable it, for the posts directed to them, 
after their MX set up some kind of agreement with the MLM.




It is hard for me to cry over mailing lists when they cannot ensure that a post 
comes from the asserted poster and they cannot adapt their DMARC defenses to 
the preferences of the recipient domains.   Life is hard.   It only gets harder 
if I wait for someone else to solve problems that I can solve myself.


I don’t understand how header rewriting ensures the authenticity of a poster. 
Given the data is being modified by the MLM, it seems to me that rewriting 
compounds the problem.



It doesn't.  The authenticity should be checked on entry.  THIS IS ABUSE post 
had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting for that, 
which is what they should have done.  We are suffering all the damage caused by 
DMARC but don't enjoy any of the advantages it could bring.



Best
Ale
--




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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Laura Atkins]

> On 12 Apr 2023, at 12:21, Douglas Foster 
>  wrote:
> 
> Any form of security creates inconvenience.

Yes. And we make tradeoffs between that. In this case, the security is ensuring 
that users at specific domains can and should only send mail through approved 
channels managed by those domains. Many users have violated those security 
policies, by participating in mailing lists. This caused problems for other 
folks on the mailing lists - as they were the ones removed from the list due to 
the security policy. The lists responded by rewriting. This causes yet more 
inconvenience to other subscribers and, additionally, allows the users to 
bypass their domain security policy. 

I am not seeing how this creates an arena of security.

> Based on the header rewriting done by IETF, I have a hard time seeing how its 
> rewrite of Comcast addresses can cause any of the problems that you cite.

That’s how the IETF rewrites, it’s not how everyone rewrites. 

> But does your domain require even headers toi be rewritten?Why doesn't 
> IETF ask you, and omit rewrite if that is what your domain wants?

Because that doesn’t scale for the IETF. 

> It is hard for me to cry over mailing lists when they cannot ensure that a 
> post comes from the asserted poster and they cannot adapt their DMARC 
> defenses to the preferences of the recipient domains.   Life is hard.   It 
> only gets harder if I wait for someone else to solve problems that I can 
> solve myself.

I don’t understand how header rewriting ensures the authenticity of a poster. 
Given the data is being modified by the MLM, it seems to me that rewriting 
compounds the problem. 

laura 

> 
> Doug Foster
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 12, 2023 at 6:23 AM Laura Atkins  > wrote:
>> 
>> 
>>> On 12 Apr 2023, at 10:45, Alessandro Vesely >> > wrote:
>>> 
>>> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
 Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST 
 NOT" that we know people will ignore calls into question the IETFs 
 relevance or legitimacy.  But I submit that the IETF issuing a standards 
 track document which fails to take the strongest possible stance against 
 deploying DMARC in a way that knowingly imposes substantial breakage, for 
 any reason, is irresponsible and is the greater threat to our legitimacy.  
 Keep in mind that improper deployment of DMARC results in damage to 
 innocent third parties: It's not the sender or the MLM that's impacted, 
 it's everyone else on the list.  It's breathtaking to me that we can feel 
 comfortable shrugging this off under the banner of "security" or "brand 
 protection".
>>> 
>>> 
>>> It is not clear whether the damage is caused by those who publish p=reject 
>>> rather than by those who honor it.  For the protocol to work, both are 
>>> needed.
>>> 
>>> History ratified that mailing lists are the refractory element.  At the 
>>> time, John compiled a list of possible DMARC workarounds[*].  Out of 
>>> inertia, From: rewriting emerged as the de-facto standard.  It works.  It's 
>>> amendable, though; there are cooperative solutions for example.  And ARC.
>>> 
>>> Rather than considering how to better the coordination between senders and 
>>> receivers, we disregard the mailing lists adaptation as undue.  Thus we're 
>>> stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.
>>> 
>>> For a possible way forward, senders can coordinate with receivers by 
>>> identifying mail streams, pivoting on users who subscribe to mailing lists 
>>> or require forwarding for email address portability.  Just like the 
>>> classic, one-sided whitelisting of specific email addresses, but using 
>>> email authentication.
>>> 
>>> Can we stop longing for the 1980s?  Let's accept the damaged we caused.  
>>> It's been mended already.
>> 
>> I would disagree that the mailing list adaptation (header rewriting) works 
>> well and is benign. In fact, it causes problems for list participants. From 
>> my own experience: 
>> 
>>  It makes it difficult to implement filters based on poster address. 
>> 
>> It makes it difficult to search for posts by certain authors. 
>> 
>> It makes it difficult to respond to someone privately or to reach out to 
>> them for non-list related reasons. 
>> 
>> It can even make it difficult to identify who is speaking as some folks 
>> don’t sign their messages and they don’t provide .sig files to identify 
>> them. 
>> 
>> laura 
>> 
>> -- 
>> The Delivery Experts
>> 
>> Laura Atkins
>> Word to the Wise
>> la...@wordtothewise.com  
>> 
>> Email Delivery Blog: http://wordtothewise.com/blog   
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> dmarc mailing list
>> dmarc@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dmarc
> 

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

Any form of security creates inconvenience.

Based on the header rewriting done by IETF, I have a hard time seeing how
its rewrite of Comcast addresses can cause any of the problems that you
cite.

But does your domain require even headers toi be rewritten?Why doesn't
IETF ask you, and omit rewrite if that is what your domain wants?

It is hard for me to cry over mailing lists when they cannot ensure that a
post comes from the asserted poster and they cannot adapt their DMARC
defenses to the preferences of the recipient domains.   Life is hard.   It
only gets harder if I wait for someone else to solve problems that I can
solve myself.

Doug Foster










On Wed, Apr 12, 2023 at 6:23 AM Laura Atkins 
wrote:

>
>
> On 12 Apr 2023, at 10:45, Alessandro Vesely  wrote:
>
> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
>
> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
> NOT" that we know people will ignore calls into question the IETFs
> relevance or legitimacy.  But I submit that the IETF issuing a standards
> track document which fails to take the strongest possible stance against
> deploying DMARC in a way that knowingly imposes substantial breakage, for
> any reason, is irresponsible and is the greater threat to our legitimacy.
> Keep in mind that improper deployment of DMARC results in damage to
> innocent third parties: It's not the sender or the MLM that's impacted,
> it's everyone else on the list.  It's breathtaking to me that we can feel
> comfortable shrugging this off under the banner of "security" or "brand
> protection".
>
>
>
> It is not clear whether the damage is caused by those who publish p=reject
> rather than by those who honor it.  For the protocol to work, both are
> needed.
>
> History ratified that mailing lists are the refractory element.  At the
> time, John compiled a list of possible DMARC workarounds[*].  Out of
> inertia, From: rewriting emerged as the de-facto standard.  It works.  It's
> amendable, though; there are cooperative solutions for example.  And ARC.
>
> Rather than considering how to better the coordination between senders and
> receivers, we disregard the mailing lists adaptation as undue.  Thus we're
> stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.
>
> For a possible way forward, senders can coordinate with receivers by
> identifying mail streams, pivoting on users who subscribe to mailing lists
> or require forwarding for email address portability.  Just like the
> classic, one-sided whitelisting of specific email addresses, but using
> email authentication.
>
> Can we stop longing for the 1980s?  Let's accept the damaged we caused.
> It's been mended already.
>
>
> I would disagree that the mailing list adaptation (header rewriting) works
> well and is benign. In fact, it causes problems for list participants. From
> my own experience:
>
>  It makes it difficult to implement filters based on poster address.
>
> It makes it difficult to search for posts by certain authors.
>
> It makes it difficult to respond to someone privately or to reach out to
> them for non-list related reasons.
>
> It can even make it difficult to identify who is speaking as some folks
> don’t sign their messages and they don’t provide .sig files to identify
> them.
>
> laura
>
> --
> The Delivery Experts
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> 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] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

Thank you for returning to the topic of stream identifiers.   Email
filtering is not about single messages, it is about identifying and
classifying streams into high value (whitelist), low value (allow) and
unwanted (block).

I know existing filtering configurations that will conditionally block list
messages, without DMARC, because of a distrusted From value.   So I do not
believe every thing would be hunky-fory if DMAzrC could only go away.

My Stream-Info header idea could add a lot of value to the ML problem

Doug

On Wed, Apr 12, 2023, 5:47 AM Alessandro Vesely  wrote:

> On Sat 08/Apr/2023 23:27:26 +0200 Douglas Foster wrote:
> > Even when the recipient and the evaluator have a great working
> relationship,
> > neither party may understand what exceptions are needed for the messages
> from
> > every participant, current or future, to be accepted reliably.   So the
> list
> > messages arrive smoothly until a message is sent from a participant in a
> > geo-blocked country.The user discovers the problem when he realizes
> that he
> > has no idea what topic is being discussed, because he missed the initial
> post.
>
>
> That seems to be an old-fashioned non-rewrite case.
>
>
> > It seems evident that to get consistent evaluation results, evaluators
> need to
> > judge based on the list identity and reputation, rather than the sender
> > identity and reputation.   I do not see how this can be achieved without
> > replacing the From address with an address in the list domain.
> Replacing the
> >  From address is not the only obstacle, but it is the starting point.
>
>
> An alternative to matching From: could be to match stream identifiers.
> Someone
> tells the recipient's MX that she subscribed to stream XYZ, so please
> accept
> such posts.  I'd guess a list has to be "DMARC-clean" for MXes to agree.
>
>
> 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] Proposed text for p=reject and indirect mail flows

[Laura Atkins]

> On 12 Apr 2023, at 10:45, Alessandro Vesely  wrote:
> 
> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
>> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST 
>> NOT" that we know people will ignore calls into question the IETFs relevance 
>> or legitimacy.  But I submit that the IETF issuing a standards track 
>> document which fails to take the strongest possible stance against deploying 
>> DMARC in a way that knowingly imposes substantial breakage, for any reason, 
>> is irresponsible and is the greater threat to our legitimacy.  Keep in mind 
>> that improper deployment of DMARC results in damage to innocent third 
>> parties: It's not the sender or the MLM that's impacted, it's everyone else 
>> on the list.  It's breathtaking to me that we can feel comfortable shrugging 
>> this off under the banner of "security" or "brand protection".
> 
> 
> It is not clear whether the damage is caused by those who publish p=reject 
> rather than by those who honor it.  For the protocol to work, both are needed.
> 
> History ratified that mailing lists are the refractory element.  At the time, 
> John compiled a list of possible DMARC workarounds[*].  Out of inertia, From: 
> rewriting emerged as the de-facto standard.  It works.  It's amendable, 
> though; there are cooperative solutions for example.  And ARC.
> 
> Rather than considering how to better the coordination between senders and 
> receivers, we disregard the mailing lists adaptation as undue.  Thus we're 
> stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.
> 
> For a possible way forward, senders can coordinate with receivers by 
> identifying mail streams, pivoting on users who subscribe to mailing lists or 
> require forwarding for email address portability.  Just like the classic, 
> one-sided whitelisting of specific email addresses, but using email 
> authentication.
> 
> Can we stop longing for the 1980s?  Let's accept the damaged we caused.  It's 
> been mended already.

I would disagree that the mailing list adaptation (header rewriting) works well 
and is benign. In fact, it causes problems for list participants. From my own 
experience: 

 It makes it difficult to implement filters based on poster address. 

It makes it difficult to search for posts by certain authors. 

It makes it difficult to respond to someone privately or to reach out to them 
for non-list related reasons. 

It can even make it difficult to identify who is speaking as some folks don’t 
sign their messages and they don’t provide .sig files to identify them. 

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Sat 08/Apr/2023 23:27:26 +0200 Douglas Foster wrote:
Even when the recipient and the evaluator have a great working relationship, 
neither party may understand what exceptions are needed for the messages from 
every participant, current or future, to be accepted reliably.   So the list 
messages arrive smoothly until a message is sent from a participant in a 
geo-blocked country.    The user discovers the problem when he realizes that he 
has no idea what topic is being discussed, because he missed the initial post.



That seems to be an old-fashioned non-rewrite case.


It seems evident that to get consistent evaluation results, evaluators need to 
judge based on the list identity and reputation, rather than the sender 
identity and reputation.   I do not see how this can be achieved without 
replacing the From address with an address in the list domain.  Replacing the 
 From address is not the only obstacle, but it is the starting point.



An alternative to matching From: could be to match stream identifiers.  Someone 
tells the recipient's MX that she subscribed to stream XYZ, so please accept 
such posts.  I'd guess a list has to be "DMARC-clean" for MXes to agree.



Best
Ale
--






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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST NOT" 
that we know people will ignore calls into question the IETFs relevance or 
legitimacy.  But I submit that the IETF issuing a standards track document 
which fails to take the strongest possible stance against deploying DMARC in a 
way that knowingly imposes substantial breakage, for any reason, is 
irresponsible and is the greater threat to our legitimacy.  Keep in mind that 
improper deployment of DMARC results in damage to innocent third parties: It's 
not the sender or the MLM that's impacted, it's everyone else on the list.  
It's breathtaking to me that we can feel comfortable shrugging this off under 
the banner of "security" or "brand protection".



It is not clear whether the damage is caused by those who publish p=reject 
rather than by those who honor it.  For the protocol to work, both are needed.


History ratified that mailing lists are the refractory element.  At the time, 
John compiled a list of possible DMARC workarounds[*].  Out of inertia, From: 
rewriting emerged as the de-facto standard.  It works.  It's amendable, though; 
there are cooperative solutions for example.  And ARC.


Rather than considering how to better the coordination between senders and 
receivers, we disregard the mailing lists adaptation as undue.  Thus we're 
stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.


For a possible way forward, senders can coordinate with receivers by 
identifying mail streams, pivoting on users who subscribe to mailing lists or 
require forwarding for email address portability.  Just like the classic, 
one-sided whitelisting of specific email addresses, but using email authentication.


Can we stop longing for the 1980s?  Let's accept the damaged we caused.  It's 
been mended already.



Best
Ale
--

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail





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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Mark Alley]

I've thought about this a bit more; I could get behind "purpose> domains MUST NOT publish p=reject" (for interoperability) as 
long as it is made clear the interoperability context for the "MUST NOT" 
does not address the perceived security benefits of its current usage by 
domain owners at large.


As said in your original message that started this topic, "... no one 
will be arrested or fined for choosing not to follow the [MUST NOT]", 
but then I feel like we still have an impasse, because it's not much of 
a standard if nobody adheres to said standard (as others have stated 
on-list), especially so in this case of strict language. The 
recommendation I feel from the community would probably still be, "have 
p=reject as a goal" even with this language in place.


Possibly off-topic slightly, I think BIMI's requirement for DMARC is 
contradictory to what this language is trying to portray for the 
standard. We'd publish "general purpose domains must not publish 
p=reject" for DMARCbis, but then one of the pre-requisites of BIMI is to 
at least have p=quarantine, which still does damage due to the 
non-standardized way disparate receivers handle the policy. Point is, it 
seems conflicting to have two documents telling (and expecting) domain 
owners to do different things.


- Mark Alley

On 4/9/2023 1:33 PM, Barry Leiba wrote:

> As Todd previously stated, my preference is for language that
> acknowledges the primacy of the domain owner over interoperability

The problem is that IETF standards are about interoperability, not 
about anyone’s primacy.


There is an alternative, though: we can acknowledge that because of 
how those deploying DMARC view their needs over interoperability, 
DMARC is not appropriate as an IETF standard, and we abandon the 
effort to make it Proposed Standard.


I see that as the only way forward if we cannot address the damage 
that improperly deployed DMARC policies do to mailing lists.


Barry


___
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] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Sun 09/Apr/2023 20:33:54 +0200 Barry Leiba wrote:


There is an alternative, though: we can acknowledge that because of how those 
deploying DMARC view their needs over interoperability, DMARC is not 
appropriate as an IETF standard, and we abandon the effort to make it Proposed 
Standard.



That sounds perfectly reasonable.  If we actually /propose/ a standard, we can 
drop the slippery concept of general purpose domains and seek to open the era 
of authenticated email for every one.



I see that as the only way forward if we cannot address the damage that 
improperly deployed DMARC policies do to mailing lists.



The correct way to address that is to propose that mailing lists too 
authenticate their posts, so that subscribing to a mailing list doesn't entail 
a security risk.  Let ARC prove their correct filtering and encourage receivers 
to override DMARC failures in MLs' streams, after subscription confirmation.



Best
Ale
--





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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Matthäus Wander]

John Levine wrote on 2023-04-09 15:55:

When someone sets a DMARC policy for mail from people, it's hard to
think of a time when they asked at wll whether that was what the
people wanted. Or if they did, they asked something like "do you want
your mail to be more secure?" which misses the point.


A domain owner can set their policy without asking their users for 
permission. Not every sender with mail from people is a mail service 
provider catering to the general public.



PS: I can make anyone's mail 100% secure by unplugging your mail
server but I'm pretty sure that's not what you want.


You can also ensure interoperability by demanding they MUST NOT use any 
type of authentication, because all it does is impairing mail flows, 
while the security benefit is nothing that IETF standards should mandate 
about.


Neither of these extremes is helpful to actually achieve 
interoperability or security.


Regards,
Matt

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On April 9, 2023 6:33:54 PM UTC, Barry Leiba  wrote:
>> As Todd previously stated, my preference is for language that
>> acknowledges the primacy of the domain owner over interoperability
>
>The problem is that IETF standards are about interoperability, not about
>anyone’s primacy.
>
>There is an alternative, though: we can acknowledge that because of how
>those deploying DMARC view their needs over interoperability, DMARC is not
>appropriate as an IETF standard, and we abandon the effort to make it
>Proposed Standard.
>
>I see that as the only way forward if we cannot address the damage that
>improperly deployed DMARC policies do to mailing lists.
>
I think this is a reasonable conclusion.

I think we either need to take a strong stand on interoperability or come up 
with another plan.

If we decide to punt on interoperability, we might document the 
interoperability mess in an appendix, make it experimental, and then wait for 
then wait for the market to decide.

I'd prefer we don't do that, but avoiding a result like that is going to take 
some compromise.

I suspect there's a path forward built around domains which [conditions] MUST 
NOT p=reject because interoperability, but no one is likely to be entirely 
happy with the results (and that's fine, IETF rough consensus is about "I can 
live with it", not "I like it").

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Neil Anuskiewicz]

> On Apr 9, 2023, at 6:33 AM, Jesse Thompson  wrote:
> 
> 
>> On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
>> Personally, I prefer the latter of the two, quoted below.
>> 
>> "to preserve interoperability, domains SHOULD NOT publish p=reject unless 
>> they are [not general purpose]* domains"
>> 
>> "Publishing DMARC records with restrictive policies does cause 
>> interoperability problems for some normal email usage patterns. Potential 
>> impacts MUST be considered before any domain publishes a restrictive policy."
> 
> I like the latter, as well. I was going to suggest something similar.
> 
> As Todd previously stated, my preference is for language that acknowledges 
> the primacy of the domain owner over interoperability. CISOs have been sold 
> (arguably, by the DMARC deployment companies' marketing) on the idea that 
> there are security benefits. Maybe oversold, but there are benefits and the 
> motivation will not change. Let's not also overlook the primary benefit of 
> _the process of deploying DMARC_ gives to an organization: increased 
> management and governance (enabled by the observability from the reports). In 
> any case, the domain owner is motivated to deploy DMARC and gain the 
> perceived benefits. If we are going to tell these motivated domain owners to 
> MUST do something, at least make it something they might consider doing.
> 
> "Before a general purpose domain publishes p=reject|quarantine, the domain 
> owner MUST emit mail from, or provide to their stakeholders/end-users, an 
> alternative domain or subdomain with a p=none policy for any email that needs 
> to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party 
> that cannot be authorized by SPF or DKIM alignment."
> 
> That, combined with Mark's language, I think would resonate with domain 
> owners more than MUST NOT 

Yes, I think presenting solutions is better than stay exposed. No security 
folks are going to go for a plan that doesn’t have a path to protection.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

This topic is so nuanced that I think we need a more detailed discussion
than has been proposed.   Below is my counter proposal for the topic.
Doug Foster


As DMARC rollout approaches completion, aggregate reports may continue to
indicate non-affiliated servers that produce DMARC FAIL.  The DMARC
implementation team will desire to understand whether these items represent
malicious impersonators that need to be blocked, or non-malicious sources
that should not be blocked.  Mailing lists are one commonly-cited example
of non-malicious messages that produce DKIM FAIL due to in-transit changes.
  Moving to p=quarantine or p=reject is expected to cause non-malicious
messages to be blocked as malicious, which may also affect the server
organization's reputation and consequently the server's reputation and
ability to deliver any messages anywhere.

Since mail is often bi-directional, the domain owner should be collecting
DMARC test results on incoming messages at the same time that it is
collecting DMARC aggregate reports on outgoing messages.  When both sources
point to the same server organization and SMTP domain, parallels can be
drawn.   If incoming messages from a server are blocked as malicious, then
traffic reported on the aggregate report is also presumed to be malicious.
If incoming messages are identified as coming from an acceptable but
content-altering mailing list, then aggregate report entries for the same
server organization and SMTP domain are also presumed to represent
acceptable traffic.  Not all ambiguity will be resolvable.   Additionally,
since aggregate reports are an incomplete view of data in a particular time
period, some source will not be detected at all.

Where desirable but unauthenticated mail is known to exist, out-of-band
conversations with the report sending organization and the message sending
organization may permit exceptions to be configured in advance, so that the
exempted traffic will be accepted even if DMARC enforcement begins.

Domain owners will request DMARC enforcement when the actual or feared
occurrence of malicious traffic exceeds their concerns about blockage to
desirable traffic.  When this occurs, the burden shifts more heavily to the
evaluator and his organization.  If the domain owner policy correctly
identifies a malicious traffic source, then the evaluator should block the
initial message and any subsequent message from the attacker, whether
authenticated or not.  But it the domain owner policy incorrectly flags a
message as suspicious, the error should be corrected with an adjustment to
local policy.   The difference between the two possible interpretations
becomes very important and requires great care.  To help avoid incorrect
dispositions, domain owners may be best served by stopping at p=quarantine,
and evaluators may be best served by handling p=reject as if it was
p=quarantine.

On Sun, Apr 9, 2023 at 10:36 AM Scott Kitterman 
wrote:

> On Sunday, April 9, 2023 3:50:46 AM EDT Murray S. Kucherawy wrote:
> > Emphatically "wearing no hat" here, just speaking as a long-time
> > participant:
> >
> > On Sat, Apr 8, 2023 at 2:13 PM Mark Alley  >
> > 40tekmarc@dmarc.ietf.org> wrote:
> > > Re-looking at the definition of "SHOULD NOT", I don't see why it can't
> be
> > > considered.
> > >
> > > "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
> there
> > > may exist valid reasons in particular circumstances when the particular
> > > behavior is acceptable or even useful, but the full implications
> should be
> > > understood and the case carefully weighed before implementing any
> behavior
> > > described with this label."
> > >
> > > Seems to fit perfectly with how domain owners currently can pick and
> > > choose interoperability with p=none over more strict protection, or
> vice
> > > versa with p=reject, in my opinion. Is that not considered
> "acceptable" by
> > > this definition's context?
> >
> > IMHO, absolutely not.
> >
> > Since one of the IETF's main goals in producing a technical specification
> > is interoperability, and since improperly deployed "p=reject" results in
> > the very essence of non-interoperability in the deployed email base, I'm
> > having trouble imagining why the standard should leave operators with any
> > choice here.  That is, in direct reply to the cited definition of "SHOULD
> > NOT", I claim there do not exist valid reasons in particular
> circumstances
> > when the particular behavior is acceptable, even when the full
> implications
> > are understood and the case carefully weighed.
> >
> > (Note, here, that Barry has in his proposed text limited the constraint
> to
> > those types of deployments where the damage is likely.  I concur.  DMARC,
> > as currently defined, works just fine when deployed in transactional
> > situations.  Or, at least, I haven't seen that identified as a problem
> > case.)
> >
> > Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
> > NOT" that we know 

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

> On Apr 9, 2023, at 2:33 PM, Barry Leiba  wrote:
> 
> > As Todd previously stated, my preference is for language that
> > acknowledges the primacy of the domain owner over interoperability
> 
> The problem is that IETF standards are about interoperability, not about 
> anyone’s primacy.
> 
> There is an alternative, though: we can acknowledge that because of how those 
> deploying DMARC view their needs over interoperability, DMARC is not 
> appropriate as an IETF standard, and we abandon the effort to make it 
> Proposed Standard.

+1,  please make this an Informational status.  

> 
> I see that as the only way forward if we cannot address the damage that 
> improperly deployed DMARC policies do to mailing lists.

+1

In fact, lets take a step back and split DMARCbis to:

DMARC-Reporting 
DMARC-Policy

Let’s get reporting out the door and spend time to revisit the DKIM Policy 
Model via DMARC which combines two protocols.

With the ESP now honoring DMARC as is, the middle ware is forced to take 
drastic changes in order for the “mail men” to move mail.

Thanks Barry.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Barry Leiba]

> As Todd previously stated, my preference is for language that
> acknowledges the primacy of the domain owner over interoperability

The problem is that IETF standards are about interoperability, not about
anyone’s primacy.

There is an alternative, though: we can acknowledge that because of how
those deploying DMARC view their needs over interoperability, DMARC is not
appropriate as an IETF standard, and we abandon the effort to make it
Proposed Standard.

I see that as the only way forward if we cannot address the damage that
improperly deployed DMARC policies do to mailing lists.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Hector Santos]

> On Apr 9, 2023, at 2:15 PM, Murray S. Kucherawy  wrote:
> 
> On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson  > wrote:
>> As Todd previously stated, my preference is for language that acknowledges 
>> the primacy of the domain owner over interoperability. CISOs have been sold 
>> (arguably, by the DMARC deployment companies' marketing) on the idea that 
>> there are security benefits. Maybe oversold, but there are benefits and the 
>> motivation will not change. Let's not also overlook the primary benefit of 
>> _the process of deploying DMARC_ gives to an organization: increased 
>> management and governance (enabled by the observability from the reports). 
>> In any case, the domain owner is motivated to deploy DMARC and gain the 
>> perceived benefits. If we are going to tell these motivated domain owners to 
>> MUST do something, at least make it something they might consider doing.
> 
> I don't think the way DMARC has been marketed is germane to discussions about 
> interoperability, which is what "MUST NOT" type language seeks to resolve.

So is that the difference with ADSP and DMARCbis?  Lacking ADSP language to 
forcibly say ESP-like domains MUST NOT use `DISCARDABLE` policy? DMARCbis will 
survive this ADSP dilemma by saying MUST NOT p=reject?  👍

Basically what we are authorizing now is permission for MDA, MLS and MTA, 
middle-ware, to do whatever they need to do that make sure mail is 
transportable and deliverable, including removing, masking the security wrapper.

Since we will never get this right with this WG and rewrite is the only 
solution, I now agree to use a MUST NOT. 

So I think it should be outlined what will expected to happen if a domain uses 
p=reject when they should not:

- risk interop issues,
- messages alterations to remove the DMARC security blanket.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson  wrote:

> As Todd previously stated, my preference is for language that acknowledges
> the primacy of the domain owner over interoperability. CISOs have been sold
> (arguably, by the DMARC deployment companies' marketing) on the idea that
> there are security benefits. Maybe oversold, but there are benefits and the
> motivation will not change. Let's not also overlook the primary benefit of
> _the process of deploying DMARC_ gives to an organization: increased
> management and governance (enabled by the observability from the reports).
> In any case, the domain owner is motivated to deploy DMARC and gain the
> perceived benefits. If we are going to tell these motivated domain owners
> to MUST do something, at least make it something they might consider doing.
>

I don't think the way DMARC has been marketed is germane to discussions
about interoperability, which is what "MUST NOT" type language seeks to
resolve.

Nobody is denying that there's a security problem to be dealt with here.
It's a question of whether the side effects are acceptable.  And given that
DMARC only addresses direct domain attacks, and not lookalikes or similar,
I suggest that there's a clear imbalance when comparing the net benefits to
the aggregate costs.  If we're going to argue that that's not true, the
document probably needs to give that a much more thorough treatment than it
currently does.


> "Before a general purpose domain publishes p=reject|quarantine, the domain
> owner MUST emit mail from, or provide to their stakeholders/end-users, an
> alternative domain or subdomain with a p=none policy for any email that
> needs to traverse a non-DMARC-mitigating MLM or (more generally) from any
> 3rd party that cannot be authorized by SPF or DKIM alignment."
>

I think something like this is worthy of consideration.  It (or something
like it) is the very least we can do.  It is the very least we must do.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Sunday, April 9, 2023 3:50:46 AM EDT Murray S. Kucherawy wrote:
> Emphatically "wearing no hat" here, just speaking as a long-time
> participant:
> 
> On Sat, Apr 8, 2023 at 2:13 PM Mark Alley  
> 40tekmarc@dmarc.ietf.org> wrote:
> > Re-looking at the definition of "SHOULD NOT", I don't see why it can't be
> > considered.
> > 
> > "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there
> > may exist valid reasons in particular circumstances when the particular
> > behavior is acceptable or even useful, but the full implications should be
> > understood and the case carefully weighed before implementing any behavior
> > described with this label."
> > 
> > Seems to fit perfectly with how domain owners currently can pick and
> > choose interoperability with p=none over more strict protection, or vice
> > versa with p=reject, in my opinion. Is that not considered "acceptable" by
> > this definition's context?
> 
> IMHO, absolutely not.
> 
> Since one of the IETF's main goals in producing a technical specification
> is interoperability, and since improperly deployed "p=reject" results in
> the very essence of non-interoperability in the deployed email base, I'm
> having trouble imagining why the standard should leave operators with any
> choice here.  That is, in direct reply to the cited definition of "SHOULD
> NOT", I claim there do not exist valid reasons in particular circumstances
> when the particular behavior is acceptable, even when the full implications
> are understood and the case carefully weighed.
> 
> (Note, here, that Barry has in his proposed text limited the constraint to
> those types of deployments where the damage is likely.  I concur.  DMARC,
> as currently defined, works just fine when deployed in transactional
> situations.  Or, at least, I haven't seen that identified as a problem
> case.)
> 
> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
> NOT" that we know people will ignore calls into question the IETFs
> relevance or legitimacy.  But I submit that the IETF issuing a standards
> track document which fails to take the strongest possible stance against
> deploying DMARC in a way that knowingly imposes substantial breakage, for
> any reason, is irresponsible and is the greater threat to our legitimacy.
> Keep in mind that improper deployment of DMARC results in damage to
> innocent third parties: It's not the sender or the MLM that's impacted,
> it's everyone else on the list.  It's breathtaking to me that we can feel
> comfortable shrugging this off under the banner of "security" or "brand
> protection".
> 
> In a separate email, Doug Foster just said:
> > I also have a hard time with the notion that any domain with a potential
> 
> exception becomes a domain that MUST NOT protect itself from impersonation.
> 
> But it's not "MUST NOT protect itself from impersonation", it's "MUST NOT
> use DMARC to protect itself from impersonation" when the use of the domain
> includes non-transactional operations likely to be disruptive.
> 
> Imagine a web server protocol that states, when receiving a proxied
> connection, if the web server looks at it and sees something it didn't
> like, it rejects the request, but also fouls up some other active,
> legitimate operation in the process.  Imagine further that the only
> defensive posture about this disruption is a "SHOULD NOT".  Whatever
> benefit such an algorithm might claim, should it be given a place among the
> other standards the IETF produces?  I would hope the answer is obvious.
> And if we're not willing to tolerate it in the web world, why are we
> willing to tolerate it for email?
> 
> The IETF has no illusion that it is the standards or protocol police.  It
> is sufficient, however, to be able to say in the face of such breakage that
> this is not how the IETF intended DMARC to be deployed.  (A similar debate
> exists already, for what it's worth, in the domain registration space.)
> That is, if you do "p=reject" when you know what you're doing is going to
> clobber other people's legitimate operations, you can't claim to be
> operating in compliance with the standard.  We need to be able to say that,
> even if the offender doesn't care to listen, and "SHOULD NOT" simply
> doesn't cut it.
> 
> Mike also likes to invoke King Canute, but I think that's a faulty
> analogy.  DMARC does not deserve elevation in our calculus to the
> equivalent of a force of nature.  It was built and deployed by humans, who
> often make mistakes or have agendas.  The same cannot be said of the ocean
> or tides.
> 
> Finally, and for the only part with my AD on but askew: Scott has proposed
> a couple of good alternatives to consider, though one of them includes
> "MUST consider".  I have placed a DISCUSS on formulations like this in
> other documents before because I don't know how one would evaluate
> compliance with such a normative assertion.  It reduces in my mind to "OK
> I've thought about it, thus I 

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Sunday, April 9, 2023 9:55:29 AM EDT John Levine wrote:
> It appears that Matthäus Wander  said:
> >Earlier in the discussion, the term high-value domain has been used
> >(along with transactional email domain) in opposition to domain for
> >general-purpose email. ...
> 
> "High value" isn't a useful metric here. yahoo.com is a very valuable
> domain, but they still shouldn't be using a reject policy. The useful
> distinction is mail from people rather than mail from machines,
> whether the latter is transactions or bulk.
> 
> Keep in mind that DMARC policies cause damage to transactional mail,
> too. If a sender only validates with SPF (still common because it's
> cheap) and a recipient uses a forwarding address, transactional mail
> will get lost. A while back I talked to some people who worked at
> Paypal who told me of course they were aware of that, but for their
> purposes and given what a phish target they are, they felt the
> benefits were worth it.
> 
> When someone sets a DMARC policy for mail from people, it's hard to
> think of a time when they asked at wll whether that was what the
> people wanted. Or if they did, they asked something like "do you want
> your mail to be more secure?" which misses the point.
> 
> R's,
> John
> 
> PS: I can make anyone's mail 100% secure by unplugging your mail
> server but I'm pretty sure that's not what you want.

It gets even more complicated to describe.

I am aware of companies that have policies that prohibit use of company 
assigned email addresses in mailing lists and other known rough spots for 
DMARC and published DMARC p=reject with the understanding that there is mail 
that won't get delivered as a result.

They've evaluated the trade-offs and put policies in place with the 
understanding of the implications of them.  They can do that.

It's not even as simple as transactional/real users.

Scott K


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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[John Levine]

It appears that Matthäus Wander  said:
>Earlier in the discussion, the term high-value domain has been used 
>(along with transactional email domain) in opposition to domain for 
>general-purpose email. ...

"High value" isn't a useful metric here. yahoo.com is a very valuable
domain, but they still shouldn't be using a reject policy. The useful
distinction is mail from people rather than mail from machines,
whether the latter is transactions or bulk.

Keep in mind that DMARC policies cause damage to transactional mail,
too. If a sender only validates with SPF (still common because it's
cheap) and a recipient uses a forwarding address, transactional mail
will get lost. A while back I talked to some people who worked at
Paypal who told me of course they were aware of that, but for their
purposes and given what a phish target they are, they felt the
benefits were worth it. 

When someone sets a DMARC policy for mail from people, it's hard to
think of a time when they asked at wll whether that was what the
people wanted. Or if they did, they asked something like "do you want
your mail to be more secure?" which misses the point.

R's,
John

PS: I can make anyone's mail 100% secure by unplugging your mail
server but I'm pretty sure that's not what you want.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Jesse Thompson]

On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
> Personally, I prefer the latter of the two, quoted below.
> 
> "to preserve interoperability, domains SHOULD NOT publish p=reject unless 
> they are [not general purpose]* domains"
> 
> "Publishing DMARC records with restrictive policies does cause 
> interoperability problems for some normal email usage patterns. Potential 
> impacts MUST be considered before any domain publishes a restrictive policy."

I like the latter, as well. I was going to suggest something similar.

As Todd previously stated, my preference is for language that acknowledges the 
primacy of the domain owner over interoperability. CISOs have been sold 
(arguably, by the DMARC deployment companies' marketing) on the idea that there 
are security benefits. Maybe oversold, but there are benefits and the 
motivation will not change. Let's not also overlook the primary benefit of _the 
process of deploying DMARC_ gives to an organization: increased management and 
governance (enabled by the observability from the reports). In any case, the 
domain owner is motivated to deploy DMARC and gain the perceived benefits. If 
we are going to tell these motivated domain owners to MUST do something, at 
least make it something they might consider doing.

"Before a general purpose domain publishes p=reject|quarantine, the domain 
owner MUST emit mail from, or provide to their stakeholders/end-users, an 
alternative domain or subdomain with a p=none policy for any email that needs 
to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party 
that cannot be authorized by SPF or DKIM alignment."

That, combined with Mark's language, I think would resonate with domain owners 
more than MUST NOT p=reject.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Matthäus Wander]

Murray S. Kucherawy wrote on 2023-04-09 09:50:
Since one of the IETF's main goals in producing a technical 
specification is interoperability, and since improperly deployed 
"p=reject" results in the very essence of non-interoperability in the 
deployed email base, I'm having trouble imagining why the standard 
should leave operators with any choice here.  That is, in direct reply 
to the cited definition of "SHOULD NOT", I claim there do not exist 
valid reasons in particular circumstances when the particular behavior 
is acceptable, even when the full implications are understood and the 
case carefully weighed.


Earlier in the discussion, the term high-value domain has been used 
(along with transactional email domain) in opposition to domain for 
general-purpose email. The proposed text leaves it to the discretion of 
the domain owner to decide whether they have a general-purpose email 
domain or, say, a special-purpose business domain with a high need for 
protection from email spoofing. The risks are outlined, thus enabling 
the domain owner to weigh the implications, and the proposed text 
acknowledges that ...


> ... the decision on which p= value to use will depend on its needs.

Isn't that having a choice?

Regards,
Matt

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

Emphatically "wearing no hat" here, just speaking as a long-time
participant:

On Sat, Apr 8, 2023 at 2:13 PM Mark Alley  wrote:

> Re-looking at the definition of "SHOULD NOT", I don't see why it can't be
> considered.
>
> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there
> may exist valid reasons in particular circumstances when the particular
> behavior is acceptable or even useful, but the full implications should be
> understood and the case carefully weighed before implementing any behavior
> described with this label."
>
> Seems to fit perfectly with how domain owners currently can pick and
> choose interoperability with p=none over more strict protection, or vice
> versa with p=reject, in my opinion. Is that not considered "acceptable" by
> this definition's context?
>
IMHO, absolutely not.

Since one of the IETF's main goals in producing a technical specification
is interoperability, and since improperly deployed "p=reject" results in
the very essence of non-interoperability in the deployed email base, I'm
having trouble imagining why the standard should leave operators with any
choice here.  That is, in direct reply to the cited definition of "SHOULD
NOT", I claim there do not exist valid reasons in particular circumstances
when the particular behavior is acceptable, even when the full implications
are understood and the case carefully weighed.

(Note, here, that Barry has in his proposed text limited the constraint to
those types of deployments where the damage is likely.  I concur.  DMARC,
as currently defined, works just fine when deployed in transactional
situations.  Or, at least, I haven't seen that identified as a problem
case.)

Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
NOT" that we know people will ignore calls into question the IETFs
relevance or legitimacy.  But I submit that the IETF issuing a standards
track document which fails to take the strongest possible stance against
deploying DMARC in a way that knowingly imposes substantial breakage, for
any reason, is irresponsible and is the greater threat to our legitimacy.
Keep in mind that improper deployment of DMARC results in damage to
innocent third parties: It's not the sender or the MLM that's impacted,
it's everyone else on the list.  It's breathtaking to me that we can feel
comfortable shrugging this off under the banner of "security" or "brand
protection".

In a separate email, Doug Foster just said:

> I also have a hard time with the notion that any domain with a potential
exception becomes a domain that MUST NOT protect itself from impersonation.

But it's not "MUST NOT protect itself from impersonation", it's "MUST NOT
use DMARC to protect itself from impersonation" when the use of the domain
includes non-transactional operations likely to be disruptive.

Imagine a web server protocol that states, when receiving a proxied
connection, if the web server looks at it and sees something it didn't
like, it rejects the request, but also fouls up some other active,
legitimate operation in the process.  Imagine further that the only
defensive posture about this disruption is a "SHOULD NOT".  Whatever
benefit such an algorithm might claim, should it be given a place among the
other standards the IETF produces?  I would hope the answer is obvious.
And if we're not willing to tolerate it in the web world, why are we
willing to tolerate it for email?

The IETF has no illusion that it is the standards or protocol police.  It
is sufficient, however, to be able to say in the face of such breakage that
this is not how the IETF intended DMARC to be deployed.  (A similar debate
exists already, for what it's worth, in the domain registration space.)
That is, if you do "p=reject" when you know what you're doing is going to
clobber other people's legitimate operations, you can't claim to be
operating in compliance with the standard.  We need to be able to say that,
even if the offender doesn't care to listen, and "SHOULD NOT" simply
doesn't cut it.

Mike also likes to invoke King Canute, but I think that's a faulty
analogy.  DMARC does not deserve elevation in our calculus to the
equivalent of a force of nature.  It was built and deployed by humans, who
often make mistakes or have agendas.  The same cannot be said of the ocean
or tides.

Finally, and for the only part with my AD on but askew: Scott has proposed
a couple of good alternatives to consider, though one of them includes
"MUST consider".  I have placed a DISCUSS on formulations like this in
other documents before because I don't know how one would evaluate
compliance with such a normative assertion.  It reduces in my mind to "OK
I've thought about it, thus I have complied", so it doesn't actually say
much in defense of interoperability.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Mark Alley]

Personally, I prefer the latter of the two, quoted below.

"to preserve interoperability, domains SHOULD NOT publish p=reject unless they are 
[not general purpose]* domains"

"Publishing DMARC records with restrictive policies does cause interoperability 
problems for some normal email usage patterns. Potential impacts MUST be considered 
before any domain publishes a restrictive policy."

These two combined address how p=reject interoperability risks are considered 
on most [general purpose] domains today during implementation, while also 
making well-known the damage that a strict policy can cause to [some types] of 
indirect mail flow.


On 4/8/2023 7:52 PM, John Levine wrote:

It appears that Scott Kitterman  said:

We could do I think any of the following and they are roughly semantically
equivalent:

[general purpose]* domains MUST NOT publish p=reject to preserve
interoperability

to preserve interoperability, domains SHOULD NOT publish p=reject unless they
are [not general purpose]* domains

which could be accompanied by:

[not general purpose]* domains SHOULD determine their email authentication
deployment is accurate and complete before publishing restrictive policies
(p=quarntine or p=reject) to avoid interoperability issues.

Publishing DMARC records with restrictive policies does cause interoperability
problems for some normal email usage patterns.  Potential impacts MUST be
considered before any domain publishes a restrictive policy.

* whatever the right formulation is, that's a related, but distinct (and I
think less controversial question).

I'm OK with any of these.

I do think it's important to make it clear that you lose interopn when
you publish a policy on a domain that's sending more than transactions
or spam.

R's,
John

___
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] Proposed text for p=reject and indirect mail flows

[John Levine]

It appears that Scott Kitterman   said:
>We could do I think any of the following and they are roughly semantically 
>equivalent:
>
>[general purpose]* domains MUST NOT publish p=reject to preserve 
>interoperability
>
>to preserve interoperability, domains SHOULD NOT publish p=reject unless they 
>are [not general purpose]* domains
>
>which could be accompanied by:
>
>[not general purpose]* domains SHOULD determine their email authentication 
>deployment is accurate and complete before publishing restrictive policies 
>(p=quarntine or p=reject) to avoid interoperability issues.
>
>Publishing DMARC records with restrictive policies does cause interoperability 
>problems for some normal email usage patterns.  Potential impacts MUST be 
>considered before any domain publishes a restrictive policy.
>
>* whatever the right formulation is, that's a related, but distinct (and I 
>think less controversial question).

I'm OK with any of these.

I do think it's important to make it clear that you lose interopn when
you publish a policy on a domain that's sending more than transactions
or spam.

R's,
John

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Neil Anuskiewicz]

> On Apr 8, 2023, at 3:28 PM, Scott Kitterman  wrote:
> 
> There are several variations of text that roughly mean the same thing, 
> particularly when you keep in mind that IETF specifications are intended to 
> be 
> interoperability specifications, not implementation specifications.
> 
> We could do I think any of the following and they are roughly semantically 
> equivalent:
> 
> [general purpose]* domains MUST NOT publish p=reject to preserve 
> interoperability
> 
> to preserve interoperability, domains SHOULD NOT publish p=reject unless they 
> are [not general purpose]* domains
> 
> which could be accompanied by:
> 
> [not general purpose]* domains SHOULD determine their email authentication 
> deployment is accurate and complete before publishing restrictive policies 
> (p=quarntine or p=reject) to avoid interoperability issues.
> 
> Publishing DMARC records with restrictive policies does cause 
> interoperability 
> problems for some normal email usage patterns.  Potential impacts MUST be 
> considered before any domain publishes a restrictive policy.
> 
> * whatever the right formulation is, that's a related, but distinct (and I 
> think less controversial question).
> 
> I think there's enough there for everyone to find their preferred answer.  I 
> think it's clear on the interoperability risks, but the last MUST allows for 
> the realist case that people are going to do it anyway.  I have no preference 
> between the first two alternatives.
> 
> 
> 
>> On Saturday, April 8, 2023 5:12:56 PM EDT Mark Alley wrote:
>> Re-looking at the definition of "SHOULD NOT", I don't see why it can't
>> be considered.
>> 
>> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
>> there may exist valid reasons in particular circumstances when the
>> particular behavior is acceptable or even useful, but the full
>> implications should be understood and the case carefully weighed before
>> implementing any behavior described with this label."
>> 
>> Seems to fit perfectly with how domain owners currently can pick and
>> choose interoperability with p=none over more strict protection, or vice
>> versa with p=reject, in my opinion. Is that not considered "acceptable"
>> by this definition's context?
>> 
>>> On 4/8/2023 4:10 PM, Scott Kitterman wrote:
>>> Possible.  I didn't count.
>>> 
>>> I didn't see any convergence towards an alternative.
>>> 
>>> I think adding explicitly that the MUST is related to interoperability
>>> reasonably addresses the concern that there are non-interoperability
>>> reasons people are going to publish p=reject despite the side effects.
>>> 
>>> I don't see a stronger consensus for a specific alternative.
>>> 
>>> I think we have exhausted the discussion on the topic, so, whatever the
>>> resolution, I'd like to see the chairs drive the question to closure. 
>>> It's pretty clear it's not going to naturally drift into a universal
>>> consensus.
>>> 
>>> Scott K
>>> 
>>> On April 8, 2023 8:58:13 PM UTC, Dotzero  wrote:
 Going back through the thread I find more people questioning/disagreeing
 with the proposed wording than agreeing with it. I don't see a rough
 consensus.
 
 Michael Hammer
 
 On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman  
> wrote:
> We've gone nearly a week without any further discussion on this thread.
> 
> I reviewed the thread and I think this is the closest we got to anything
> (most) people agreed on.  I know not everyone liked it, but I doubt
> we're
> going to get closer to a consensus on this.
> 
> Can we adopt this and move forward on to the next thing?
> 
> Scott K

Yes, I think so.  I get the feeling you possibly think it’s text that isn’t 
going to make much of an impact but presumably it’ll at least make a difference 
at the margins? The margins can grow as others see the benefits. I don’t know.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

hat is high-value.
> >>>>>> 
> >>>>>> comcast.com: p=reject
> >>>>>> comcast.net: p=none
> >>>>>> xfinity.com: p=quarantine
> >>>>>> 
> >>>>>> The top one is corporate, middle is consumer, bottom is consumer (but
> >>> 
> >>> not
> >>> 
> >>>>>> actually used) & customer comms (sub-domains).  They’re all used in
> >>>>>> various ways for internal messaging.  Should I tell our corporate
> >>> 
> >>> admins
> >>> 
> >>>>>> that they need to no longer publish p=reject?  They’re violating the
> >>> 
> >>> RFC
> >>> 
> >>>>>> by doing so?  There are very few consumer-oriented messages that
> >>>>>> originate from comcast.com.  Are we doing it right?  It makes things
> >>> 
> >>> a
> >>> 
> >>>>>> little harder when one of our employees wants to use a mailing list.
> >>>>>> But that still feels like the right thing to do.
> >>>>>> 
> >>>>>> If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> >>>>>> dictating to domain owners what is in their best interests,
> >>>>>> regardless
> >>>>>> of our perceived value of their domain.
> >>>>>> 
> >>>>>> --
> >>>>>> Alex Brotman
> >>>>>> Sr. Engineer, Anti-Abuse & Messaging Policy
> >>>>>> Comcast
> >>>>>> 
> >>>>>> From: dmarc  On Behalf Of Barry Leiba
> >>>>>> Sent: Wednesday, March 29, 2023 10:15 AM
> >>>>>> To: Todd Herr
> >>>>>> Cc:dmarc@ietf.org
> >>>>>> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect
> >>>>>> mail
> >>>>>> flows
> >>>>>> 
> >>>>>> I'm very much against text such as this, as I think it encourages
> >>>>>> deployments that are contrary to interoperability and to the intent
> >>>>>> of
> >>>>>> p=reject.
> >>>>>> 
> >>>>>> I contend that p=reject (as with the similar construct in the older
> >>> 
> >>> ADSP)
> >>> 
> >>>>>> was intended for high-value domains and transactional mail, and that
> >>> 
> >>> it
> >>> 
> >>>>>> was never intended for use in domains where general users send
> >>>>>> general
> >>>>>> email.
> >>>>>> 
> >>>>>> I stand by the MUST NOT that I proposed.
> >>>>>> 
> >>>>>> Barry
> >>>>>> 
> >>>>>> 
> >>>>>> On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> >>> 
> >>>>>>  >>> 40valimail@dmarc.iet
> >>> 
> >>>>>> f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> >>>>>> mailto:resn...@episteme.net>> wrote:
> >>>>>> 
> >>>>>> If you agree that interoperability is increased, then I'd suggest
> >>>>>> that
> >>>>>> you actually do agree that the proposed text is appropriate.
> >>>>>> 
> >>>>>> 
> >>>>>> I don't know that I agree that interoperability is increased...
> >>>>>> 
> >>>>>> I'm having trouble squaring proposed language that says "Domain
> >>>>>> owners
> >>>>>> MUST NOT publish p=reject because it breaks interoperability" with
> >>>>>> the
> >>>>>> following language from section 5.8:
> >>>>>> 
> >>>>>> 
> >>>>>> Mail Receivers **MAY** choose to accept email that fails the DMARC
> >>>>>> 
> >>>>>> mechanism check even if the published Domain Owner Assessment Policy
> >>>>>> 
> >>>>>> is "reject". In particular, because of the considerations discussed
> >>>>>> 
> >>>>>> in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT**
> >>> 
> >>> reject
> >>> 
> >>>>>> messages solely because of a published policy of "reject", but that
> >>>>>> 
> >>>>>> they apply other knowledge and analysis to avoid situations such as
> >>>>>> 
> >>>>>> rejection of legitimate messages sent in ways that DMARC cannot
> >>>>>> describe, harm to the operation of mailing lists, and similar.
> >>>>>> 
> >>>>>> It seems inconsistent to state with certainty that authorized mail
> >>> 
> >>> will
> >>> 
> >>>>>> be rejected due to authentication breakage when there is no
> >>> 
> >>> requirement
> >>> 
> >>>>>> that a reject policy be honored (and we have plenty of evidence that
> >>>>>> Mail Receivers are following the 'SHOULD NOT reject messages'
> >>> 
> >>> guidance).
> >>> 
> >>>>>> Language that would be more consistent in guidance to the domain
> >>> 
> >>> owners
> >>> 
> >>>>>> might look something like this:
> >>>>>> 
> >>>>>> After careful analysis of the aggregate report data as described in
> >>>>>> section 5.5.5 (Collect and Analyze Reports), Domain Owners **MAY**
> >>>>>> choose to change their policy from 'none' to 'quarantine' or
> >>>>>> 'reject'.
> >>>>>> If, in the Domain Owner's judgement, unauthorized and deceptive use
> >>>>>> of
> >>>>>> its domain name in the RFC5322.From field puts at risk the trust it
> >>> 
> >>> has
> >>> 
> >>>>>> built with its recipients, then it is **RECOMMENDED** that the Domain
> >>>>>> Owner make use of the p and/or sp tags to set policy to 'quarantine'
> >>> 
> >>> or
> >>> 
> >>>>>> 'reject' for those streams most at risk of loss of trust.
> >>>>>> 
> >>>>>> If going that route, probably want to consider expanding on 5.5.5,
> >>> 
> >>> too; I
> >>> 
> >>>>>> need to think about it some more.
> >>> 
> >>> ___
> >>> 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] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Sat, Apr 8, 2023 at 5:10 PM Scott Kitterman  wrote:

> Possible.  I didn't count.
>
> I didn't see any convergence towards an alternative.
>

The fact that there hasn't been convergence on an alternative doesn't mean
there has been convergence on the proposed new txt. This also doesn't mean
the proposed new text becomes the default in the event of a lack of
consensus. If anything were to be considered the default in the event of
lack of consensus it would most logically be the original text.


>
> I think adding explicitly that the MUST is related to interoperability
> reasonably addresses the concern that there are non-interoperability
> reasons people are going to publish p=reject despite the side effects.
>

I don't read it that way. We clearly see interoperability even with domains
such as AOL, Yahoo and other similar domains publishing p=reject. I
recognize there are issues but I'm not comfortable that they rise to the
level of a failure to interoperate. I'm also not comfortable publishing
"MUST NOT" for p=reject when we know that domains representing a very large
number of sending users are. To me that smacks of virtue signaling and a
failure to address a difficult problem space because, "you know". This is
why I am more comfortable with "should not". It recognizes the problems but
doesn't pretend they are going away because of a demand to conform that the
promulgators of the standard recognize won't be listened to.

>
> I don't see a stronger consensus for a specific alternative.
>
> I think we have exhausted the discussion on the topic, so, whatever the
> resolution, I'd like to see the chairs drive the question to closure.  It's
> pretty clear it's not going to naturally drift into a universal consensus.
>
> Michael Hammer
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

; > >xfinity.com: p=quarantine
> > > >
> > > >The top one is corporate, middle is consumer, bottom is consumer (but
> not
> > > >actually used) & customer comms (sub-domains).  They’re all used in
> > > >various ways for internal messaging.  Should I tell our corporate
> admins
> > > >that they need to no longer publish p=reject?  They’re violating the
> RFC
> > > >by doing so?  There are very few consumer-oriented messages that
> > > >originate from comcast.com.  Are we doing it right?  It makes things
> a
> > > >little harder when one of our employees wants to use a mailing list.
> > > >But that still feels like the right thing to do.
> > > >
> > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> > > >dictating to domain owners what is in their best interests, regardless
> > > >of our perceived value of their domain.
> > > >
> > > >--
> > > >Alex Brotman
> > > >Sr. Engineer, Anti-Abuse & Messaging Policy
> > > >Comcast
> > > >
> > > >From: dmarc  On Behalf Of Barry Leiba
> > > >Sent: Wednesday, March 29, 2023 10:15 AM
> > > >To: Todd Herr 
> > > >Cc: dmarc@ietf.org
> > > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> > > >flows
> > > >
> > > >I'm very much against text such as this, as I think it encourages
> > > >deployments that are contrary to interoperability and to the intent of
> > > >p=reject.
> > > >
> > > >I contend that p=reject (as with the similar construct in the older
> ADSP)
> > > >was intended for high-value domains and transactional mail, and that
> it
> > > >was never intended for use in domains where general users send general
> > > >email.
> > > >
> > > >I stand by the MUST NOT that I proposed.
> > > >
> > > >Barry
> > > >
> > > >
> > > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> > > > 40valimail@dmarc.iet
> > > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> > > >mailto:resn...@episteme.net>> wrote:
> > > >
> > > >If you agree that interoperability is increased, then I'd suggest that
> > > >you actually do agree that the proposed text is appropriate.
> > > >
> > > >
> > > >I don't know that I agree that interoperability is increased...
> > > >
> > > >I'm having trouble squaring proposed language that says "Domain owners
> > > >MUST NOT publish p=reject because it breaks interoperability" with the
> > > >following language from section 5.8:
> > > >
> > > >
> > > >Mail Receivers **MAY** choose to accept email that fails the DMARC
> > > >
> > > >mechanism check even if the published Domain Owner Assessment Policy
> > > >
> > > >is "reject". In particular, because of the considerations discussed
> > > >
> > > >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT**
> reject
> > > >
> > > >messages solely because of a published policy of "reject", but that
> > > >
> > > >they apply other knowledge and analysis to avoid situations such as
> > > >
> > > >rejection of legitimate messages sent in ways that DMARC cannot
> > > >describe, harm to the operation of mailing lists, and similar.
> > > >
> > > >It seems inconsistent to state with certainty that authorized mail
> will
> > > >be rejected due to authentication breakage when there is no
> requirement
> > > >that a reject policy be honored (and we have plenty of evidence that
> > > >Mail Receivers are following the 'SHOULD NOT reject messages'
> guidance).
> > > >
> > > >Language that would be more consistent in guidance to the domain
> owners
> > > >might look something like this:
> > > >
> > > >After careful analysis of the aggregate report data as described in
> > > >section 5.5.5 (Collect and Analyze Reports), Domain Owners **MAY**
> > > >choose to change their policy from 'none' to 'quarantine' or 'reject'.
> > > >If, in the Domain Owner's judgement, unauthorized and deceptive use of
> > > >its domain name in the RFC5322.From field puts at risk the trust it
> has
> > > >built with its recipients, then it is **RECOMMENDED** that the Domain
> > > >Owner make use of the p and/or sp tags to set policy to 'quarantine'
> or
> > > >'reject' for those streams most at risk of loss of trust.
> > > >
> > > >If going that route, probably want to consider expanding on 5.5.5,
> too; I
> > > >need to think about it some more.
>
>
>
>
>
> ___
> 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] Proposed text for p=reject and indirect mail flows

[Mark Alley]

Re-looking at the definition of "SHOULD NOT", I don't see why it can't 
be considered.


"SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that 
there may exist valid reasons in particular circumstances when the 
particular behavior is acceptable or even useful, but the full 
implications should be understood and the case carefully weighed before 
implementing any behavior described with this label."


Seems to fit perfectly with how domain owners currently can pick and 
choose interoperability with p=none over more strict protection, or vice 
versa with p=reject, in my opinion. Is that not considered "acceptable" 
by this definition's context?


On 4/8/2023 4:10 PM, Scott Kitterman wrote:

Possible.  I didn't count.

I didn't see any convergence towards an alternative.

I think adding explicitly that the MUST is related to interoperability 
reasonably addresses the concern that there are non-interoperability reasons 
people are going to publish p=reject despite the side effects.

I don't see a stronger consensus for a specific alternative.

I think we have exhausted the discussion on the topic, so, whatever the 
resolution, I'd like to see the chairs drive the question to closure.  It's 
pretty clear it's not going to naturally drift into a universal consensus.

Scott K

On April 8, 2023 8:58:13 PM UTC, Dotzero  wrote:

Going back through the thread I find more people questioning/disagreeing
with the proposed wording than agreeing with it. I don't see a rough
consensus.

Michael Hammer

On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman  wrote:


We've gone nearly a week without any further discussion on this thread.

I reviewed the thread and I think this is the closest we got to anything
(most) people agreed on.  I know not everyone liked it, but I doubt we're
going to get closer to a consensus on this.

Can we adopt this and move forward on to the next thing?

Scott K

On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:

I'm happy with that suggestion.

Barry

On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman

wrote:

Would you feel any better if the MUST NOT was followed by 'to preserve
interoperability '?  That's implicitly there and I believe technically
correct.  If you value other properties of the system higher than
interoperability, then the advice may not apply, which is fine.

Scott K

On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"

  wrote:

I’m just not sure how we determine what is high-value.

comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine

The top one is corporate, middle is consumer, bottom is consumer (but

not

actually used) & customer comms (sub-domains).  They’re all used in
various ways for internal messaging.  Should I tell our corporate

admins

that they need to no longer publish p=reject?  They’re violating the

RFC

by doing so?  There are very few consumer-oriented messages that
originate from comcast.com.  Are we doing it right?  It makes things

a

little harder when one of our employees wants to use a mailing list.
But that still feels like the right thing to do.

If it’s not obvious, I’m having a hard time with “MUST NOT”, and
dictating to domain owners what is in their best interests, regardless
of our perceived value of their domain.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr
Cc:dmarc@ietf.org
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
flows

I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.

I contend that p=reject (as with the similar construct in the older

ADSP)

was intended for high-value domains and transactional mail, and that

it

was never intended for use in domains where general users send general
email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr

40valimail@dmarc.iet

f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
mailto:resn...@episteme.net>> wrote:

If you agree that interoperability is increased, then I'd suggest that
you actually do agree that the proposed text is appropriate.


I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners
MUST NOT publish p=reject because it breaks interoperability" with the
following language from section 5.8:


Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT**

reject

messages so

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

Possible.  I didn't count.

I didn't see any convergence towards an alternative.

I think adding explicitly that the MUST is related to interoperability 
reasonably addresses the concern that there are non-interoperability reasons 
people are going to publish p=reject despite the side effects.

I don't see a stronger consensus for a specific alternative.

I think we have exhausted the discussion on the topic, so, whatever the 
resolution, I'd like to see the chairs drive the question to closure.  It's 
pretty clear it's not going to naturally drift into a universal consensus.

Scott K

On April 8, 2023 8:58:13 PM UTC, Dotzero  wrote:
>Going back through the thread I find more people questioning/disagreeing
>with the proposed wording than agreeing with it. I don't see a rough
>consensus.
>
>Michael Hammer
>
>On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman  wrote:
>
>> We've gone nearly a week without any further discussion on this thread.
>>
>> I reviewed the thread and I think this is the closest we got to anything
>> (most) people agreed on.  I know not everyone liked it, but I doubt we're
>> going to get closer to a consensus on this.
>>
>> Can we adopt this and move forward on to the next thing?
>>
>> Scott K
>>
>> On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
>> > I'm happy with that suggestion.
>> >
>> > Barry
>> >
>> > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman 
>> wrote:
>> > > Would you feel any better if the MUST NOT was followed by 'to preserve
>> > > interoperability '?  That's implicitly there and I believe technically
>> > > correct.  If you value other properties of the system higher than
>> > > interoperability, then the advice may not apply, which is fine.
>> > >
>> > > Scott K
>> > >
>> > > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"
>>  wrote:
>> > > >I’m just not sure how we determine what is high-value.
>> > > >
>> > > >comcast.com: p=reject
>> > > >comcast.net: p=none
>> > > >xfinity.com: p=quarantine
>> > > >
>> > > >The top one is corporate, middle is consumer, bottom is consumer (but
>> not
>> > > >actually used) & customer comms (sub-domains).  They’re all used in
>> > > >various ways for internal messaging.  Should I tell our corporate
>> admins
>> > > >that they need to no longer publish p=reject?  They’re violating the
>> RFC
>> > > >by doing so?  There are very few consumer-oriented messages that
>> > > >originate from comcast.com.  Are we doing it right?  It makes things
>> a
>> > > >little harder when one of our employees wants to use a mailing list.
>> > > >But that still feels like the right thing to do.
>> > > >
>> > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
>> > > >dictating to domain owners what is in their best interests, regardless
>> > > >of our perceived value of their domain.
>> > > >
>> > > >--
>> > > >Alex Brotman
>> > > >Sr. Engineer, Anti-Abuse & Messaging Policy
>> > > >Comcast
>> > > >
>> > > >From: dmarc  On Behalf Of Barry Leiba
>> > > >Sent: Wednesday, March 29, 2023 10:15 AM
>> > > >To: Todd Herr 
>> > > >Cc: dmarc@ietf.org
>> > > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
>> > > >flows
>> > > >
>> > > >I'm very much against text such as this, as I think it encourages
>> > > >deployments that are contrary to interoperability and to the intent of
>> > > >p=reject.
>> > > >
>> > > >I contend that p=reject (as with the similar construct in the older
>> ADSP)
>> > > >was intended for high-value domains and transactional mail, and that
>> it
>> > > >was never intended for use in domains where general users send general
>> > > >email.
>> > > >
>> > > >I stand by the MUST NOT that I proposed.
>> > > >
>> > > >Barry
>> > > >
>> > > >
>> > > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
>> > > >> 40valimail@dmarc.iet
>> > > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
>> > &g

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

Going back through the thread I find more people questioning/disagreeing
with the proposed wording than agreeing with it. I don't see a rough
consensus.

Michael Hammer

On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman  wrote:

> We've gone nearly a week without any further discussion on this thread.
>
> I reviewed the thread and I think this is the closest we got to anything
> (most) people agreed on.  I know not everyone liked it, but I doubt we're
> going to get closer to a consensus on this.
>
> Can we adopt this and move forward on to the next thing?
>
> Scott K
>
> On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
> > I'm happy with that suggestion.
> >
> > Barry
> >
> > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman 
> wrote:
> > > Would you feel any better if the MUST NOT was followed by 'to preserve
> > > interoperability '?  That's implicitly there and I believe technically
> > > correct.  If you value other properties of the system higher than
> > > interoperability, then the advice may not apply, which is fine.
> > >
> > > Scott K
> > >
> > > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"
>  wrote:
> > > >I’m just not sure how we determine what is high-value.
> > > >
> > > >comcast.com: p=reject
> > > >comcast.net: p=none
> > > >xfinity.com: p=quarantine
> > > >
> > > >The top one is corporate, middle is consumer, bottom is consumer (but
> not
> > > >actually used) & customer comms (sub-domains).  They’re all used in
> > > >various ways for internal messaging.  Should I tell our corporate
> admins
> > > >that they need to no longer publish p=reject?  They’re violating the
> RFC
> > > >by doing so?  There are very few consumer-oriented messages that
> > > >originate from comcast.com.  Are we doing it right?  It makes things
> a
> > > >little harder when one of our employees wants to use a mailing list.
> > > >But that still feels like the right thing to do.
> > > >
> > > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> > > >dictating to domain owners what is in their best interests, regardless
> > > >of our perceived value of their domain.
> > > >
> > > >--
> > > >Alex Brotman
> > > >Sr. Engineer, Anti-Abuse & Messaging Policy
> > > >Comcast
> > > >
> > > >From: dmarc  On Behalf Of Barry Leiba
> > > >Sent: Wednesday, March 29, 2023 10:15 AM
> > > >To: Todd Herr 
> > > >Cc: dmarc@ietf.org
> > > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> > > >flows
> > > >
> > > >I'm very much against text such as this, as I think it encourages
> > > >deployments that are contrary to interoperability and to the intent of
> > > >p=reject.
> > > >
> > > >I contend that p=reject (as with the similar construct in the older
> ADSP)
> > > >was intended for high-value domains and transactional mail, and that
> it
> > > >was never intended for use in domains where general users send general
> > > >email.
> > > >
> > > >I stand by the MUST NOT that I proposed.
> > > >
> > > >Barry
> > > >
> > > >
> > > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> > > > 40valimail@dmarc.iet
> > > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> > > >mailto:resn...@episteme.net>> wrote:
> > > >
> > > >If you agree that interoperability is increased, then I'd suggest that
> > > >you actually do agree that the proposed text is appropriate.
> > > >
> > > >
> > > >I don't know that I agree that interoperability is increased...
> > > >
> > > >I'm having trouble squaring proposed language that says "Domain owners
> > > >MUST NOT publish p=reject because it breaks interoperability" with the
> > > >following language from section 5.8:
> > > >
> > > >
> > > >Mail Receivers **MAY** choose to accept email that fails the DMARC
> > > >
> > > >mechanism check even if the published Domain Owner Assessment Policy
> > > >
> > > >is "reject". In particular, because of the considerations discussed
> > > >
> > > >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

We've gone nearly a week without any further discussion on this thread.

I reviewed the thread and I think this is the closest we got to anything 
(most) people agreed on.  I know not everyone liked it, but I doubt we're 
going to get closer to a consensus on this.

Can we adopt this and move forward on to the next thing?

Scott K

On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
> I'm happy with that suggestion.
> 
> Barry
> 
> On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman  
wrote:
> > Would you feel any better if the MUST NOT was followed by 'to preserve
> > interoperability '?  That's implicitly there and I believe technically
> > correct.  If you value other properties of the system higher than
> > interoperability, then the advice may not apply, which is fine.
> > 
> > Scott K
> > 
> > On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex" 
 wrote:
> > >I’m just not sure how we determine what is high-value.
> > >
> > >comcast.com: p=reject
> > >comcast.net: p=none
> > >xfinity.com: p=quarantine
> > >
> > >The top one is corporate, middle is consumer, bottom is consumer (but not
> > >actually used) & customer comms (sub-domains).  They’re all used in
> > >various ways for internal messaging.  Should I tell our corporate admins
> > >that they need to no longer publish p=reject?  They’re violating the RFC
> > >by doing so?  There are very few consumer-oriented messages that
> > >originate from comcast.com.  Are we doing it right?  It makes things a
> > >little harder when one of our employees wants to use a mailing list. 
> > >But that still feels like the right thing to do.
> > >
> > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> > >dictating to domain owners what is in their best interests, regardless
> > >of our perceived value of their domain.
> > >
> > >--
> > >Alex Brotman
> > >Sr. Engineer, Anti-Abuse & Messaging Policy
> > >Comcast
> > >
> > >From: dmarc  On Behalf Of Barry Leiba
> > >Sent: Wednesday, March 29, 2023 10:15 AM
> > >To: Todd Herr 
> > >Cc: dmarc@ietf.org
> > >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> > >flows
> > >
> > >I'm very much against text such as this, as I think it encourages
> > >deployments that are contrary to interoperability and to the intent of
> > >p=reject.
> > >
> > >I contend that p=reject (as with the similar construct in the older ADSP)
> > >was intended for high-value domains and transactional mail, and that it
> > >was never intended for use in domains where general users send general
> > >email.
> > >
> > >I stand by the MUST NOT that I proposed.
> > >
> > >Barry
> > >
> > >
> > >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
> > >mailto:40valimail@dmarc.iet
> > >f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
> > >mailto:resn...@episteme.net>> wrote:
> > >
> > >If you agree that interoperability is increased, then I'd suggest that
> > >you actually do agree that the proposed text is appropriate.
> > >
> > >
> > >I don't know that I agree that interoperability is increased...
> > >
> > >I'm having trouble squaring proposed language that says "Domain owners
> > >MUST NOT publish p=reject because it breaks interoperability" with the
> > >following language from section 5.8:
> > >
> > >
> > >Mail Receivers **MAY** choose to accept email that fails the DMARC
> > >
> > >mechanism check even if the published Domain Owner Assessment Policy
> > >
> > >is "reject". In particular, because of the considerations discussed
> > >
> > >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
> > >
> > >messages solely because of a published policy of "reject", but that
> > >
> > >they apply other knowledge and analysis to avoid situations such as
> > >
> > >rejection of legitimate messages sent in ways that DMARC cannot
> > >describe, harm to the operation of mailing lists, and similar.
> > >
> > >It seems inconsistent to state with certainty that authorized mail will
> > >be rejected due to authentication breakage when there is no requirement
> > >that a reject policy be honored (and we have plenty of evidenc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On April 2, 2023 5:01:20 PM UTC, Alessandro Vesely  wrote:
>On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote:
>> On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely  wrote:
>>> On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote:
 On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely  wrote:
 
> Does that mean that instead of "non-transactional mail flows" we could say
> "mail flows involving decades old software"?
 
 If you're going to put that label on MLMs, we need to add it to MTAs too.
 Oh and most of the protocols we're talking about.
 
 This is a pretty deep rabbit hole.
>>> 
>>> Agreed.  Yet, did you notice, for example, the steady decrease of 
>>> X-MIME-Autoconverted breakage cases?  The hype on security sped up software 
>>> upgrading quite noticeably.
>> 
>> Yes, but it didn't actively make the software less useful, so it's not 
>> really relevant to this case.
>
>
>Eh?  Some auto-conversion filters were implemented by rather elegant filters 
>able to decode and/or encode on the fly based on peer's capabilities.  That 
>stuff became less useful, if that's what you mean...

Less needed maybe, but in any case not really the same thing.  That may have 
accelerated prioritization of technical resources to abate the issue, but in 
that case there's no negative impact to upgrading.  

Mailing list changes to ameliorate damage due to DMARC are in no way an 
improvement.  Absent DMARC, they would not be needed at all.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Fri 31/Mar/2023 18:16:28 +0200 Scott Kitterman wrote:

On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely  wrote:

On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote:

On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely  wrote:


Does that mean that instead of "non-transactional mail flows" we could say
"mail flows involving decades old software"?


If you're going to put that label on MLMs, we need to add it to MTAs too.
Oh and most of the protocols we're talking about.

This is a pretty deep rabbit hole.


Agreed.  Yet, did you notice, for example, the steady decrease of 
X-MIME-Autoconverted breakage cases?  The hype on security sped up software 
upgrading quite noticeably.


Yes, but it didn't actively make the software less useful, so it's not really 
relevant to this case.



Eh?  Some auto-conversion filters were implemented by rather elegant filters 
able to decode and/or encode on the fly based on peer's capabilities.  That 
stuff became less useful, if that's what you mean...



Best
Ale
--





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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On March 31, 2023 11:06:37 AM UTC, Alessandro Vesely  wrote:
>On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote:
>> On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely  wrote:
>> 
>>> Does that mean that instead of "non-transactional mail flows" we could say
>>> "mail flows involving decades old software"?
>> 
>> If you're going to put that label on MLMs, we need to add it to MTAs too.
>> Oh and most of the protocols we're talking about.
>> 
>> This is a pretty deep rabbit hole.
>
>
>Agreed.  Yet, did you notice, for example, the steady decrease of 
>X-MIME-Autoconverted breakage cases?  The hype on security sped up software 
>upgrading quite noticeably.
>
Yes, but it didn't actively make the software less useful, so it's not really 
relevant to this case.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

Douglas Foster wrote " My point was to only restate that "signed" is the
only truth that the DMARC policy can assert."

This is not true. If a sending domain provides a p=reject policy assertion
in their DMARC record, that is truth. They are not saying that fail always
means fraud. They are saying that mail which fails to pass either SPF or
DKIM is requested to be rejected (for whatever reason). Why do people keep
on trying to overload their personal interpretations on top of something
very simple and straight forward?

Michael Hammer

On Thu, Mar 30, 2023 at 11:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My point was to only restate that "signed" is the only truth that the
> DMARC policy can assert.The new prose needs to fix the false certainty
> that the old prose created.   But until this week, the group seemed ready
> to repeat the same mistake and use language which perpetuates the myth that
> FAIL always means fraud.   Maybe, but not certainly.   The difference is
> important.
>
> DF
>
>
> On Thu, Mar 30, 2023, 8:46 PM Murray S. Kucherawy 
> wrote:
>
>> On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> I would be happy with p=signed, because that is what p=reject means, and
>>> it is our job is to ensure that people interpret the signal correctly.
>>>
>>
>> Quoting the charter:
>>
>> "The working group will seek to preserve interoperability with the
>> installed base of DMARC systems, and provide detailed justification for any
>> non-interoperability."
>>
>> Changing one of the valid "p=" values seems to me to be the opposite of
>> "preserve interoperability with the installed base", so the bar is high to
>> make this change.
>>
>> Can the problem you're trying to address be handled in any other way?
>> Say, improved informational prose?
>>
>> -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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Fri 31/Mar/2023 02:41:19 +0200 Murray S. Kucherawy wrote:

On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely  wrote:


Does that mean that instead of "non-transactional mail flows" we could say
"mail flows involving decades old software"?


If you're going to put that label on MLMs, we need to add it to MTAs too.
Oh and most of the protocols we're talking about.

This is a pretty deep rabbit hole.



Agreed.  Yet, did you notice, for example, the steady decrease of 
X-MIME-Autoconverted breakage cases?  The hype on security sped up software 
upgrading quite noticeably.



Best
Ale
--




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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Fri, Mar 31, 2023 at 12:22 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My point was to only restate that "signed" is the only truth that the
> DMARC policy can assert.The new prose needs to fix the false certainty
> that the old prose created.   But until this week, the group seemed ready
> to repeat the same mistake and use language which perpetuates the myth that
> FAIL always means fraud.   Maybe, but not certainly.   The difference is
> important.
>

Do you have a specific text change you want to propose?

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

My point was to only restate that "signed" is the only truth that the DMARC
policy can assert.The new prose needs to fix the false certainty that
the old prose created.   But until this week, the group seemed ready to
repeat the same mistake and use language which perpetuates the myth that
FAIL always means fraud.   Maybe, but not certainly.   The difference is
important.

DF


On Thu, Mar 30, 2023, 8:46 PM Murray S. Kucherawy 
wrote:

> On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I would be happy with p=signed, because that is what p=reject means, and
>> it is our job is to ensure that people interpret the signal correctly.
>>
>
> Quoting the charter:
>
> "The working group will seek to preserve interoperability with the
> installed base of DMARC systems, and provide detailed justification for any
> non-interoperability."
>
> Changing one of the valid "p=" values seems to me to be the opposite of
> "preserve interoperability with the installed base", so the bar is high to
> make this change.
>
> Can the problem you're trying to address be handled in any other way?
> Say, improved informational prose?
>
> -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] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Thu, Mar 30, 2023 at 7:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I would be happy with p=signed, because that is what p=reject means, and
> it is our job is to ensure that people interpret the signal correctly.
>

Quoting the charter:

"The working group will seek to preserve interoperability with the
installed base of DMARC systems, and provide detailed justification for any
non-interoperability."

Changing one of the valid "p=" values seems to me to be the opposite of
"preserve interoperability with the installed base", so the bar is high to
make this change.

Can the problem you're trying to address be handled in any other way?  Say,
improved informational prose?

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Thu, Mar 30, 2023 at 8:41 PM Alessandro Vesely  wrote:

> Does that mean that instead of "non-transactional mail flows" we could say
> "mail flows involving decades old software"?
>

If you're going to put that label on MLMs, we need to add it to MTAs too.
Oh and most of the protocols we're talking about.

This is a pretty deep rabbit hole.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Thu 30/Mar/2023 01:44:42 +0200 Barry Leiba wrote:
There's no need for me to define it: I intentionally did not word my 
proposed text that way.  I think my proposed text is clear about who MUST 
NOT use p=reject and why... and, as I said in my response to Scott, I'm 
happy to add an explicit statement that it's an issue of interoperability 
with existing, decades-old mail flows.



Does that mean that instead of "non-transactional mail flows" we could say 
"mail flows involving decades old software"?



Best
Ale


On Thu, Mar 30, 2023 at 12:36 AM Todd Herr  wrote:


On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba 
wrote:


I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.

I contend that p=reject (as with the similar construct in the older ADSP)
was intended for high-value domains and transactional mail, and that it was
never intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.



I wonder if perhaps you might define "high-value domains" or restate your
position using a term other than "value" and its derivatives?

The reason I ask this is because your contention could perhaps be read as
"low-value domains MUST NOT use p=reject because their mail won't get to
its destination" and that seemingly ascribes a value to their mail that
might be considered somewhat higher than "low" in the eyes of some
beholders.


--

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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




___
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] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Thu 30/Mar/2023 04:01:10 +0200 Barry Leiba wrote:
Hooya’s use of p=reject would amount to announcing that policy, given how 
mailing list software works and has worked for decades.



Actually, that's how mailing list software has worked for decades, but not how 
it works now.



Best
Ale
--








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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

I would be happy with p=signed, because that is what p=reject means, and it
is our job is to ensure that people interpret the signal correctly.

But for those who believe (a) that sender policy is the problem and (b)
that the mailing lists should not be inconvenienced, there is a simple way
to force the issue.

"We are sorry, but your post to this list cannot be accepted because your
account is in listen-only mode.   This has become necessary because your
domain has published a DMARC policy which prevents us from making changes
to your post and then presenting the result as if it had been part of your
original submission.   To return to bi-directiional participation, you must
convince your domain to change its DMARC policy or change your subscription
to an email account on a different domain with a weaker DMARC policy."

Apparently universities acceded to this type of pressure.

I am not an alchemist that can make gold out of straw or make secure email
out of insecure practices.   The power to change a message in transit
includes the power to change it maliciously.   That makes it a privileged
function which requires prior authorization.   The only way to get that
permission is to ask for it from the evaluator, and to demonstrate to its
satisfaction that your messages can be trusted.

There is no reliable algorithm for reliably distinguishing mailing list
messages from all other messages, much less an algorithm for identifying
mailing list messages from trustworthy list sources.   In the absence of
that ideal, I cannot provide automatic privileges to mailing list
messages.   Lists are asking for the impossible.

DF

On Thu, Mar 30, 2023 at 12:45 AM Pete Resnick  wrote:

> On 30 Mar 2023, at 10:32, Douglas Foster wrote:
>
> > Here is a quick attempt at a definition:
> >
> > Interoperability:Two (or more) entities cooperating to achieve a
> > mutual
> > objective"
>
> Not quite. If a third party does something that causes failure even when
> two entities do cooperate on their mutual objective, that's still a
> failure of interoperability. Go again to the TCP retransmission example:
> If I violate the standard, I can cause you and someone else on the
> network who are behaving reasonably to fail in rather impressive ways
> (indeed, even taking down whole networks). Documenting interoperability
> also means documenting what intermediaries and ancillary players MUST
> and MUST NOT do.
>
> > Disruption
> >
> > If a message is blocked inappropriately, the responsibility falls on
> > the
> > entity that made the block decision, which is the recipient's
> > evaluator.
>
> No, that's not the way we write standards in the IETF. Compare: An SMTP
> sender definitely has to deal with the possibility of a connection
> closing unexpectedly, but the standard still says that an SMTP receiver
> "MUST NOT intentionally close the transmission channel until it receives
> and replies to a QUIT command (even if there was an error)", and we say
> that because we know that not doing so causes problems for some senders.
> Saying, "Hey, it's up to the senders to implement things properly" is
> all well and good, but we still put requirements on the other end in
> order to increase interoperability. So:
>
> > The sender's DMARC policy is an input to that decision, it has no
> > power of its own.
>
> Of course it has power of its own: It is interpreted. You can object to
> the way it is interpreted, but if we have operational experience that it
> is interpreted in particular ways that cause delivery failures that we
> expect should complete reasonably, then it is incumbent on us to
> document that some DMARC policies MUST NOT be used in certain
> circumstances with known failures. I understand that some people wish
> the IETF produced conformance standards, but that's not what we do. When
> we see running code that consistently produces bad results, we write the
> standard to document that state of affairs.
>
> > The previous and proposed DMARC specifications are misleading because
> > they
> > communicate false certainty.   The only thing that a sender can assert
> > is
> > that all of the messages originated by him will be properly signed by
> > him.
>
> Well, that's a bit misleading itself. The directive is not "p=signed".
> It is called "p=reject" for a reason, and that word is used elsewhere in
> the document. It carries meaning. The fact that it has been interpreted
> in a particular way should not be surprising. And given that historical
> interpretation, we now have an interoperability problem that needs to be
> documented appropriately.
>
> pr
> --
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Pete Resnick]

On 30 Mar 2023, at 10:32, Douglas Foster wrote:


Here is a quick attempt at a definition:

Interoperability:Two (or more) entities cooperating to achieve a 
mutual

objective"


Not quite. If a third party does something that causes failure even when 
two entities do cooperate on their mutual objective, that's still a 
failure of interoperability. Go again to the TCP retransmission example: 
If I violate the standard, I can cause you and someone else on the 
network who are behaving reasonably to fail in rather impressive ways 
(indeed, even taking down whole networks). Documenting interoperability 
also means documenting what intermediaries and ancillary players MUST 
and MUST NOT do.



Disruption

If a message is blocked inappropriately, the responsibility falls on 
the
entity that made the block decision, which is the recipient's 
evaluator.


No, that's not the way we write standards in the IETF. Compare: An SMTP 
sender definitely has to deal with the possibility of a connection 
closing unexpectedly, but the standard still says that an SMTP receiver 
"MUST NOT intentionally close the transmission channel until it receives 
and replies to a QUIT command (even if there was an error)", and we say 
that because we know that not doing so causes problems for some senders. 
Saying, "Hey, it's up to the senders to implement things properly" is 
all well and good, but we still put requirements on the other end in 
order to increase interoperability. So:


The sender's DMARC policy is an input to that decision, it has no 
power of its own.


Of course it has power of its own: It is interpreted. You can object to 
the way it is interpreted, but if we have operational experience that it 
is interpreted in particular ways that cause delivery failures that we 
expect should complete reasonably, then it is incumbent on us to 
document that some DMARC policies MUST NOT be used in certain 
circumstances with known failures. I understand that some people wish 
the IETF produced conformance standards, but that's not what we do. When 
we see running code that consistently produces bad results, we write the 
standard to document that state of affairs.


The previous and proposed DMARC specifications are misleading because 
they
communicate false certainty.   The only thing that a sender can assert 
is
that all of the messages originated by him will be properly signed by 
him.


Well, that's a bit misleading itself. The directive is not "p=signed". 
It is called "p=reject" for a reason, and that word is used elsewhere in 
the document. It carries meaning. The fact that it has been interpreted 
in a particular way should not be surprising. And given that historical 
interpretation, we now have an interoperability problem that needs to be 
documented appropriately.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Barry Leiba]

> Our spec needs to fix the evaluators, and their products, not the sender
policy.

No: it should be doing both.

Let’s look at it this way:

Suppose a general-use email provider called “Hooya” promulgated a policy
that said receiving domains should bounce any message from a hooya.com
sender that was fanned out to mailing list recipients.

I think that, worded that way, we would all agree it’s a bad idea.

If we were writing a policy spec of some sort and we were addressing this,
I think we should say BOTH that such a policy is inappropriate in that
would damage mailing list operation AND that receiving domains should not
be accommodating that policy.

Hooya’s use of p=reject would amount to announcing that policy, given how
mailing list software works and has worked for decades.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

Here is a quick attempt at a definition:

Interoperability:Two (or more) entities cooperating to achieve a mutual
objective"

Interoperability can perhaps be illustrated by design for a VPN tunnel or
other encryption mechanism:

1) You have to know the identity of the other party.  It does not matter
that you have transport security if you are sending your message to the bad
guys.  For VPN, this uses per-shared keys or digital certificates among
other options. For email, forwarding hides some of the originator's
identity, and forwarding with identity rewrite hides the rest.

2) You have to know if you have received all of the message/  If it has to
be broken into pieces for transmission, you need to find all the pieces and
reassemble them in order.   Transport protocols handle this well.

3) You have to know if the message or message component has been altered in
transit.   For VPN, "MAC" hash values demonstrate this.   For email, DKIM
verifies this.In either system, a failed hash is supposed to indicate
loss of trustworthiness.

4) You have to have an error recovery / exception management process.   For
VPN, this is retransmission.   For email, IETF has carefully avoided any
discussion of error recovery and exception management.   I don't know why.

Of course, trust would not be a problem is all email was wanted and
trustworthy.The forwarding problem exists because fraudulent mail
exists, and it is nearly impossible to distinguish a legitimate forwarded
message chain from a fraudulently constructed one.

Disruption

If a message is blocked inappropriately, the responsibility falls on the
entity that made the block decision, which is the recipient's evaluator.
 The sender's DMARC policy is an input to that decision, it has no power of
its own.

The previous and proposed DMARC specifications are misleading because they
communicate false certainty.   The only thing that a sender can assert is
that all of the messages originated by him will be properly signed by him.
 Even when that assertion is made, it may or may not be true.   But it
cannot say whether an unauthorized message was done for beneficial or
malicious purposes.   It cannot control whether a recipient decides to
forward the message.

In short, the damage happens because evaluators have been misled by the
specification, believing that all FAILs are malicious.   This is a
widespread and pernicious belief, which is created and sustained by IETF
documents.

The optimal handling of authentication failures is quarantine, followed by
a decision:   if the source is a malicious impersonation, block the current
and all future messages.   If the source is legitimate, create a local
policy which authenticates in place of the failed SPF or DMARC check.   In
either case, the disposition of future messages are unambiguous.

More specifically, the damage often comes from product developers who
develop to the specification, without a nuanced understanding of real world
filtering.   Without good options for handling exceptions, the system
administrators are hamstrung.

Our spec needs to fix the evaluators, and their products, not the sender
policy.

DF





--

On Wed, Mar 29, 2023 at 8:52 PM Murray S. Kucherawy 
wrote:

> On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> There is no interoperability problem.
>>
>
> How are you defining interoperability?
>
> "p=reject" when used on domains that send non-transactional messages
> disrupts interoperability of the email ecosystem in ways that are well
> documented.  This collateral damage is not trivial.
>
> There's no interoperability problem at the DMARC layer, sure.  But there's
> a bigger story we need to consider.
>
> An evaluator  has an unlimited right to block any incoming message for any
>> reason.
>>
> Specifically, an evaluator has the right to block any message which he
>> determines to be insufficiently authenticated.
>>
>
> An operator has every right to block DNS queries of types they don't like
> or don't recognize.  The choice to do so by some firewalls was the source
> of the problems behind the introduction of the SPF resource record.  That's
> a pretty broad kind of disruption that I would claim also shouldn't have
> been ignored or dismissed.  (See RFC 6686, Appendix A, for this story.)
>
>
>> If a sender wants a message to be accepted, he carries the burden of
>> earning the evaluator's trust.   He has no right to have his message
>> delivered.
>>
>> [...]
>>
>> If an evaluator blocks a message that a user considers acceptable, that
>> is a management issue between the user and the administrator.  It happens
>> all the time, and it is resolved through normal support processes.
>>
>
> I don't think anyone's arguing that.  But does the receiver in your
> scenario also have a right to impact the experiences of users not under
> their control?  If we're going to argue that the receiver's rights are the
> only thing that matter, we'd better

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> MUST seems to take us back to the unfinished debate of 3 years ago, where
>> some asserted that DMARC did more harm than good and should only be used
>> for transactional mail, which seemed to mean PayPal and not much else.
>
>Have we concluded that DMARC (or "reject" in particular) is now appropriate
>for use with non-transactional mail?

I haven't seen any objections to using it for bulk broadcast mail, but that
may be because the recipients don't care whether they get it.

The canonical example paypal sends rather odd mail, a high value domain
that sends only low value messages, since the only thing paypal sends
are variations on something happened, log in and check your account.

R's,
John

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Thu, Mar 30, 2023 at 7:30 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> There is no interoperability problem.
>

How are you defining interoperability?

"p=reject" when used on domains that send non-transactional messages
disrupts interoperability of the email ecosystem in ways that are well
documented.  This collateral damage is not trivial.

There's no interoperability problem at the DMARC layer, sure.  But there's
a bigger story we need to consider.

An evaluator  has an unlimited right to block any incoming message for any
> reason.
>
Specifically, an evaluator has the right to block any message which he
> determines to be insufficiently authenticated.
>

An operator has every right to block DNS queries of types they don't like
or don't recognize.  The choice to do so by some firewalls was the source
of the problems behind the introduction of the SPF resource record.  That's
a pretty broad kind of disruption that I would claim also shouldn't have
been ignored or dismissed.  (See RFC 6686, Appendix A, for this story.)


> If a sender wants a message to be accepted, he carries the burden of
> earning the evaluator's trust.   He has no right to have his message
> delivered.
>
> [...]
>
> If an evaluator blocks a message that a user considers acceptable, that is
> a management issue between the user and the administrator.  It happens all
> the time, and it is resolved through normal support processes.
>

I don't think anyone's arguing that.  But does the receiver in your
scenario also have a right to impact the experiences of users not under
their control?  If we're going to argue that the receiver's rights are the
only thing that matter, we'd better be able to explain why the collateral
damage is justifiable.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Barry Leiba]

There's no need for me to define it: I intentionally did not word my
proposed text that way.  I think my proposed text is clear about who MUST
NOT use p=reject and why... and, as I said in my response to Scott, I'm
happy to add an explicit statement that it's an issue of interoperability
with existing, decades-old mail flows.

Barry


On Thu, Mar 30, 2023 at 12:36 AM Todd Herr  wrote:

> On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba 
> wrote:
>
>> I'm very much against text such as this, as I think it encourages
>> deployments that are contrary to interoperability and to the intent of
>> p=reject.
>>
>> I contend that p=reject (as with the similar construct in the older ADSP)
>> was intended for high-value domains and transactional mail, and that it was
>> never intended for use in domains where general users send general email.
>>
>> I stand by the MUST NOT that I proposed.
>>
>>
> I wonder if perhaps you might define "high-value domains" or restate your
> position using a term other than "value" and its derivatives?
>
> The reason I ask this is because your contention could perhaps be read as
> "low-value domains MUST NOT use p=reject because their mail won't get to
> its destination" and that seemingly ascribes a value to their mail that
> might be considered somewhat higher than "low" in the eyes of some
> beholders.
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Barry Leiba]

I'm happy with that suggestion.

Barry

On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman  wrote:
>
> Would you feel any better if the MUST NOT was followed by 'to preserve 
> interoperability '?  That's implicitly there and I believe technically 
> correct.  If you value other properties of the system higher than 
> interoperability, then the advice may not apply, which is fine.
>
> Scott K
>
> On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex" 
>  wrote:
> >I’m just not sure how we determine what is high-value.
> >
> >comcast.com: p=reject
> >comcast.net: p=none
> >xfinity.com: p=quarantine
> >
> >The top one is corporate, middle is consumer, bottom is consumer (but not 
> >actually used) & customer comms (sub-domains).  They’re all used in various 
> >ways for internal messaging.  Should I tell our corporate admins that they 
> >need to no longer publish p=reject?  They’re violating the RFC by doing so?  
> >There are very few consumer-oriented messages that originate from 
> >comcast.com.  Are we doing it right?  It makes things a little harder when 
> >one of our employees wants to use a mailing list.  But that still feels like 
> >the right thing to do.
> >
> >If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating 
> >to domain owners what is in their best interests, regardless of our 
> >perceived value of their domain.
> >
> >--
> >Alex Brotman
> >Sr. Engineer, Anti-Abuse & Messaging Policy
> >Comcast
> >
> >From: dmarc  On Behalf Of Barry Leiba
> >Sent: Wednesday, March 29, 2023 10:15 AM
> >To: Todd Herr 
> >Cc: dmarc@ietf.org
> >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> >
> >I'm very much against text such as this, as I think it encourages 
> >deployments that are contrary to interoperability and to the intent of 
> >p=reject.
> >
> >I contend that p=reject (as with the similar construct in the older ADSP) 
> >was intended for high-value domains and transactional mail, and that it was 
> >never intended for use in domains where general users send general email.
> >
> >I stand by the MUST NOT that I proposed.
> >
> >Barry
> >
> >
> >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr 
> >mailto:40valimail@dmarc.ietf.org>>
> > wrote:
> >On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
> >mailto:resn...@episteme.net>> wrote:
> >
> >If you agree that interoperability is increased, then I'd suggest that you 
> >actually do agree that the proposed text is appropriate.
> >
> >
> >I don't know that I agree that interoperability is increased...
> >
> >I'm having trouble squaring proposed language that says "Domain owners MUST 
> >NOT publish p=reject because it breaks interoperability" with the following 
> >language from section 5.8:
> >
> >
> >Mail Receivers **MAY** choose to accept email that fails the DMARC
> >
> >mechanism check even if the published Domain Owner Assessment Policy
> >
> >is "reject". In particular, because of the considerations discussed
> >
> >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
> >
> >messages solely because of a published policy of "reject", but that
> >
> >they apply other knowledge and analysis to avoid situations such as
> >
> >rejection of legitimate messages sent in ways that DMARC cannot
> >describe, harm to the operation of mailing lists, and similar.
> >
> >It seems inconsistent to state with certainty that authorized mail will be 
> >rejected due to authentication breakage when there is no requirement that a 
> >reject policy be honored (and we have plenty of evidence that Mail Receivers 
> >are following the 'SHOULD NOT reject messages' guidance).
> >
> >Language that would be more consistent in guidance to the domain owners 
> >might look something like this:
> >
> >After careful analysis of the aggregate report data as described in section 
> >5.5.5
> >(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
> >policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's 
> >judgement,
> >unauthorized and deceptive use of its domain name in the RFC5322.From field 
> >puts
> >at risk the trust it has built with its recipients, then it is 
> >**RECOMMENDED** that
> >the Domain Owner make use of the p and/or sp tags to set policy to 
>

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Mark Alley]

I have a question for the group; I have read RFC7960, but I feel my 
question merits reiteration for those of us on this list (like me) that 
may have differing opinions on this topic from experience as a consumer 
of the standard, and having worked with many of these "general purpose" 
domains at p=reject.


The concern with interoperability with p=reject is that if, 
hypothetically, every domain on the internet were to go to p=reject 
right now, the damage would be tangible because many indirect and 
"non-DMARC described" mail flows would be prevented from delivery? 
(non-5322.FROM munging mail lists, some non-descript mail relays, a 
random mailbox forwarding, a non-DKIM preserving forwarding mail 
service, non-DKIM signed forwarded mail flows, etc. etc.) Is this a 
correct assessment behind the reasoning for the "MUST NOT" language?


I am concerned that others may see this language and perceive it as 
weakening the value of DMARC, or that DMARC should not be implemented at 
all, when there is a proven track record of many  
domains that have implemented strict policies to great effect in 
securing their domains without major issues.


-

Separately, from a "general purpose" domain owners perspective, I share 
Alex's thoughts. Having worked with many (extremely high volume) 
non-transactional domains at p=reject, the noticeable issues caused from 
p=reject has been negligible to these organizations.


Many of the mitigations from RFC7960 already apply to the traffic that 
would have otherwise been impacted by what would normally be considered 
an interoperability issue otherwise. That is not to say there is not 
/any/ impact from its implementation, but from an organizational 
standpoint, all the important messages are still delivered. There have 
been outliers, of course, but they are dealt with by the organizations 
on a case-by-case basis, which, to date, have been less than a handful.


- Mark Alley


On 3/29/2023 3:59 PM, Scott Kitterman wrote:

Would you feel any better if the MUST NOT was followed by 'to preserve 
interoperability '?  That's implicitly there and I believe technically correct. 
 If you value other properties of the system higher than interoperability, then 
the advice may not apply, which is fine.

Scott K

On March 29, 2023 3:32:10 PM UTC, "Brotman, 
Alex"  wrote:

I’m just not sure how we determine what is high-value.

comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine

The top one is corporate, middle is consumer, bottom is consumer (but not actually 
used) & customer comms (sub-domains).  They’re all used in various ways for 
internal messaging.  Should I tell our corporate admins that they need to no longer 
publish p=reject?  They’re violating the RFC by doing so?  There are very few 
consumer-oriented messages that originate from comcast.com.  Are we doing it right? 
 It makes things a little harder when one of our employees wants to use a mailing 
list.  But that still feels like the right thing to do.

If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to 
domain owners what is in their best interests, regardless of our perceived 
value of their domain.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr
Cc:dmarc@ietf.org
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I'm very much against text such as this, as I think it encourages deployments 
that are contrary to interoperability and to the intent of p=reject.

I contend that p=reject (as with the similar construct in the older ADSP) was 
intended for high-value domains and transactional mail, and that it was never 
intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
mailto:resn...@episteme.net>> wrote:

If you agree that interoperability is increased, then I'd suggest that you 
actually do agree that the proposed text is appropriate.


I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners MUST NOT 
publish p=reject because it breaks interoperability" with the following language 
from section 5.8:


Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject

messages solely because of a published policy of "reject", but that

they apply other knowledge and analysis to avoid situations such 

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

There is no interoperability problem.
An evaluator  has an unlimited right to block any incoming message for any
reason.
Specifically, an evaluator has the right to block any message which he
determines to be insufficiently authenticated.

If a sender wants a message to be accepted, he carries the burden of
earning the evaluator's trust.   He has no right to have his message
delivered.

An intermediary does not have a right to alter a message in transit and
still have it treated as if it had not been modified.Arguing that a
change is "innocuous" is not a viable argument.   Doing so would require a
before-and-after comparison (which is not available), and a
technical specification of "innocuous" (which does not exist.)

Interoperability only requires that the evaluator be given the opportunity
to evaluate the message, and to do so in a way that does not cause injury
to the submitting server.   It does not matter whether he blocks the sender
IP at his firewall, rejects the connection request at hello, rejects all
recipients on RCPT TO, rejects the message after DATA, or discards the
message after DATA.  As long as both parties implement RFC5321, we have
interoperability.

If an evaluator blocks a message that a user considers acceptable, that is
a management issue between the user and the administrator.  It happens all
the time, and it is resolved through normal support processes.

Doug Foster






On Wed, Mar 29, 2023 at 5:00 PM Scott Kitterman 
wrote:

> Would you feel any better if the MUST NOT was followed by 'to preserve
> interoperability '?  That's implicitly there and I believe technically
> correct.  If you value other properties of the system higher than
> interoperability, then the advice may not apply, which is fine.
>
> Scott K
>
> On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"  40comcast@dmarc.ietf.org> wrote:
> >I’m just not sure how we determine what is high-value.
> >
> >comcast.com: p=reject
> >comcast.net: p=none
> >xfinity.com: p=quarantine
> >
> >The top one is corporate, middle is consumer, bottom is consumer (but not
> actually used) & customer comms (sub-domains).  They’re all used in various
> ways for internal messaging.  Should I tell our corporate admins that they
> need to no longer publish p=reject?  They’re violating the RFC by doing
> so?  There are very few consumer-oriented messages that originate from
> comcast.com.  Are we doing it right?  It makes things a little harder
> when one of our employees wants to use a mailing list.  But that still
> feels like the right thing to do.
> >
> >If it’s not obvious, I’m having a hard time with “MUST NOT”, and
> dictating to domain owners what is in their best interests, regardless of
> our perceived value of their domain.
> >
> >--
> >Alex Brotman
> >Sr. Engineer, Anti-Abuse & Messaging Policy
> >Comcast
> >
> >From: dmarc  On Behalf Of Barry Leiba
> >Sent: Wednesday, March 29, 2023 10:15 AM
> >To: Todd Herr 
> >Cc: dmarc@ietf.org
> >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
> flows
> >
> >I'm very much against text such as this, as I think it encourages
> deployments that are contrary to interoperability and to the intent of
> p=reject.
> >
> >I contend that p=reject (as with the similar construct in the older ADSP)
> was intended for high-value domains and transactional mail, and that it was
> never intended for use in domains where general users send general email.
> >
> >I stand by the MUST NOT that I proposed.
> >
> >Barry
> >
> >
> >On Wed, Mar 29, 2023 at 10:33 PM Todd Herr  40valimail@dmarc.ietf.org<mailto:40valimail@dmarc.ietf.org>>
> wrote:
> >On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick  <mailto:resn...@episteme.net>> wrote:
> >
> >If you agree that interoperability is increased, then I'd suggest that
> you actually do agree that the proposed text is appropriate.
> >
> >
> >I don't know that I agree that interoperability is increased...
> >
> >I'm having trouble squaring proposed language that says "Domain owners
> MUST NOT publish p=reject because it breaks interoperability" with the
> following language from section 5.8:
> >
> >
> >Mail Receivers **MAY** choose to accept email that fails the DMARC
> >
> >mechanism check even if the published Domain Owner Assessment Policy
> >
> >is "reject". In particular, because of the considerations discussed
> >
> >in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
> >
> >messages solely because of a published policy of &quo

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

Would you feel any better if the MUST NOT was followed by 'to preserve 
interoperability '?  That's implicitly there and I believe technically correct. 
 If you value other properties of the system higher than interoperability, then 
the advice may not apply, which is fine.

Scott K

On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex" 
 wrote:
>I’m just not sure how we determine what is high-value.
>
>comcast.com: p=reject
>comcast.net: p=none
>xfinity.com: p=quarantine
>
>The top one is corporate, middle is consumer, bottom is consumer (but not 
>actually used) & customer comms (sub-domains).  They’re all used in various 
>ways for internal messaging.  Should I tell our corporate admins that they 
>need to no longer publish p=reject?  They’re violating the RFC by doing so?  
>There are very few consumer-oriented messages that originate from comcast.com. 
> Are we doing it right?  It makes things a little harder when one of our 
>employees wants to use a mailing list.  But that still feels like the right 
>thing to do.
>
>If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to 
>domain owners what is in their best interests, regardless of our perceived 
>value of their domain.
>
>--
>Alex Brotman
>Sr. Engineer, Anti-Abuse & Messaging Policy
>Comcast
>
>From: dmarc  On Behalf Of Barry Leiba
>Sent: Wednesday, March 29, 2023 10:15 AM
>To: Todd Herr 
>Cc: dmarc@ietf.org
>Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
>
>I'm very much against text such as this, as I think it encourages deployments 
>that are contrary to interoperability and to the intent of p=reject.
>
>I contend that p=reject (as with the similar construct in the older ADSP) was 
>intended for high-value domains and transactional mail, and that it was never 
>intended for use in domains where general users send general email.
>
>I stand by the MUST NOT that I proposed.
>
>Barry
>
>
>On Wed, Mar 29, 2023 at 10:33 PM Todd Herr 
>mailto:40valimail@dmarc.ietf.org>>
> wrote:
>On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
>mailto:resn...@episteme.net>> wrote:
>
>If you agree that interoperability is increased, then I'd suggest that you 
>actually do agree that the proposed text is appropriate.
>
>
>I don't know that I agree that interoperability is increased...
>
>I'm having trouble squaring proposed language that says "Domain owners MUST 
>NOT publish p=reject because it breaks interoperability" with the following 
>language from section 5.8:
>
>
>Mail Receivers **MAY** choose to accept email that fails the DMARC
>
>mechanism check even if the published Domain Owner Assessment Policy
>
>is "reject". In particular, because of the considerations discussed
>
>in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
>
>messages solely because of a published policy of "reject", but that
>
>they apply other knowledge and analysis to avoid situations such as
>
>rejection of legitimate messages sent in ways that DMARC cannot
>describe, harm to the operation of mailing lists, and similar.
>
>It seems inconsistent to state with certainty that authorized mail will be 
>rejected due to authentication breakage when there is no requirement that a 
>reject policy be honored (and we have plenty of evidence that Mail Receivers 
>are following the 'SHOULD NOT reject messages' guidance).
>
>Language that would be more consistent in guidance to the domain owners might 
>look something like this:
>
>After careful analysis of the aggregate report data as described in section 
>5.5.5
>(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
>policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's 
>judgement,
>unauthorized and deceptive use of its domain name in the RFC5322.From field 
>puts
>at risk the trust it has built with its recipients, then it is **RECOMMENDED** 
>that
>the Domain Owner make use of the p and/or sp tags to set policy to 
>'quarantine' or
>'reject' for those streams most at risk of loss of trust.
>
>If going that route, probably want to consider expanding on 5.5.5, too; I need 
>to think about it some more.
>
>--
>Todd Herr | Technical Director, Standards and Ecosystem
>e: todd.h...@valimail.com<mailto:todd.h...@valimail.com>
>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 recipie

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

Suppose we use your language.  Some domains will still reject your advice,
so evaluators still need to apply intelligence to their disposition
decisions, if they care about  pleasing their account holders.

Mailing lists take a calculated risk by forwarding with changes.  Doing so
creates a trust problem between the list and the recipient's evaluator.
DMARC does not create the problem, it merely gives it visibility.

It is not the originator's job to solve the intermediary's trust problem,
especiallysince attempting to do so will facilitate the malicious conduct
of others.

Our job is to document the potential impact of decisions made by each
party: sender, forwarder, and evaluator.   It is not our job to decide
which party's interess must be sacrificed for the benefit of the other
participants

DF

On Wed, Mar 29, 2023, 10:15 AM Barry Leiba  wrote:

> I'm very much against text such as this, as I think it encourages
> deployments that are contrary to interoperability and to the intent of
> p=reject.
>
> I contend that p=reject (as with the similar construct in the older ADSP)
> was intended for high-value domains and transactional mail, and that it was
> never intended for use in domains where general users send general email.
>
> I stand by the MUST NOT that I proposed.
>
> Barry
>
>
> On Wed, Mar 29, 2023 at 10:33 PM Todd Herr  40valimail@dmarc.ietf.org> wrote:
>
>> On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
>> wrote:
>>
>>> If you agree that interoperability is increased, then I'd suggest that
>>> you actually do agree that the proposed text is appropriate.
>>>
>>>
>>> I don't know that I agree that interoperability is increased...
>>
>> I'm having trouble squaring proposed language that says "Domain owners
>> MUST NOT publish p=reject because it breaks interoperability" with the
>> following language from section 5.8:
>>
>> Mail Receivers **MAY** choose to accept email that fails the DMARC
>>
>> mechanism check even if the published Domain Owner Assessment Policy
>>
>> is "reject". In particular, because of the considerations discussed
>>
>> in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
>>
>> messages solely because of a published policy of "reject", but that
>>
>> they apply other knowledge and analysis to avoid situations such as
>>
>> rejection of legitimate messages sent in ways that DMARC cannot
>> describe, harm to the operation of mailing lists, and similar.
>>
>>
>> It seems inconsistent to state with certainty that authorized mail will
>> be rejected due to authentication breakage when there is no requirement
>> that a reject policy be honored (and we have plenty of evidence that Mail
>> Receivers are following the 'SHOULD NOT reject messages' guidance).
>>
>> Language that would be more consistent in guidance to the domain owners
>> might look something like this:
>>
>> After careful analysis of the aggregate report data as described in
>> section 5.5.5
>>
>> (Collect and Analyze Reports), Domain Owners **MAY** choose to change
>> their
>> policy from 'none' to 'quarantine' or 'reject'. If, in the Domain
>> Owner's judgement,
>>
>> unauthorized and deceptive use of its domain name in the RFC5322.From
>> field puts
>>
>> at risk the trust it has built with its recipients, then it is
>> **RECOMMENDED** that
>>
>> the Domain Owner make use of the p and/or sp tags to set policy to
>> 'quarantine' or
>>
>> 'reject' for those streams most at risk of loss of trust.
>>
>>
>> If going that route, probably want to consider expanding on 5.5.5, too; I
>> need to think about it some more.
>>
>> --
>>
>> *Todd Herr * | Technical Director, Standards and Ecosystem
>> *e:* todd.h...@valimail.com
>> *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
>>
> ___
> 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] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Wed 29/Mar/2023 15:25:19 +0200 Murray S. Kucherawy wrote:

On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster wrote:

MUST seems to take us back to the unfinished debate of 3 years ago, where 
some asserted that DMARC did more harm than good and should only be used 
for transactional mail, which seemed to mean PayPal and not much else.


Have we concluded that DMARC (or "reject" in particular) is now appropriate 
for use with non-transactional mail?



Not yet.

Anyway, receiver-side forwarding (with possible footer additions e.g. by 
anti-virus) make the transactional vs. human distinction not so much significant.



Best
Ale
--







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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Todd Herr]

On Wed, Mar 29, 2023 at 10:15 AM Barry Leiba 
wrote:

> I'm very much against text such as this, as I think it encourages
> deployments that are contrary to interoperability and to the intent of
> p=reject.
>
> I contend that p=reject (as with the similar construct in the older ADSP)
> was intended for high-value domains and transactional mail, and that it was
> never intended for use in domains where general users send general email.
>
> I stand by the MUST NOT that I proposed.
>
>
I wonder if perhaps you might define "high-value domains" or restate your
position using a term other than "value" and its derivatives?

The reason I ask this is because your contention could perhaps be read as
"low-value domains MUST NOT use p=reject because their mail won't get to
its destination" and that seemingly ascribes a value to their mail that
might be considered somewhat higher than "low" in the eyes of some
beholders.


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

I’m just not sure how we determine what is high-value.

comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine

The top one is corporate, middle is consumer, bottom is consumer (but not 
actually used) & customer comms (sub-domains).  They’re all used in various 
ways for internal messaging.  Should I tell our corporate admins that they need 
to no longer publish p=reject?  They’re violating the RFC by doing so?  There 
are very few consumer-oriented messages that originate from comcast.com.  Are 
we doing it right?  It makes things a little harder when one of our employees 
wants to use a mailing list.  But that still feels like the right thing to do.

If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to 
domain owners what is in their best interests, regardless of our perceived 
value of their domain.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I'm very much against text such as this, as I think it encourages deployments 
that are contrary to interoperability and to the intent of p=reject.

I contend that p=reject (as with the similar construct in the older ADSP) was 
intended for high-value domains and transactional mail, and that it was never 
intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
mailto:resn...@episteme.net>> wrote:

If you agree that interoperability is increased, then I'd suggest that you 
actually do agree that the proposed text is appropriate.


I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners MUST NOT 
publish p=reject because it breaks interoperability" with the following 
language from section 5.8:


Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject

messages solely because of a published policy of "reject", but that

they apply other knowledge and analysis to avoid situations such as

rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.

It seems inconsistent to state with certainty that authorized mail will be 
rejected due to authentication breakage when there is no requirement that a 
reject policy be honored (and we have plenty of evidence that Mail Receivers 
are following the 'SHOULD NOT reject messages' guidance).

Language that would be more consistent in guidance to the domain owners might 
look something like this:

After careful analysis of the aggregate report data as described in section 
5.5.5
(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's 
judgement,
unauthorized and deceptive use of its domain name in the RFC5322.From field puts
at risk the trust it has built with its recipients, then it is **RECOMMENDED** 
that
the Domain Owner make use of the p and/or sp tags to set policy to 'quarantine' 
or
'reject' for those streams most at risk of loss of trust.

If going that route, probably want to consider expanding on 5.5.5, too; I need 
to think about it some more.

--
Todd Herr | Technical Director, Standards and Ecosystem
e: todd.h...@valimail.com<mailto:todd.h...@valimail.com>
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<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Barry Leiba]

I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.

I contend that p=reject (as with the similar construct in the older ADSP)
was intended for high-value domains and transactional mail, and that it was
never intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr  wrote:

> On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick  wrote:
>
>> If you agree that interoperability is increased, then I'd suggest that
>> you actually do agree that the proposed text is appropriate.
>>
>>
>> I don't know that I agree that interoperability is increased...
>
> I'm having trouble squaring proposed language that says "Domain owners
> MUST NOT publish p=reject because it breaks interoperability" with the
> following language from section 5.8:
>
> Mail Receivers **MAY** choose to accept email that fails the DMARC
>
> mechanism check even if the published Domain Owner Assessment Policy
>
> is "reject". In particular, because of the considerations discussed
>
> in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
>
> messages solely because of a published policy of "reject", but that
>
> they apply other knowledge and analysis to avoid situations such as
>
> rejection of legitimate messages sent in ways that DMARC cannot
> describe, harm to the operation of mailing lists, and similar.
>
>
> It seems inconsistent to state with certainty that authorized mail will be
> rejected due to authentication breakage when there is no requirement that a
> reject policy be honored (and we have plenty of evidence that Mail
> Receivers are following the 'SHOULD NOT reject messages' guidance).
>
> Language that would be more consistent in guidance to the domain owners
> might look something like this:
>
> After careful analysis of the aggregate report data as described in
> section 5.5.5
>
> (Collect and Analyze Reports), Domain Owners **MAY** choose to change
> their
> policy from 'none' to 'quarantine' or 'reject'. If, in the Domain
> Owner's judgement,
>
> unauthorized and deceptive use of its domain name in the RFC5322.From
> field puts
>
> at risk the trust it has built with its recipients, then it is
> **RECOMMENDED** that
>
> the Domain Owner make use of the p and/or sp tags to set policy to
> 'quarantine' or
>
> 'reject' for those streams most at risk of loss of trust.
>
>
> If going that route, probably want to consider expanding on 5.5.5, too; I
> need to think about it some more.
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *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
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Todd Herr]

On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick  wrote:

> If you agree that interoperability is increased, then I'd suggest that you
> actually do agree that the proposed text is appropriate.
>
>
> I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners MUST
NOT publish p=reject because it breaks interoperability" with the following
language from section 5.8:

Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject

messages solely because of a published policy of "reject", but that

they apply other knowledge and analysis to avoid situations such as

rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.


It seems inconsistent to state with certainty that authorized mail will be
rejected due to authentication breakage when there is no requirement that a
reject policy be honored (and we have plenty of evidence that Mail
Receivers are following the 'SHOULD NOT reject messages' guidance).

Language that would be more consistent in guidance to the domain owners
might look something like this:

After careful analysis of the aggregate report data as described in section
5.5.5

(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
policy from 'none' to 'quarantine' or 'reject'. If, in the Domain
Owner's judgement,

unauthorized and deceptive use of its domain name in the RFC5322.From field
puts

at risk the trust it has built with its recipients, then it is
**RECOMMENDED** that

the Domain Owner make use of the p and/or sp tags to set policy to
'quarantine' or

'reject' for those streams most at risk of loss of trust.


If going that route, probably want to consider expanding on 5.5.5, too; I
need to think about it some more.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Wed, Mar 29, 2023 at 7:18 PM Alessandro Vesely  wrote:

> I'd mention indirect mail flows explicitly, rather than referring to
> generic
> interoperability problems.  But several mailing list adopted expedients in
> order to overcome those problems.  Furthermore, there are experimental
> protocols that address the issue maintaining the end-to-end nature of
> existing
> identifier fields, and more are going to come.  It is possible that a
> future
> ecosystem will support strict DMARC policies for everyone.  Thus it is a
> "MUST
> until" rather than unless.  Is that compliant with RFC 2119?
>

I don't think I've ever seen an RFC published that uses a "MUST until" kind
of construct.  Since we can't predict the future, and since this document
doesn't acknowledge any of the external mitigations to which you refer (in
particular, it doesn't reference ARC), I don't think it should try.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Murray S. Kucherawy]

On Wed, Mar 29, 2023 at 8:59 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> MUST seems to take us back to the unfinished debate of 3 years ago, where
> some asserted that DMARC did more harm than good and should only be used
> for transactional mail, which seemed to mean PayPal and not much else.
>

Have we concluded that DMARC (or "reject" in particular) is now appropriate
for use with non-transactional mail?

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

MUST seems to take us back to the unfinished debate of 3 years ago, where
some asserted that DMARC did more harm than good and should only be used
for transactional mail, which seemed to mean PayPal and not much else.

On Wed, Mar 29, 2023, 6:18 AM Alessandro Vesely  wrote:

> On Tue 28/Mar/2023 10:15:04 +0200 Barry Leiba wrote:
> > I raised this issue in the DMARC session in Vienna, and have let it
> > sit for a while so as not to derail other discussion.  As we're pretty
> > close to finished with the DMARCbis document, I'd like to raise it
> > again, this time with specific proposed text for us to discuss.
> >
> > And so:
> >
> > OLD
> >
> > 5.5.6.  Decide If and When to Update DMARC Policy
> >
> > Once the Domain Owner is satisfied that it is properly authenticating
> > all of its mail, then it is time to decide if it is appropriate to
> > change the p= value in its DMARC record to p=quarantine or p=reject.
> > Depending on its cadence for sending mail, it may take many months of
> > consuming DMARC aggregate reports before a Domain Owner reaches the
> > point where it is sure that it is properly authenticating all of its
> > mail, and the decision on which p= value to use will depend on its
> > needs.
> >
> > NEW
> >
> > 5.5.6.  Decide If and When to Update DMARC Policy
> >
> > Once the Domain Owner is satisfied that it is properly authenticating
> > all of its mail, then it is time to decide if it is appropriate to
> > change the p= value in its DMARC record to p=quarantine or p=reject.
> > Depending on its cadence for sending mail, it may take many months of
> > consuming DMARC aggregate reports before a Domain Owner reaches the
> > point where it is sure that it is properly authenticating all of its
> > mail, and the decision on which p= value to use will depend on its
> > needs.
> >
> > It is important to understand that many domains may never use
> > policies of “quarantine” or “reject”, and that these policies are
> > intended not as goals, but as policies available for use when they
> > are appropriate.  In particular, “reject” is not intended for
> > deployment in domains with users who send routine email, and its
> > deployment in such domains can disrupt indirect mail flows and cause
> > damage to operation of mailing lists and other forwarding services.
> > This is discussed in [RFC7960] and in Section 5.8, below.  The
> > “reject” policy is best reserved for domains that send only
> > transactional email that is not intended to be posted to mailing
> > lists.
> >
> > To be explicitly clear: domains used for general-purpose email MUST
> > NOT deploy a DMARC policy of p=reject.
> >
> > END
> >
> > I'm well aware that the MUST will *not* be followed by everyone, and
> > that some domain owners will feel that they need to use p=reject,
> > regardless.  I think that's fine: the standard should specify what's
> > right for interoperability, and I believe that improper use of
> > p=reject is extremely harmful to interoperability... so "MUST" is
> > correct here.  And no one will be arrested or fined for choosing not
> > to follow it.  We should still say it, nonetheless.
>
>
> I think I grasped Pete's point that MUST is appropriate here even if some
> domain owners do otherwise.  If we wanted to say "MUST unless" then we
> ought to
> say SHOULD, but this is not the case.
>
> General purpose domains, and some well known freemail providers, should
> never
> have set strict policies.  Yet, they did.  No clear wording is going to be
> able
> to correct that practice.  Cannot push the genius back into the bottle.
>
> I'd mention indirect mail flows explicitly, rather than referring to
> generic
> interoperability problems.  But several mailing list adopted expedients in
> order to overcome those problems.  Furthermore, there are experimental
> protocols that address the issue maintaining the end-to-end nature of
> existing
> identifier fields, and more are going to come.  It is possible that a
> future
> ecosystem will support strict DMARC policies for everyone.  Thus it is a
> "MUST
> until" rather than unless.  Is that compliant with RFC 2119?
>
>
> 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] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely]

On Tue 28/Mar/2023 10:15:04 +0200 Barry Leiba wrote:

I raised this issue in the DMARC session in Vienna, and have let it
sit for a while so as not to derail other discussion.  As we're pretty
close to finished with the DMARCbis document, I'd like to raise it
again, this time with specific proposed text for us to discuss.

And so:

OLD

5.5.6.  Decide If and When to Update DMARC Policy

Once the Domain Owner is satisfied that it is properly authenticating
all of its mail, then it is time to decide if it is appropriate to
change the p= value in its DMARC record to p=quarantine or p=reject.
Depending on its cadence for sending mail, it may take many months of
consuming DMARC aggregate reports before a Domain Owner reaches the
point where it is sure that it is properly authenticating all of its
mail, and the decision on which p= value to use will depend on its
needs.

NEW

5.5.6.  Decide If and When to Update DMARC Policy

Once the Domain Owner is satisfied that it is properly authenticating
all of its mail, then it is time to decide if it is appropriate to
change the p= value in its DMARC record to p=quarantine or p=reject.
Depending on its cadence for sending mail, it may take many months of
consuming DMARC aggregate reports before a Domain Owner reaches the
point where it is sure that it is properly authenticating all of its
mail, and the decision on which p= value to use will depend on its
needs.

It is important to understand that many domains may never use
policies of “quarantine” or “reject”, and that these policies are
intended not as goals, but as policies available for use when they
are appropriate.  In particular, “reject” is not intended for
deployment in domains with users who send routine email, and its
deployment in such domains can disrupt indirect mail flows and cause
damage to operation of mailing lists and other forwarding services.
This is discussed in [RFC7960] and in Section 5.8, below.  The
“reject” policy is best reserved for domains that send only
transactional email that is not intended to be posted to mailing
lists.

To be explicitly clear: domains used for general-purpose email MUST
NOT deploy a DMARC policy of p=reject.

END

I'm well aware that the MUST will *not* be followed by everyone, and
that some domain owners will feel that they need to use p=reject,
regardless.  I think that's fine: the standard should specify what's
right for interoperability, and I believe that improper use of
p=reject is extremely harmful to interoperability... so "MUST" is
correct here.  And no one will be arrested or fined for choosing not
to follow it.  We should still say it, nonetheless.



I think I grasped Pete's point that MUST is appropriate here even if some 
domain owners do otherwise.  If we wanted to say "MUST unless" then we ought to 
say SHOULD, but this is not the case.


General purpose domains, and some well known freemail providers, should never 
have set strict policies.  Yet, they did.  No clear wording is going to be able 
to correct that practice.  Cannot push the genius back into the bottle.


I'd mention indirect mail flows explicitly, rather than referring to generic 
interoperability problems.  But several mailing list adopted expedients in 
order to overcome those problems.  Furthermore, there are experimental 
protocols that address the issue maintaining the end-to-end nature of existing 
identifier fields, and more are going to come.  It is possible that a future 
ecosystem will support strict DMARC policies for everyone.  Thus it is a "MUST 
until" rather than unless.  Is that compliant with RFC 2119?



Best
Ale
--





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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On March 29, 2023 4:49:16 AM UTC, John Levine  wrote:
>It appears that Dotzero   said:
>>I agree with Scott on this.  I don't believe that "open signup" domains
>>deserve this special call out in this manner. ...
>
>The only way to get an account on my system is to know me personally,
>but my human users have the same issues as Gmail's or Yahoo's. They're
>people, they send mail in various ways, some of which DMARC can't describe.
>
I'll hazard a guess that they send mail to human users who receive mail in 
various ways that they don't even know about and which DMARC can't describe.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[John Levine]

It appears that Dotzero   said:
>I agree with Scott on this.  I don't believe that "open signup" domains
>deserve this special call out in this manner. ...

The only way to get an account on my system is to know me personally,
but my human users have the same issues as Gmail's or Yahoo's. They're
people, they send mail in various ways, some of which DMARC can't describe.

R's,
John

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Douglas Foster]

Are we trying to define a protocol that evaluators can follow automatically
without ever making any mistakes?   I am not.

It is simply wrong to assume that changes-in-transit are the only cause of
DMARC Fail on acceptable messages.If you work with a mailstream, you
should be aware of these other causes, which are probably more important,
because they have universal applicability:

   - Benevolent impersonation by trusted entities
   - Overzealous implementation of DMARC before all messages have DKIM
   signature
   - Software errors that cause outbound signatures to be missing or
   unverifiable (a variant of the previous)

If we say, "DMARC should only be implemented by domains where FAIL will
never occur on an acceptable message", then there are few domains that can
use DMARC, and the value of the protocol vanishes.

If DMARC FAIL could actually mean that a message source is certainly
malicious, then the necessary response is much more than blocking one
message.   A competent administrator must block all messages from a source
known to be malicious.It would be reckless to reject malicious
impersonations while accepting malicious messages that are not
impersonations.   But recklessly blocking message sources based on an
automated DMARC FAIL would multiply the mistakes.

The flip side of this topic is an implicit assumption that acceptable
p=none messages will never be discarded because the evaluator will not
enforce authentication.   Similarly, an assumption that No Policy messages
will never be discarded because the evaluator cannot enforce
authentication.   The domain owner does not eliminate risks by avoiding
DMARC, he merely chooses different risks.

For the current topic, we need language that says simply:
- Evaluators need to be cautious about blocking messages exclusively on
DMARC results, as acceptable messages may be blocked sometimes.
and
- Domain owners need to be cautious when setting DMARC policy to reject,
because acceptable messages may not appear authenticated when they are
received by the evaluator, and some evaluators may block on DMARC results
alone..

The evaluator is the most important part of the DMARC process.   If we want
optimal results, we need to give him the guidance needed to make optimal
decisions.

Doug Foster



On Tue, Mar 28, 2023 at 4:15 AM Barry Leiba  wrote:

> I raised this issue in the DMARC session in Vienna, and have let it
> sit for a while so as not to derail other discussion.  As we're pretty
> close to finished with the DMARCbis document, I'd like to raise it
> again, this time with specific proposed text for us to discuss.
>
> And so:
>
> OLD
>
>5.5.6.  Decide If and When to Update DMARC Policy
>
>Once the Domain Owner is satisfied that it is properly authenticating
>all of its mail, then it is time to decide if it is appropriate to
>change the p= value in its DMARC record to p=quarantine or p=reject.
>Depending on its cadence for sending mail, it may take many months of
>consuming DMARC aggregate reports before a Domain Owner reaches the
>point where it is sure that it is properly authenticating all of its
>mail, and the decision on which p= value to use will depend on its
>needs.
>
> NEW
>
>5.5.6.  Decide If and When to Update DMARC Policy
>
>Once the Domain Owner is satisfied that it is properly authenticating
>all of its mail, then it is time to decide if it is appropriate to
>change the p= value in its DMARC record to p=quarantine or p=reject.
>Depending on its cadence for sending mail, it may take many months of
>consuming DMARC aggregate reports before a Domain Owner reaches the
>point where it is sure that it is properly authenticating all of its
>mail, and the decision on which p= value to use will depend on its
>needs.
>
>It is important to understand that many domains may never use
>policies of “quarantine” or “reject”, and that these policies are
>intended not as goals, but as policies available for use when they
>are appropriate.  In particular, “reject” is not intended for
>deployment in domains with users who send routine email, and its
>deployment in such domains can disrupt indirect mail flows and cause
>damage to operation of mailing lists and other forwarding services.
>This is discussed in [RFC7960] and in Section 5.8, below.  The
>“reject” policy is best reserved for domains that send only
>transactional email that is not intended to be posted to mailing
>lists.
>
>To be explicitly clear: domains used for general-purpose email MUST
>NOT deploy a DMARC policy of p=reject.
>
> END
>
> I'm well aware that the MUST will *not* be followed by everyone, and
> that some domain owners will feel that they need to use p=reject,
> regardless.  I think that's fine: the standard should specify what's
> right for interoperability, and I believe that improper use of
> p=reject is extremely harmful to interoperability... so "

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Pete Resnick]

On 29 Mar 2023, at 5:20, Todd Herr wrote:

In my estimation, the language you propose here establishes the 
primacy of interoperability over the needs/wishes of the domain 
owner. 


As is appropriate for such normative language. From RFC 2119:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

My preference is for language that acknowledges the primacy of the 
domain owner over interoperability.


Not only ought there not be primacy of the needs/wishes of the domain 
owner over interoperability, the IETF has repeatedly rejected such a 
principle. An implementer might decide to implement a security backdoor, 
but our protocol documents say that you MUST NOT do that. An implementer 
might decide to violate TCP retransmission timer requirements to get 
better performance, but our protocol documents say that you MUST NOT do 
that. We document interoperability; we do not give primacy to the wishes 
of of domain owners.


If you agree that interoperability is increased, then I'd suggest that 
you actually do agree that the proposed text is appropriate.


pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

I think it's much closer to acceptable in theoretical cases which are unlikely 
to exist now, but may be okay in the future, but it will be difficult to know.

It's perfectly fine for a domain owner to accept this and take the risk, but we 
shouldn't even try to pretend there aren't issues.

Scott K

On March 28, 2023 8:21:43 PM UTC, "Brotman, Alex" 
 wrote:
>There may need to be a bit more clarification around the use of sp= in these 
>cases.  "We are telling you that p=reject is harmful, but sp=q/r is acceptable 
>in many cases, where these conditions are satisfied".
>
>
>
>--
>Alex Brotman
>Sr. Engineer, Anti-Abuse & Messaging Policy
>Comcast
>
>> -Original Message-
>> From: dmarc  On Behalf Of Scott Kitterman
>> Sent: Tuesday, March 28, 2023 4:01 PM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
>> 
>> On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
>> > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman 
>> >
>> > wrote:
>> > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
>> > > > NEW
>> > > >
>> > > >5.5.6.  Decide If and When to Update DMARC Policy
>> > > >
>> > > >Once the Domain Owner is satisfied that it is properly 
>> > > > authenticating
>> > > >all of its mail, then it is time to decide if it is appropriate to
>> > > >change the p= value in its DMARC record to p=quarantine or p=reject.
>> > > >Depending on its cadence for sending mail, it may take many months 
>> > > > of
>> > > >consuming DMARC aggregate reports before a Domain Owner reaches
>> the
>> > > >point where it is sure that it is properly authenticating all of its
>> > > >mail, and the decision on which p= value to use will depend on its
>> > > >needs.
>> > > >
>> > > >It is important to understand that many domains may never use
>> > > >policies of “quarantine” or “reject”, and that these policies are
>> > > >intended not as goals, but as policies available for use when they
>> > > >are appropriate.  In particular, “reject” is not intended for
>> > > >deployment in domains with users who send routine email, and its
>> > > >deployment in such domains can disrupt indirect mail flows and cause
>> > > >damage to operation of mailing lists and other forwarding services.
>> > > >This is discussed in [RFC7960] and in Section 5.8, below.  The
>> > > >“reject” policy is best reserved for domains that send only
>> > > >transactional email that is not intended to be posted to mailing
>> > > >lists.
>> > > >
>> > > >To be explicitly clear: domains used for general-purpose email MUST
>> > > >NOT deploy a DMARC policy of p=reject.
>> > > >
>> > > > END
>> > >
>> > > [snip]
>> > >
>> > > How about, "... MUST NOT deploy a DMARC policy other than p=none
>> > > because improper used of p=reject or (to a slightly lesser exent)
>> > > p=quarantine is extremely harmful to email interoperability."
>> >
>> > Or, "...MUST NOT deploy a DMARC policy other than p=none because
>> > improper use of p=reject or (to a slightly lesser extent) p=quarantine
>> > is extremely harmful to email interoperability. Such improper use
>> > includes, but is not limited to, cases where the mitigation strategies
>> > discussed in RFCs 7960 and 8617 and elsewhere are not deployed for the
>> > mail flows in question and cases where the domain owner deems the
>> > collateral damage as acceptable loss in service of protecting its
>> > domain from unauthorized usage."
>> >
>> > I suspect that my text above won't go over well, but the use of the
>> > term "improper use" smacks, to me, of the IETF being the protocol
>> > police, and I've been led to believe that's not what we do here.
>> >
>> > There are many things I believe, and two of them are these:
>> >
>> >1. Any domain is a target to be spoofed
>> >2. The custodian of a thing has the autonomy to do with that thing what
>> >they please, so long as it's within the limits of the law. "My
>> > network, my rules" as it w

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On March 28, 2023 8:20:54 PM UTC, Todd Herr 
 wrote:
>On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman 
>wrote:
>
>>
>> "...MUST NOT deploy a DMARC policy other than p=none because use of
>> p=reject
>> or (to a slightly lesser extent) p=quarantine for such domains is
>> extremely
>> harmful to email interoperability.  Mitigation strategies are discussed in
>> [RFC 7960] and [RFC 8617]."
>>
>> I don't think we need to reiterate what p=reject does here, that's
>> extensively
>> addressed elsewhere in the document.  I don't think we have enough data to
>> opine either way about the effectiveness of such strategies, so it's
>> enough to
>> point at them here.  We don't currently list RFC 8617 as a reference.  I
>> think
>> introducing an informative reference here is useful.  It's experimental,
>> so we
>> definitely don't want to put any normative language around it.
>>
>> I suspect that's probably not what you would find ideal (it's not what I
>> would
>> find ideal either, but I can live with it).  Can you live with it?  What
>> do
>> others think?
>>
>>
>In my estimation, the language you propose here establishes the primacy of
>interoperability over the needs/wishes of the domain owner.
>
>My preference is for language that acknowledges the primacy of the domain
>owner over interoperability.
>
>I don't have time tonight to propose alternative text, but I wanted to
>acknowledge that I've read your message and make a promise to propose
>alternative text tomorrow.

Yes, but that's what RFCs are for.  Thanks for replying.

Scott K

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

There may need to be a bit more clarification around the use of sp= in these 
cases.  "We are telling you that p=reject is harmful, but sp=q/r is acceptable 
in many cases, where these conditions are satisfied".



--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 4:01 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman 
> >
> > wrote:
> > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> > > > NEW
> > > >
> > > >5.5.6.  Decide If and When to Update DMARC Policy
> > > >
> > > >Once the Domain Owner is satisfied that it is properly authenticating
> > > >all of its mail, then it is time to decide if it is appropriate to
> > > >change the p= value in its DMARC record to p=quarantine or p=reject.
> > > >Depending on its cadence for sending mail, it may take many months of
> > > >consuming DMARC aggregate reports before a Domain Owner reaches
> the
> > > >point where it is sure that it is properly authenticating all of its
> > > >mail, and the decision on which p= value to use will depend on its
> > > >needs.
> > > >
> > > >It is important to understand that many domains may never use
> > > >policies of “quarantine” or “reject”, and that these policies are
> > > >intended not as goals, but as policies available for use when they
> > > >are appropriate.  In particular, “reject” is not intended for
> > > >deployment in domains with users who send routine email, and its
> > > >deployment in such domains can disrupt indirect mail flows and cause
> > > >damage to operation of mailing lists and other forwarding services.
> > > >This is discussed in [RFC7960] and in Section 5.8, below.  The
> > > >“reject” policy is best reserved for domains that send only
> > > >transactional email that is not intended to be posted to mailing
> > > >lists.
> > > >
> > > >To be explicitly clear: domains used for general-purpose email MUST
> > > >NOT deploy a DMARC policy of p=reject.
> > > >
> > > > END
> > >
> > > [snip]
> > >
> > > How about, "... MUST NOT deploy a DMARC policy other than p=none
> > > because improper used of p=reject or (to a slightly lesser exent)
> > > p=quarantine is extremely harmful to email interoperability."
> >
> > Or, "...MUST NOT deploy a DMARC policy other than p=none because
> > improper use of p=reject or (to a slightly lesser extent) p=quarantine
> > is extremely harmful to email interoperability. Such improper use
> > includes, but is not limited to, cases where the mitigation strategies
> > discussed in RFCs 7960 and 8617 and elsewhere are not deployed for the
> > mail flows in question and cases where the domain owner deems the
> > collateral damage as acceptable loss in service of protecting its
> > domain from unauthorized usage."
> >
> > I suspect that my text above won't go over well, but the use of the
> > term "improper use" smacks, to me, of the IETF being the protocol
> > police, and I've been led to believe that's not what we do here.
> >
> > There are many things I believe, and two of them are these:
> >
> >1. Any domain is a target to be spoofed
> >2. The custodian of a thing has the autonomy to do with that thing what
> >they please, so long as it's within the limits of the law. "My
> > network, my rules" as it were (or "Your network, your rules")
> >
> > DMARC is a tool in the fight against exact-domain spoofing, but some
> > methods of its deployment can cause interoperability issues. I believe
> > that as long as the risks are well understood and fully documented (to
> > include references to mitigation strategies) then a domain owner will
> > have all the information they need to make their choice as to what
> > policy to deploy. To mandate that certain classes of domains not do
> > something (and just how do we define "general-purpose" email anyway?)
> seems a bridge too far for me.
> 
> I agree with your items 1 and 2.  I'm not a particular fan of improper use 
>

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Todd Herr]

On Tue, Mar 28, 2023 at 4:01 PM Scott Kitterman 
wrote:

>
> "...MUST NOT deploy a DMARC policy other than p=none because use of
> p=reject
> or (to a slightly lesser extent) p=quarantine for such domains is
> extremely
> harmful to email interoperability.  Mitigation strategies are discussed in
> [RFC 7960] and [RFC 8617]."
>
> I don't think we need to reiterate what p=reject does here, that's
> extensively
> addressed elsewhere in the document.  I don't think we have enough data to
> opine either way about the effectiveness of such strategies, so it's
> enough to
> point at them here.  We don't currently list RFC 8617 as a reference.  I
> think
> introducing an informative reference here is useful.  It's experimental,
> so we
> definitely don't want to put any normative language around it.
>
> I suspect that's probably not what you would find ideal (it's not what I
> would
> find ideal either, but I can live with it).  Can you live with it?  What
> do
> others think?
>
>
In my estimation, the language you propose here establishes the primacy of
interoperability over the needs/wishes of the domain owner.

My preference is for language that acknowledges the primacy of the domain
owner over interoperability.

I don't have time tonight to propose alternative text, but I wanted to
acknowledge that I've read your message and make a promise to propose
alternative text tomorrow.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman 
> 
> wrote:
> > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> > > NEW
> > > 
> > >5.5.6.  Decide If and When to Update DMARC Policy
> > >
> > >Once the Domain Owner is satisfied that it is properly authenticating
> > >all of its mail, then it is time to decide if it is appropriate to
> > >change the p= value in its DMARC record to p=quarantine or p=reject.
> > >Depending on its cadence for sending mail, it may take many months of
> > >consuming DMARC aggregate reports before a Domain Owner reaches the
> > >point where it is sure that it is properly authenticating all of its
> > >mail, and the decision on which p= value to use will depend on its
> > >needs.
> > >
> > >It is important to understand that many domains may never use
> > >policies of “quarantine” or “reject”, and that these policies are
> > >intended not as goals, but as policies available for use when they
> > >are appropriate.  In particular, “reject” is not intended for
> > >deployment in domains with users who send routine email, and its
> > >deployment in such domains can disrupt indirect mail flows and cause
> > >damage to operation of mailing lists and other forwarding services.
> > >This is discussed in [RFC7960] and in Section 5.8, below.  The
> > >“reject” policy is best reserved for domains that send only
> > >transactional email that is not intended to be posted to mailing
> > >lists.
> > >
> > >To be explicitly clear: domains used for general-purpose email MUST
> > >NOT deploy a DMARC policy of p=reject.
> > > 
> > > END
> > 
> > [snip]
> > 
> > How about, "... MUST NOT deploy a DMARC policy other than p=none because
> > improper used of p=reject or (to a slightly lesser exent) p=quarantine is
> > extremely harmful to email interoperability."
> 
> Or, "...MUST NOT deploy a DMARC policy other than p=none because
> improper use of p=reject or (to a slightly lesser extent) p=quarantine is
> extremely harmful to email interoperability. Such improper use includes,
> but is not limited to, cases where the mitigation strategies discussed in
> RFCs 7960 and 8617 and elsewhere are not deployed for the mail flows
> in question and cases where the domain owner deems the collateral damage
> as acceptable loss in service of protecting its domain from unauthorized
> usage."
> 
> I suspect that my text above won't go over well, but the use of the term
> "improper use" smacks, to me, of the IETF being the protocol police, and
> I've been led to believe that's not what we do here.
> 
> There are many things I believe, and two of them are these:
> 
>1. Any domain is a target to be spoofed
>2. The custodian of a thing has the autonomy to do with that thing what
>they please, so long as it's within the limits of the law. "My network,
> my rules" as it were (or "Your network, your rules")
> 
> DMARC is a tool in the fight against exact-domain spoofing, but some
> methods of its deployment can cause interoperability issues. I believe that
> as long as the risks are well understood and fully documented (to include
> references to mitigation strategies) then a domain owner will have all the
> information they need to make their choice as to what policy to deploy. To
> mandate that certain classes of domains not do something (and just how do
> we define "general-purpose" email anyway?) seems a bridge too far for me.

I agree with your items 1 and 2.  I'm not a particular fan of improper use 
either.  Maybe instead of improper use.  Maybe just "use with such domains".

Your characterization reads more like SHOULD NOT unless   I don't think 
that unless [list of things that are only true in very limited circumstances 
and can't really be verified reliably] is very useful.  How about this instead 
(I am attempting to split the difference between assuming p=reject is okay is 
normal or exceptional):

"...MUST NOT deploy a DMARC policy other than p=none because use of p=reject 
or (to a slightly lesser extent) p=quarantine for such domains is extremely 
harmful to email interoperability.  Mitigation strategies are discussed in
[RFC 7960] and [RFC 8617]."

I don't think we need to reiterate what p=reject does here, that's extensively 
addressed elsewhere in the document.  I don't think we have enough data to 
opine either way about the effectiveness of such strategies, so it's enough to 
point at them here.  We don't currently list RFC 8617 as a reference.  I think 
introducing an informative reference here is useful.  It's experimental, so we 
definitely don't want to put any normative language around it.

I suspect that's probably not what you would find ideal (it's not what I would 
find ideal either, but I can live with it).  Can you live with it?  What do 
others think?

Scott K


___

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Todd Herr]

On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman 
wrote:

> On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
>
> > NEW
> >
> >5.5.6.  Decide If and When to Update DMARC Policy
> >
> >Once the Domain Owner is satisfied that it is properly authenticating
> >all of its mail, then it is time to decide if it is appropriate to
> >change the p= value in its DMARC record to p=quarantine or p=reject.
> >Depending on its cadence for sending mail, it may take many months of
> >consuming DMARC aggregate reports before a Domain Owner reaches the
> >point where it is sure that it is properly authenticating all of its
> >mail, and the decision on which p= value to use will depend on its
> >needs.
> >
> >It is important to understand that many domains may never use
> >policies of “quarantine” or “reject”, and that these policies are
> >intended not as goals, but as policies available for use when they
> >are appropriate.  In particular, “reject” is not intended for
> >deployment in domains with users who send routine email, and its
> >deployment in such domains can disrupt indirect mail flows and cause
> >damage to operation of mailing lists and other forwarding services.
> >This is discussed in [RFC7960] and in Section 5.8, below.  The
> >“reject” policy is best reserved for domains that send only
> >transactional email that is not intended to be posted to mailing
> >lists.
> >
> >To be explicitly clear: domains used for general-purpose email MUST
> >NOT deploy a DMARC policy of p=reject.
> >
> > END
> >
> [snip]
>
> How about, "... MUST NOT deploy a DMARC policy other than p=none because
> improper used of p=reject or (to a slightly lesser exent) p=quarantine is
> extremely harmful to email interoperability."
>
>
Or, "...MUST NOT deploy a DMARC policy other than p=none because
improper use of p=reject or (to a slightly lesser extent) p=quarantine is
extremely harmful to email interoperability. Such improper use includes,
but is not limited to, cases where the mitigation strategies discussed in
RFCs 7960 and 8617 and elsewhere are not deployed for the mail flows
in question and cases where the domain owner deems the collateral damage
as acceptable loss in service of protecting its domain from unauthorized
usage."

I suspect that my text above won't go over well, but the use of the term
"improper use" smacks, to me, of the IETF being the protocol police, and
I've been led to believe that's not what we do here.

There are many things I believe, and two of them are these:

   1. Any domain is a target to be spoofed
   2. The custodian of a thing has the autonomy to do with that thing what
   they please, so long as it's within the limits of the law. "My network, my
   rules" as it were (or "Your network, your rules")

DMARC is a tool in the fight against exact-domain spoofing, but some
methods of its deployment can cause interoperability issues. I believe that
as long as the risks are well understood and fully documented (to include
references to mitigation strategies) then a domain owner will have all the
information they need to make their choice as to what policy to deploy. To
mandate that certain classes of domains not do something (and just how do
we define "general-purpose" email anyway?) seems a bridge too far for me.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> I raised this issue in the DMARC session in Vienna, and have let it
> sit for a while so as not to derail other discussion.  As we're pretty
> close to finished with the DMARCbis document, I'd like to raise it
> again, this time with specific proposed text for us to discuss.
> 
> And so:
> 
> OLD
> 
>5.5.6.  Decide If and When to Update DMARC Policy
> 
>Once the Domain Owner is satisfied that it is properly authenticating
>all of its mail, then it is time to decide if it is appropriate to
>change the p= value in its DMARC record to p=quarantine or p=reject.
>Depending on its cadence for sending mail, it may take many months of
>consuming DMARC aggregate reports before a Domain Owner reaches the
>point where it is sure that it is properly authenticating all of its
>mail, and the decision on which p= value to use will depend on its
>needs.
> 
> NEW
> 
>5.5.6.  Decide If and When to Update DMARC Policy
> 
>Once the Domain Owner is satisfied that it is properly authenticating
>all of its mail, then it is time to decide if it is appropriate to
>change the p= value in its DMARC record to p=quarantine or p=reject.
>Depending on its cadence for sending mail, it may take many months of
>consuming DMARC aggregate reports before a Domain Owner reaches the
>point where it is sure that it is properly authenticating all of its
>mail, and the decision on which p= value to use will depend on its
>needs.
> 
>It is important to understand that many domains may never use
>policies of “quarantine” or “reject”, and that these policies are
>intended not as goals, but as policies available for use when they
>are appropriate.  In particular, “reject” is not intended for
>deployment in domains with users who send routine email, and its
>deployment in such domains can disrupt indirect mail flows and cause
>damage to operation of mailing lists and other forwarding services.
>This is discussed in [RFC7960] and in Section 5.8, below.  The
>“reject” policy is best reserved for domains that send only
>transactional email that is not intended to be posted to mailing
>lists.
> 
>To be explicitly clear: domains used for general-purpose email MUST
>NOT deploy a DMARC policy of p=reject.
> 
> END
> 
> I'm well aware that the MUST will *not* be followed by everyone, and
> that some domain owners will feel that they need to use p=reject,
> regardless.  I think that's fine: the standard should specify what's
> right for interoperability, and I believe that improper use of
> p=reject is extremely harmful to interoperability... so "MUST" is
> correct here.  And no one will be arrested or fined for choosing not
> to follow it.  We should still say it, nonetheless.
> 
> OK, have at it.

I think this is pretty good.  I would only add a "because ..." clause at the 
end.  Often in IETF documents we say SHOULD/SHOULD NOT unless $REASON if there 
are clear exceptions.  We don't generally justify MUST/MUST NOT because we 
expect people to adhere to them.  In this case though we know that the MUST is 
going to be met with suspicion is some quarters, so I think we should explain 
why.  It doesn't have to be much.  You may have even written it already in 
your note after the suggested change.  I thnk it applies to p=quarantine as 
well, as Jim Fenton suggested.

How about, "... MUST NOT deploy a DMARC policy other than p=none because 
improper used of p=reject or (to a slightly lesser exent) p=quarantine is 
extremely harmful to email interoperability."

Scott K


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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

Technically I think it's domains that send mail which is received via indirect 
mail flows and want such mail delivered.

I think that's approximately all domains with human users.  The only exception 
I can think of is if a corporate domain prohibits employees from using their 
company email address on mailing lists, bug trackers, web forums, etc.

Ultimately I think the conceptual difference is between the view that p=reject 
being a problem is a special case versus p=reject not being a problem for 
interoperability is a special case.

I am very much in support of the latter view.

Scott K

On March 28, 2023 4:36:39 PM UTC, "Brotman, Alex" 
 wrote:
>Should it reference consumer-oriented domains instead? 
>
>Users of comcast.net can't get an email account with out first being an ISP 
>customer.  I don't believe the intent was to exclude them from the proposed 
>language.  Similarly for a few other providers, and then there are explicit 
>pay-for services like Fastmail, Tutanova, etc.  I would think they're in the 
>same category?
>
>--
>Alex Brotman
>Sr. Engineer, Anti-Abuse & Messaging Policy
>Comcast
>
>> -Original Message-
>> From: dmarc  On Behalf Of Scott Kitterman
>> Sent: Tuesday, March 28, 2023 12:18 PM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
>> 
>> On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote:
>> > Upon further reflection, I find myself liking Barry's proposed text
>> > less, and instead propose the following:
>> >
>> > On Tue, Mar 28, 2023 at 9:42 AM Todd Herr  wrote:
>> > > On 28 Mar 2023, at 17:15, Barry Leiba wrote:
>> > >> > NEW
>> > >> >
>> > >> >5.5.6.  Decide If and When to Update DMARC Policy
>> > >> >
>> > >> >Once the Domain Owner is satisfied that it is properly
>> > >> >authenticating
>> > >> >all of its mail, then it is time to decide if it is appropriate to
>> > >> >change the p= value in its DMARC record to p=quarantine or 
>> > >> > p=reject.
>> > >> >Depending on its cadence for sending mail, it may take many months
>> > >> >of
>> > >> >consuming DMARC aggregate reports before a Domain Owner reaches
>> the
>> > >> >point where it is sure that it is properly authenticating all of 
>> > >> > its
>> > >> >mail, and the decision on which p= value to use will depend on its
>> > >> >needs.
>> > >> >
>> > >> >It is important to understand that many domains may never use
>> > >> >policies of “quarantine” or “reject”, and that these policies are
>> > >> >intended not as goals, but as policies available for use when they
>> > >> >are appropriate.  In particular, “reject” is not intended for
>> > >> >deployment in domains with users who send routine email, and its
>> > >> >deployment in such domains can disrupt indirect mail flows and 
>> > >> > cause
>> > >> >damage to operation of mailing lists and other forwarding services.
>> > >> >This is discussed in [RFC7960] and in Section 5.8, below.  The
>> > >> >“reject” policy is best reserved for domains that send only
>> > >> >transactional email that is not intended to be posted to mailing
>> > >> >lists.
>> > > >
>> > > >To be explicitly clear: domains used for general-purpose email
>> > > > MUST
>> > > >
>> > >> >NOT deploy a DMARC policy of p=reject.
>> >
>> > NEW
>> >
>> > 5.5.6 Decide Whether to Update DMARC Policy
>> >
>> > Once the Domain Owner is satisfied that it is properly authenticating
>> >
>> > all of its mail, then it is time to decide if it is appropriate to
>> >
>> > change the p= value in its DMARC record to p=quarantine or p=reject.
>> >
>> > Depending on its cadence for sending mail, it may take many months
>> >
>> > of consuming DMARC aggregate reports before a Domain Owner reaches
>> >
>> > the point where it is sure that it is properly authenticating all
>> >
>> > of its mail, and the decision on which p= value to use will depend on
>> > its needs.
>> >
>> > The policies "reject&qu

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Dotzero]

On Tue, Mar 28, 2023 at 12:18 PM Scott Kitterman 
wrote:

>
>
> I don't understand the connection between DMARC policies and open signup
> domains?  What makes them in any way special relative to DMARC?
>
> Scott K
>

I agree with Scott on this.  I don't believe that "open signup" domains
deserve this special call out in this manner. For example, a domain
providing accounts to the public ( "open signup domains") may choose to
specify in its TOS that account email addresses may not be used to send
email from servers other than the domain's own servers. This is a
contractual issue, not an interoperability issue. We should be very careful
before wading into these waters. I understand the concern but I think the
concern is best handled in a separate BCP.

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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

Should it reference consumer-oriented domains instead? 

Users of comcast.net can't get an email account with out first being an ISP 
customer.  I don't believe the intent was to exclude them from the proposed 
language.  Similarly for a few other providers, and then there are explicit 
pay-for services like Fastmail, Tutanova, etc.  I would think they're in the 
same category?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 12:18 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote:
> > Upon further reflection, I find myself liking Barry's proposed text
> > less, and instead propose the following:
> >
> > On Tue, Mar 28, 2023 at 9:42 AM Todd Herr  wrote:
> > > On 28 Mar 2023, at 17:15, Barry Leiba wrote:
> > >> > NEW
> > >> >
> > >> >5.5.6.  Decide If and When to Update DMARC Policy
> > >> >
> > >> >Once the Domain Owner is satisfied that it is properly
> > >> >authenticating
> > >> >all of its mail, then it is time to decide if it is appropriate to
> > >> >change the p= value in its DMARC record to p=quarantine or p=reject.
> > >> >Depending on its cadence for sending mail, it may take many months
> > >> >of
> > >> >consuming DMARC aggregate reports before a Domain Owner reaches
> the
> > >> >point where it is sure that it is properly authenticating all of its
> > >> >mail, and the decision on which p= value to use will depend on its
> > >> >needs.
> > >> >
> > >> >It is important to understand that many domains may never use
> > >> >policies of “quarantine” or “reject”, and that these policies are
> > >> >intended not as goals, but as policies available for use when they
> > >> >are appropriate.  In particular, “reject” is not intended for
> > >> >deployment in domains with users who send routine email, and its
> > >> >deployment in such domains can disrupt indirect mail flows and cause
> > >> >damage to operation of mailing lists and other forwarding services.
> > >> >This is discussed in [RFC7960] and in Section 5.8, below.  The
> > >> >“reject” policy is best reserved for domains that send only
> > >> >transactional email that is not intended to be posted to mailing
> > >> >lists.
> > > >
> > > >To be explicitly clear: domains used for general-purpose email
> > > > MUST
> > > >
> > >> >NOT deploy a DMARC policy of p=reject.
> >
> > NEW
> >
> > 5.5.6 Decide Whether to Update DMARC Policy
> >
> > Once the Domain Owner is satisfied that it is properly authenticating
> >
> > all of its mail, then it is time to decide if it is appropriate to
> >
> > change the p= value in its DMARC record to p=quarantine or p=reject.
> >
> > Depending on its cadence for sending mail, it may take many months
> >
> > of consuming DMARC aggregate reports before a Domain Owner reaches
> >
> > the point where it is sure that it is properly authenticating all
> >
> > of its mail, and the decision on which p= value to use will depend on
> > its needs.
> >
> > The policies "reject" and "quarantine" are more effective than "none"
> > for accomplishing the chief goal of DMARC, namely to stop the
> > exact-domain spoofing of the domain in the RFC5322.From header.
> > However, experience has shown that a policy of "reject" can result in
> > the disruption of indirect mail flows and cause damage to the
> > operation of mailing lists and other forwarding services; [@!RFC7960]
> > and [@!RFC8617] and Section 5.8, below, all discuss this topic and/or
> > possible strategies for addressing it.
> >
> > Because of these challenges, some domains, particularly those with
> > open signup capabilities, may prefer to remain at a policy of p=none.
> > This topic is discussed further in section 11.4 below.
> >
> > 11.4 Open Signup Domains and DMARC Policies
> >
> >
> > Certain domains with open signup capabilities, where anyone can
> > register an
> >
> > account and send mail, may not want to implement p=reject. An

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman]

On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote:
> Upon further reflection, I find myself liking Barry's proposed text less,
> and instead propose the following:
> 
> On Tue, Mar 28, 2023 at 9:42 AM Todd Herr  wrote:
> > On 28 Mar 2023, at 17:15, Barry Leiba wrote:
> >> > NEW
> >> > 
> >> >5.5.6.  Decide If and When to Update DMARC Policy
> >> >
> >> >Once the Domain Owner is satisfied that it is properly
> >> >authenticating
> >> >all of its mail, then it is time to decide if it is appropriate to
> >> >change the p= value in its DMARC record to p=quarantine or p=reject.
> >> >Depending on its cadence for sending mail, it may take many months
> >> >of
> >> >consuming DMARC aggregate reports before a Domain Owner reaches the
> >> >point where it is sure that it is properly authenticating all of its
> >> >mail, and the decision on which p= value to use will depend on its
> >> >needs.
> >> >
> >> >It is important to understand that many domains may never use
> >> >policies of “quarantine” or “reject”, and that these policies are
> >> >intended not as goals, but as policies available for use when they
> >> >are appropriate.  In particular, “reject” is not intended for
> >> >deployment in domains with users who send routine email, and its
> >> >deployment in such domains can disrupt indirect mail flows and cause
> >> >damage to operation of mailing lists and other forwarding services.
> >> >This is discussed in [RFC7960] and in Section 5.8, below.  The
> >> >“reject” policy is best reserved for domains that send only
> >> >transactional email that is not intended to be posted to mailing
> >> >lists.
> > >
> > >To be explicitly clear: domains used for general-purpose email MUST
> > >
> >> >NOT deploy a DMARC policy of p=reject.
> 
> NEW
> 
> 5.5.6 Decide Whether to Update DMARC Policy
> 
> Once the Domain Owner is satisfied that it is properly authenticating
> 
> all of its mail, then it is time to decide if it is appropriate to
> 
> change the p= value in its DMARC record to p=quarantine or p=reject.
> 
> Depending on its cadence for sending mail, it may take many months
> 
> of consuming DMARC aggregate reports before a Domain Owner reaches
> 
> the point where it is sure that it is properly authenticating all
> 
> of its mail, and the decision on which p= value to use will depend
> on its needs.
> 
> The policies "reject" and "quarantine" are more effective than "none" for
> accomplishing the chief goal of DMARC, namely to stop the exact-domain
> spoofing of the domain in the RFC5322.From header. However, experience
> has shown that a policy of "reject" can result in the disruption of
> indirect mail
> flows and cause damage to the operation of mailing lists and other
> forwarding
> services; [@!RFC7960] and [@!RFC8617] and Section 5.8, below, all discuss
> this topic and/or possible strategies for addressing it.
> 
> Because of these challenges, some domains, particularly those with open
> signup
> capabilities, may prefer to remain at a policy of p=none. This topic is
> discussed
> further in section 11.4 below.
> 
> 11.4 Open Signup Domains and DMARC Policies
> 
> 
> Certain domains with open signup capabilities, where anyone can register an
> 
> account and send mail, may not want to implement p=reject. An example of
> such
> 
> domains would be consumer mailbox providers that used to be known as
> "freemail
> 
> providers". Domains with no DMARC policy or a policy of p=none are
> vulnerable
> 
> to spoofing, but their users can send mail using these registered email
> addresses
> 
> from unrelated third party systems (such as "forward to a friend" services)
> or participate
> 
> in mailing lists without impediment. The security challenges that this
> presents to the
> 
> domain owner are left up to those systems that allow open registration of
> users.

I don't understand the connection between DMARC policies and open signup 
domains?  What makes them in any way special relative to DMARC?

Scott K



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

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Todd Herr]

Upon further reflection, I find myself liking Barry's proposed text less,
and instead propose the following:

On Tue, Mar 28, 2023 at 9:42 AM Todd Herr  wrote:

> On 28 Mar 2023, at 17:15, Barry Leiba wrote:
>>
>> > NEW
>> >
>> >5.5.6.  Decide If and When to Update DMARC Policy
>> >
>> >Once the Domain Owner is satisfied that it is properly authenticating
>> >all of its mail, then it is time to decide if it is appropriate to
>> >change the p= value in its DMARC record to p=quarantine or p=reject.
>> >Depending on its cadence for sending mail, it may take many months of
>> >consuming DMARC aggregate reports before a Domain Owner reaches the
>> >point where it is sure that it is properly authenticating all of its
>> >mail, and the decision on which p= value to use will depend on its
>> >needs.
>> >
>> >It is important to understand that many domains may never use
>> >policies of “quarantine” or “reject”, and that these policies are
>> >intended not as goals, but as policies available for use when they
>> >are appropriate.  In particular, “reject” is not intended for
>> >deployment in domains with users who send routine email, and its
>> >deployment in such domains can disrupt indirect mail flows and cause
>> >damage to operation of mailing lists and other forwarding services.
>> >This is discussed in [RFC7960] and in Section 5.8, below.  The
>> >“reject” policy is best reserved for domains that send only
>> >transactional email that is not intended to be posted to mailing
>> >lists.
>>
>

> >To be explicitly clear: domains used for general-purpose email MUST
>> >NOT deploy a DMARC policy of p=reject.
>>
>>
>
NEW

5.5.6 Decide Whether to Update DMARC Policy

Once the Domain Owner is satisfied that it is properly authenticating

all of its mail, then it is time to decide if it is appropriate to

change the p= value in its DMARC record to p=quarantine or p=reject.

Depending on its cadence for sending mail, it may take many months

of consuming DMARC aggregate reports before a Domain Owner reaches

the point where it is sure that it is properly authenticating all

of its mail, and the decision on which p= value to use will depend
on its needs.

The policies "reject" and "quarantine" are more effective than "none" for
accomplishing the chief goal of DMARC, namely to stop the exact-domain
spoofing of the domain in the RFC5322.From header. However, experience
has shown that a policy of "reject" can result in the disruption of
indirect mail
flows and cause damage to the operation of mailing lists and other
forwarding
services; [@!RFC7960] and [@!RFC8617] and Section 5.8, below, all discuss
this topic and/or possible strategies for addressing it.

Because of these challenges, some domains, particularly those with open
signup
capabilities, may prefer to remain at a policy of p=none. This topic is
discussed
further in section 11.4 below.

11.4 Open Signup Domains and DMARC Policies


Certain domains with open signup capabilities, where anyone can register an

account and send mail, may not want to implement p=reject. An example of
such

domains would be consumer mailbox providers that used to be known as
"freemail

providers". Domains with no DMARC policy or a policy of p=none are
vulnerable

to spoofing, but their users can send mail using these registered email
addresses

from unrelated third party systems (such as "forward to a friend" services)
or participate

in mailing lists without impediment. The security challenges that this
presents to the

domain owner are left up to those systems that allow open registration of
users.



-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*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] Proposed text for p=reject and indirect mail flows

[Mark Alley]

I know that M3 is totally separate from this group, but this is more-so 
a question for Todd H- does this mean that the M3AAWG authentication 
best practices recommendation will also change based on this if this is 
the intended usage going forwards with DMARCbis?


Quote from the existing document 
 
-


 * "DMARC Policy statements should be “p=reject” where possible,

 * “p=quarantine” otherwise.
 o   “p=none”, “sp=none”, and pct<100 should only be viewed as
   transitional states, with the goal of removing them as
   quickly as possible. "

On 3/28/2023 8:42 AM, Todd Herr wrote:

On Tue, Mar 28, 2023 at 8:36 AM Jim Fenton  wrote:

On 28 Mar 2023, at 17:15, Barry Leiba wrote:

> NEW
>
>    5.5.6.  Decide If and When to Update DMARC Policy
>
>    Once the Domain Owner is satisfied that it is properly
authenticating
>    all of its mail, then it is time to decide if it is
appropriate to
>    change the p= value in its DMARC record to p=quarantine or
p=reject.
>    Depending on its cadence for sending mail, it may take many
months of
>    consuming DMARC aggregate reports before a Domain Owner
reaches the
>    point where it is sure that it is properly authenticating all
of its
>    mail, and the decision on which p= value to use will depend
on its
>    needs.
>
>    It is important to understand that many domains may never use
>    policies of “quarantine” or “reject”, and that these policies are
>    intended not as goals, but as policies available for use when
they
>    are appropriate.  In particular, “reject” is not intended for
>    deployment in domains with users who send routine email, and its
>    deployment in such domains can disrupt indirect mail flows
and cause
>    damage to operation of mailing lists and other forwarding
services.
>    This is discussed in [RFC7960] and in Section 5.8, below.  The
>    “reject” policy is best reserved for domains that send only
>    transactional email that is not intended to be posted to mailing
>    lists.

Mailing lists being a primary example of usage that may run afoul
of a p=reject policy, but not the only one.

>    To be explicitly clear: domains used for general-purpose
email MUST
>    NOT deploy a DMARC policy of p=reject.

I’m not sure p=quarantine is a good idea either for such domains.

>
> END
>
> I'm well aware that the MUST will *not* be followed by everyone, and
> that some domain owners will feel that they need to use p=reject,
> regardless.  I think that's fine: the standard should specify what's
> right for interoperability, and I believe that improper use of
> p=reject is extremely harmful to interoperability... so "MUST" is
> correct here.  And no one will be arrested or fined for choosing not
> to follow it.  We should still say it, nonetheless.
>
> OK, have at it.


I also like the new text, and further propose updating section 7.6 (in 
the Changes from RFC 7489 section) from this:


OLD

7.6 Domain Owner Actions


This section has been expanded upon from RFC 7489.


To this:


NEW


7.6  Expansion of Domain Owner Actions Section


This section has been expanded upon from RFC 7489.


RFC 7489 had just two paragraphs in its Domain Owner Actions
section, and while

the content of those paragraphs was correct, it was minimalist in
its approach to

providing guidance to domain owners on just how to implement DMARC.


This document provides much more detail and explanatory text to a
domain owner,

focusing not just on what to do to implement DMARC, but also on
the reasons for

each step and the repercussions of each decision.

In particular, this document makes explicit that domains for
general-purpose

email **MUST NOT** deploy a DMARC policy of p=reject.


END


Obviously, the last paragraph of section 7.6 will reflect the 
consensus of whatever 5.5.6 ends up being.



--
*Todd Herr *| Technical Director, Standards and Ecosystem
*e:*todd.h...@valimail.com
*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___
dmarc m