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

[Barry Leiba]

> 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

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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

> On Apr 13, 2023, at 4:33 PM, John Levine  wrote:
> 
>> (2) An author domain can decide to affix this at its discretion, ...
> 
> The basic problem is that author domains lie about their policy, i.e.,
> p=none but they expect mailing lists to work, and their users are
> stuck.

It’s not a lie. The protocol expected the MLS or MLM using low code scripts to 
adjust. It’s been 17 years!  Hello?

1. Honor the policy, protect security by rejecting restrictive domains, or

2. Break the security layer, redistribute with no security.

You, as the author of DMARCbis, oddly choose #2.  Why not #1?

—
HLS

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

Re: [dmarc-ietf] Signaling MLMs

[John Levine]

It appears that Murray S. Kucherawy   said:
>(1) MLMs don't necessarily want to start doing DNS queries.  They operate
>just fine never touching the DNS today; this is a new dependency and bunch
>of stuff they have to learn to apply and suppot.

Depends how they're set up.  In the common case that the inbound MTA adds an A-R
header, it can get the DMARC policy there.  That's how my dmarc.fail shim works.

>(2) An author domain can decide to affix this at its discretion, ...

The basic problem is that author domains lie about their policy, i.e.,
p=none but they expect mailing lists to work, and their users are
stuck.

R's,
John

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

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

[Hector Santos]

> On Apr 13, 2023, at 3:13 PM, Hector Santos 
>  wrote:
> 
> On 4/13/2023 11:21 AM, 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.
>> 
> Keep in mind, there are implementers of SPF that act at SMTP before DATA and 
> reject hard failures with 55z errors.  In other words, no payload is 
> transferred.
> 


Let me expand on this:

First, SPF predated DMARC. 

DMARC as a payload protocol, like any other payload protocol have high overhead 
associated with it;  DKIM, ADSP, ATPS, DMARC processing.  

Nothing to worry about at low scale and nothing to worry about at high scale if 
optimized correctly, and that is by allowing SPF to pre-empt payload processing 
when there is a hard SPF failure.  That’s good. Not Bad. In 18 years of SPF,  I 
maybe had 1 false positive.

But even then with introduction of DMARC, I recognized the domain policy may be 
p=none or p=quarantine.

Therefore I propose RFC 4405 SUBMITTER protocol to pass the PRA at MAIL FROM

C: MAIL FROM: SUBMITTER=pra

Where the PRA is the 5322.From address.

The allow SMTP to check the DMARC policy at SMTP. helping it how to handle SPF 
rejections.

Please let’s make this Protocol Complete.   If DMARC requires SPF to be delayed 
until the DATA state, then you are talking about an anti-scaling feature. Use 
SUBMITTER to pass the PRA.

—
HLS

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

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

[Hector Santos]

I didn’t we need to mention the type of people, organization, etc.

“This is particularly important because SPF will always fail in situations 
where mail is forwarded.”  

The issue applies to all.

> On Apr 13, 2023, at 12:04 PM, Todd Herr 
>  wrote:
> 
> On Thu, Apr 13, 2023 at 11:21 AM 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.
>> 
> I don't disagree.
> 
> How do we make the following text stronger?
> 5.5.2.  
> Configure
>  Sending System for DKIM Signing Using an Aligned Domain 
> 
> While it is possible to secure a DMARC pass verdict based on only one of SPF 
> or DKIM, it is commonly accepted best practice to ensure that both 
> authentication mechanisms are in place to guard against failure of just one 
> of them.
> 
> This is particularly important because SPF will always fail in situations 
> where mail is sent to a forwarding address offered by a professional society, 
> school or other institution, where the address simply relays the message to 
> the recipient's current "real" address. Many recipients use such addresses 
> and with SPF alone and not DKIM, messages sent to such users will always 
> produce DMARC fail. 
> 
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain in 
> the DKIM-Signature header) that aligns with the Author Domain.
> 
> 
> 
> -- 
> Todd Herr  | Technical Director, Standards and Ecosystem
> e: todd.h...@valimail.com  
> m: 703.220.4153
> 
> This email and all data transmitted with it contains confidential and/or 
> proprietary information intended solely for the use of individual(s) 
> authorized to receive it. If you are not an intended and authorized recipient 
> you are hereby notified of any use, disclosure, copying or distribution of 
> the information included in this transmission is prohibited and may be 
> unlawful. Please immediately notify the sender by replying to this email and 
> then delete it from your system.
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

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

