Chris Lewis wrote:
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).
Ugh! ;-)
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>
No - there are a few that do not have that address at the moment (they
probably should), but as another example - autoexpiry of the SORBS Proxy
DBs wiped out the test entrys until I hardcoded them in the DNSBl export
script to put the entries in regardless of a matching lookup. Consider
the following (not the wording, only the intent):
If 127.0.0.2 is missing the user should look at the status of the DNSbl
as it MAY be due to zone shutdown.
<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>
Well the accidental inclusion of 1.0.0.127.dnsbl.sorbs.net did not
indicate the DNSbl was non-functional, which is why I suggested using
either 255.255.255.255/32 (or earlier 0.0.0.1/32) the former is
theoretically impossible as a valid *usable* host address, the latter
is, just as 127.0.0.1, is a valid address.
<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>
Agreed, though that is a client operation rather than a DNSBl operation.
(The other BCP/RFC/Section?)
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.
I did not read it correctly the first time around - read as 'the same
DNSbl' - not as 'the same DNS zone'
Regards,
Mat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg