>
> 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".
> =20
> > "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 [EMAIL PROTECTED] the mail would come
from [EMAIL PROTECTED] 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.
Mark
> 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".
>
> Frank
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