[Hector Santos]

On 4/13/2023 11:21 AM, 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.

Keep in mind, there are implementers of SPF that act at SMTP before 
DATA and reject hard failures with 55z errors.  In other words, no 
payload is transferred.




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



___
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 April 13, 2023 5:49:30 PM UTC, "Brotman, Alex" 
 wrote:
>> That's the sort of thing I proposed, and which some participants here are
>> objecting to.  I continue not to understand the objection to clear language 
>> that
>> says that if you do  under  conditions, it will cause problems, 
>> so
>> don't do .  I don't buy the idea that saying "don't do " when we 
>> know
>> that some deployers will ignore that makes us look out of touch with 
>> reality, but
>> that *not* saying that is better (when that already *has* given DMARC a bad
>> name in the wider Internet community).
>
>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 'then what' is there will be interoperability issues.  I don't see anyone 
claiming that's not true, despite an extreme reluctance (as I see it) to 
actually say it.

I don't think saying [some constraining words] domains MUST NOT publish 
p=reject should be in any way controversial.  Even if we explicitly add the 
implicit 'or there will be interoperability problems', it's no different.  As a 
technical point, I don't understand why there is a problem with this.  The 
tricky part is defining [some constraining words].

If we could get [some constraining words] defined, I think it would be useful 
to the community as it would help address the question of 'but I want p=reject, 
what should I do'.  The answer is, change your domain email usage so you no 
longer fit the definition of [some constraining words].

It might even be as simple as [unconstrained email usage].  Then we write an 
appendix that explains the things to do in terms of constraints that will avoid 
(or mostly avoid) the interoperability issues.

I feel like we are making this much harder than it needs to be.

Scott K

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

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

[John R Levine]

I’ve talked about this before.  I ran into a utility company that I conversed 
with that explicitly didn’t want to use DKIM because they felt their messages 
should not be forwarded to another provider.  I didn’t quite understand the 
logic, but it was their decision.


I believe it, but needless to say, the fact that some people do dumb 
things don't make them any less dumb.


R's,
John



I definitely favor some language that endorses using both and perhaps even 
outlines the pitfalls of using only one (can’t forward, both gives you a better 
chance of success, etc)


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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/13/2023 11:14 AM, Barry Leiba wrote:
There's no need for a signal here: the MLM can simply check the 
sending domain's DMARC policy when a new post comes in, and 
preemptively reject it if the policy is "reject". The IETF 
considered doing that and ruled it out because it would mean that 
users with yahoo.com addresses (and others) could then not 
participate in IETF mailing lists without changing addresses. 

Code change where?  In the MLS or some post scripting code?

I think that was the wrong decision, but we decided on the ugly 
"from" alteration instead. 


Code change anyway.   No way around this code change - a direct MLS 
change or MLM low code script add-on/change.   My MLS checks it's 
entry points for restrictive DMARC domain; subscription and submissions.


I still think that outright refusal of posts from p=reject domains 
is a good approach and I wish it were used more, but most MLMs that 
are willing to put in a change to address this seems to prefer not 
to punish the sending domains users for the excesses of the domain 
management.


+1.

It can only be considered more with key cogs support and promotion to 
their industry/trade support peers. Iow, Editors SHOULD 
support/champion their RFC work like ATPS and DMARC.  Many ideas and 
concepts from DSAP merged from WG work. DMARC is a collection of all 
the past work with reporting. But it needs DSAP policy ideas and ATPS 
concept to help bring some steady state to transporters. DMARCbis p= 
should be describing the failure handling not restricting the 
evaluation of a failure.  This will provide the tools to define the 
nine possible 1st vs 3rd party signers.  MLS needs to support this.  
The MLM operators need to support it too. Of course, the MLS/MLM can 
use Local Policy to override at its own risk especially when DMARCBis 
offers nothing to resolve this problem.  But it can easily fit in too 
and see where it goes.



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

[Brotman, Alex]

I’ve talked about this before.  I ran into a utility company that I conversed 
with that explicitly didn’t want to use DKIM because they felt their messages 
should not be forwarded to another provider.  I didn’t quite understand the 
logic, but it was their decision.

I definitely favor some language that endorses using both and perhaps even 
outlines the pitfalls of using only one (can’t forward, both gives you a better 
chance of success, etc)

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

