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] Example of Indirect Mail Flow Breakage with p=reject?

[Scott Kitterman]

Perfect.  The goal is working towards consensus is to find something we can 
live with, so that's exactly what I was hoping for.  I don't think it's ideal 
either, but I can live with it.

Scott K

On Friday, April 14, 2023 10:43:24 PM EDT Mark Alley wrote:
> Its not ideal, but I could live with that. That's somewhat less ambiguous
> than [general purpose] domains, but still ambiguous; the Appendix or the
> same section could easily clarify "unrestrictive usage policies",  and then
> maybe the appendix, as you say, could cover the known issues and
> workarounds.
> 
> If I'm being honest, given the different versions put forth so far, it
> seems like this type of language is closer to the compromise on the
> interoperability statement. The other versions say relatively the same
> thing.
> 
> - Mark Alley
> 
> On Fri, Apr 14, 2023, 7:08 PM Scott Kitterman  wrote:
> > On Friday, April 14, 2023 5:54:06 PM EDT Dotzero wrote:
> > > Barry wrote:
> > > 
> > > " The idea is MUST NOT because it harms interop with long-standing
> > > deployments.  If you decide you're more important than that, you do
> > > what you want and there it is.  It's as simple as that"
> > > 
> > > I could live with the normative MUST NOT if there were some
> > > non-normative
> > > text recognizing that there are domains that violate the MUST NOT but
> > > not
> > > in any way attempting to validate violating the MUST NOT. Is there any
> > > potential that such wordsmithing could break the apparent impasse? Just
> > > sort of noodling on this.
> > 
> > Due to the interoperability affects both on a domain's own message stream
> > and
> > side effects on other domain's email flow, domains with [unrestrictive]
> > usage
> > policies MUST NOT publish DMARC records with p=reject as the policy.  See
> > Appendix [X] for information on how to ameliorate some of these issues and
> > the
> > possible side effects.
> > 
> > I bracketed [unrestrictive] because I'm reasonably confident that's not
> > the
> > right word, but I didn't think of another, better one.  I bracketed the
> > [X]
> > because I didn't look up where exactly I thought it ought to go.
> > 
> > Note: I do think only having p=reject in here is correct because
> > p=quarantine
> > doesn't have the same blow-back effects on third parties.
> > 
> > Something like that?
> > 
> > Scott K
> > 
> > 
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc




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

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote:
> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
> > The Sender's users being denied the ability to participate in a list due
> > to its policies seems to me like it puts this customer service problem
> > where it belongs.
> Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
> well as for every other member with p=reject) and/or disables from
> rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue
> with his CISO and IT security team and biz dev team and public relations
> team and legal team and all of the other forces that caused his domain
> owner to publish p=reject. But he can argue with IETF for making the
> decision to make the change, because he feels like the IETF considers him
> an important stakeholder.
> 
> It's this list's customer service problem, like it or not.
> 
> After calling IETF customer service, Todd finds out his options are:
> 1. Create an email address in a domain that houses members of the general
> public, instead of one that represents his identity as a member of a
> company. 2. Don't participate in the list.
> 
> But Todd is really important to this list, and doesn't like these options.
> Surely something can be done for an old friend? John, having been escalated
> this customer service dilemma seeks DMARCbis for guidance and finds:
> 
> ...MUST NOT p=reject...
> (Todd's company is pretty clearly stating Todd mustn't be representing his
> company on any mailing list.)
> 
> ...Domain Owner MUST provide a different domain with p=none for mailing list
> participants. (Maybe they do, maybe they don't, but it's worth asking.)
> 
> ...Mailbox providers MUST NOT reject or quarantine email based solely on a
> DMARC policy violation. (John could ask each mailbox provider to create an
> exception to their DMARC policy enforcement)
> 
> and he also finds something like:
> 
> ...If a mailing list would like to provide the best customer experience for
> authors within domains that violate the "MUST NOT p=reject" and to deliver
> the author's mail to mailbox providers violate their "MUST NOT solely
> enforce", for those authors the mailing list MUST rewrite the From header
> to use a different domain. This is a new mode of interoperability the
> mailing list may choose to adhere to.
> 
> John now knows what he MUST do to provide the best customer experience given
> the reality he finds himself in with an important stakeholder. He can
> choose to ignore that MUST as much as the domain owners and mailbox
> providers will choose to ignore their MUST NOTs.
> 
> I feel like there will be very few mailing lists that will ever stop
> rewriting (among those who are doing it), especially if DMARC adoption
> (publishing and enforcement) continues to rise. This is the new way of
> interoperating, in reality.
> 
> Throw them a bone so that they have a MUST to justify the things they had to
> do to interoperate all this time. It's not as easy for them to justify
> their reality with only this page
> 
> to lean on.

Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at 
windmills.

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]

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

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson  wrote:

> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
>
> The Sender's users being denied the ability to participate in a list due
> to its policies seems to me like it puts this customer service problem
> where it belongs.
>
>
> Let's say, tomorrow, IETF configures this list to reject Todd's mail (as
> well as for every other member with p=reject) and/or disables from
> rewriting. Does Todd's domain owner care? No.
>

This is where it breaks down for me.

What's the calculus here?  The domain owner decides that protecting its
name in this one targeted way is so valuable that it's fine with whatever
negative impact it has downstream?  And we're supposed to be OK with giving
this sort of approach a blanket green light by not declaring such use of
DMARC not interoperable?  And we're fine with giving their biz dev, PR,
legal, and all the other teams you named a pass on dealing with the
aftermath?  Because as I think you can see, those are not the teams in the
trenches figuring this out.

Why do you believe that the domain owner and its users shouldn't feel the
pain for such a decision?  That its customers go someplace else that does
care about these things?  Or that it has to split its mail flows into
something general purpose and something transactional in the name of
continued interoperability?

Before this domain turns on "p=reject", the MLM didn't have a customer
service problem.  Now it suddenly does, not through any change it made, but
rather because one of its subscriber's domains set that policy, and some
other subscriber's domain elects to enforce it.  Does that seem right to
you?  Because that's what all of this did to the IETF, for example.


> Todd cares. Todd can't argue with his CISO and IT security team and biz
> dev team and public relations team and legal team and all of the other
> forces that caused his domain owner to publish p=reject. But he can argue
> with IETF for making the decision to make the change, because he feels like
> the IETF considers him an important stakeholder.
>

So push on the smaller operator, not the ones imposing the change that
suddenly renders well established practices invalid.  That seems like the
right solution to you?

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Mark Alley]

Its not ideal, but I could live with that. That's somewhat less ambiguous
than [general purpose] domains, but still ambiguous; the Appendix or the
same section could easily clarify "unrestrictive usage policies",  and then
maybe the appendix, as you say, could cover the known issues and
workarounds.

