--On Friday, July 18, 2014 01:01 +0000 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
(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.
In an odd way, your comment above illustrates the reason I think
an extended status code would be useful and why I'm concerned
that this draft might not have received adequately broad review.
If the use of nullmx were confined to parted domains, I would
agree with you and not see a problem. But the document doesn't
say that -- from reading it, one could get the impression that
it is being recommended for the domain associated with any
system that doesn't expect to receive mail. That leads into
some of the other cases, including the large mail operator whose
sending and receiving hosts are separate, as discussed earlier
and, e.g., some interesting questions about what happens if,
despite what it says in the document, multiple MX records are
configured only one of which has "." as the data. In some of
those cases, the cause of rejection might be an operational
configuration error, not an error on the part of the sender.
For such cases (including the examp1e.com one) details status
codes could be a big advantage.
The primary use for nullmx is parked domains. At previous
employer we configured thousands of parked domains with nullmx
RRs.
I'm not recommending this but, if the documents said "this is
for parked domains, for any other cases, the structure is
outdated and SHOUDL NOT be used except under special
circumstances and with adequate explanation.
john