From: dmarc  On Behalf Of Barry Leiba
Sent: Thursday, April 13, 2023 12:44 PM
To: Dotzero 
Cc: Todd Herr ; John Levine ; 
dmarc@ietf.org; superu...@gmail.com
Subject: Re: [dmarc-ietf] Signaling forwarders, not just MLMs

We can say that as well, but I want to specifically say "don't use SPF without 
DKIM and expect it to work right;"

b


On Thu, Apr 13, 2023 at 12:41 PM Dotzero 
mailto:dotz...@gmail.com>> wrote:


On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
Maybe just add a sentence to the end of the second paragraph:

   The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.

Barry

I think the opposite. Something along the lines of "Sending domains SHOULD 
implement both SPF and DKIM to minimize breakage and non-delivery of mail.

Michael Hammer



On Thu, Apr 13, 2023 at 12:04 PM Todd Herr 
mailto:todd.h...@valimail.com>> wrote:
On Thu, Apr 13, 2023 at 11:21 AM Barry Leiba 
mailto:barryle...@computer.org>> 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.
I don't disagree.

How do we make the following text stronger?
5.5.2. 

 Configure Sending System for DKIM Signing Using an Aligned 
Domain

While it is possible to secure a DMARC pass verdict based on only one of SPF or 
DKIM, it is commonly accepted best practice to ensure that both authentication 
mechanisms are in place to guard against failure of just one of them.

This is particularly important because SPF will always fail in situations where 
mail is sent to a forwarding address offered by a professional society, school 
or other institution, where the address simply relays the message to the 
recipient's current "real" address. Many recipients use such addresses and with 
SPF alone and not DKIM, messages sent to such users will always produce DMARC 
fail.

The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain in 
the DKIM-Signature header) that aligns with the Author Domain.


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

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

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

[Brotman, Alex]

> That's the sort of thing I proposed, and which some participants here are
> objecting to.  I continue not to understand the objection to clear language 
> that
> says that if you do  under  conditions, it will cause problems, 
> so
> don't do .  I don't buy the idea that saying "don't do " when we 
> know
> that some deployers will ignore that makes us look out of touch with reality, 
> but
> that *not* saying that is better (when that already *has* given DMARC a bad
> name in the wider Internet community).

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

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

> -Original Message-
> From: Barry Leiba 
> Sent: Thursday, April 13, 2023 12:34 PM
> To: Brotman, Alex 
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
> p=reject?
> 
> > I think we all understand the inconvenience that DMARC can cause to a
> > subset of domains, or more accurately its users.
> 
> The problem here that we're describing as an interoperability issue is not 
> that
> DMARC causes problems for the users of domains that choose to use p=reject --
> that would be the domain's problem -- but that it causes cascading problems 
> for
> the users of *other* domains.  That makes it more than an inconvenience.
> 
> > 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?
> 
> That's the sort of thing I proposed, and which some participants here are
> objecting to.  I continue not to understand the objection to clear language 
> that
> says that if you do  under  conditions, it will cause problems, 
> so
> don't do .  I don't buy the idea that saying "don't do " when we 
> know
> that some deployers will ignore that makes us look out of touch with reality, 
> but
> that *not* saying that is better (when that already *has* given DMARC a bad
> name in the wider Internet community).
> 
> Barry
___
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 Thu, Apr 13, 2023 at 9:11 AM Dotzero  wrote:

> On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy 
> wrote:
>
>> 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.
>>
>
> If DMARC is a surprise to "some actors" today, they clearly haven't been
> paying attention. It was first publicly published (not through IETF) in
> 2011. With regard to MLMs and forwarders, the wake up call would/should
> have been in 2014 when AOL, !Yahoo and other domains with lots of users
> started publishing p=reject policies. I'm not commenting on other aspects
> of the discussion, only your belief that in this day and age, DMARC is a
> surprise to anyone.
>

The context in which I said that is important.  I didn't claim people are
surprised by the existence of DMARC in a "keep up with the world" sort of
sense.

In comparison to DNSSEC, however, the intermediary (the DNS platform) does
not one day find itself surprised by the world having changed around it; it
was part of the change.  In DMARC, the intermediary (the MLM) suddenly
finds the world broken around it, and other actors in the scenario are
pointing their fingers at the intermediary saying it's the thing that's
broken.  That's a huge difference.

-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 Thu, 13 Apr 2023, Dotzero wrote:

