Re: [dmarc-ietf] AOL-compatible mailing lists

[Douglas Foster]

What is the operational experience with domains that stop at o=quarantine?


On Sun, Apr 9, 2023, 5:28 PM Murray S. Kucherawy 
wrote:

> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As an evaluator, what I can accept is that "Some intermediaries could be
>> allowed to make some changes y do want unrestricto messages, if I have a
>> list of intermediaries that should be allowed, sufficient reason to trust
>> what they propose to do, and a reliable way to identify them."I do
>> exceptions all the time.   But lists don't want to make special
>> arrangements with evaluators, and don't want to make special arrangements
>> with senders.  Apparently, lists don't even want to do rigorous
>> verification to ensure that a post comes from the purported subscriber.
>>  But theted access to evaluators that filter based on simplistic triggers
>> like "p=reject".
>>
>
> I see two issues with this line of thinking:
>
> (1) "I do exceptions all the time" works when you are a relatively small
> operator with a relatively small user base for whom you need to configure
> exceptions.  You can get away with doing those manually.  What size staff
> do you imagine GMail would need to hire to investigate and configure manual
> exceptions on a timely basis for each time one of its billion-plus users
> wants to subscribe to a mailing list?  The notion screams for automation,
> and automation screams for something deterministic or at least close to it
> upon which to base automated decisions.  That last bit is what's missing
> here.
>
> (2) "But lists don't want to make special arrangements with evaluators,
> and don't want to make special arrangements with senders".  They might, if
> there existed a reliable way to do so.  How would you accomplish this in a
> way that prevents an attacker from making you think he's a list, and then
> sending whatever he wants from inside that trust boundary?
>
> I think evaluators SHOULD NOT block on simplistic rules like p=reject,
>> because a correct p=reject block requires follow-on work to block
>> everything else from that malicious source, and should not be done
>> incorrectly.   They should review, either with pre-quarantine or
>> post-audit, which is what I do.  I have no problem with
>> disposition=quarantine, even for p=none.   I am obligated to protect my
>> users, while also obligated to provide my users the messages they need, not
>> the ones that are technically optimal   I don't understand why Big Tech and
>> its A.I. tools cannot be deployed to do the best thing.
>>
>
> I'm pretty sure they could, for their own use cases.  But what about the
> operators in between, who aren't Big Tech and don't have AI tools?  A
> standard has to work for everyone.
>
> -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

[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] AOL-compatible mailing lists

[Douglas Foster]

Those are all valid points, and I don't have a solution for them which
preserves the status quo.

I see the world moving to more Sender Authentication, not less.  Mandatory
Sender Authentication is my expected end-state.

ARC is an acknowledgement of this trend.   ARC may not add much value to
lists, because it requires out-of-band communication before From-munging
can be disabled.   But to the extent that ARC is useful to lists, it forces
them to do more and better Sender Authentication than the previous norm.
 So even they are getting sucked in, willing or not.

All of which is why I sketched out a very different mailing list design.
 It's not my job or my agenda to sell it to people, not my job to build
the product, and not my job to deal with hurt feelings.The Internet
changed when we realized that bad guys dominate the environment, and Sender
Authentication is one of the consequences.   The name-translating design
provides a path to reliable list delivery when Sender Authentication is
mandatory.  I think that kind of future-thinking is what standards are
supposed to do.

Doug






On Sun, Apr 9, 2023 at 5:28 PM Murray S. Kucherawy 
wrote:

> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As an evaluator, what I can accept is that "Some intermediaries could be
>> allowed to make some changes y do want unrestricto messages, if I have a
>> list of intermediaries that should be allowed, sufficient reason to trust
>> what they propose to do, and a reliable way to identify them."I do
>> exceptions all the time.   But lists don't want to make special
>> arrangements with evaluators, and don't want to make special arrangements
>> with senders.  Apparently, lists don't even want to do rigorous
>> verification to ensure that a post comes from the purported subscriber.
>>  But theted access to evaluators that filter based on simplistic triggers
>> like "p=reject".
>>
>
> I see two issues with this line of thinking:
>
> (1) "I do exceptions all the time" works when you are a relatively small
> operator with a relatively small user base for whom you need to configure
> exceptions.  You can get away with doing those manually.  What size staff
> do you imagine GMail would need to hire to investigate and configure manual
> exceptions on a timely basis for each time one of its billion-plus users
> wants to subscribe to a mailing list?  The notion screams for automation,
> and automation screams for something deterministic or at least close to it
> upon which to base automated decisions.  That last bit is what's missing
> here.
>
> (2) "But lists don't want to make special arrangements with evaluators,
> and don't want to make special arrangements with senders".  They might, if
> there existed a reliable way to do so.  How would you accomplish this in a
> way that prevents an attacker from making you think he's a list, and then
> sending whatever he wants from inside that trust boundary?
>
> I think evaluators SHOULD NOT block on simplistic rules like p=reject,
>> because a correct p=reject block requires follow-on work to block
>> everything else from that malicious source, and should not be done
>> incorrectly.   They should review, either with pre-quarantine or
>> post-audit, which is what I do.  I have no problem with
>> disposition=quarantine, even for p=none.   I am obligated to protect my
>> users, while also obligated to provide my users the messages they need, not
>> the ones that are technically optimal   I don't understand why Big Tech and
>> its A.I. tools cannot be deployed to do the best thing.
>>
>
> I'm pretty sure they could, for their own use cases.  But what about the
> operators in between, who aren't Big Tech and don't have AI tools?  A
> standard has to work for everyone.
>
> -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] AOL-compatible mailing lists

[Murray S. Kucherawy]

On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> As an evaluator, what I can accept is that "Some intermediaries could be
> allowed to make some changes y do want unrestricto messages, if I have a
> list of intermediaries that should be allowed, sufficient reason to trust
> what they propose to do, and a reliable way to identify them."I do
> exceptions all the time.   But lists don't want to make special
> arrangements with evaluators, and don't want to make special arrangements
> with senders.  Apparently, lists don't even want to do rigorous
> verification to ensure that a post comes from the purported subscriber.
>  But theted access to evaluators that filter based on simplistic triggers
> like "p=reject".
>

I see two issues with this line of thinking:

(1) "I do exceptions all the time" works when you are a relatively small
operator with a relatively small user base for whom you need to configure
exceptions.  You can get away with doing those manually.  What size staff
do you imagine GMail would need to hire to investigate and configure manual
exceptions on a timely basis for each time one of its billion-plus users
wants to subscribe to a mailing list?  The notion screams for automation,
and automation screams for something deterministic or at least close to it
upon which to base automated decisions.  That last bit is what's missing
here.

(2) "But lists don't want to make special arrangements with evaluators, and
don't want to make special arrangements with senders".  They might, if
there existed a reliable way to do so.  How would you accomplish this in a
way that prevents an attacker from making you think he's a list, and then
sending whatever he wants from inside that trust boundary?

I think evaluators SHOULD NOT block on simplistic rules like p=reject,
> because a correct p=reject block requires follow-on work to block
> everything else from that malicious source, and should not be done
> incorrectly.   They should review, either with pre-quarantine or
> post-audit, which is what I do.  I have no problem with
> disposition=quarantine, even for p=none.   I am obligated to protect my
> users, while also obligated to provide my users the messages they need, not
> the ones that are technically optimal   I don't understand why Big Tech and
> its A.I. tools cannot be deployed to do the best thing.
>

I'm pretty sure they could, for their own use cases.  But what about the
operators in between, who aren't Big Tech and don't have AI tools?  A
standard has to work for everyone.

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

Re: [dmarc-ietf] AOL-compatible mailing lists

[Douglas Foster]

This discussion is based on a mixture of theory and pragmatism.

The pragmatism side is that AOL has created a problem, is unlikely to
change, and we have to deal with life as it is rather than the way I would
like it to be.

The theoretical side is more difficult.   I would like to be more
sympathetic, but the theory doesn't support it.   I hear the mailing list
complaint as, "Any intermediary should be able to modify any traffic
without restriction.   These modifications are always beneficial, and
therefore the modified message should be more acceptable than the
original."  In short, the whole idea of DKIM is rejected.

