On 9/23/20 2:49 PM, Seth Blank wrote:
... the Chairs strongly believe that having rough consensus on clear
definitions is key to progressing the bis effort effectively. We
strongly agree with Dave Crocker's position here:
https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/
Role definitions are useful, and indeed several appear in RFC7489
section 3. (I'm surprised that Report Generator isn't there...)
I think that expanding those definitions _in the RFC_ would be useful to
provide a stable reference and avoid confusion in related and subsequent
documents, not to mention our discussions.
Should the spec be clear about ... what it means for each to
participate partially and completely?
This sounds like, "You haven't really implemented DMARC unless you do
all of X, Y, and Z and do them this way."
We should keep in mind that DMARC is a _cooperative_ endeavor outside
the protocol evaluation - the Domain Owner _requests_ a particular
treatment, they cannot coerce it. A Mail Receiver / mailbox provider may
send reports to enable the Domain Owner to correct authentication
issues, but they cannot compel it.*
Yet many of the discussions related to ticket 66 on- and off-list appear
to arise from people thinking that they are entitled to dictate how
other entities implement and/or use DMARC outside the protocol
evaluation, and that is a recipe for disappointment. Guidance is
perfectly reasonable, probably even helpful, but we aren't going to get
very far with commandments and proscriptions unless the goal is to have
them ignored.
-1 to normative language in this sense
+1 to guidance/suggestions, probably moreso in a BCP
--S.
* Obviously certain parties _can_ compel behavior (AOL/VZN/Yahoo,
Google, etc). But that ability wasn't created by DMARC, and such a
capability will not be conferred in the other direction by DMARC.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