It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters
but there is a calculus regarding the tradeoffs of a very small percentage
(in the case of my former a very small fraction of a percent) of email not
getting delivered vs the damage caused to recipients of malicious emails
involving direct domain abuse. ...


Well, yes, I oversimplified a little for effect.

In your case, you know all the places that should be sending mail with 
your name on it, no random third party ESPs or mailing lists, and you know 
who should be getting it.  So if a trickle ends up at mailing lists or 
ticketing systems or any of the other things that munge messages on the 
way through, you don't care about that trickle.


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] Signaling forwarders, not just MLMs

[Barry Leiba]

We can say that as well, but I want to specifically say "don't use SPF
without DKIM and expect it to work right;"

b


On Thu, Apr 13, 2023 at 12:41 PM Dotzero  wrote:

>
>
> On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba 
> wrote:
>
>> Maybe just add a sentence to the end of the second paragraph:
>>
>>The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.
>>
>> Barry
>>
>
> I think the opposite. Something along the lines of "Sending domains SHOULD
> implement both SPF and DKIM to minimize breakage and non-delivery of mail.
>
> Michael Hammer
>
>
>>
>>
>> On Thu, Apr 13, 2023 at 12:04 PM Todd Herr 
>> wrote:
>>
>>> On Thu, Apr 13, 2023 at 11:21 AM 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.

 I don't disagree.
>>>
>>> How do we make the following text stronger?
>>> 5.5.2.
>>> Configure
>>> Sending System for DKIM Signing Using an Aligned Domain
>>> 
>>>
>>> While it is possible to secure a DMARC pass verdict based on only one of
>>> SPF or DKIM, it is commonly accepted best practice to ensure that both
>>> authentication mechanisms are in place to guard against failure of just one
>>> of them.
>>>
>>> This is particularly important because SPF will always fail in
>>> situations where mail is sent to a forwarding address offered by a
>>> professional society, school or other institution, where the address simply
>>> relays the message to the recipient's current "real" address. Many
>>> recipients use such addresses and with SPF alone and not DKIM, messages
>>> sent to such users will always produce DMARC fail.
>>> 
>>>
>>> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d=
>>> domain in the DKIM-Signature header) that aligns with the Author Domain.
>>>
>>>
>>> --
>>>
>>> *Todd Herr * | Technical Director, Standards and Ecosystem
>>> *e:* todd.h...@valimail.com
>>> *m:* 703.220.4153
>>>
>>> This email and all data transmitted with it contains confidential and/or
>>> proprietary information intended solely for the use of individual(s)
>>> authorized to receive it. If you are not an intended and authorized
>>> recipient you are hereby notified of any use, disclosure, copying or
>>> distribution of the information included in this transmission is prohibited
>>> and may be unlawful. Please immediately notify the sender by replying to
>>> this email and then delete it from your system.
>>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba 
wrote:

> Maybe just add a sentence to the end of the second paragraph:
>
>The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.
>
> Barry
>

I think the opposite. Something along the lines of "Sending domains SHOULD
implement both SPF and DKIM to minimize breakage and non-delivery of mail.

Michael Hammer


>
>
> On Thu, Apr 13, 2023 at 12:04 PM Todd Herr  wrote:
>
>> On Thu, Apr 13, 2023 at 11:21 AM 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.
>>>
>>> I don't disagree.
>>
>> How do we make the following text stronger?
>> 5.5.2.
>> Configure
>> Sending System for DKIM Signing Using an Aligned Domain
>> 
>>
>> While it is possible to secure a DMARC pass verdict based on only one of
>> SPF or DKIM, it is commonly accepted best practice to ensure that both
>> authentication mechanisms are in place to guard against failure of just one
>> of them.
>>
>> This is particularly important because SPF will always fail in situations
>> where mail is sent to a forwarding address offered by a professional
>> society, school or other institution, where the address simply relays the
>> message to the recipient's current "real" address. Many recipients use such
>> addresses and with SPF alone and not DKIM, messages sent to such users will
>> always produce DMARC fail.
>> 
>>
>> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d=
>> domain in the DKIM-Signature header) that aligns with the Author Domain.
>>
>>
>> --
>>
>> *Todd Herr * | Technical Director, Standards and Ecosystem
>> *e:* todd.h...@valimail.com
>> *m:* 703.220.4153
>>
>> This email and all data transmitted with it contains confidential and/or
>> proprietary information intended solely for the use of individual(s)
>> authorized to receive it. If you are not an intended and authorized
>> recipient you are hereby notified of any use, disclosure, copying or
>> distribution of the information included in this transmission is prohibited
>> and may be unlawful. Please immediately notify the sender by replying to
>> this email and then delete it from your system.
>>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Barry Leiba]

