> On Apr 9, 2023, at 6:33 AM, Jesse Thompson <z...@fastmail.com> wrote:
>
>
>> On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
>> Personally, I prefer the latter of the two, quoted below.
>>
>> "to preserve interoperability, domains SHOULD NOT publish p=reject unless
>> they are [not general purpose]* domains"
>>
>> "Publishing DMARC records with restrictive policies does cause
>> interoperability problems for some normal email usage patterns. Potential
>> impacts MUST be considered before any domain publishes a restrictive policy."
>
> I like the latter, as well. I was going to suggest something similar.
>
> As Todd previously stated, my preference is for language that acknowledges
> the primacy of the domain owner over interoperability. CISOs have been sold
> (arguably, by the DMARC deployment companies' marketing) on the idea that
> there are security benefits. Maybe oversold, but there are benefits and the
> motivation will not change. Let's not also overlook the primary benefit of
> _the process of deploying DMARC_ gives to an organization: increased
> management and governance (enabled by the observability from the reports). In
> any case, the domain owner is motivated to deploy DMARC and gain the
> perceived benefits. If we are going to tell these motivated domain owners to
> MUST do something, at least make it something they might consider doing.
>
> "Before a general purpose domain publishes p=reject|quarantine, the domain
> owner MUST emit mail from, or provide to their stakeholders/end-users, an
> alternative domain or subdomain with a p=none policy for any email that needs
> to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party
> that cannot be authorized by SPF or DKIM alignment."
>
> That, combined with Mark's language, I think would resonate with domain
> owners more than MUST NOT
Yes, I think presenting solutions is better than stay exposed. No security
folks are going to go for a plan that doesn’t have a path to protection.
N
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
