Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

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

> This puts me in mind of Section 8.5, which calls out some potential
> impacts of blocking policies to "Mediators," which role doesn't otherwise
> appear very often in this document. Is there any need to add Mediator
> Actions/Considerations under section 5? Or does this belong in a separate
> document?
>

We should probably review it and think about whether what it says is
enough.

> ISTR there were some vocal and visible mailing list operators that were
> rejecting messages from domains that published "p=reject" policies, maybe
> around 2014-15? I also thought they did this by checking the sending
> domain's published policy in DNS, to your point about implementation.
>
This would be great [anec-]data to have.  Do you remember where you might
have seen it?

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

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

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  wrote:

> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
> wrote:
>
>> I've been thinking about the point a few people have made now that DMARC
>> has two actors that cause the problem: Those who "blindly" apply
>> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
>> to tango; enforcement doesn't happen without an advertising sender and a
>> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
>> cover both ends.  We need to be careful about admonishing participating
>> receivers though.  What would we say to them about how to be selective in
>> application?
>>
>
> I'd argue that we have language already that advises receivers to be
> selective in application. The second paragraph of section 5.8, Policy
> Enforcement Considerations, currently reads as follows in DMARCbis:
>
> Mail Receivers MAY choose to accept email that fails the DMARC mechanism
> check even if the published Domain Owner Assessment Policy is "reject". In
> particular, because of the considerations discussed in [RFC7960
> ],
> it is important that Mail Receivers SHOULD NOT reject messages solely
> because of a published policy of "reject", but that they apply other
> knowledge and analysis to avoid situations such as rejection of legitimate
> messages sent in ways that DMARC cannot describe, harm to the operation of
> mailing lists, and similar.
>
>
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider
>
> Might that language be made stronger? Sure. Might it or other text include
> mention of ARC as a possible solution? Maybe.
>

Right, thanks for the reminder.

I think part of the problem might be that blanket observance of "reject" is
already commonplace.  There's also very little in the way of algorithms or
text guidance to indicate to receivers how they're supposed to know when
it's safe to actually reject.


>
> I've also been thinking about ways to push the burden back on the
>> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
>> can take advantage of indicating to them that the author is using a strong
>> policy, and so it would be possibly a bad idea for the MLM to accept,
>> mutate, and re-send this message.  This could be a header field or an SMTP
>> extension (though the latter is complex to get right in a store-and-forward
>> system).  The MLM can then decide if it is willing to pass the message
>> unmodified to the list, or reject it with an error like "The policies of
>> this list require modification of your message, which violates your
>> domain's apparent policy.  Your submission therefore cannot be accepted.
>> Please contact your support organization for further assistance."  There's
>> never an opportunity for the collateral bounce to occur if the message is
>> never distributed, and the author domain has to either soften its policy or
>> separate its regular users from its transactional stuff somehow.
>>
>> This avoids the "collateral" and "persistent" damage issues I raised in a
>> separate post.  It still requires the MLMs to do something new, but avoids
>> the need to implement any of a variety of unsavory mutations.  MLMs could
>> also determine this by querying the current DMARC policy of the author's
>> domain, to be sure, so it's a choice between MLMs looking for a header
>> field (which they already know how to do) or becoming DNS-aware (relatively
>> simple, but pulls in some complexities and dependencies they may not want).
>>
>
> My preference here would be to add text for Domain Owners to make them
> understand the ways that p=reject might cause some mail using their domain
> to not make it to its destination, with "mailing lists might reject your
> mail" being one such example.
>

And a good example, given it's the most obvious one.  But is it enough to
say that and nothing else?  What about MLMs actually doing something like
this?

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

Re: [dmarc-ietf] THIS IS ABUSE (it might be)

[John R Levine]

On Wed, 12 Apr 2023, Eric D. Williams wrote:

No, it's a DMARC problem. DKIM didn't cause any problems for mailing

lists ...



mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's
a failure with DKIM signature invalidation as a result of relaying via
mailing lists.


My mailing lists put their own DKIM signature on the outgoing mail, and 
the DKIN spec says to ignore signatures that don't validate, so as far as 
DKIM is concerned, that mail is fully authenticated.  As RFC 6376 says:


  INFORMATIVE RATIONALE: The signing identity specified by a DKIM
  signature is not required to match an address in any particular
  header field because of the broad methods of interpretation by
  recipient mail systems, including MUAs.

It's only DMARC that adds a new and in this case unfortunate rule that 
requires a DKIM signature that matches the domain in the From header.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] THIS IS ABUSE (it might be)

[Eric D. Williams]

On Mon, Apr 10, 2023 at 9:30 AM John R Levine  wrote:

> On Mon, 10 Apr 2023, Alessandro Vesely wrote:
> > On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote:
> >> It appears that Eric D. Williams   said:
> >>> -=-=-=-=-=-
> >>>
> >>> I think the reliance upon list operators is properly placed on that
> role.
> >>> It's not a DMARC problem, it's a DKIM problem, I think.
> >>
> >> No, it's a DMARC problem. DKIM didn't cause any problems for mailing
> lists
> >> (ignoring ill-advised and never used ADSP) until DMARC was layered on
> top
> >> of it, and AOL and Yahoo abused it to foist the support costs on the
> rest
> >> of the world after they let crooks steal their users' address books.
> >
>

I disagree.  Despite the failure of adoption of ADSP, which is not a new
thing by any stretch - we've seen that before, if we are talking about
mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's
a failure with DKIM signature invalidation as a result of relaying via
mailing lists.


> > That's how it happened.  Can we now accept their push?  After so many
> email
> > addresses became public, how about accepting that email addresses being
> > public doesn't have to imply that anyone can impersonate them?
>
> No, that's not what happened.  People had been faking AOL and Yahoo
> addresses forever and the providers dealt with it.  The problem was that
> spammers used the stolen address books to send spam from the addresses of
> people the recipients knew, and they were flooded with complaints "why are
> my friends spamming me."  It's entirely the fault of those providers'
> poor security.
>
> Re impersonating, until DMARC can tell the difference between
> impersonation and the kinds of ordinary forwarding we've been doing since
> the 1980s, nope.
>

Now, perhaps I misunderstood the original thread, so I'll cop to that, but
I will assert that although DMARC can certainly provide some legitimacy
assurances it certainly does have a gap with impersonation, particularly
manifested with maillist relaying in many common configurations.


>
> R's,
> John
>

/r/

-e


-- 
Eric D. Williams 
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF  7B19 0544 A590 FF65 B789
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy  wrote:
> 
> I've been thinking about the point a few people have made now that DMARC has 
> two actors that cause the problem: Those who "blindly" apply "p=reject", and 
> those who advertise "p=reject".  You do, indeed, need two to tango; 
> enforcement doesn't happen without an advertising sender and a participating 
> receiver.  Maybe any "MUST NOT" advice we provide needs to cover both ends.  
> We need to be careful about admonishing participating receivers though.  What 
> would we say to them about how to be selective in application?

Murray, you have RFC 5016 Section 10.3, Item10 as a Functional Specification 
reinforcement basis for a MUST NOT honor DMARC p=reject that causes 3rd party 
problems.   Even though 5016 applied to SSP, it applies equally to DMARCbis too.

—
HLS


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

Re: [dmarc-ietf] Signaling MLMs

[Steven M Jones]

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:


The MLM can then decide if it is willing to pass the message 
unmodified to the list, or reject it with an error like "The policies 
of this list require modification of your message, which violates your 
domain's apparent policy.  Your submission therefore cannot be 
accepted.  Please contact your support organization for further 
assistance."  There's never an opportunity for the collateral bounce 
to occur if the message is never distributed, and the author domain 
has to either soften its policy or separate its regular users from its 
transactional stuff somehow.


This puts me in mind of Section 8.5, which calls out some potential 
impacts of blocking policies to "Mediators," which role doesn't 
otherwise appear very often in this document. Is there any need to add 
Mediator Actions/Considerations under section 5? Or does this belong in 
a separate document?


ISTR there were some vocal and visible mailing list operators that were 
rejecting messages from domains that published "p=reject" policies, 
maybe around 2014-15? I also thought they did this by checking the 
sending domain's published policy in DNS, to your point about 
implementation.


In which case I think this approach was tried, and I don't recall it 
persisting as a pain point for terribly long - perhaps they moved on to 
"unsavory mutations..."


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



On 4/12/23 11:41 AM, Todd Herr wrote:

My preference here would be to add text for Domain Owners to make them 
understand the ways that p=reject might cause some mail using their 
domain to not make it to its destination, with "mailing lists might 
reject your mail" being one such example.
Yes, it seems like we'd either add something short to domain owner 
considerations per Todd, or we'd need to add considerably more to cover 
list operators and/or other Mediators.


--S.

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

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

My own feeling is that lists should have a service agreement / disclosure
statement that says,
"We will modify your text in {manner} for {reason}.".
"We will do {feature} to reduce the risk of unwanted or dangerous list
posts".
"We will do {feature} to minimize use of off-topic posts.   The following
behaviors will ..."
"Your email address will be released to all list participants.   This list
does not condone use of list addresses for non-lust purposes, but cannot
prevent that from occurring.   Consider this possibility when choosing an
address to use for list participation."

My only point of reference is this list, and I am not happy that such a
disclosure was not provided at sign-up.

DF


On Wed, Apr 12, 2023, 2:16 PM Murray S. Kucherawy 
wrote:

> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
> cover both ends.  We need to be careful about admonishing participating
> receivers though.  What would we say to them about how to be selective in
> application?
>
> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
> can take advantage of indicating to them that the author is using a strong
> policy, and so it would be possibly a bad idea for the MLM to accept,
> mutate, and re-send this message.  This could be a header field or an SMTP
> extension (though the latter is complex to get right in a store-and-forward
> system).  The MLM can then decide if it is willing to pass the message
> unmodified to the list, or reject it with an error like "The policies of
> this list require modification of your message, which violates your
> domain's apparent policy.  Your submission therefore cannot be accepted.
> Please contact your support organization for further assistance."  There's
> never an opportunity for the collateral bounce to occur if the message is
> never distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post.  It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations.  MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>
> -MSK, trying to be useful here
> ___
> 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

[Todd Herr]

On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy 
wrote:

> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject".  You do, indeed, need two
> to tango; enforcement doesn't happen without an advertising sender and a
> participating receiver.  Maybe any "MUST NOT" advice we provide needs to
> cover both ends.  We need to be careful about admonishing participating
> receivers though.  What would we say to them about how to be selective in
> application?
>

I'd argue that we have language already that advises receivers to be
selective in application. The second paragraph of section 5.8, Policy
Enforcement Considerations, currently reads as follows in DMARCbis:

Mail Receivers MAY choose to accept email that fails the DMARC mechanism
check even if the published Domain Owner Assessment Policy is "reject". In
particular, because of the considerations discussed in [RFC7960
],
it is important that Mail Receivers SHOULD NOT reject messages solely
because of a published policy of "reject", but that they apply other
knowledge and analysis to avoid situations such as rejection of legitimate
messages sent in ways that DMARC cannot describe, harm to the operation of
mailing lists, and similar.

https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider

Might that language be made stronger? Sure. Might it or other text include
mention of ARC as a possible solution? Maybe.


> We've talked about having signal from the enforcing receivers back to the
> MLM that the bounce occurred because of DMARC, but we haven't seen much
> uptake of that idea for various reasons.
>
> I've also been thinking about ways to push the burden back on the
> advertisers.  Imagine we have some kind of signaling mechanism that MLMs
> can take advantage of indicating to them that the author is using a strong
> policy, and so it would be possibly a bad idea for the MLM to accept,
> mutate, and re-send this message.  This could be a header field or an SMTP
> extension (though the latter is complex to get right in a store-and-forward
> system).  The MLM can then decide if it is willing to pass the message
> unmodified to the list, or reject it with an error like "The policies of
> this list require modification of your message, which violates your
> domain's apparent policy.  Your submission therefore cannot be accepted.
> Please contact your support organization for further assistance."  There's
> never an opportunity for the collateral bounce to occur if the message is
> never distributed, and the author domain has to either soften its policy or
> separate its regular users from its transactional stuff somehow.
>
> This avoids the "collateral" and "persistent" damage issues I raised in a
> separate post.  It still requires the MLMs to do something new, but avoids
> the need to implement any of a variety of unsavory mutations.  MLMs could
> also determine this by querying the current DMARC policy of the author's
> domain, to be sure, so it's a choice between MLMs looking for a header
> field (which they already know how to do) or becoming DNS-aware (relatively
> simple, but pulls in some complexities and dependencies they may not want).
>

My preference here would be to add text for Domain Owners to make them
understand the ways that p=reject might cause some mail using their domain
to not make it to its destination, with "mailing lists might reject your
mail" being one such example.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

I've been thinking about the point a few people have made now that DMARC
has two actors that cause the problem: Those who "blindly" apply
"p=reject", and those who advertise "p=reject".  You do, indeed, need two
to tango; enforcement doesn't happen without an advertising sender and a
participating receiver.  Maybe any "MUST NOT" advice we provide needs to
cover both ends.  We need to be careful about admonishing participating
receivers though.  What would we say to them about how to be selective in
application?

We've talked about having signal from the enforcing receivers back to the
MLM that the bounce occurred because of DMARC, but we haven't seen much
uptake of that idea for various reasons.

I've also been thinking about ways to push the burden back on the
advertisers.  Imagine we have some kind of signaling mechanism that MLMs
can take advantage of indicating to them that the author is using a strong
policy, and so it would be possibly a bad idea for the MLM to accept,
mutate, and re-send this message.  This could be a header field or an SMTP
extension (though the latter is complex to get right in a store-and-forward
system).  The MLM can then decide if it is willing to pass the message
unmodified to the list, or reject it with an error like "The policies of
this list require modification of your message, which violates your
domain's apparent policy.  Your submission therefore cannot be accepted.
Please contact your support organization for further assistance."  There's
never an opportunity for the collateral bounce to occur if the message is
never distributed, and the author domain has to either soften its policy or
separate its regular users from its transactional stuff somehow.

