I have a question for the group; I have read RFC7960, but I feel my
question merits reiteration for those of us on this list (like me) that
may have differing opinions on this topic from experience as a consumer
of the standard, and having worked with many of these "general purpose"
domains at p=reject.
The concern with interoperability with p=reject is that if,
hypothetically, every domain on the internet were to go to p=reject
right now, the damage would be tangible because many indirect and
"non-DMARC described" mail flows would be prevented from delivery?
(non-5322.FROM munging mail lists, some non-descript mail relays, a
random mailbox forwarding, a non-DKIM preserving forwarding mail
service, non-DKIM signed forwarded mail flows, etc. etc.) Is this a
correct assessment behind the reasoning for the "MUST NOT" language?
I am concerned that others may see this language and perceive it as
weakening the value of DMARC, or that DMARC should not be implemented at
all, when there is a proven track record of many <general purpose>
domains that have implemented strict policies to great effect in
securing their domains without major issues.
-----
Separately, from a "general purpose" domain owners perspective, I share
Alex's thoughts. Having worked with many (extremely high volume)
non-transactional domains at p=reject, the noticeable issues caused from
p=reject has been negligible to these organizations.
Many of the mitigations from RFC7960 already apply to the traffic that
would have otherwise been impacted by what would normally be considered
an interoperability issue otherwise. That is not to say there is not
/any/ impact from its implementation, but from an organizational
standpoint, all the important messages are still delivered. There have
been outliers, of course, but they are dealt with by the organizations
on a case-by-case basis, which, to date, have been less than a handful.
- Mark Alley
On 3/29/2023 3:59 PM, Scott Kitterman wrote:
Would you feel any better if the MUST NOT was followed by 'to preserve
interoperability '? That's implicitly there and I believe technically correct.
If you value other properties of the system higher than interoperability, then
the advice may not apply, which is fine.
Scott K
On March 29, 2023 3:32:10 PM UTC, "Brotman,
Alex"<[email protected]> wrote:
I’m just not sure how we determine what is high-value.
comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine
The top one is corporate, middle is consumer, bottom is consumer (but not actually
used) & customer comms (sub-domains). They’re all used in various ways for
internal messaging. Should I tell our corporate admins that they need to no longer
publish p=reject? They’re violating the RFC by doing so? There are very few
consumer-oriented messages that originate from comcast.com. Are we doing it right?
It makes things a little harder when one of our employees wants to use a mailing
list. But that still feels like the right thing to do.
If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to
domain owners what is in their best interests, regardless of our perceived
value of their domain.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc<[email protected]> On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr<[email protected]>
Cc:[email protected]
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
I'm very much against text such as this, as I think it encourages deployments
that are contrary to interoperability and to the intent of p=reject.
I contend that p=reject (as with the similar construct in the older ADSP) was
intended for high-value domains and transactional mail, and that it was never
intended for use in domains where general users send general email.
I stand by the MUST NOT that I proposed.
Barry
On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
<[email protected]<mailto:[email protected]>>
wrote:
On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
<[email protected]<mailto:[email protected]>> wrote:
If you agree that interoperability is increased, then I'd suggest that you
actually do agree that the proposed text is appropriate.
I don't know that I agree that interoperability is increased...
I'm having trouble squaring proposed language that says "Domain owners MUST NOT
publish p=reject because it breaks interoperability" with the following language
from section 5.8:
Mail Receivers **MAY** choose to accept email that fails the DMARC
mechanism check even if the published Domain Owner Assessment Policy
is "reject". In particular, because of the considerations discussed
in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject
messages solely because of a published policy of "reject", but that
they apply other knowledge and analysis to avoid situations such as
rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.
It seems inconsistent to state with certainty that authorized mail will be
rejected due to authentication breakage when there is no requirement that a
reject policy be honored (and we have plenty of evidence that Mail Receivers
are following the 'SHOULD NOT reject messages' guidance).
Language that would be more consistent in guidance to the domain owners might
look something like this:
After careful analysis of the aggregate report data as described in section
5.5.5
(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's
judgement,
unauthorized and deceptive use of its domain name in the RFC5322.From field puts
at risk the trust it has built with its recipients, then it is **RECOMMENDED**
that
the Domain Owner make use of the p and/or sp tags to set policy to 'quarantine'
or
'reject' for those streams most at risk of loss of trust.
If going that route, probably want to consider expanding on 5.5.5, too; I need
to think about it some more.
--
Todd Herr | Technical Director, Standards and Ecosystem
e:[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
