> Perhaps this will alleviate some confusion.
> * All this draft does is define an MX that says "you can't send mail
> here." It's intended for domains that handle no mail at all, but get
> mail anyway due to typos or brain-os. There's no hidden agenda.
> Really.
> * It has been widely implemented in Exim, Postfix and other MTAs for
> nearly a decade. If there were severe damage, we'd probably have
> noticed by now. The fact that it's widely implemented suggests that
> people find it useful.
> * The part in the draft about sending and receiving was confusing
> and unhelpful, so I rewrote it. Now it says you SHOULD NOT send mail
> from a domain that publishes null MX. This is both on principle,
> don't send mail if you don't want an answer, and practice, since many,
> many MTAs reject mail from domains without a resolvable mail server.
> (Remember, SHOULD NOT means don't do this if you want to interoperate.)
The closest existing code is 5.4.4 Unable to route:
The mail system was unable to determine the next hop for the
message because the necessary routing information was
unavailable from the directory server. This is useful for both
permanent and persistent transient errors.
A DNS lookup returning only an SOA (Start of Administration)
record for a domain name is one example of the unable to route
error.
But this isn't quite right, because this is for when there's no relevant DNS
information at all. And for diagnostic purposes it makes sense to be able to
distinguish "no entry in DNS" from "DNS says host doesn't accept mail"
Which is what I was trying to say; this really deserves a new 5.4.x code.
As for text, how about:
X.4.8 Destination does not accept mail
The directory server has returned an indication that the
next hop is incapable of accepting mail.
In the case of a DNS lookup, this can be indicated through the
use of a null MX entry [this rfc].
Or something along those lines. (8 may not be the right code, but it what
the IANA registry says is correct.)
Ned