If I'm being honest, given the different versions put forth so far, it
seems like this type of language is closer to the compromise on the
interoperability statement. The other versions say relatively the same
thing.

- Mark Alley

On Fri, Apr 14, 2023, 7:08 PM Scott Kitterman  wrote:

> On Friday, April 14, 2023 5:54:06 PM EDT Dotzero wrote:
> > Barry wrote:
> >
> > " The idea is MUST NOT because it harms interop with long-standing
> > deployments.  If you decide you're more important than that, you do
> > what you want and there it is.  It's as simple as that"
> >
> > I could live with the normative MUST NOT if there were some non-normative
> > text recognizing that there are domains that violate the MUST NOT but not
> > in any way attempting to validate violating the MUST NOT. Is there any
> > potential that such wordsmithing could break the apparent impasse? Just
> > sort of noodling on this.
>
> Due to the interoperability affects both on a domain's own message stream
> and
> side effects on other domain's email flow, domains with [unrestrictive]
> usage
> policies MUST NOT publish DMARC records with p=reject as the policy.  See
> Appendix [X] for information on how to ameliorate some of these issues and
> the
> possible side effects.
>
> I bracketed [unrestrictive] because I'm reasonably confident that's not
> the
> right word, but I didn't think of another, better one.  I bracketed the
> [X]
> because I didn't look up where exactly I thought it ought to go.
>
> Note: I do think only having p=reject in here is correct because
> p=quarantine
> doesn't have the same blow-back effects on third parties.
>
> Something like that?
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Jesse Thompson]

On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote:
> The Sender's users being denied the ability to participate in a list due to 
> its policies seems to me like it puts this customer service problem where it 
> belongs.

Let's say, tomorrow, IETF configures this list to reject Todd's mail (as well 
as for every other member with p=reject) and/or disables from rewriting. Does 
Todd's domain owner care? No. Todd cares. Todd can't argue with his CISO and IT 
security team and biz dev team and public relations team and legal team and all 
of the other forces that caused his domain owner to publish p=reject. But he 
can argue with IETF for making the decision to make the change, because he 
feels like the IETF considers him an important stakeholder. 

It's this list's customer service problem, like it or not.

After calling IETF customer service, Todd finds out his options are:
1. Create an email address in a domain that houses members of the general 
public, instead of one that represents his identity as a member of a company.
2. Don't participate in the list.

But Todd is really important to this list, and doesn't like these options. 
Surely something can be done for an old friend? John, having been escalated 
this customer service dilemma seeks DMARCbis for guidance and finds:

...MUST NOT p=reject...  
(Todd's company is pretty clearly stating Todd mustn't be representing his 
company on any mailing list.) 

...Domain Owner MUST provide a different domain with p=none for mailing list 
participants. 
(Maybe they do, maybe they don't, but it's worth asking.)

...Mailbox providers MUST NOT reject or quarantine email based solely on a 
DMARC policy violation.
(John could ask each mailbox provider to create an exception to their DMARC 
policy enforcement)

and he also finds something like:

...If a mailing list would like to provide the best customer experience for 
authors within domains that violate the "MUST NOT p=reject" and to deliver the 
author's mail to mailbox providers violate their "MUST NOT solely enforce", for 
those authors the mailing list MUST rewrite the From header to use a different 
domain. This is a new mode of interoperability the mailing list may choose to 
adhere to.

John now knows what he MUST do to provide the best customer experience given 
the reality he finds himself in with an important stakeholder. He can choose to 
ignore that MUST as much as the domain owners and mailbox providers will choose 
to ignore their MUST NOTs.

I feel like there will be very few mailing lists that will ever stop rewriting 
(among those who are doing it), especially if DMARC adoption (publishing and 
enforcement) continues to rise. This is the new way of interoperating, in 
reality.

Throw them a bone so that they have a MUST to justify the things they had to do 
to interoperate all this time. It's not as easy for them to justify their 
reality with only this page 
 to 
lean on.

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

[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] Author vs Signer Domains

[Mark Alley]

If you meant "external ESPs are applying DMARC per spec according to
RFC7489 6.6.2 step #5" that would be more accurate.

The prescribed method is, "If *one or more of the Authenticated
Identifiers* align with the RFC5322.From domain, the message is considered
to pass the DMARC mechanism check."

No ESP I'm aware of evaluates a DMARC failure result if *any* of the
authentication methods produces a failure. That is definitely not expected
behavior.

Do you have examples of any ESPs that deviate from this?

- Mark Alley

On Fri, Apr 14, 2023, 8:42 PM Hector Santos  wrote:

> On 4/14/2023 7:31 PM, Dotzero wrote:
> > On Fri, Apr 14, 2023 at 5:55 PM Hector Santos
> >  > > wrote:
> >
> > Yes, it is simple DeMorgan’s Theorem where you use
> > short-circuiting logic.
> >
> > DMARC says that any FAIL calculated via SPF or DKIM is an
> > overall DMARC failure.  In standard boolean logic is it an OR
> > condition:
> >
> > IF SPF FAILS or DKIM FAILS Then Reject.
> >
> >
> > You have it absolutely backwards.
> >
> > DMARC says if either (aligned) SPF validates or (aligned) DKIM
> > validates, it passes.
> I don't follow you, so NO
>
> a fail of either is a failure as a whole.
>
> That is how the major EPS of late are applying it - per specs.
>
>
> --
> Hector Santos,
> https://santronics.com
> https://winserver.com
>
> --
> Hector Santos,
> https://santronics.com
> https://winserver.com
>
>
>
> ___
> 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] Author vs Signer Domains

[Neil Anuskiewicz]

> On Apr 14, 2023, at 6:42 PM, Hector Santos 
>  wrote:
> 
> On 4/14/2023 7:31 PM, Dotzero wrote:
>> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos 
>> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>>Yes, it is simple DeMorgan’s Theorem where you use
>>short-circuiting logic.
>> 
>>DMARC says that any FAIL calculated via SPF or DKIM is an
>>overall DMARC failure.  In standard boolean logic is it an OR
>>condition:
>> 
>>IF SPF FAILS or DKIM FAILS Then Reject.
>> 
>> 
>> You have it absolutely backwards.
>> 
>> DMARC says if either (aligned) SPF validates or (aligned) DKIM validates, it 
>> passes.
> I don't follow you, so NO
> 
> a fail of either is a failure as a whole.
> 
> That is how the major EPS of late are applying it - per specs.

Hector, you’re wrong on this one. Check out 
https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.2. How would you 
interpret the following (follow link above for more context):
DMARC evaluation can only yield a "pass" result after one of the underlying 
authentication mechanisms passes for an aligned identifier.
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

