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
> ietf@xxxxxxxx mailing lists by 2014-07-17. Exceptionally, comments may be
> sent to iesg@xxxxxxxx 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
--