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

You or the others seem to be confusing NXDOMAIN on RFC5321.MailFrom lookup
with NXDOMAIN on RFC5322.FROM.  The issues are very different.

NXDomain on the MailFrom lookup says neither the SPF policy nor the SMTP
domain exist, and therefore there is no reverse path.   Rejecting such
messages makes a lot of sense and, as has been said, has nothing to do with
DMARC.

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.
- 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.

With the expectation of significant errors in both directions, we do not
have a usable definition of NP.

Doug Foster

On Wed, Jun 16, 2021 at 1:51 PM Alessandro Vesely <vesely@tana.it> wrote:

> On Wed 16/Jun/2021 18:01:08 +0200 John Levine wrote:
> > It appears that Alessandro Vesely  <vesely@tana.it> said:
> >>However, to reject based just on NXDOMAIN is too harsh.
> >
> > I dunno, in my experience it's quite common, and if you do, the chances
> of losing a message you care
> > about are negligible.
>
>
> It's been customary to reject NXDOMAIN in smtp.mailfrom since when I
> recall it.
>   To reject NXDOMAIN in header.from is (was) an ADSP feature which doesn't
> seem
> to be very widespread.  DMARC dropped it a long time ago.
>
>
> > In any event, this has nothing to do with DMARC.  If for some reason you
> want to do a DMARC evaluation
> > of a non-existent domain, you can use the organizational domain or I
> suppose PSD.
>
>
> It might make sense to reject that ~30% which doesn't even have an
> organizational domain (dubbed totally astray in my previous post).  But I
> still
> receive From: <please.post@publicly.invalid> on a mailing list.
> Rejecting that
> risks getting unsubscribed.  Perhaps mailing lists deserve a special
> permission...
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>

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