Re: [apps-discuss] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Nico Williams <[e-mail]>]

On Thu, Jul 03, 2014 at 12:03:47PM -0700, The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'A NULL MX Resource Record for Domains that Accept No Mail'
>   <draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2014-07-17. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>    Internet mail determines the address of a receiving server through
>    the DNS, first by looking for an MX record and then by looking for an
>    A/AAAA record as a fallback.  Unfortunately this means that the A/
>    AAAA record is taken to be mail server address even when that address
>    does not accept mail.  The NULL MX RR formalizes the existing
>    mechanism by which a domain announces that it accepts no mail, which
>    permits significant operational efficiencies.

So far so good, but the abstract does not mention that the I-D conflates
"does not accept e-mail" assertions with "does not send e-mail".  That
is a big deal, and it must at the very least be mentioned in the
abstract.

"Does not accept e-mail" assertions are a highly desirable optimization
for the delivery of non-derlivery notifications.  I see absolutely no
reason to conflate "does not accept" with "does not send", either in
mechanism or RFC.

Indeed, as the I-D mentions, the SPF already provides a method for
asserting "does not send e-mail".  By encouraging the inference "does
not accept implies does not send" this I-D leaves us with no mechanism
by which to indicate "does not accept but does send".

Consider automated job ("cron") e-mail.  There may be no return path.
But the received headers allow the recipient to find the source of the
e-mail and fix whatever problem might need fixing.  Causing such e-mail
to not be delivered would be a serious problem.

Please do not publish this I-D as-is.  Please remove the "does not
accept" -> "does not send" inference and mechanism from the text.
Otherwise this I-D will likely cause harm.

Nico
--