[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

[dmarc-ietf] Author vs Signer Domains

[Hector Santos]

On 4/14/2023 7:31 PM, Dotzero wrote:
On Fri, Apr 14, 2023 at 5:55 PM Hector Santos 
> wrote:


Yes, it is simple DeMorgan’s Theorem where you use
short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an
overall DMARC failure.  In standard boolean logic is it an OR
condition:

IF SPF FAILS or DKIM FAILS Then Reject.


You have it absolutely backwards.

DMARC says if either (aligned) SPF validates or (aligned) DKIM 
validates, it passes.

I don't follow you, so NO

a fail of either is a failure as a whole.

That is how the major EPS of late are applying it - per specs.


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

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

[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] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023, 14:51 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Interoperability problems occur because MLMs believe they are exempt from
> the security problems that lesser mortals face.
>

This isn't true. Interoperability problems started when senders posted a
restrictive policy and receivers began enforcing it. The MLMs didn't have a
chance to form such a belief structure before things were already broken.


The Sender or MLM may be unhappy if lost eyes mean lost revenue, but an
> evaluator is tasked with disappointing senders, many times per day.
>

The Sender's users being denied the ability to participate in a list due to
its policies seems to me like it puts this customer service problem where
it belongs.

Document the issue as a customer service problem and I am on board.
>

Indeed.

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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Scott Kitterman]

On Friday, April 14, 2023 5:54:06 PM EDT Dotzero wrote:
> Barry wrote:
> 
> " The idea is MUST NOT because it harms interop with long-standing
> deployments.  If you decide you're more important than that, you do
> what you want and there it is.  It's as simple as that"
> 
> I could live with the normative MUST NOT if there were some non-normative
> text recognizing that there are domains that violate the MUST NOT but not
> in any way attempting to validate violating the MUST NOT. Is there any
> potential that such wordsmithing could break the apparent impasse? Just
> sort of noodling on this.

Due to the interoperability affects both on a domain's own message stream and 
side effects on other domain's email flow, domains with [unrestrictive] usage 
policies MUST NOT publish DMARC records with p=reject as the policy.  See 
Appendix [X] for information on how to ameliorate some of these issues and the 
possible side effects.

I bracketed [unrestrictive] because I'm reasonably confident that's not the 
right word, but I didn't think of another, better one.  I bracketed the [X] 
because I didn't look up where exactly I thought it ought to go.

Note: I do think only having p=reject in here is correct because p=quarantine 
doesn't have the same blow-back effects on third parties.

Something like that?

Scott K


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

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

On Fri, Apr 14, 2023 at 5:55 PM Hector Santos  wrote:

> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.
>
> DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC
> failure.  In standard boolean logic is it an OR condition:
>
> IF SPF FAILS or DKIM FAILS Then Reject.
>

You have it absolutely backwards.

DMARC says if either (aligned) SPF validates or (aligned) DKIM validates,
it passes.

Michael Hammer


> On Apr 14, 2023, at 5:44 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> Hector, it sounds like you are saying that SPF is all we need, so scrap
> DMARC.   If it is something else please clarify.
>
> Doug
>
> On Fri, Apr 14, 2023, 4:44 PM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>>
>>
>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy 
>> wrote:
>>
>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely 
>> wrote:
>>
>>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
>>> superu...@gmail.com> wrote:
>>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
>>> wrote:
>>> >>
>>> >>> Heck, MLMs should start rejecting messages sent from domains that
>>> publish a
>>> >>> blocking policy *when they fail authentication on entry*!!
>>> >>
>>> >> That's not enough to avoid the damage we're talking about.
>>>
>>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>>> completely ignoring ABUSE.
>>>
>>
>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against
>> rejection of messages merely because they fail authentication on ingress.
>>
>>
>> And respectfully, SPF always had a strong reject, hard fail policy
>> concept since it's LMAP R&D upbringing — immediate rejection, 55z rejection
>> code.
>>
>> Why Not?  It was optimized.  It served a purpose to address spoofs.
>> Partial, Neutral and Unknown results were possible. That was suppose to be
>> feed to a heuristics, highly subjective Reputation Engine. After exactly 20
>> years of data, SPF rejection rate is 6.3% of the incoming rejection
>> reasons. https://winserver.com/public/spamstats.wct
>>
>> I agree there are better solutions, but they're not yet developed.  As
>>> ugly as
>>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>>> repeat
>>> again that the IETF standardized facts, not theories...
>>>
>>
>> Let's put the challenge back on you: Where's your evidence that From
>> munging is the emerged consensus solution that this working group should
>> standardize?  Where is this _fact_?  If we advance that as a Proposed
>> Standard, the community will quite reasonably ask why we think this is
>> true, and we're going to need to be able to answer them.  If working group
>> consensus agrees, then away we go.
>>
>>
>> As much as I am an original mail engineering purest (anyone here ever
>> work with Fidonet?) and therefore consider it to be a fundamental taboo to
>> destroy originating copyrighted authorship of anything, the MLS/MLM needs
>> to evolve to handle the various 1::many broadcasting distributions under a
>> new security umbrella.
>>
>> Because the current DMARCbis umbrella ist not providing 100% coverage,
>> for the MLS./MLM, it needs to do one of two things;  restrict
>> subscription/submissions or strip the security and rewrite the copyrighting
>> authorship, perpetuating a potential harm including legal.
>>
>> The latter is not preferred.  The former would be normal part of a
>> protocol complete algorithm. You would do the former always.  It’s the
>> easiest.  No need to modify the MLS.  Just the MLM low code provisional
>> scripts.
>>
>> —
>> HLS
>> ___
>> 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] Example of Indirect Mail Flow Breakage with p=reject?

[Neil Anuskiewicz]

On Apr 14, 2023, at 2:54 PM, Dotzero  wrote:On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba  wrote:> I don’t think folks are objecting to cautionary language.  I think
> folks are objecting to a blanket MUST NOT.  If we're going to qualify
> the MUST NOT with a bunch of language, that's a bit different.   The
> original proposal was: "To be explicitly clear: domains used for
> general-purpose email MUST NOT deploy a DMARC policy of p=reject."
> I'm still fuzzy on what constitutes general purpose, or perhaps more
> accurately when p=reject is acceptable?  Is it acceptable to use
> p=quarantine in those cases?  If a domain (such as comcast.com)
> decides p=reject is what they really want .. then what? (I know, we're
> not the protocol police..)

The idea is MUST NOT because it harms interop with long-standing
deployments.  If you decide you're more important than that, you do
what you want and there it is.  It's as simple as that.  The "then
what" is that you don't interoperate with mailing lists (and perhaps
other things, depending upon the exact configuration).  That's the
definition of MUST NOT.  It doesn't mean that someone will come down
on you if you do.  It means you will likely fail to interoperate if
you do.

As to "what constitutes general purpose", if you are providing email
addresses to the general public, that qualifies.  If your domain is
sending email only from employees, and you have policies about
employees using their email addresses to conduct business, then that's
a different issue.  Of course, if their business involves posting to
mailing lists, you have some decisions to make.