This avoids the "collateral" and "persistent" damage issues I raised in a
separate post.  It still requires the MLMs to do something new, but avoids
the need to implement any of a variety of unsavory mutations.  MLMs could
also determine this by querying the current DMARC policy of the author's
domain, to be sure, so it's a choice between MLMs looking for a header
field (which they already know how to do) or becoming DNS-aware (relatively
simple, but pulls in some complexities and dependencies they may not want).

-MSK, trying to be useful here
___
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?

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex 
wrote:

> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and
> the website signs records via DNSSEC.  The website I want to go to breaks
> their DNSSEC.  My ISP cannot retrieve a record to return to my browser that
> can be used.  A is the browser, B is the website, C is the ISP DNS platform.
>
>
>
> I understand your point, though I think mine still has reasonable merit.
> I understand the charter is to resolve the interoperability between
> indirect mail and p=reject.  I’m just not sure I see an intersection of
> “fix indirect email” and “p=reject”.
>

I see what you're getting at, but I don't think they're comparable.  There
are a few main differences:

1) DMARC is a surprise to some actors.  The intermediary in DMARC doesn't
know that it's suddenly contributing to a problem.  In the DNSSEC example,
the ISP DNS platform knows it's participating; it is, after all, a
DNSSEC-aware resolver.  In DMARC, suddenly MLMs around the world have to
change what they're doing and don't know they're part of a new problem.

2) DMARC causes collateral damage.  In the failure you've described, "A" is
simply unable to reach "B".  Other users of "B" are not blocked as a result
of anything "A" did.  The same goes for your TLSv1 example; it stopped
working, but only for the outdated client.  Meanwhile, in DMARC, something
"A" does causes other users of "B" to be unable to make use of "B".

3) DMARC's damage is persistent once the issue is corrected.  In DMARC,
once "C" decides "B" is unavailable, "C" causes "B" to do things that will
degrade or prevent "A" from using "B" in the future unless "A" takes some
kind of corrective action even after the outage is resolved.  The blast
radius is very different.

Each of these individually is a barrier to adoption; DMARC suffers from all
of them.

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

[dmarc-ietf] Introducing DSAP/ATPS for Improved Email Authentication

[Hector Santos]

Dear Alex and all,

I appreciate your insights on the challenges of balancing security and 
interoperability, particularly in the context of DMARC and its implications on 
email delivery. I agree with your suggestion of adding a more detailed section 
on the implications of DMARC policies in DMARCbis. We could provide an in-depth 
explanation of the various policy types, their use cases, and the potential 
implications of each, which would help stakeholders make more informed 
decisions when implementing their email authentication strategies.

In light of the ongoing discussion, I would also like to introduce the concept 
of DSAP (Domain-based Sender Authorization Protocol) with ATPS (Authorized 
Third-Party Signers) as a potential solution to address these concerns and 
improve email authentication.

DSAP with ATPS aims to offer a more comprehensive and flexible approach to 
email authentication by accounting for all possible combinations of 1st and 3rd 
party signers. This not only addresses the limitations of DMARC and its 
p=reject policy but also enables domain owners to define their own email 
signature expectations and authorized third-party signers.

By adopting DSAP with ATPS, we can reduce false positives and improve the 
overall accuracy and effectiveness of email authentication, leading to a more 
secure email ecosystem without causing disruptions to mail delivery.

I invite all stakeholders, including MLM developers and operators, to join the 
discussion and collaborate on the development of DSAP/ATPS as a more robust and 
adaptable email authentication protocol that serves the interests of all 
parties involved.

I look forward to your thoughts and feedback on this proposal.

Best regards,

Hector Santos, CEO/CTO
Santronics.com


> On Apr 12, 2023, at 8:20 AM, Brotman, Alex 
>  wrote:
> 
> There is a non-zero set of cases where the IETF prefers security over 
> interoperability.   A document like RFC8997/8996 where we've deprecated TLSv1 
> in because it was no longer secure. I assure you there are still 
> systems/users who have devices incapable of TLSv1.2.  DNSSEC (and things that 
> depend on it) can break in "mysterious" ways (specific to DNSSEC) that impact 
> interoperability, but sites do so in the in the name of security.
> 
> I think we all understand the inconvenience that DMARC can cause to a subset 
> of domains, or more accurately its users.  8996 has a section about 
> operational considerations, and discusses the impact of systems/users that do 
> not support TLSv1.2 and how it will break interoperability.  Can we not do 
> similar in DMARCbis with a more lengthy section about the implications of 
> "reject"?  Perhaps even expand it to cover the use cases of each policy type, 
> and the implications of each?  
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
> 
>> -Original Message-
>> From: dmarc  On Behalf Of Scott Kitterman
>> Sent: Tuesday, April 11, 2023 11:50 PM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
>> p=reject?
>> 
>> 
>> 
>> On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz > tech@dmarc.ietf.org> wrote:
>>> 
>>> 
 On Apr 8, 2023, at 6:56 AM, John Levine  wrote:
 
 We're never going to persuade DMARC absolutists that the damage is
 real, nor the rest of us that we can wave our hands and ignore the damage.
