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