On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote:
Murray S. Kucherawy wrote on 2023-07-08 02:44:
"SHOULD" leaves the implementer with a choice. You really ought to do what
it says in the general case, but there might be circumstances where you could
deviate from that advice, with some possible effect on interoperability. If
you do that, it is expected that you fully understand the possible impact
you're about to have on the Internet before proceeding. To that end, we like
the use of SHOULD [NOT] to be accompanied by some prose explaining when one
might deviate in this manner, such as an example of when it might be okay to
do so.
The elaborated Interoperability Considerations in Barry's proposal gives the
implementer guidance to understand the impact. In my understanding, SHOULD is
ought to be followed, unless the implementer has good reasons not to. The
burden of justification is on the implementer, not on the spec.
The implementer, in turn, passes the buck to the user. To quote Cisco's email
security appliance[*]:
The default behavior of the ESA is to never drop any messages unless
explicitly instructed by the customer, so default DMARC verification
profile will have all actions set to “No Action”.
It has to stay that way until we fix forwarding.
Does anyone have such an example in mind that could be included here?
Specifically: Can we describe a scenario where (a) a sender publishes
p=reject (b) with users that post to lists (c) that the community at large
would be willing to accept/tolerate?
The scenario I have in mind is a business domain with a high demand for
protection from exact domain spoofing and a low to no demand for list
communication. Note the wording in Barry's proposal: "users who *might* post
messages to mailing lists" (not: "users that post to lists").
ADSP characterized them as domains /with no individual human users/. Yet that
helps only the sender side of the equation. Since human receivers /might/ want
to forward messages to another mailbox, we're back to a protocol with no humans
on either side. A rather disconcerting position.
Maybe one day there will be a DMARC with batteries included, where implementers
ship default configurations which are effective out of the box. While I don't
know how to get there, I think it's counter-productive to exact perfect
compliance during the transition. There have to be people who think they have
good reasons to push, otherwise we won't move.
Best
Ale
--
[*]
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/215360-best-practice-for-email-authentication.html#toc-hId-103046190
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