>>> 
>>> John, the damage is real. There’s no doubt about that. Trade offs, painful 
>>> trade
>> offs, have to be made and I’m sure this isn’t the first WG to face trade 
>> offs and
>> have to make hard decisions or not.
>>> 
>>> If DMARC can protect domains from spoofing which I believe ends up costing
>> over $14 billion per year. Forget about the $14 billion and think how this 
>> crime
>> spree affects people’s view of one of the last remnants of the free 
>> internet. It’s
>> a fiasco on so many levels. If you have the tools to make a real difference 
>> and I
>> can say from first hand experience DMARC has helped people’s financial and
>> mental health.
>>> 
>>> The standard and the document should reflect that it’s already making a
>> massive difference and could do even more. I don’t think it’s unreasonable to
>> expect ml managers to adapt. If cyber crime was street crime people would be
>> panicking in the streets.
>>> 
>> You can leave the marketing text aside.  We know.
>> 
>> The purpose of IETF specifications is to promote interoperability.  For good
>> reason, they tend to mostly document reality, not drive it.
>> 
>> The implication of your approach is we punt to experimental because it's
>> currently impossible to document an interoperable protocol that works for
>> normal email use cases until the indirect mail flow questions are sorted 
>> (they are
>> not fully understood yet - ARC is experimental for a reason).  Or maybe the
>> working group just shuts down.
>> 
>> Alternately we keep this on the standards track with a statement al

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[John R Levine]

I note that you didn't write "MUST NOT". I heartily concur with "shouldn't"
or SHOULD NOT. I still have issues with "MUST NOT".


Keep in mind that MUST NOT doesn't mean "do this and you will die", it 
means "do this and you won't interoperate" which seems exactly correct 
here.


SHOULD NOT means that you have external reasons to believe that you'll 
interoperate anyway, which doesn't seem right here, unless your plan is to 
send mail from your p=reject only to people with whom you have private 
whitelisting agreements.


R's,
John

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

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[Dotzero]

On Wed, Apr 12, 2023 at 9:41 AM John R Levine  wrote:



>
> When we say that mail systems that don't fit the DMARC threat profile
> shouldn't publish DMARC policies, we have good reasons to say so, and
> that's what our standards need to say if we're serious about
> interoperating.
>
> R's,
> John
>

" ...shouldn't publish DMARC policies..."

I note that you didn't write "MUST NOT". I heartily concur with "shouldn't"
or SHOULD NOT. I still have issues with "MUST NOT".

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

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[Hector Santos]

> On Apr 12, 2023, at 9:41 AM, John R Levine  wrote:
> 
> When we say that mail systems that don't fit the DMARC threat profile 
> shouldn't publish DMARC policies, we have good reasons to say so, and that's 
> what our standards need to say if we're serious about interoperating.
> 

With DMARCbis, If domains MUST NOT publish p=reject is mandated for certain 
classes of domain mail, then it should also apply to MUST NOT honor p=reject as 
a recommendation for verifiers.  If so,

- Should MDA receivers ignore sender p=reject for local users?
- Should MLM strip the submission security (From rewrite)?

—
HLS




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

[Brotman, Alex]

In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and the 
website signs records via DNSSEC.  The website I want to go to breaks their 
DNSSEC.  My ISP cannot retrieve a record to return to my browser that can be 
used.  A is the browser, B is the website, C is the ISP DNS platform.

I understand your point, though I think mine still has reasonable merit.  I 
understand the charter is to resolve the interoperability between indirect mail 
and p=reject.  I’m just not sure I see an intersection of “fix indirect email” 
and “p=reject”.

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

From: Murray S. Kucherawy 
Sent: Wednesday, April 12, 2023 9:51 AM
To: Brotman, Alex 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy 
mailto:superu...@gmail.com>> wrote:
To my mind, there's a substantial difference between something like TLSv1 or 
HTTP whose deprecation excludes you from participating in something until you 
upgrade, versus the DMARC situation where because of an unfortunate interaction 
between A (e.g., me) and B (e.g., you) through intermediary C (e.g., this 
list), D (e.g., someone else) is negatively impacted.

Sorry, that's not quite right: You don't need "D"; if "A" sets a policy and "B" 
generally enforces anyone's policies, "B" will be impacted by messages from "A" 
transiting "C".

