Subject: [dmarc-ietf] PSD DMARC: draft-ietf-dmarc-psd post-WGLC Status

From: Scott Kitterman <[email-masked]>
Date: Sat, 28 Sep 2019 17:38:37 -0400

WGLC started on 2019-06-26.  It ended 2019-07-17.

2019-06-26: WG Secretary called for additional discussion on three topics:

1. What further context is needed in the introduction
2. If explicit call outs to ICANN/limited operator capacity to implement are 
needed
3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs

By the end of the WGLC period, after a slow start, there was a vigorous 
discussion on all these issues and (with a few days post-WGLC for the np= tag 
discussion to finish) moved towards what was in my judgment a reasonably solid 
consensus.  All issues that people brought up were addressed by the WG 
(including inclusion of some recommended editorial changes made before WGLC 
that hadn't made it into the draft).

A new revision addressing the WGLC discussion (-05) and document shepherd 
comments was uploaded 2019-07-27. 

Post WGLC discussion:

2019-07-22: A question was brought up if the draft should include hard 
requirements to forbid mail from non-existent domains.  The WG concluded that 
independent of the wisdom of such a rule, it was out of scope for the WG.

2019-07-27:  A set of editorial nits were provided against -05.

2019-07-31: Additional document shepherd feedback based on revisions provided 
in -05 and earlier comments.

2019-08-09: New revision (-06) published fixing editorial nits and 
incorporating additional changes based on document shepherd feedback.

2019-08-10: Comments on -06 from Alessandro Vesely, but no suggested changes.

2019-08-13: Comments on the general PSD DMARC concept from Dave Crocker.

2019-09-03: WG Chair feedback on 2019-08-13 comments, some discussion ensues.

2019-09-09: Discussion concludes.  It appears to me that the upshot of the 
discussion is that the Section 2.3 Longest PSD definition needs to be updated.  
All other issues have been addressed.

2019-09-24: Alessandro Vesely reports having implemented PSD DMARC in 
zdkimfilter for Courier MTA using an alternative data format for PSD DMARC 
participants based on the PSL format.

Based on the post-WGLC discussion, I believe an updated draft before IETF last 
call is appropriate with three changes:

1.  Updated Longest PSD definition:

> 2.3.  Longest PSD
> 
>    The longest PSD is the Organizational Domain with one label removed.

2.  Addition of the PSL data format to Appendix B (it would be B.3).  I 
haven't drafted text yet, but I don't expect it to be controverisial.

3.  Add zdkimfilter to Appendix C (also didn't make text yet).

Unless someone tells me otherwise, I plan to go ahead with those changes.

Scott K

---

From: Jane Moneypenny <[email-masked]>
Date: Sun, 29 Sep 2019 12:05:07 +0000

Regarding:
2.6. Non-existent Domains
For DMARC purposes, a non-existent domain is a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.

Comments:
- sometimes a domain used for mailing purposes does not have a MX record - I am not sure if 'and' is appropriate word here,
- question: what if there is a CNAME record?,
- email receivers could/should perform reverse DNS lookup, however they do not - as a result, an email from (both: Envelope and Mail from), is accepted by the MTAs,
- today, an email ‘from’ (Envelope and Mail) NXDOMAIN is accepted by vast majority of MTAs, and SPF check result is “spf=neutral” (in general), same with non-existent sub-domains (even if there is DMARC in place a message from non-existent sub-domain could be successfully delivered).

There is a solution for non-existent subdomains: Wildcard SPF. Wildcard SPF covers sub-domains (if there is no other RR for such sub-domain), and (in general) it works with DMARC.
For example:
*.example.com IN TXT v=spf1 -all
together with
example.com IN TXT v=DMARC1; p=reject;
Covers each and every NX-sub-domain, and it works pretty well.

Currently proposed solution, even with the 'np' tag, may not work. It could be rather fatally flawed.

That being said, we should consider (for PSDs) a solution similar to a Wildcard SPF, if we want PSD-DMARC work as it should.

And, because a Wildcard SPF is a TXT - not A, AAAA, MX - record, and it does not mess with the definition (2.6. Non-Existent Domains).

Sincerely,
Mnpn.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, September 28, 2019 11:38 PM, Scott Kitterman <[email-masked]> wrote:

> 4.  Updated Longest PSD definition:
>
> > 2.3. Longest PSD
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 29 Sep 2019 17:14:21 -0400

On Sunday, September 29, 2019 8:05:07 AM EDT Jane Moneypenny wrote:
> For DMARC purposes, a non-existent domain is a domain for which there is an
> NXDOMAIN or NODATA response for A, AAAA, and MX records.
> 
> Comments:
> - sometimes a domain used for mailing purposes does not have a MX record - I
> am not sure if 'and' is appropriate word here, - question: what if there is
> a CNAME record?,

Yes.  The way it's written, if any of A, AAAA, or MX give some answer other 
than NXDOMAIN or NODATA, then the domain exists.  As previously discussed 
during WGLC, CNAMES would be followed prior to such a determination, so the 
existence check would, correctly, be for the target of the CNAME, no issue.

> - email receivers could/should perform reverse DNS lookup, however they do
> not - as a result, an email from (both: Envelope and Mail from), is
> accepted by the MTAs, - today, an email ‘from’ (Envelope and Mail) NXDOMAIN
> is accepted by vast majority of MTAs, and SPF check result is “spf=neutral”
> (in general), same with non-existent sub-domains (even if there is DMARC in
> place a message from non-existent sub-domain could be successfully
> delivered).
> 
> There is a solution for non-existent subdomains: Wildcard SPF. Wildcard SPF
> covers sub-domains (if there is no other RR for such sub-domain), and (in
> general) it works with DMARC. For example:
> That being said, we should consider (for PSDs) a solution similar to a
> Wildcard SPF, if we want PSD-DMARC work as it should.
> 
> And, because a Wildcard SPF is a TXT - not A, AAAA, MX - record, and it does
> not mess with the definition (2.6. Non-Existent Domains).

We have also discussed making broader recommendations on email processing 
behavior and concluded they were out of scope.  Wild cards aren't so simple.  
The DMARC record for example.com isn't published at example.com.  It's 
published at _dmarc.example.com and you can't wild card _dmcarc.*.example.com.

Scott K