> I think we all understand the inconvenience that DMARC can cause to a
> subset of domains, or more accurately its users.

The problem here that we're describing as an interoperability issue is
not that DMARC causes problems for the users of domains that choose to
use p=reject -- that would be the domain's problem -- but that it
causes cascading problems for the users of *other* domains.  That
makes it more than an inconvenience.

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

That's the sort of thing I proposed, and which some participants here
are objecting to.  I continue not to understand the objection to clear
language that says that if you do  under  conditions, it
will cause problems, so don't do .  I don't buy the idea that
saying "don't do " when we know that some deployers will ignore
that makes us look out of touch with reality, but that *not* saying
that is better (when that already *has* given DMARC a bad name in the
wider Internet community).

Barry

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

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

The claim that DMARC protects against spoofing has never been made by the
originators of DMARC. We have always been careful that it only addresses
direct domain abuse.


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

Nobody has full control over all the routes email will take. How does the
emitting domain know that a recipient hasn't set up forwarding from one
account to another or that a recipient address isn't an exploder or alias
representing multiple recipients at multiple domains?

It also isn't that " IT DOES NOT MATTER IF YOUR MAIL GETS LOST". It matters
but there is a calculus regarding the tradeoffs of a very small percentage
(in the case of my former a very small fraction of a percent) of email not
getting delivered vs the damage caused to recipients of malicious emails
involving direct domain abuse. In one example of direct domain abuse, the
malicious actors copied and pasted from real transactional emails and
inadvertently included tracking code.Over the course of 48 hours over
180,000 people clicked on the malicious link before the site hosting the
malicious content was shut down. And that was all from receiver domains
that were not validating DMARC. And again, the original intent of DMARC was
mitigating direct domain abuse involving transactional emails. We
recognized the tradeoffs involved but to say it didn't (and doesn't) matter
if such transactional email gets lost is a gross exaggeration.

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

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

[Barry Leiba]

Maybe just add a sentence to the end of the second paragraph:

   The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.

Barry


On Thu, Apr 13, 2023 at 12:04 PM Todd Herr  wrote:

> On Thu, Apr 13, 2023 at 11:21 AM 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.
>>
>> I don't disagree.
>
> How do we make the following text stronger?
> 5.5.2.
> Configure
> Sending System for DKIM Signing Using an Aligned Domain
> 
>
> While it is possible to secure a DMARC pass verdict based on only one of
> SPF or DKIM, it is commonly accepted best practice to ensure that both
> authentication mechanisms are in place to guard against failure of just one
> of them.
>
> This is particularly important because SPF will always fail in situations
> where mail is sent to a forwarding address offered by a professional
> society, school or other institution, where the address simply relays the
> message to the recipient's current "real" address. Many recipients use such
> addresses and with SPF alone and not DKIM, messages sent to such users will
> always produce DMARC fail.
> 
>
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
> in the DKIM-Signature header) that aligns with the Author Domain.
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dotzero]

On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy 
wrote:

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

If DMARC is a surprise to "some actors" today, they clearly haven't been
paying attention. It was first publicly published (not through IETF) in
2011. With regard to MLMs and forwarders, the wake up call would/should
have been in 2014 when AOL, !Yahoo and other domains with lots of users
started publishing p=reject policies. I'm not commenting on other aspects
of the discussion, only your belief that in this day and age, DMARC is a
surprise to anyone.

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

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

[Todd Herr]

On Thu, Apr 13, 2023 at 11:21 AM 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.
>
> I don't disagree.

How do we make the following text stronger?
5.5.2.
Configure
Sending System for DKIM Signing Using an Aligned Domain


While it is possible to secure a DMARC pass verdict based on only one of
SPF or DKIM, it is commonly accepted best practice to ensure that both
authentication mechanisms are in place to guard against failure of just one
of them.

This is particularly important because SPF will always fail in situations
where mail is sent to a forwarding address offered by a professional
society, school or other institution, where the address simply relays the
message to the recipient's current "real" address. Many recipients use such
addresses and with SPF alone and not DKIM, messages sent to such users will
always produce DMARC fail.


The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
in the DKIM-Signature header) that aligns with the Author Domain.