I think your analogy would be more apt of "C" simply refused to accept anything 
from "A", or refused to let "B" subscribe.  But that doesn't seem to be the 
kind of mitigation on which we've settled.  And there's no way for "C" to know 
that "B" is enforcing until it's seen a bounce.  And "C" would need to be sure 
about the reason for the bounce.

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

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy 
wrote:

> To my mind, there's a substantial difference between something like TLSv1
> or HTTP whose deprecation excludes you from participating in something
> until you upgrade, versus the DMARC situation where because of an
> unfortunate interaction between A (e.g., me) and B (e.g., you) through
> intermediary C (e.g., this list), D (e.g., someone else) is negatively
> impacted.
>

Sorry, that's not quite right: You don't need "D"; if "A" sets a policy and
"B" generally enforces anyone's policies, "B" will be impacted by messages
from "A" transiting "C".

I think your analogy would be more apt of "C" simply refused to accept
anything from "A", or refused to let "B" subscribe.  But that doesn't seem
to be the kind of mitigation on which we've settled.  And there's no way
for "C" to know that "B" is enforcing until it's seen a bounce.  And "C"
would need to be sure about the reason for the bounce.

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

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

[John R Levine]

On Tue, 11 Apr 2023, Neil Anuskiewicz wrote:
If DMARC can protect domains from spoofing which I believe ends up 
costing over $14 billion per year. Forget about the $14 billion and 
think how this crime spree affects people’s view 


But it obviously can't do that, and what it does do happens at 
considerable cost.


I don't know where that $14B number came from but I am reasonably sure 
someone pulled it out of his, er, hat.  WHen people talk abbout 
"spoofing", they might mean exact domain impersonation or they might mean 
lookalikes, or as likely as not mail where the body impersonates someone 
and the From address is totally unrelated since, as Dave Crocker often 
reminds us, most users don't look at the return address and a lot of mail 
software doesn't even show it.  DMARC only addresses one modest part of 
that.


If you are someone like Paypal or a big bank, and you have full control 
over all the routes of your mail, AND IT DOES NOT MATTER IF YOUR MAIL GETS 
LOST, p=reject makes sense.  The farther from that you are, the less sense 
it makes and the higher the costs you impose on other people. People 
chronically forget the capitalized part when thinking about the tradeoffs.


There are lots and lots of examples of real costs that DMARC imposes on 
real people that have nothing to do with mailing lists.


I used to handle the mail for my local town government.  Many of the users 
asked me to forward their town addresses to Gmail acounts. In 2020 I 
noticed in my logs that mail from the US Census Bureau was getting lost 
due to DMARC rejects when I forwarded it. The Census had implemented DMARC 
in the cheapest possible way, a bunch of SPF records and no DKIM.  Losing 
that mail was a big deal -- this was in preparation for the 2020 census 
enumeration, and towns care deeply about that since a decade of revenue 
sharing depends on the census count.


Once I noticed the rejects, I knew that the least bad workaround was to 
have Google pull the mail, so I had to spend time setting up mailboxes for 
everyone, spend more time explaining to my users what the problem was, and 
spend their and my time walking them through and checking the setup on 
their end.  This is all actual costs imposed on actual people, none of 
which would have been needed if the Census just deleted their DMARC 
record.  Maybe they're a phish target, but the way they treated DMARC as a 
checklist item suggests not.


Or there's Yahoo and AOL, who used DMARC to force the costs of their 
own security failures on the rest of the Internet.  (See many previous 
messages for details.)


When we say that mail systems that don't fit the DMARC threat profile 
shouldn't publish DMARC policies, we have good reasons to say so, and 
that's what our standards need to say if we're serious about 
interoperating.


R's,
John

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

[Murray S. Kucherawy]

On Wed, Apr 12, 2023 at 5:20 AM Brotman, Alex  wrote:

> There is a non-zero set of cases where the IETF prefers security over
> interoperability.   A document like RFC8997/8996 where we've deprecated
> TLSv1 in because it was no longer secure. I assure you there are still
> systems/users who have devices incapable of TLSv1.2.  DNSSEC (and things
> that depend on it) can break in "mysterious" ways (specific to DNSSEC) that
> impact interoperability, but sites do so in the in the name of security.
>
> I think we all understand the inconvenience that DMARC can cause to a
> subset of domains, or more accurately its users.  8996 has a section about
> operational considerations, and discusses the impact of systems/users that
> do not support TLSv1.2 and how it will break interoperability.  Can we not
> do similar in DMARCbis with a more lengthy section about the implications
> of "reject"?  Perhaps even expand it to cover the use cases of each policy
> type, and the implications of each?
>

To my mind, there's a substantial difference between something like TLSv1
or HTTP whose deprecation excludes you from participating in something
until you upgrade, versus the DMARC situation where because of an
unfortunate interaction between A (e.g., me) and B (e.g., you) through
intermediary C (e.g., this list), D (e.g., someone else) is negatively
impacted.

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

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

