ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

2014-07-17 20:02:20
On Thu, Jul 17, 2014 at 01:39:53PM -0400, John C Klensin wrote:

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. 

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.

In find nullmx on the contrary far less objectionable than all
other anti-abuse measures.  I just designates non-sending domains,
via a simple low cost mechanism.  It is already reasonably widely
in use even without a formal standard, based on the prior draft
revisions.  There is nothing here that is about silent discard of
mail by remote domains.  The origin domain declares non-sending of
mail and receiving systems are free to reject forgeries.

It is certainly far less damaging than DMARC.

That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.

Thanks.  The subsequent technical comments are generally sound and
should be addressed.

(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order.  Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing).   Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.

This is likely already practiced, and is clear enough in practice.
Keep in mind that there are no legitimate senders of mail blocked
by nullmx rejection, so the DSN status codes are of little interest
to anyone but the bad guys.

The primary use for nullmx is parked domains.  At previous employer
we configured thousands of parked domains with nullmx RRs.

-- 
        Viktor.

<Prev in Thread] Current Thread [Next in Thread>