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
--