[Scott Kitterman]

On April 12, 2023 9:51:14 AM UTC, Alessandro Vesely  wrote:
>On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:
>> 
>> 
>> On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely  wrote:
>>> On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
 On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely  wrote:
> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
>> I don't feel strongly about N=10, but I do feel strongly that N=5 is 
>> insufficient. My gut feel is that 6 or 7 is likely more than enough to 
>> cover all real world examples, but it's a gut feel only and not backed 
>> by data.
> 
> IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 
> (instead of 4), and then say that N=5 is the value we currently consider 
> good but recommend to make it configurable.  Or we could leave the text 
> as is (if it's easier to understand it that way) and just recommend to 
> not hardcode "5" and "4".
 
 I don't think everyone picking their own N is going to promote 
 interoperability.
>>> 
>>> It would, as long as subsequent standard revisions suggest different 
>>> values, and people more or less follow.  Compare with suggested/ 
>>> recommended RSA key lengths.
>> 
>> I don't think that's an apt comparison, but even if it were, what's the 
>> advantage of making the outcome of record lookups less consistent?
>
>
>Not getting stuck in hard-coded limits, like 10 lookups for SPF, for example.

If we'd written N lookups where N=10 instead of 10 lookups, the impact on the 
installed base would be no different.  We'll publish a new RFC and everyone 
will update their systems in no time isn't a thing.  It's also not a topic I 
think it's useful to spend time on, so I'm out of this thread.

Scott K

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

[Brotman, Alex]

There is a non-zero set of cases where the IETF prefers security over 
interoperability.   A document like RFC8997/8996 where we've deprecated TLSv1 
in because it was no longer secure. I assure you there are still systems/users 
who have devices incapable of TLSv1.2.  DNSSEC (and things that depend on it) 
can break in "mysterious" ways (specific to DNSSEC) that impact 
interoperability, but sites do so in the in the name of security.

I think we all understand the inconvenience that DMARC can cause to a subset of 
domains, or more accurately its users.  8996 has a section about operational 
considerations, and discusses the impact of systems/users that do not support 
TLSv1.2 and how it will break interoperability.  Can we not do similar in 
DMARCbis with a more lengthy section about the implications of "reject"?  
Perhaps even expand it to cover the use cases of each policy type, and the 
implications of each?  

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, April 11, 2023 11:50 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
> p=reject?
> 
> 
> 
> On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz  tech@dmarc.ietf.org> wrote:
> >
> >
> >> On Apr 8, 2023, at 6:56 AM, John Levine  wrote:
> >>
> >> We're never going to persuade DMARC absolutists that the damage is
> >> real, nor the rest of us that we can wave our hands and ignore the damage.
> >
> >John, the damage is real. There’s no doubt about that. Trade offs, painful 
> >trade
> offs, have to be made and I’m sure this isn’t the first WG to face trade offs 
> and
> have to make hard decisions or not.
> >
> >If DMARC can protect domains from spoofing which I believe ends up costing
> over $14 billion per year. Forget about the $14 billion and think how this 
> crime
> spree affects people’s view of one of the last remnants of the free internet. 
> It’s
> a fiasco on so many levels. If you have the tools to make a real difference 
> and I
> can say from first hand experience DMARC has helped people’s financial and
> mental health.
> >
> >The standard and the document should reflect that it’s already making a
> massive difference and could do even more. I don’t think it’s unreasonable to
> expect ml managers to adapt. If cyber crime was street crime people would be
> panicking in the streets.
> >
> You can leave the marketing text aside.  We know.
> 
> The purpose of IETF specifications is to promote interoperability.  For good
> reason, they tend to mostly document reality, not drive it.
> 
> The implication of your approach is we punt to experimental because it's
> currently impossible to document an interoperable protocol that works for
> normal email use cases until the indirect mail flow questions are sorted 
> (they are
> not fully understood yet - ARC is experimental for a reason).  Or maybe the
> working group just shuts down.
> 
> Alternately we keep this on the standards track with a statement along the 
> lines
> of [some appropriate description] domains MUST NOT publish restrictive
> DMARC policies due to interoperability issues.  Then the community works on
> making it easier for domains not to fit [some appropriate description] so it's
> reasonable for them to move to a restrictive policy.
> 
> I believe there's a way to get there on the specifics of the language, if we 
> work
> on it.  I have yet to hear any kind of interest in trying to work something 
> out
> from the anti-interoperability crowd.  More people showing up to opine about
> cyber isn't going to get us there.
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!GooL5z7r6yyYuhFHHRpgovAgUdqy_1ApVEhmyKC1MGY-
> i_qh2X2DY-sNSspGx-Toul9a1rsnu7xwgdQ_V-ZOejFhscE$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Laura Atkins]

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

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

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

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

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

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

