Re: [dmarc-ietf] Ticket #111 (and #112) - Proposed language

[Douglas Foster <[e-mail]>]

(Subject ticket number corrected.)

Michael, I am surprised and disappointed by the severity of your critique.

NP Policy
-------------
The NP policy is upon us.   PSD for DMARC demonstrated the need.    The
problem is that their definition of NP, which the current DMARCbis draft
inherits, is a pre-SPF test for an invalid SMTP MailFrom address.   It is a
bizarre stretch to apply that test to the RFC5322.From address.    The
current test is insufficiently defined, undefended, and indefensible.  It
must be fixed.   The focus of this draft is a proposed fix, because there
have been no other fixes offered.

The key insight behind the NP policy idea is that some domain abuse can be
detected and rejected without depending on the attributes which create the
mailing list problem.  The best boundary for the NP policy is between those
names that are used as FROM address and those that are not.   Domain owners
currently lack sufficient mechanism to signal that condition correctly.

I evaluated options based on NXDOMAIN, but rejected them.  Even when done
perfectly, NXDOMAIN excludes a smaller set of unauthorized names than this
approach, and seems more difficult to implement.  NXDOMAIN has some nuances
which I found problematic.  This proposal introduces relatively low
compliance measures for those domain owners that wish to implement NP.

The Introduction
----------------------
As to the introduction, I think the relationship between SP=NONE and the
mailing list problem has been well elucidated.    Nor do I think that an
introductory sentence needs to enumerate all possible reasons for SP=NONE.
 But if you prefer to simply say "some domain owners have difficulty moving
beyond SP=NONE,", without any additional comment, I can accept a change
along those lines.   Getting the correct definition of NP is my priority,
not the opening sentence.

Validate vs Reject
------------------------
Sender authentication involves two partially independent goals:  proving
that a message is definitely authorized, and proving that a message is
definitely not authenticated.   Proving authorization is only relevant for
names that are used as email addresses.   Proving non-authorization has a
much larger scope, because it involves all possible names, not merely
in-use names.

RFC 7489 attempted to prove non-authentication based on domains achieving
SP=REJECT and messages being delivered without in-transit loss of
credentials.   This has not worked out well in practice.   NP defines
non-authentication based on attributes which are not dependent on transit,
and therefore it is a very powerful idea.

Level of Detail
-------------------
I could be convinced to move some of this content into a Best Practices
document.,   But my target audience is not limited to the big organizations
that can build custom code and spend a large amount of money on
consultants.   I am equally concerned about the smaller players who are
dependent on off-the-shelf products available from vendors, and the
developers witin those vendors who often implement to the specification
rather than to the security problem.   So yes, I favor laying things out
clearly, rather than assuming that sophisticated people will be able to
read between the lines.

If you have a different definition of NP, let's hear the proposal and its
defense.

Doug Foster

>
>