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(_at_)ietf(_dot_)org mailing lists by 2014-07-17. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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
--