Because that doesn’t scale for the IETF. 

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

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

laura 

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

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

[Douglas Foster]

Any form of security creates inconvenience.

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

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

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

Doug Foster










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

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

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

[Douglas Foster]

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

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

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

Doug

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

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

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

[Alessandro Vesely]

On Wed 12/Apr/2023 07:10:26 +0200 Neil Anuskiewicz wrote:

On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy  wrote:
On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz wrote:

The standard and the document should reflect that it’s already making a 
massive difference and could do even more.


The IETF is a consensus-based organization.  I suggest that if we're going to 
claim DMARC as-is has the consensus of the community, that community needs to 
be representative of the interests of the MLM developers and operators.  Since 
we keep talking about "them", I don't think it is.


Expecting them to adapt (or perhaps "comply" is the better word) merely 
because we say so feels a lot like pushing on a string.



Some strings seem to be quite pushable.  I'm not so much into string theory, 
but recall threads like this:

http://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio


Is there really going to be language in the new standard saying general purpose 
domains must be p=none type of language? That’s quite a compromise if it’s the 
case. Like all of us I’m busy and tired so maybe didn’t read everything 
including nuance. I thought the gist of one bit was that “general purpose” 
domains must have a p=none. What is a general purpose domain? Like could the org 
domain of some organization be called general purpose?



A similar discussion was made at the times of ADSP.  A good explanation of the 
intent is given in this post:

https://mailarchive.ietf.org/arch/msg/ietf-dkim/EC8IQuaYwAZ4FeoKBsgICisRwSQ/

Note that Brett McDowell writes from paypal-inc.com, a domain created purposely 
to be general purpose.


We all know where that path leads.


Best
Ale
--








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

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

[Laura Atkins]

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

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

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

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

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

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

laura 

-- 
The Delivery Experts

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

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






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

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

[Alessandro Vesely]

On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:



On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely  wrote:

On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:

On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely  wrote:

On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:

I don't feel strongly about N=10, but I do feel strongly that N=5 is 
insufficient. My gut feel is that 6 or 7 is likely more than enough to cover 
all real world examples, but it's a gut feel only and not backed by data.


IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then 
say that N=5 is the value we currently consider good but recommend to make it configurable.  Or we 
could leave the text as is (if it's easier to understand it that way) and just recommend to not 
hardcode "5" and "4".


I don't think everyone picking their own N is going to promote interoperability.


It would, as long as subsequent standard revisions suggest different values, 
and people more or less follow.  Compare with suggested/ recommended RSA key 
lengths.


I don't think that's an apt comparison, but even if it were, what's the 
advantage of making the outcome of record lookups less consistent?



Not getting stuck in hard-coded limits, like 10 lookups for SPF, for example.


Best
Ale
--





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

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

[Alessandro Vesely]

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



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


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



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



Best
Ale
--






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

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

[Alessandro Vesely]

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



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


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


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


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


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



Best
Ale
--

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





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

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

[Scott Kitterman]

On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely  wrote:
>On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
>> On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely  wrote:
>>> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
 I don't feel strongly about N=10, but I do feel strongly that N=5 is 
 insufficient. My gut feel is that 6 or 7 is likely more than enough to 
 cover all real world examples, but it's a gut feel only and not backed by 
 data.
>>> 
>>> IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 
>>> (instead of 4), and then say that N=5 is the value we currently consider 
>>> good but recommend to make it configurable.  Or we could leave the text as 
>>> is (if it's easier to understand it that way) and just recommend to not 
>>> hardcode "5" and "4".
>> 
>> I don't think everyone picking their own N is going to promote 
>> interoperability.
>
>
>It would, as long as subsequent standard revisions suggest different values, 
>and people more or less follow.  Compare with suggested/ recommended RSA key 
>lengths.
>

I don't think that's an apt comparison, but even if it were, what's the 
advantage of making the outcome of record lookups less consistent?

Scott K

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

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

[Alessandro Vesely]

On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:

On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely  wrote:

On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:

I don't feel strongly about N=10, but I do feel strongly that N=5 is 
insufficient. My gut feel is that 6 or 7 is likely more than enough to cover 
all real world examples, but it's a gut feel only and not backed by data.


IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then 
say that N=5 is the value we currently consider good but recommend to make it configurable.  Or we 
could leave the text as is (if it's easier to understand it that way) and just recommend to not 
hardcode "5" and "4".


I don't think everyone picking their own N is going to promote interoperability.



It would, as long as subsequent standard revisions suggest different values, 
and people more or less follow.  Compare with suggested/ recommended RSA key 
lengths.



Best
Ale
--





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