-- 

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

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

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

[John R Levine]

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.


Well, it depends whether you care whather people get your mail.

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.


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.


R's,
John

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

Re: [dmarc-ietf] Signaling MLMs

[Dotzero]

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

This is certainly worth a discussion.


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

My recollection is similar to Steve's except that I saw the talk but didn't
see the walking the walk.

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

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

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

Re: [dmarc-ietf] Signaling MLMs

[Murray S. Kucherawy]

On Thu, Apr 13, 2023 at 8:14 AM Barry Leiba  wrote:

> There's no need for a signal here: the MLM can simply check the
> sending domain's DMARC policy when a new post comes in, and
> preemptively reject it if the policy is "reject".  The IETF considered
> doing that and ruled it out because it would mean that users with
> yahoo.com addresses (and others) could then not participate in IETF
> mailing lists without changing addresses.  I think that was the wrong
> decision, but we decided on the ugly "from" alteration instead.
>

My idea is based on two assumptions:

(1) MLMs don't necessarily want to start doing DNS queries.  They operate
just fine never touching the DNS today; this is a new dependency and bunch
of stuff they have to learn to apply and suppot.

(2) An author domain can decide to affix this at its discretion, so it has
some say in which out-flows are subjected to this "do not modify"
constraint.  Of course, that discretion can lead to other problems, such as
the author domain not affixing it when it should, or vice versa.

As for the IETF, if this WG comes out with contrary advice to that
decision, we (the IETF) would have to reconsider.  It's an ugly question
either way.

I still think that outright refusal of posts from p=reject domains is
> a good approach and I wish it were used more, but most MLMs that are
> willing to put in a change to address this seems to prefer not to
> punish the sending domains users for the excesses of the domain
> management.
>

I think if the outcome is that we decide we don't want to do this, this
discussion would be good to capture in the document to indicate what we
considered and discarded.

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

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

[Mark Alley]

+1

On 4/13/2023 10:21 AM, 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.

Barry

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

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

[Barry Leiba]

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

Barry

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

Re: [dmarc-ietf] Signaling MLMs

[Barry Leiba]

I would like to make the receiving advice stronger *also*, yes.  In
particular, I would change the SHOULD NOT to MUST NOT, and I would add text
that suggests that it's a particularly bad idea to react to p=reject for
domains that are known to host email addresses for the general public, and
expand on the reasons why.

I don't think that eliminates the need for strong advice to senders as well.

Barry


On Thu, Apr 13, 2023 at 11:07 AM Todd Herr  wrote:

> On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy 
> wrote:
>
>> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr > 40valimail@dmarc.ietf.org> 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'm not sure it's true to say blanket observance of "reject" is
> commonplace. Both Gmail and Microsoft will override p=reject on a regular
> basis due to reasons known only to them.
>
> As for when it's safe to actually reject, I'm not sure that the full
> effect of policy changes can ever truly be known or predicted before
> they're implemented; one usually only learns the full impact after
> implementation. Back when I worked in email ops, the volume of customer
> complaints was a pretty good indicator to tell me that a decision I'd made
> had resulted in users not getting wanted mail (or getting too much unwanted
> mail). There was no hard and fast rule, of course, nor should we ever
> expect that there will be, but each organization I'm sure has some
> threshold for realizing that a new change's impact is a net negative, and a
> process for deciding whether or not to roll back a change if it does prove
> to be a net negative.
>
> It is possible, of course (or should be) to simulate the effect of changes
> prior to implementing them and use the information gathered to determine
> whether or not to go forward. When the decision under consideration is
> "should we honor p=reject?" I would study the inbound traffic for a
> reasonable period of time (maybe a couple of months or more) and track how
> much mail would've been rejected (perhaps on a per-domain basis) and to the
> extent my system allowed, what percentage of that mail was engaged with,
> and how (spam complaints, opens, deleted without opening, forwarded, etc.).
> Obviously, such engagement tracking might be beyond the capability of some
> mail receivers, but that's how I'd want to approach the problem.
>
> Might the above two paragraphs contribute to additional text to add to
> this document in section 5.8?
>
>
>
>>
>>
>>>
>>> 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 

Re: [dmarc-ietf] Signaling MLMs

[Barry Leiba]

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

