Mark Andrews wrote:
First, it may have been obvious to you, but it wasn't obvious to=20
many of us. In the general case, it still isn't. But you=20
stated the situation exactly correctly. "MX 0 ." means "I=20
don't want email". "SRV 0 0 ." doesn't really indicate "no=20
service", it indicates "please do look for that service here".
"SRV 0 0 <hostname>" means look for that service here.
"." is not a valid hostname.
Possibly you miss a subtle point in the nullmx design, it does not
only mean "I don't want email". It also means "any mail claiming
to be MAIL FROM me cannot be okay, because there is no route to
report non-delivery" [etc. down to RFC 3834 auto-replies, but the
REQUIRED capability is to report non-delivery].
I'm well aware of that.
It doesn't however mean you cannot send mail from that
machine however. You just have to set an appropriate mail
domain for outgoing mail.
Rather than toster(_at_)toaster(_dot_)example(_dot_)net the mail would
from tosterXXX(_at_)example(_dot_)net or something similar if you
were using "MX 0 .".
Non deliver reports don't have to go back to the originating
machine. There are 100's of millions of clients today that
operate in exactly this manner.
On the DKIM list folks discussed to emulate "I send no mail" with
a public statement "all my mails are signed", and then simply not
sending signed mails. That's possible, but rather indirect, and
won't help receivers not interested in DKIM signing practises.
Even more subtle, DKIM is not about the 2821 MAIL FROM, so this
approach is beside the point wrt SMTP. Likewise a SenderID PRA
"spf2.0/pra -all" policy won't help wrt SMTP.
The SPF solution "v=3Dspf1 -all" is acceptable, but this won't help
receivers not interested in checking SPF. It also might not work
for receivers deciding to accept SPF FAIL, using it only as an
ingredient in scoring.=20
Another now AFAIK long dead solution was a blacklist of domains
never sending mails, again not working for receivers not checking
this black list, or using it only as an ingredient in scoring.
nullmx tackles the problem directly within RFC 2821 and 2821bis
MUSTard, because receivers MUST report non-delivery they have no
business to accept an "impossible" reverse path bound to a nullmx.
Of course receivers intending to violate 2821(bis) could still
accept the nullmx reverse path, but that is their problem, folks
are free to be as stupid as they can get away with.
Disclaimer for those who have not read it on the general list:
I do NOT support to add nullmx post second Last Call to 2821bis,
and I don't think that billions of IPv6 toasters and webcams not
interested in mail should have a nullmx or publish "v=3Dspf1 -all"
or whatever DKIM offers to say "all mail from me is discardable".
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org