As an evaluator, what I can accept is that "Some intermediaries could be
allowed to make some changes to messages, if I have a list of
intermediaries that should be allowed, sufficient reason to trust what they
propose to do, and a reliable way to identify them."I do exceptions all
the time.   But lists don't want to make special arrangements with
evaluators, and don't want to make special arrangements with senders.
Apparently, lists don't even want to do rigorous verification to ensure
that a post comes from the purported subscriber.   But they do want
unrestricted access to evaluators that filter based on simplistic triggers
like "p=reject".

I think evaluators SHOULD NOT block on simplistic rules like p=reject,
because a correct p=reject block requires follow-on work to block
everything else from that malicious source, and should not be done
incorrectly.   They should review, either with pre-quarantine or
post-audit, which is what I do.  I have no problem with
disposition=quarantine, even for p=none.   I am obligated to protect my
users, while also obligated to provide my users the messages they need, not
the ones that are technically optimal   I don't understand why Big Tech and
its A.I. tools cannot be deployed to do the best thing.

Doug Foster




On Sun, Apr 9, 2023 at 2:52 PM Murray S. Kucherawy 
wrote:

> On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> It becomes a simple choice:   Lists can adapt to operate the way AOL and
>> others want them to work, or they can keep to the old ways and live with
>> the consequences.When the old ways cause damage, I don't think the
>> damage is any longer a DMARC problem.   We should formally document how to
>> implement a DMARC-compatible mailing list, and then stop worrying about
>> those who don't want to be DMARC-compatible.
>>
>
> In what way do "the old ways cause damage"?  What damage?  They didn't
> change anything.  Abruptly, unilaterally, declaring the entire global
> deployed mailing list base to be obsolete is a strikingly audacious move.
>
> Still, if something like what you're proposing could gain acceptance and
> commitment from the mailing list community, you just might have a consensus
> solution on your hands.  I suggest approaching them to ask.  They may not
> be able to accept it as-is, but could have a counter-proposal that we find
> palatable.
>
> -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

[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] AOL-compatible mailing lists

[Murray S. Kucherawy]

On Sat, Apr 8, 2023 at 2:13 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> It becomes a simple choice:   Lists can adapt to operate the way AOL and
> others want them to work, or they can keep to the old ways and live with
> the consequences.When the old ways cause damage, I don't think the
> damage is any longer a DMARC problem.   We should formally document how to
> implement a DMARC-compatible mailing list, and then stop worrying about
> those who don't want to be DMARC-compatible.
>

In what way do "the old ways cause damage"?  What damage?  They didn't
change anything.  Abruptly, unilaterally, declaring the entire global
deployed mailing list base to be obsolete is a strikingly audacious move.

Still, if something like what you're proposing could gain acceptance and
commitment from the mailing list community, you just might have a consensus
solution on your hands.  I suggest approaching them to ask.  They may not
be able to accept it as-is, but could have a counter-proposal that we find
palatable.

-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]

> 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

[dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 9 06:00:05 2023

[John Levine]

   Count|  Bytes |  Who
++---
 64 ( 100%) | 796721 ( 100%) | Total
 12 (18.8%) |  96343 (12.1%) | Scott Kitterman 
 10 (15.6%) | 204726 (25.7%) | Douglas Foster 

  7 (10.9%) |  88202 (11.1%) | Jesse Thompson 
  7 (10.9%) |  35691 ( 4.5%) | John Levine 
  6 ( 9.4%) |  37251 ( 4.7%) | Alessandro Vesely 
  5 ( 7.8%) |  75321 ( 9.5%) | Neil Anuskiewicz 
  4 ( 6.2%) |  55890 ( 7.0%) | Dotzero 
  3 ( 4.7%) |  99289 (12.5%) | Seth Blank 
  2 ( 3.1%) |  37772 ( 4.7%) | Mark Alley 
  2 ( 3.1%) |  24709 ( 3.1%) | Murray S. Kucherawy 
  2 ( 3.1%) |  10327 ( 1.3%) | Baptiste Carvello 

  2 ( 3.1%) |   9825 ( 1.2%) | Jim Fenton 
  1 ( 1.6%) |  16276 ( 2.0%) | Hector Santos 
  1 ( 1.6%) |   5099 ( 0.6%) | Eric D. Williams 

___
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