Again, none of this is on pain of death.  We're just talking about how
to use the protocol interoperably.  If you have reasons you think are
important to do otherwise, you can do what you want.  The protocol
specification needs to define interoperability clearly and strictly.

BarryBarry wrote:"
The idea is MUST NOT because it harms interop with long-standing
deployments.  If you decide you're more important than that, you do
what you want and there it is.  It's as simple as that"I could live with the normative MUST NOT if there were some non-normative text recognizing that there are domains that violate the MUST NOT but not in any way attempting to validate violating the MUST NOT. Is there any potential that such wordsmithing could break the apparent impasse? Just sort of noodling on this.I really like the way this is headed.Neil___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.

DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC 
failure.  In standard boolean logic is it an OR condition:

IF SPF FAILS or DKIM FAILS Then Reject.

I hope you can understand this technical implementation detail.

—
HLS



> On Apr 14, 2023, at 5:44 PM, Douglas Foster 
>  wrote:
> 
> Hector, it sounds like you are saying that SPF is all we need, so scrap 
> DMARC.   If it is something else please clarify.
> 
> Doug
> 
> On Fri, Apr 14, 2023, 4:44 PM Hector Santos 
> mailto:40isdg@dmarc.ietf.org>> wrote:
>> 
>> 
>>> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy >> > wrote:
>>> 
>>> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely >> > wrote:
 On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
 > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
 > mailto:superu...@gmail.com>> wrote:
 >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely >>> >> > wrote:
 >>
 >>> Heck, MLMs should start rejecting messages sent from domains that 
 >>> publish a 
 >>> blocking policy *when they fail authentication on entry*!!
 >>
 >> That's not enough to avoid the damage we're talking about.
 
 Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
 completely ignoring ABUSE.
>>> 
>>> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection 
>>> of messages merely because they fail authentication on ingress. 
>> 
>> And respectfully, SPF always had a strong reject, hard fail policy concept 
>> since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.
>> 
>> Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
>> Neutral and Unknown results were possible. That was suppose to be feed to a 
>> heuristics, highly subjective Reputation Engine. After exactly 20 years of 
>> data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
>> https://winserver.com/public/spamstats.wct
>> 
 I agree there are better solutions, but they're not yet developed.  As 
 ugly as 
 it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
 repeat 
 again that the IETF standardized facts, not theories...
>>> 
>>> Let's put the challenge back on you: Where's your evidence that From 
>>> munging is the emerged consensus solution that this working group should 
>>> standardize?  Where is this _fact_?  If we advance that as a Proposed 
>>> Standard, the community will quite reasonably ask why we think this is 
>>> true, and we're going to need to be able to answer them.  If working group 
>>> consensus agrees, then away we go.
>> 
>> As much as I am an original mail engineering purest (anyone here ever work 
>> with Fidonet?) and therefore consider it to be a fundamental taboo to 
>> destroy originating copyrighted authorship of anything, the MLS/MLM needs to 
>> evolve to handle the various 1::many broadcasting distributions under a new 
>> security umbrella.
>> 
>> Because the current DMARCbis umbrella ist not providing 100% coverage, for 
>> the MLS./MLM, it needs to do one of two things;  restrict 
>> subscription/submissions or strip the security and rewrite the copyrighting 
>> authorship, perpetuating a potential harm including legal.
>> 
>> The latter is not preferred.  The former would be normal part of a protocol 
>> complete algorithm. You would do the former always.  It’s the easiest.  No 
>> need to modify the MLS.  Just the MLM low code provisional scripts.
>> 
>> —
>> HLS
>> ___
>> 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] Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba  wrote:

> > I don’t think folks are objecting to cautionary language.  I think
> > folks are objecting to a blanket MUST NOT.  If we're going to qualify
> > the MUST NOT with a bunch of language, that's a bit different.   The
> > original proposal was: "To be explicitly clear: domains used for
> > general-purpose email MUST NOT deploy a DMARC policy of p=reject."
> > I'm still fuzzy on what constitutes general purpose, or perhaps more
> > accurately when p=reject is acceptable?  Is it acceptable to use
> > p=quarantine in those cases?  If a domain (such as comcast.com)
> > decides p=reject is what they really want .. then what? (I know, we're
> > not the protocol police..)
>
> The idea is MUST NOT because it harms interop with long-standing
> deployments.  If you decide you're more important than that, you do
> what you want and there it is.  It's as simple as that.  The "then
> what" is that you don't interoperate with mailing lists (and perhaps
> other things, depending upon the exact configuration).  That's the
> definition of MUST NOT.  It doesn't mean that someone will come down
> on you if you do.  It means you will likely fail to interoperate if
> you do.
>
> As to "what constitutes general purpose", if you are providing email
> addresses to the general public, that qualifies.  If your domain is
> sending email only from employees, and you have policies about
> employees using their email addresses to conduct business, then that's
> a different issue.  Of course, if their business involves posting to
> mailing lists, you have some decisions to make.
>
> Again, none of this is on pain of death.  We're just talking about how
> to use the protocol interoperably.  If you have reasons you think are
> important to do otherwise, you can do what you want.  The protocol
> specification needs to define interoperability clearly and strictly.
>
> Barry
>

Barry wrote:

" The idea is MUST NOT because it harms interop with long-standing
deployments.  If you decide you're more important than that, you do
what you want and there it is.  It's as simple as that"

I could live with the normative MUST NOT if there were some non-normative
text recognizing that there are domains that violate the MUST NOT but not
in any way attempting to validate violating the MUST NOT. Is there any
potential that such wordsmithing could break the apparent impasse? Just
sort of noodling on this.

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

Interoperability problems occur because MLMs believe they are exempt from
the security problems that lesser mortals face.

I am not obligated to deliver every message that arrives for my users.  If
DMARC causes an evaluator to block a message that his user wants, they have
a  customer service problem, not an interoperability problem.   The
protocol correctly provided information which the evaluator used as he saw
fit.

The Sender or MLM may be unhappy if lost eyes mean lost revenue, but an
evaluator is tasked with disappointing senders, many times per day.

Document the issue as a customer service problem and I am on board.

Doug

On Fri, Apr 14, 2023, 1:59 PM Scott Kitterman  wrote:

