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

[Douglas Foster <[e-mail]>]

This is frustrating.   NP is a new design and the design issues should
have been discussed before we got to this point.   I don't know why so many
people are eager to not define the new technology.

There seems to be an unwillingness to acknowledge the current state of the
email ecosystem.  There seems to be a mythology that any email suffix used
with a mailing service must also exist elsewhere in the ecosystem as an
SMTP sender and receiver.   The MX/A/AAAA/.SPF seems to be based on this
myth.  There is no such necessity in the real world.

For a legitimate message, where a mailing service uses its own identity for
MailFrom and the client's identity for the From, the From address has very
few constraints:
- IETF format rules
- DMARC policy if present
- Mailing service business practices

On mailing service business practices:
I find that the major mailing services can be trusted to correctly present
the client organization.  But that does not include a requirement that the
email suffix has a separate identity as an SMTP sender and receiver.   My
data indicates that they will be happy to let @Example.Com send a message
from @EasterSale.Marketing.Example.com.

On DMARC policy
NP is only relevant if:
- The message does not authenticate.  DMARC PASS continues to be a final
result.
- A domain P policy does not apply.   P policies override SP and NP
policies.
- The SP policy is NONE and the NP policy is QUARANTINE or REJECT.   (If
the NP policy is the same as the SP policy, the result will be equivalent
to RFC7489 SP without NP.  If the NP policy is weaker than the SP policy,
the configuration is simply stupid.)

NP is an effort to partition the RFC 7489 SP=NONE result set, so that a
subset of all SP results can be blocked on some additional criteria.
This additional criterion could be based on non-existent as indicated by
NXDOMAIN, or it could be based on "not used for email" based on a criterion
to be defined.   Either approach needs to have a mechanism for
non-compliant names to be made compliant.   I believe that this should
involve a DNS entry, but the compliance measure should be specific to the
NP test.   Requiring that every FROM address be linked to an IP address
does not meet that requirement.

Doug Foster

Doug Foster


On Thu, Jun 17, 2021 at 3:57 AM Murray S. Kucherawy <[e-mail]>
wrote:

> I continue to not understand the defect you're highlighting here.
>
> I think you've expressed yourself primarily in the abstract.  Could you
> craft a sample message, sample envelope, and sample DNS context that
> highlights the problem you're talking about?  Maybe then it'll snap into
> focus.
>
> On Wed, Jun 16, 2021 at 2:43 PM Douglas Foster <
> [e-mail]> wrote:
>
>> NXDomain on RFC5322.From is a completely different issue.    It means
>> that the name is only used for service provider messaging, and is therefore
>> not linked to any IP address or other physical infrastructure.  It affects
>> the ability to define a meaningful NP test.   The issue becomes irrelevant
>> to DMARC if and only if we drop the NP policy idea completely.
>>
>> The proposed MX/A/AAAA/SPF test has two significant problems:
>> - It incorrectly classifies some names as NP because they do not need
>> MX/A/AAAA/SPF records because they are not tied to an IP address, and we
>> have provided a very poor mechanism for a domain owner to come into
>> compliance.
>>
>
> There's a workaround here: If I want to use a name that is not represented
> in the DNS according to that test, all I need to do is DKIM sign with my
> parent domain.  That makes "p" apply because now you have an aligned
> "pass", which presumably trumps any "np" that's set.
>
> If you aren't signing with DKIM in that scenario, and you obviously can't
> pass SPF either, then you can't possibly hope to pass DMARC irrespective of
> any test being done on the name's validity.
>
> - It incorrectly classifies some names that are not used for email as not
>> NP, simply because they have an A/AAAA record.   It provides no method for
>> the domain owner to signal that the name is not used for email and
>> therefore should be treated as NP.
>>
>
> If they're not used for email, then they're not in DMARC's problem space.
>
> At any rate, since PSD has been approved, I'm hoping the experiment is
> underway, or will be soon, and then we might have some actual data about
> the severity of this defect and thus also possibly some hints about ways it
> can be mitigated.
>
> -MSK
>