On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely <ves...@tana.it> wrote: >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. > It's not a transition until there's something to transition to. Currently it's a bridge to nowhere.
Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
