[dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30

[Seth Blank <[e-mail]>]

There are three items in the document that have consensus, which I believe
are wrong. I am in the rough on these, and not looking to relitigate them.
I am hoping to provide text that clarifies concerns in a manner that leads
consumers of the document to make better informed implementations, and I
provide what I've previously shared to the list as rationale for the
language but not as relitigation of the core topics.

In order from most to least contentious:

1. 8.6. Interoperability Considerations

"It is therefore critical that domains that host users who might post
messages to mailing lists SHOULD NOT publish p=reject."

While this advice represents consensus, it does not represent operational
best practice, nor where the market is moving to stop fraud and abuse.
DMARC is becoming increasingly required at the major mail receivers, and
messages that cannot get a DMARC pass are increasingly likely to get
rejected outright. This language feels like it is creating an even worse
interoperability problem-- giving guidance to people that will guarantee
their mail gets rejected by major mail systems. These DMARC mandates arose
after consensus was called, and have changed the playing field materially.

More accurate language that alleviates the concern would be "It is
therefore critical that domains that host users who wish for their messages
to be modified and spoofed by downstream intermediaries, such as alumni
forwarders or mailing lists, SHOULD NOT publish p=reject. Such spoofed
messages may still be rejected, regardless of a domain owner's published
DMARC policy."

When it comes to the Charter, the document is supposed to articulate how to
address indirect mail flow, and this would be the place. Therefore, I
believe it is also worthwhile in this section to reference both ARC, as
well as other mechanisms that such breaking intermediaries that create new
messages (and therefore spoof the sender) could undertake, such as From
rewriting to properly claim ownership of the message, or not making changes
to the message that invalidate DKIM.


2. 5.7.4. Send Aggregate Reports

There are no protocol police, and implementers are free to follow or ignore
normative guidance at their whim.

For a domain owner, it is an interoperability problem to not receive
reports, and therefore this meets the normative requirement to be a MUST.
Smaller receivers are of course free to ignore this if the burden is too
high, but that should be their guidance to ignore, not the document's duty
to presuppose. Domain owners need reports, or they cannot put the work in
to authenticate their mail and publish a policy that has an impact they can
expect. So reports MUST be sent.

Given the consensus around SHOULD, I'd recommend the following change:

OLD: Given the above, to ensure maximum usefulness for DMARC across the
email ecosystem, Mail Receivers SHOULD generate and send aggregate reports
with a frequency of at least once every 24 hours.

NEW: In order for domain owners to properly collect and analyze reports
(section 5.5.5) in order to authenticate their mail and publish a policy if
they wish (section 5.5.6), mail receivers need to supply those reports. To
ensure maximum usefulness for DMARC across the email ecosystem,
understanding that some receivers may find this an undue burden, Mail
Receivers SHOULD generate and send aggregate reports with a frequency of at
least once every 24 hours.


3. 4.4. Identifier Alignment Explained

If we ever open alignment again for a future document, I hope we do away
with strict alignment. It would also simplify the document and the examples
greatly.

Early on, consensus was that we should keep strict alignment, as it was
used by a very small handful of organizations, but primary amongst them
were some banks who took strict to mean more secure. Further details were
discussed at the interim here:
https://mailarchive.ietf.org/arch/msg/dmarc/PPskhJKs-cvXJpjzh-UiJQ9ba4M/
This decision to keep strict alignment made sense in isolation.

Since then, we've discussed two other removals -- relying on SPF at all,
and not worrying about mailing list traffic at all -- both of which affect
more mailflow and deployment than strict alignment. If we're willing to
seriously discuss things that affect more mail, should we not also review
the need for strict alignment?

I also don't think we really reviewed strict alignment after incorporating
the tree walk into the document. Most of the uses for strict alignment were
in the "I have a large organization, and want to make sure one part of the
organization cannot spoof another" camp-- which now the tree walk should
have provided a more scalable solution for.

As was discussed during the interim, there is not operational practice that
underscores strict alignment actually providing any real advantage.
Practically speaking, almost no one uses strict alignment. And for those
that do, it tends to be significantly more difficult to implement, for no
actual benefit that's ever been presented to this working group. Further,
there are many that look at "strict" as "better" and "more secure" and then
find themselves unable to implement DMARC, when relaxed alignment would
have actually given them everything they need and the protections they're
looking for.

At a minimum, I think the second paragraph of section 4.4 should be changed:

OLD: The choice of relaxed or strict alignment is left to the Domain Owner
and is expressed in the domain's DMARC policy record.

NEW: The choice of relaxed or strict alignment is left to the Domain Owner
and is expressed in the domain's DMARC policy record. In practice, nearly
all domain owners have found relaxed alignment sufficient to meet their
needs.



Seth, as an individual, not trying to relitigate, just trying to clarify
concerns, and not dying on any of these hills.

-- 

Seth Blank | Chief Technology Officer
Email: [e-mail]


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.