There's no need for a signal here: the MLM can simply check the
sending domain's DMARC policy when a new post comes in, and
preemptively reject it if the policy is "reject".  The IETF considered
doing that and ruled it out because it would mean that users with
yahoo.com addresses (and others) could then not participate in IETF
mailing lists without changing addresses.  I think that was the wrong
decision, but we decided on the ugly "from" alteration instead.

I still think that outright refusal of posts from p=reject domains is
a good approach and I wish it were used more, but most MLMs that are
willing to put in a change to address this seems to prefer not to
punish the sending domains users for the excesses of the domain
management.

Barry

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

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

[John Levine]

It appears that Murray S. Kucherawy   said:
>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?

MLMs get all the attention but please remember my lost census mail example.

Anyone who does forwarding is damaged by DMARC because there are a lot of
people who do DMARC on the cheap with SPF only.  There is a lot of fowarding,
both the pobox style stuff and people who collect mail from other places at
big webmail providers.

R's,
John

___
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 11:35 PM Murray S. Kucherawy 
wrote:

> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  40valimail@dmarc.ietf.org> 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'm not sure it's true to say blanket observance of "reject" is
commonplace. Both Gmail and Microsoft will override p=reject on a regular
basis due to reasons known only to them.

As for when it's safe to actually reject, I'm not sure that the full effect
of policy changes can ever truly be known or predicted before they're
implemented; one usually only learns the full impact after implementation.
Back when I worked in email ops, the volume of customer complaints was a
pretty good indicator to tell me that a decision I'd made had resulted in
users not getting wanted mail (or getting too much unwanted mail). There
was no hard and fast rule, of course, nor should we ever expect that there
will be, but each organization I'm sure has some threshold for realizing
that a new change's impact is a net negative, and a process for deciding
whether or not to roll back a change if it does prove to be a net negative.

It is possible, of course (or should be) to simulate the effect of changes
prior to implementing them and use the information gathered to determine
whether or not to go forward. When the decision under consideration is
"should we honor p=reject?" I would study the inbound traffic for a
reasonable period of time (maybe a couple of months or more) and track how
much mail would've been rejected (perhaps on a per-domain basis) and to the
extent my system allowed, what percentage of that mail was engaged with,
and how (spam complaints, opens, deleted without opening, forwarded, etc.).
Obviously, such engagement tracking might be beyond the capability of some
mail receivers, but that's how I'd want to approach the problem.

Might the above two paragraphs contribute to additional text to add to this
document in section 5.8?



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

Re: [dmarc-ietf] Signaling MLMs

[Hector Santos]

On 4/12/2023 11:38 PM, Murray S. Kucherawy wrote:
On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones > wrote:


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?


This was initially outlined in 2006 DSAP guidelines for list servers.  
It has been mentioned numerous times in the DKIM and DMARC WGs 
throughout the many years.  The following is a 2011 Wildcat! SMTP List 
Server wcBASIC language p-code script called at DATA and it applies to 
ADSP/DMARC restrictive domain list submissions.  All of my Wildcat! 
customers/operators managing a list have the same stock code.


//***
// (c) Copyright 1998-2012 Santronics Software, Inc. All Rights Reserved.
//***
//
// File Name : smtpfilter-listchecker.wcc
// Subsystem : wcListServer
// Date  : 10/11/2011
// Author: SSI
// About : checks wcListServer list to accept delivery
//
//data\smtpfilterhookloader.ini
//config\wcmail.names
//
// Run this filter before smtpfitler-whitelist because you may have
// some auto-whitelisted users with restricted DMARC domains.  If
// WCLS is not ready for DMARC checking, a major distribution problem
// will occur with DMARC checking downlink receivers.
//
// Revision History:
//
// 2.0, 454.6, 11/09/18 11:28 pm
// 2.1, 454.6, 11/12/18 10:52 am
// 3.0, 454.12, 04/11/21 01:10 pm
//
// - Added ADSP/DMARC check.
//
//   ADSP/DMARC checks are not done on control messages.
//
// - Adding new support accepting extended list control messages:
//
// tmailist.name + "-subscribe";
// tmailist.name + "-unsubscribe"
// tmailist.name + "-bounces"
//
// 2.2, 454.10, 05/03/20 11:18 am
//
// - fix DMARC bug of using just the local part and not the
//   the domain to see of its a valid list.  The fix is
//   compare the ListDomain with the address.domain
//
//***

#include 
#include 
#include 
#include 

//--
// GLOBALS
//--

