Matthew Sullivan wrote:
SORBS has listed 127.0.0.1 in the past, though never used it as a return
code. It occurred due to error, but it was an easy one - the relay
tester was triggered to test localhost by someone first setting up an
open relay then sending spam, then within hours changing the DNS record
to return 127.0.0.1 for the host. Result, a request for a valid
hostname was put in the system then before it was tested someone changed
the target IP to localhost. This was fixed fairly promptly but it was
not an indicator of a shutdown. I believe other DNSBls have listed
127.0.0.1 on occasion.
I think I've figured out how this supposed to be said (pardon the raw
XML). I also fixed the bungled /8 expansion. I should know better,
because we're one of the few who actually _has_ one...
As for accidental listings - perhaps we should say something about
"SHOULD implement coding checks in DNSBLs" to avoid listing of bits that
the DNSBL isn't supposed to? That would go in the section about
reserved et. al.
What do you think of this version?
<t>Most DNSBLs follow a convention of entries for IPs in
127.0.0.0/8 (127.0.0.0-127.255.255.255) to
provide online indication of whether the DNSBL is operational.
Many DNSBLs arrange to have a query
of 127.0.0.2 return an A record indicating that the IP is listed.
See <xref target="DNSBL-EMAIL" /></t>
<t>If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN),
the DNSBL should be considered non-functional.</t>
<t>Note: In <xref target="down" /> it is noted that some DNSBLs
have shut down in such a way to list all of the Internet. Further,
in <xref target="reserved" />, DNSBL operators MUST NOT list
127.0.0.1. Therefore, a positive listing for 127.0.0.1 SHOULD
also be an indicator that the DNSBL is non-functional.</t>
<t>Other results, such as 127.0.0.3, may have different meanings.
This operational flag usage and meaning SHOULD be published on the
DNSBL's web site, and the DNSBL user SHOULD periodically test the
DNSBL.</t>
Some mail systems are unable to differentiate between these various
results or flags, however, so a public DNSBL MUST NOT include
opposing or widely different meanings -- such as 127.0.0.23 for
"sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
same DNS zone.
Not sure why this is a MUST NOT. If people are dumb enough to use a
mixed list in a broken way they get what they deserve. What's the
justification?
"Suicidal administrator" prevention. JD suggested it. I like it, but
I'm not committed to it. Thoughts?
I disagree, simply: not in the same zone - but no problem with the same
DNSBl.
Would a SHOULD NOT instead be sufficient? A reword is probably better.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg