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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx 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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]