> On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
> > On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"
>  wrote:
> > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
> wrote:
> > >>> Heck, MLMs should start rejecting messages sent from domains that
> > >>> publish a
> > >>> blocking policy *when they fail authentication on entry*!!
> > >>
> > >> That's not enough to avoid the damage we're talking about.
> >
> > Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> > completely ignoring ABUSE.
> >
> > >>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> > >>> substitute "de-facto" with "proposed".  Better methods, implying
> > >>> different, possibly experimental, protocols are to be defined in
> > >>> separate documents. >>
> > >>
> > >> Are you suggesting we put that forward as our Proposed Standard way of
> > >> dealing with this problem?  It's been my impression that this is not a
> > >> solution that's been well received.
> >
> > I agree there are better solutions, but they're not yet developed.  As
> ugly
> > as it may be, From: munging is the emerged solution.  It is a _fact_.
> Now
> > repeat again that the IETF standardized facts, not theories...
> >
> > >>> Let me recall that when I proposed something like that, I was told
> that
> > >>> that was phase II and the WG was then already in phase III.  So,
> let's
> > >>> complete DMARCbis /without cannibalizing the spec/ by saying that it
> > >>> MUST NOT be used (as it is being used already).
> > >>
> > >> What you describe as "cannibalizing" is actually a matter of
> presenting
> > >> the
> > >> correct normative advice about interoperability.
> >
> > It is nonsensical.  It means DMARC is only useful for looking at the
> > reports. If that's really what we think, we'd be better off deprecating
> p=
> > completely. Otherwise, let's wait until next April 1st and publish it as
> > such.  It's ridiculous.
> >
> > >>  So I don't agree at all with that characterization.
> > >
> > > Agreed.  If people can't get over saying some domains will have
> > > interoperability problems when that's demonstrably a technically
> accurate
> > > statement (and I don't see anyone claiming it isn't), I don't see how
> > > progress is possible.
> >
> > I agree that we have to say that some domains have interoperability
> problems
> > as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
> > unless (or until) better solutions arise, or unless they don't alter
> > messages.
> >
> > We're proposing email authentication, not anything less.
>
> Yes, but we don't get to close our eyes and pretend the rest of the world
> doesn't exist.
>
> If we want to change this, we're going to have to update RFC 5321, which I
> think is out of our scope.  In the section on aliases and lists (3.9), it
> says:
>
> >However, in this case, the message header section (RFC 5322 [4]) MUST
> >be left unchanged; in particular, the "From" field of the header
> >section is unaffected.
>
> I think it would be wrong to mandate From rewriting for a lot of reasons,
> but
> I don't think we get to just ignore an Internet Standard.  I think we
> particularly don't get to ignore an Internet Standard and make it through
> an
> IETF wide last call.
>
> I still don't hear anyone claiming there's no interoperability problems
> when
> some domains publish p=reject.  Can we please just agree to document
> reality
> and move forward?
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

Hector, it sounds like you are saying that SPF is all we need, so scrap
DMARC.   If it is something else please clarify.

Doug

On Fri, Apr 14, 2023, 4:44 PM Hector Santos  wrote:

>
>
> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy 
> wrote:
>
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  wrote:
>
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
>> wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that
>> publish a
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>>
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>>
>
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection
> of messages merely because they fail authentication on ingress.
>
>
> And respectfully, SPF always had a strong reject, hard fail policy concept
> since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.
>
> Why Not?  It was optimized.  It served a purpose to address spoofs.
> Partial, Neutral and Unknown results were possible. That was suppose to be
> feed to a heuristics, highly subjective Reputation Engine. After exactly 20
> years of data, SPF rejection rate is 6.3% of the incoming rejection
> reasons. https://winserver.com/public/spamstats.wct
>
> I agree there are better solutions, but they're not yet developed.  As
>> ugly as
>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>> repeat
>> again that the IETF standardized facts, not theories...
>>
>
> Let's put the challenge back on you: Where's your evidence that From
> munging is the emerged consensus solution that this working group should
> standardize?  Where is this _fact_?  If we advance that as a Proposed
> Standard, the community will quite reasonably ask why we think this is
> true, and we're going to need to be able to answer them.  If working group
> consensus agrees, then away we go.
>
>
> As much as I am an original mail engineering purest (anyone here ever work
> with Fidonet?) and therefore consider it to be a fundamental taboo to
> destroy originating copyrighted authorship of anything, the MLS/MLM needs
> to evolve to handle the various 1::many broadcasting distributions under a
> new security umbrella.
>
> Because the current DMARCbis umbrella ist not providing 100% coverage, for
> the MLS./MLM, it needs to do one of two things;  restrict
> subscription/submissions or strip the security and rewrite the copyrighting
> authorship, perpetuating a potential harm including legal.
>
> The latter is not preferred.  The former would be normal part of a
> protocol complete algorithm. You would do the former always.  It’s the
> easiest.  No need to modify the MLS.  Just the MLM low code provisional
> scripts.
>
> —
> HLS
> ___
> 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 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] Signaling MLMs

[Hector Santos]

> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy  wrote:
> 
> On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  > wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>> > mailto:superu...@gmail.com>> wrote:
>> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely > >> > wrote:
>> >>
>> >>> Heck, MLMs should start rejecting messages sent from domains that 
>> >>> publish a 
>> >>> blocking policy *when they fail authentication on entry*!!
>> >>
>> >> That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
>> completely ignoring ABUSE.
> 
> Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection of 
> messages merely because they fail authentication on ingress. 

And respectfully, SPF always had a strong reject, hard fail policy concept 
since it's LMAP R&D upbringing — immediate rejection, 55z rejection code.

Why Not?  It was optimized.  It served a purpose to address spoofs. Partial, 
Neutral and Unknown results were possible. That was suppose to be feed to a 
heuristics, highly subjective Reputation Engine. After exactly 20 years of 
data, SPF rejection rate is 6.3% of the incoming rejection reasons. 
https://winserver.com/public/spamstats.wct

>> I agree there are better solutions, but they're not yet developed.  As ugly 
>> as 
>> it may be, From: munging is the emerged solution.  It is a _fact_.  Now 
>> repeat 
>> again that the IETF standardized facts, not theories...
> 
> Let's put the challenge back on you: Where's your evidence that From munging 
> is the emerged consensus solution that this working group should standardize? 
>  Where is this _fact_?  If we advance that as a Proposed Standard, the 
> community will quite reasonably ask why we think this is true, and we're 
> going to need to be able to answer them.  If working group consensus agrees, 
> then away we go.

As much as I am an original mail engineering purest (anyone here ever work with 
Fidonet?) and therefore consider it to be a fundamental taboo to destroy 
originating copyrighted authorship of anything, the MLS/MLM needs to evolve to 
handle the various 1::many broadcasting distributions under a new security 
umbrella.

Because the current DMARCbis umbrella ist not providing 100% coverage, for the 
MLS./MLM, it needs to do one of two things;  restrict subscription/submissions 
or strip the security and rewrite the copyrighting authorship, perpetuating a 
potential harm including legal.

The latter is not preferred.  The former would be normal part of a protocol 
complete algorithm. You would do the former always.  It’s the easiest.  No need 
to modify the MLS.  Just the MLM low code provisional scripts.

—
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

[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] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely  wrote:

> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely 
> wrote:
> >>
> >>> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >>
> >> That's not enough to avoid the damage we're talking about.
>
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
>

Both DKIM (certainly) and SPF (I'm pretty sure) advocate against rejection
of messages merely because they fail authentication on ingress.  They both
acknowledge that there are perfectly legitimate mail flows where that can
happen.  Since DMARC is built on those foundations, I think your assertion
strains reason.  That is, it's weird to say "If you observe DKIM and SPF,
don't reject; but if you observe DMARC, do."

>>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
>
> I agree there are better solutions, but they're not yet developed.  As
> ugly as
> it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat
> again that the IETF standardized facts, not theories...
>

Let's put the challenge back on you: Where's your evidence that From
munging is the emerged consensus solution that this working group should
standardize?  Where is this _fact_?  If we advance that as a Proposed
Standard, the community will quite reasonably ask why we think this is
true, and we're going to need to be able to answer them.  If working group
consensus agrees, then away we go.

Laura, I believe, enumerated a few reasons why it doesn't work all that
well.  We'll need to explain why that's all fine.


> >> What you describe as "cannibalizing" is actually a matter of presenting
> the
> >> correct normative advice about interoperability.
>
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports.
> If that's really what we think, we'd be better off deprecating p=
> completely.
> Otherwise, let's wait until next April 1st and publish it as such.  It's
> ridiculous.
>

I think that's rather hyperbolic, but ignoring that for the moment, there
is some validity to the idea that the reports part of DMARC is the only
part of DMARC that does not disrupt interoperability.

>>  So I don't agree at all with that characterization.
> >
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically
> accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
>
> I agree that we have to say that some domains have interoperability
> problems as
> a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless
> (or
> until) better solutions arise, or unless they don't alter messages.
>
> We're proposing email authentication, not anything less.
>

Sure, but that proposal is -- clearly by now -- fraught with disruption.
We can't ignore it because it's inconvenient to DMARC's goal.

This is the first time I've ever heard someone push the idea that From
munging deserves Proposed Standard status.  I'd be happy to hear what
others think.  If that's actually a sleeper consensus of some kind, then
out with it.

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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

The solution to move forward is:

- Recommend MUST NOT publish if domain wants to allow users to use domain in 
public list systems,

- Warn MLS/MLS  to avoid From Rewrite and recommend to honor p=reject by 
rejecting subscription, submissions. This is already in practice since 2011.

- Update section 4.4.3 to assist domains with a desire to use p=reject to 
consider supporting extended technologies to help with public usage of p=reject.

- Add a section for marketers of DMARC security systems to assist in correcting 
this problem with less aggressive campaigns to be prepare mail hosting 
customers with p=reject policies before they’re ready to do so. Always start 
with p=none.

- Make DMARCbis Informational status for faster IETF adoption  As a proposed 
standard, it’s going to be a rough poison pill too shallow after ADSP was 
abandoned for the same problems.  The difference now is this MUST NOT publish 
and honor for DMARCbis.  This may be enough to get IETF endorsement for a 
proposed standard.  

—
HLS


> On Apr 14, 2023, at 1:58 PM, Scott Kitterman  wrote:
> 
> On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
>> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
>>> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
>  wrote:
 On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> Heck, MLMs should start rejecting messages sent from domains that
> publish a
> blocking policy *when they fail authentication on entry*!!
 
 That's not enough to avoid the damage we're talking about.
>> 
>> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
>> completely ignoring ABUSE.
>> 
> From: rewriting is the de-facto standard.  In DMARCbis we can only
> substitute "de-facto" with "proposed".  Better methods, implying
> different, possibly experimental, protocols are to be defined in
> separate documents. >>
 
 Are you suggesting we put that forward as our Proposed Standard way of
 dealing with this problem?  It's been my impression that this is not a
 solution that's been well received.
>> 
>> I agree there are better solutions, but they're not yet developed.  As ugly
>> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
>> repeat again that the IETF standardized facts, not theories...
>> 
> Let me recall that when I proposed something like that, I was told that
> that was phase II and the WG was then already in phase III.  So, let's
> complete DMARCbis /without cannibalizing the spec/ by saying that it
> MUST NOT be used (as it is being used already).
 
 What you describe as "cannibalizing" is actually a matter of presenting
 the
 correct normative advice about interoperability.
>> 
>> It is nonsensical.  It means DMARC is only useful for looking at the
>> reports. If that's really what we think, we'd be better off deprecating p=
>> completely. Otherwise, let's wait until next April 1st and publish it as
>> such.  It's ridiculous.
>> 
 So I don't agree at all with that characterization.
>>> 
>>> Agreed.  If people can't get over saying some domains will have
>>> interoperability problems when that's demonstrably a technically accurate
>>> statement (and I don't see anyone claiming it isn't), I don't see how
>>> progress is possible.
>> 
>> I agree that we have to say that some domains have interoperability problems
>> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
>> unless (or until) better solutions arise, or unless they don't alter
>> messages.
>> 
>> We're proposing email authentication, not anything less.
> 
> Yes, but we don't get to close our eyes and pretend the rest of the world 
> doesn't exist.
> 
> If we want to change this, we're going to have to update RFC 5321, which I 
> think is out of our scope.  In the section on aliases and lists (3.9), it 
> says:
> 
>>   However, in this case, the message header section (RFC 5322 [4]) MUST
>>   be left unchanged; in particular, the "From" field of the header
>>   section is unaffected.
> 
> I think it would be wrong to mandate From rewriting for a lot of reasons, but 
> I don't think we get to just ignore an Internet Standard.  I think we 
> particularly don't get to ignore an Internet Standard and make it through an 
> IETF wide last call.
> 
> I still don't hear anyone claiming there's no interoperability problems when 
> some domains publish p=reject.  Can we please just agree to document reality 
> and move forward?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] 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] Signaling MLMs

[Scott Kitterman]

On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote:
> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:
> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" 
 wrote:
