I am not concerned about defining an acceptable DMARC implementation, but I
am concerned about making implementations successful.,    My four-way
partition is a framework for talking about the obstacles to success:

- Domain owners have trouble knowing whether they are ready for p=reject
because they only get feedback from evaluators that do RUA reporting.

- Extended status codes open an independent communication channel from
evaluator to sending system operator.   The sending system operator may be
independent of the domain owner (mailing list, ESP, forwarding service), or
may operate largely independent of the domain owner (John's "Holy Roman
Empire" organization.)

Ergo:
- We need to explicitly encourage the use of extended status codes.
 Messages that are blocked for DMARC FAIL, but lack an extended status
code, are useless for helping a domain owner fix his problems.

- The current IANA registration should be modified to allow extended status
codes for authentication failure even for accepted messages.   These serve
as warnings to the sending system operators.   This adds no risk.   The
deliberate impersonator knows that his messages will fail sender
authentication, so his interest is whether his message is accepted or not.
 Telling him that I noticed his missing credentials, but allowed the
message anyway, causes no harm.   Telling the same thing to a legitimate
sender gives him a warning to fix the problem.

- We need to encourage people to become RUA reporters, but we cannot
mandate it.   Evaluators will do whatever they want.

How do we sell this in the document, and where?


On Fri, Sep 10, 2021 at 2:48 PM John Levine <[email protected]> wrote:

> It appears that Tim Wicinski  <[email protected]> said:
> >I am not well ensconced in the Mail community, but are this disagreements
> >between vendors, software, etc over if one is "implementing DMARC"?
>
> Sure, but it's not our problem.  People still have arguments about whether
> you've really implemented SMTP if you use a DNSBL to reject some of the
> traffic.
>
> R's,
> John
>
> PS: In case it's not obvious I concur with the advice to take the section
> out.
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to