Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster <[e-mail]>]

I was referring to this section of RFC 7208, which I have interpreted as a
replacement for the older language of RFC 5321.
Perhaps I overgeneralized, and it is acceptable/desirable to send NDRs if
the system is confident that the return-path target is not forged.
My perception has been that NDRs are widely ignored even when they are
sent.  Is your experience different?

Doug Foster


2.5 <https://tools.ietf.org/html/rfc7208#section-2.5>.  Location of Checks

   The authorization check SHOULD be performed during the processing of
   the SMTP transaction that receives the mail.  This reduces the
   complexity of determining the correct IP address to use as an input
   to check_host() and allows errors to be returned directly to the
   sending MTA by way of SMTP replies.  Appendix D of [RFC7001]
<https://tools.ietf.org/html/rfc7001#appendix-D> provides
   a more thorough discussion of this topic.

   The authorization check is performed during the SMTP transaction at
   the time of the MAIL command, and uses the MAIL FROM value and the
   client IP address.  Performing the check at later times or with other
   input can cause problems such as the following:

   o  It might be difficult to accurately extract the required
      information from potentially deceptive headers.

   o  Legitimate email might fail the authorization check because the
      sender's policy has since changed.

   Generating non-delivery notifications to forged identities that have
   failed the authorization check often constitutes backscatter, i.e.,
   nuisance rejection notices that are not actionable.  Operators are
   strongly advised to avoid such practices.  Section 2 of [RFC3834]
<https://tools.ietf.org/html/rfc3834#section-2>
   describes backscatter and the problems it causes.



On Thu, May 6, 2021 at 6:32 PM Jeremy Harris <[e-mail]> wrote:

> On 05/05/2021 12:28, Douglas Foster wrote:
> > Non-delivery reports are officially discouraged
>
> RFC 5321 Section 6.2 says the reverse.
>
> --
> Cheers,
>    Jeremy
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>