On Thu, Jul 17, 2014 at 01:39:53PM -0400, John C Klensin wrote:
- 'A NULL MX Resource Record for Domains that Accept No Mail'
<draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
When I first saw this and your reply I thought "what the heck is he
talking about, it's so obviously a good idea". Then I read sections 4.3
and 5. Now I join the objection chorus.
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful. I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages. I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery. [...]
I think what you're objecting to is the section 4.3 and related text
that conflates "does not accept e-mail" with "does not send e-mail". If
so I agree. The two assertions *must* be separable! And preferably the
two assertions should be separate both, in terms of mechanism and
specification.
Assuming this conflation were fixed or the "does not send e-mail" text
removed, nothing in the remainder of the draft prevents notifications
for non-deliveries. Indeed, the "does not accept e-mail" assertion
[greatly] optimizes the case where the target domain does not accept
incoming e-mail -- a very desirable feature, and one worth standardizing
without any relation to "does not send e-mail" assertions.
I especially reject the first sentence of the third paragraph of section
4.3: regardless of the truth of that statement, it is insufficient to
draw the inference "does not accept e-mail implies does not send
e-mail".
The last sentence of the second paragraph of Section 5
("Security Considerations") of the spec says:
"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."
First, two issues of terminology:
+1, but I think this should all be fixed by removing section 4.3 and any
remnant of the conflation of "does not accept" with "does not send"
e-mail. That is my preferred resolution.
I strongly recommend splitting this into two I-Ds, or at the very least
section 4.3 and related text into a top-level section. The "does not
send e-mail" assertion *must not* be the same as the "does not accept
e-mail".
Nico
--