> >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> >>> Heck, MLMs should start rejecting messages sent from domains that
> >>> publish a
> >>> blocking policy *when they fail authentication on entry*!!
> >> 
> >> That's not enough to avoid the damage we're talking about.
> 
> Agreed.  Yet, it is a sane half-way between crazy rejecting always and
> completely ignoring ABUSE.
> 
> >>> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >>> substitute "de-facto" with "proposed".  Better methods, implying
> >>> different, possibly experimental, protocols are to be defined in
> >>> separate documents. >>
> >> 
> >> Are you suggesting we put that forward as our Proposed Standard way of
> >> dealing with this problem?  It's been my impression that this is not a
> >> solution that's been well received.
> 
> I agree there are better solutions, but they're not yet developed.  As ugly
> as it may be, From: munging is the emerged solution.  It is a _fact_.  Now
> repeat again that the IETF standardized facts, not theories...
> 
> >>> Let me recall that when I proposed something like that, I was told that
> >>> that was phase II and the WG was then already in phase III.  So, let's
> >>> complete DMARCbis /without cannibalizing the spec/ by saying that it
> >>> MUST NOT be used (as it is being used already).
> >> 
> >> What you describe as "cannibalizing" is actually a matter of presenting
> >> the
> >> correct normative advice about interoperability.
> 
> It is nonsensical.  It means DMARC is only useful for looking at the
> reports. If that's really what we think, we'd be better off deprecating p=
> completely. Otherwise, let's wait until next April 1st and publish it as
> such.  It's ridiculous.
> 
> >>  So I don't agree at all with that characterization.
> > 
> > Agreed.  If people can't get over saying some domains will have
> > interoperability problems when that's demonstrably a technically accurate
> > statement (and I don't see anyone claiming it isn't), I don't see how
> > progress is possible.
> 
> I agree that we have to say that some domains have interoperability problems
> as a consequence of DMARC.  Let's say that MLMs MUST do From: munging
> unless (or until) better solutions arise, or unless they don't alter
> messages.
> 
> We're proposing email authentication, not anything less.

Yes, but we don't get to close our eyes and pretend the rest of the world 
doesn't exist.

If we want to change this, we're going to have to update RFC 5321, which I 
think is out of our scope.  In the section on aliases and lists (3.9), it 
says:

>However, in this case, the message header section (RFC 5322 [4]) MUST
>be left unchanged; in particular, the "From" field of the header
>section is unaffected.

I think it would be wrong to mandate From rewriting for a lot of reasons, but 
I don't think we get to just ignore an Internet Standard.  I think we 
particularly don't get to ignore an Internet Standard and make it through an 
IETF wide last call.

I still don't hear anyone claiming there's no interoperability problems when 
some domains publish p=reject.  Can we please just agree to document reality 
and move forward?

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

[Alessandro Vesely]

On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote:

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"  
wrote:

On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:

Heck, MLMs should start rejecting messages sent from domains that publish a 
blocking policy *when they fail authentication on entry*!!


That's not enough to avoid the damage we're talking about.



Agreed.  Yet, it is a sane half-way between crazy rejecting always and 
completely ignoring ABUSE.



From: rewriting is the de-facto standard.  In DMARCbis we can only 
substitute "de-facto" with "proposed".  Better methods, implying 
different, possibly experimental, protocols are to be defined in 
separate documents. >>
Are you suggesting we put that forward as our Proposed Standard way of 
dealing with this problem?  It's been my impression that this is not a 
solution that's been well received.



I agree there are better solutions, but they're not yet developed.  As ugly as 
it may be, From: munging is the emerged solution.  It is a _fact_.  Now repeat 
again that the IETF standardized facts, not theories...



Let me recall that when I proposed something like that, I was told that 
that was phase II and the WG was then already in phase III.  So, let's 
complete DMARCbis /without cannibalizing the spec/ by saying that it 
MUST NOT be used (as it is being used already).


What you describe as "cannibalizing" is actually a matter of presenting the 
correct normative advice about interoperability.



It is nonsensical.  It means DMARC is only useful for looking at the reports. 
If that's really what we think, we'd be better off deprecating p= completely. 
Otherwise, let's wait until next April 1st and publish it as such.  It's 
ridiculous.




 So I don't agree at all with that characterization.


Agreed.  If people can't get over saying some domains will have 
interoperability problems when that's demonstrably a technically accurate 
statement (and I don't see anyone claiming it isn't), I don't see how 
progress is possible.


I agree that we have to say that some domains have interoperability problems as 
a consequence of DMARC.  Let's say that MLMs MUST do From: munging unless (or 
until) better solutions arise, or unless they don't alter messages.


We're proposing email authentication, not anything less.


Best
Ale
--







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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

The situation will converge to two separate but unequal environments, those
that prioritize security, and those that require insecurity.

As people get burned, the pro-security segment will grow and the insecure
segment will find more and more restrictions on their ability to connect to
their high-risk environments

I see no reason to expect any other outcome.Whatever words we publish
will be ignored or followed based on the camp that domains have chosen.

Doug Foster

On Fri, Apr 14, 2023, 9:48 AM Scott Kitterman  wrote:

>
>
> On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
> >
> >> Heck, MLMs should start rejecting messages sent from domains that
> publish
> >> a
> >> blocking policy *when they fail authentication on entry*!!
> >>
> >
> >That's not enough to avoid the damage we're talking about.
> >
> >
> >> From: rewriting is the de-facto standard.  In DMARCbis we can only
> >> substitute
> >> "de-facto" with "proposed".  Better methods, implying different,
> possibly
> >> experimental, protocols are to be defined in separate documents.
> >>
> >
> >Are you suggesting we put that forward as our Proposed Standard way of
> >dealing with this problem?  It's been my impression that this is not a
> >solution that's been well received.
> >
> >
> >> Let me recall that when I proposed something like that, I was told that
> >> that
> >> was phase II and the WG was then already in phase III.  So, let's
> complete
> >> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
> >> used
> >> (as it is being used already).
> >>
> >
> >What you describe as "cannibalizing" is actually a matter of presenting
> the
> >correct normative advice about interoperability.  So I don't agree at all
> >with that characterization.
>
> Agreed.  If people can't get over saying some domains will have
> interoperability problems when that's demonstrably a technically accurate
> statement (and I don't see anyone claiming it isn't), I don't see how
> progress is possible.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman]

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy"  
wrote:
>On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:
>
>> Heck, MLMs should start rejecting messages sent from domains that publish
>> a
>> blocking policy *when they fail authentication on entry*!!
>>
>
>That's not enough to avoid the damage we're talking about.
>
>
>> From: rewriting is the de-facto standard.  In DMARCbis we can only
>> substitute
>> "de-facto" with "proposed".  Better methods, implying different, possibly
>> experimental, protocols are to be defined in separate documents.
>>
>
>Are you suggesting we put that forward as our Proposed Standard way of
>dealing with this problem?  It's been my impression that this is not a
>solution that's been well received.
>
>
>> Let me recall that when I proposed something like that, I was told that
>> that
>> was phase II and the WG was then already in phase III.  So, let's complete
>> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
>> used
>> (as it is being used already).
>>
>
>What you describe as "cannibalizing" is actually a matter of presenting the
>correct normative advice about interoperability.  So I don't agree at all
>with that characterization.

Agreed.  If people can't get over saying some domains will have 
interoperability problems when that's demonstrably a technically accurate 
statement (and I don't see anyone claiming it isn't), I don't see how progress 
is possible.

Scott K

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely  wrote:

> Heck, MLMs should start rejecting messages sent from domains that publish
> a
> blocking policy *when they fail authentication on entry*!!
>

That's not enough to avoid the damage we're talking about.