const FILTER_VERSION = "3.0"
Const CONTROL_NAMES  = "wc:\cfg\wcmail.names"

//--
// MAIN PROGRAM
//--


  sfInitializeHook(paramstr(1))

  dim args  as string  = lcase(paramstr(1))
  dim msgfn as string  = GetParamStr(args,"psf")  // prespool
  dim from  as string  = GetParamStr(args,"from") // sender
  dim rcpt  as string  = GetParamStr(args,"rcpt") // recipient

  // strip angle brackets from addresses

  rcpt = lcase(sfStripBrackets(rcpt))
  from = lcase(sfStripBrackets(from))

  // Parse the rcpt address to get its parts.
  // We want the user id part (left hand side) of address.
  // This would be the "list name".

  dim eaToas TEmailAddress
  dim eaFrom  as TEmailAddress
  ParseEmailAddress(rcpt,eaTo)
  ParseEmailAddress(from,eaFrom)

  dim lname as string = eaTo.usrid

  // Get the WCLS control name and compare with the list name,
  // or search for a existing mailing list by list name.
  // If found, then accept this email, record it in log
  // and also in the session trace (meta log).

  dim cname as string = lcase(ReadListControlName())

  dim ml as TMailList

  //-
  // 2.1
  // - Added control name and list control names check
  dim IsControlName as boolean
  if (cname = lname) then IsControlName = true
  if not IsControlName and right(lname,10) = "-subscribe"   then 
IsControlName = true
  if not IsControlName and right(lname,12) = "-unsubscribe" then 
IsControlName = true
  if not IsControlName and right(lname, 8) = "-bounces" then 
IsControlName = true

  //-

  // 2.2 05/03/20 04:58 pm
  // -- pass the domain to compare with listdomain
  dim ListDomainOK as Boolean = 
MailListRead(lname+".LIST",ml,eaTo.Domain)

  //
  if (IsControlName or ListDomainOk) then
 dim s as string = "Sender: "+from
 if from = "" then
 s = "Bounce message"
 from = "<>"
 end if
 //---
 // 2.1, added ADSP/DMARC check
 //---
 if (not IsControlName) and ml.CheckADSP then
dim dmarc  as string
dim adsp  as string
dim policy as string
if GetDMARC(eaFrom.Domain, "", dmarc) then
   policy = lcase(GetHeaderTag(dmarc,"p="))
   dim fv as 

Re: [dmarc-ietf] Signaling MLMs

[Douglas Foster]

I am beginning work on a Best Practices document which will attempt to
explain what evaluators should understand about p=reject.   Topics to
include:

   - PASS is more important than FAIL
   - SPF and DMARC are not the end of authentication options.   Any message
   can be authenticated for the purpose of distinguishing acceptable mail
   streams from their impersonators.
   - Exceptions are to be expected.
   - Tuning of Sender Authentication should be a normal process of filter
   tuning, occurring in parallel with content filter adjustment, whitelisting,
   and blacklisting.

Since nothing like this exists, it may change the approach used by some
evaluators, but nothing will change all of them.

MLM senders need their minimally-authenticated messages to be accepted by
evaluators.  This requires a recognized identity with a high reputation
that is considered relevant to the decision.John suggested that his
doman's signature should be enough to remove distrust.   If his domain was "
pphosted.com" or "mimecast.com", his signature might be sufficient.
 Evaluators know that those signatures mean the message has been initiated
by a big-money organization, and then been filtered to prevent accidental
release of malicious messages.

How does a MLM start building that kind of reputation?

   - Ensure posts are personal messages where MailFrom and From represent
   the same account, or at minimum the same domain.
   - Ensure messages are not impersonated by validating the MailFrom domain
   with SPF, DKIM (in the absence of SPF policy), or a local policy that
   corrects for SPF policy errors.
   - Ensure messages are not malicious by performing best-effort malware
   filtering.
   - Further protect against malware and abuse by restricting high-risk
   attachment types and overly large attachments.
   - Most importantly, publish all of these policies online where a
   subscriber and his mail system administrator will find it.

But yes, it is within the power of MLMs to reject subscriptions from
p=reject domains, especially since alternatives like Gmail are readily
available for free.  But this could have happened already without IETF
advice on the matter.   So how serious is the problem, and how does our
document add value to the negotiation between domains and MLMs?

Doug Foster



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

> On Wed, Apr 12, 2023 at 11:41 AM Todd Herr  40valimail@dmarc.ietf.org> 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