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

Douglas Foster <> Thu, 06 May 2021 23:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D7933A1009 for <>; Thu, 6 May 2021 16:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4hx4082ERhuA for <>; Thu, 6 May 2021 16:19:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52FCE3A1007 for <>; Thu, 6 May 2021 16:19:35 -0700 (PDT)
Received: by with SMTP id c8-20020a9d78480000b0290289e9d1b7bcso6410605otm.4 for <>; Thu, 06 May 2021 16:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XuoXwao1qvLOEEGrVZlIn5AG7rZ0YYm8mqAbUUVSNIM=; b=FXSFzF4Pu//hxjszDznNjXkCo82VEqbsDxsas4r6iIPxQRIe90aVlgM0nwP5BzU+rp 7iPBWY7m2f24i92VOahoTD3dXEtPMshSVe6x/GHDj30mB5wKbKKp8lI406E/BbVr6gDJ WPMAz/wjPDr/a4uYYxoW+Ru9Wxbvy8ZJXmtttMlTvhrGyd7NPxrR/CN0jouRD3JQZIAU 9BUW7cebuRLw81mKcI4pTLLZBmzMUxz++ADXohPdnQp+54UxTLT4XacUan/HTtfp+AGz 6CCxtIkACMuKx1gCuLpBmGhMaeoZ8iah4yhMMztvxFZ1Pur+BzuKs1odHpUVIrXqJu9M dJKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XuoXwao1qvLOEEGrVZlIn5AG7rZ0YYm8mqAbUUVSNIM=; b=BfXc+HvSWiHCXRFnHmrj3/0oChawaTLQblwRZJMKM+MtZZRKULU9HP7DB9TP/UE7Mi AK7jYcLLM1RDgrNJUz8ksuz9XHD2JlUncR6oqs6XYym/ISyGMf9ax6ObJwVKMsj47hNm 0KXfDFuj4femN8R3nc46wS26xmtmFVyGBK3LgKaAanGMRZZO5KF2lXn9oQ6lFSYASj/v aiXYOlbkQlccYj6uNzQ9isrYxVFUSiKEgZhdW35pTDLl1dk2c6TY5/2VG3xaotlEnjIS tsVBIyFimEdpIY78or5xcWB5uHYYdE48ofzsvg7JqGzAA4xJ/nWEJH7UEsuFZ52y0/uL zl/w==
X-Gm-Message-State: AOAM532zy9/RUsfWvsr/aqgJT6NvJZ/opkk0R3mqocimuAwVig4o7XWG mCEg8jpRrEy3QK6y8+uEKkionF0rwXONgGdsA7G+24b1YjM=
X-Google-Smtp-Source: ABdhPJyRBYUXn6Mw5Um0KUTyARSdeabf+7TiAwv7F8vDwkRY3baQXIYJfI1NIqf/0S6nxqb2oJnjjyq4jdxO4XhRJDc=
X-Received: by 2002:a9d:30b:: with SMTP id 11mr5469341otv.298.1620343173786; Thu, 06 May 2021 16:19:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Thu, 6 May 2021 19:19:22 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000049af8d05c1b18bcf"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 May 2021 23:19:39 -0000

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 <>.  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]
<> 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]
   describes backscatter and the problems it causes.

On Thu, May 6, 2021 at 6:32 PM Jeremy Harris <> 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