> From: rewriting is the de-facto standard.  In DMARCbis we can only
> substitute
> "de-facto" with "proposed".  Better methods, implying different, possibly
> experimental, protocols are to be defined in separate documents.
>

Are you suggesting we put that forward as our Proposed Standard way of
dealing with this problem?  It's been my impression that this is not a
solution that's been well received.


> Let me recall that when I proposed something like that, I was told that
> that
> was phase II and the WG was then already in phase III.  So, let's complete
> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be
> used
> (as it is being used already).
>

What you describe as "cannibalizing" is actually a matter of presenting the
correct normative advice about interoperability.  So I don't agree at all
with that characterization.

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

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Hector Santos]

On 4/14/2023 7:43 AM, Alessandro Vesely wrote:

On Thu 13/Apr/2023 18:01:40 +0200 John R Levine wrote:

In ADSP I made the equivalent policy "discardable" to reinforce 
this point.  My co-authors weren't happy about it, but they 
couldn't disagree.


ADSP was different from DMARC.



ADSP dkim=discardable basically said "Expect mail to be always signed 
by the author and only the author if not, discard" which is basically 
DMARC p=reject.   Discard is used because was possible to process 
after acceptance. So to avoid the "required" bounce, this authorize 
mail men discard it. Don't bounce it, don't let the user see it.   If 
DMARC was processed at data before acceptance, then its a 55z Reject 
concept.  So the same as DMARC p=reject.


ADSP dkim=all said "expect my mail to be signed by someone"

We could not finish this 3rd party idea of authorizing the always signed.

DMARC needs this Always Signed by someone idea too with ATPS to finish 
the authorization missing piece.


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

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

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Alessandro Vesely]

On Thu 13/Apr/2023 17:21:30 +0200 Barry Leiba wrote:

Anyone who does forwarding is damaged by DMARC because there are a lot of
people who do DMARC on the cheap with SPF only.


This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC reliability, and
using SPF only, without DKIM, is strongly NOT RECOMMENDED.



+1.  However, properly used SPF implies extensive whitelisting.  It is 
relegated to Appendix D in RFC 7208, but it's the only one thing that makes SPF 
effective.


Best
Ale
--




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

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Alessandro Vesely]

On Thu 13/Apr/2023 18:01:40 +0200 John R Levine wrote:


I'm trying to figure out where best to say this, but when you say p=reject, you 
are saying your mail is *not* important, and if there is any doubt about it, 
you want recipients to throw it away, even though some of your real mail will 
get lost.



Hm... What p= should I set i I consider my mail important and wand people to 
throw away fakes?


To wit, if there was a Mailman option to say "reject my posts on verification 
failure", I'd click it.  In this respect, reject is much safer than quarantine, 
because, if the message was authentic, I'd get a bounce, correct a signing 
error and re-send.  Pretty safe.



In ADSP I made the equivalent policy "discardable" to reinforce this point.  My 
co-authors weren't happy about it, but they couldn't disagree.



ADSP was different from DMARC.


Best
Ale
--





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

Re: [dmarc-ietf] General-purpose domains with users from the general public MUST NOT use p=reject

[Mark Alley]

I can agree with the premise of this version. This expanded definition of
"general purpose" domains makes it somewhat more clear what/who the
intended target for the language is.

- Mark Alley


On Fri, Apr 14, 2023, 4:16 AM Matthäus Wander  wrote:

> Barry Leiba wrote on 2023-04-14 03:52:
> > As to "what constitutes general purpose", if you are providing email
> > addresses to the general public, that qualifies.  If your domain is
> > sending email only from employees, and you have policies about
> > employees using their email addresses to conduct business, then that's
> > a different issue.  Of course, if their business involves posting to
> > mailing lists, you have some decisions to make.
>
> How about this?
>
> 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 the Domain Owner may never use
> a policy of p=quarantine or p=reject, and that these policies are
> intended not as goals, but as policies available for use when they
> are appropriate.  In particular, domains with users from the general
> public, where the Domain Owner has no overview about and no
> intention to govern with who their users communicate with, MUST NOT
> deploy a policy of p=reject to preserve interoperability.  In such
> scenarios, the deployment of a policy other than p=none can disrupt
> indirect mail flows and cause damage to the operation of mailing
> lists and other forwarding services that are incompatible with
> DMARC.  This is discussed in [RFC7960] and in Section 5.8, below.
>
> Regards,
> Matt
>
> ___
> 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] Signaling MLMs

[Alessandro Vesely]

On Thu 13/Apr/2023 17:57:55 +0200 Dotzero wrote:

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy  
wrote:

On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones  wrote:

In any case, are we really going to start suggesting that list operators 
start rejecting messages sent from domains that publish a blocking policy, 
as official guidance? (Now I'm looking ever so forward to catching up on 
these other threads - what the heck are people seeing out there??)



Heck, MLMs should start rejecting messages sent from domains that publish a 
blocking policy *when they fail authentication on entry*!!



Well, this WG is chartered to come up with some kind of standards track 
solution to the problem.  I don't see one in DMARCbis at the moment.  Given 
how long this WG has existed so far, that's a fairly glaring omission. 
Doesn't seem to me this idea should be off the table just yet...


I don't think it should be off the table but believe it is only one of the 
options that MLMs/forwarders have.



From: rewriting is the de-facto standard.  In DMARCbis we can only substitute 
"de-facto" with "proposed".  Better methods, implying different, possibly 
experimental, protocols are to be defined in separate documents.


Let me recall that when I proposed something like that, I was told that that 
was phase II and the WG was then already in phase III.  So, let's complete 
DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be used 
(as it is being used already).


If it will be possible to get back to indirect mail flows, there's more work to 
do there.



Best
Ale
--





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

[dmarc-ietf] General-purpose domains with users from the general public MUST NOT use p=reject

[Matthäus Wander]

Barry Leiba wrote on 2023-04-14 03:52:

As to "what constitutes general purpose", if you are providing email
addresses to the general public, that qualifies.  If your domain is
sending email only from employees, and you have policies about
employees using their email addresses to conduct business, then that's
a different issue.  Of course, if their business involves posting to
mailing lists, you have some decisions to make.


How about this?

   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 the Domain Owner may never use
   a policy of p=quarantine or p=reject, and that these policies are
   intended not as goals, but as policies available for use when they
   are appropriate.  In particular, domains with users from the general
   public, where the Domain Owner has no overview about and no
   intention to govern with who their users communicate with, MUST NOT
   deploy a policy of p=reject to preserve interoperability.  In such
   scenarios, the deployment of a policy other than p=none can disrupt
   indirect mail flows and cause damage to the operation of mailing
   lists and other forwarding services that are incompatible with
   DMARC.  This is discussed in [RFC7960] and in Section 5.8, below.

Regards,
Matt

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