ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spam Control Complexity -- scaling, adoption, diversit y and scenarios

2003-04-21 17:19:29
On Mon, Apr 21, 2003 at 09:06:43AM -0600, Vernon Schryver wrote

  - DNS blacklists including MAPS's RBL+, SBL, and SPEWS
      used DNS which has already been and continues to be subject to 
      network standardization.  DNSSEC sounds like a good idea here.

      It might be good if the IETF/IRTF would standardize the values
      returned by DNS blacklists.  There is currently an ad hoc and
      inconsistent protocol using IP addresses in 127/8 to mean "this
      sender is a bad spammer," "this sender might be bad," "this sender
      was bad," and other things.

  Off the top of my head, I don't think that's possible.  About the only
standardization I've seen so far is that *SINGLE-CHOICE* (binary yes/no)
lists generally return 127.0.0.2, and all that means is that the queried
IP address is on the list... of what?  Dynamic IP addresses, open
relays, proxies, known spamhausen, whatever.  In order to cut down on
DNS queries, there are some "aggregator" DNSbls that allow you to
effectively ask multiple questions with one query.  relays.osirusoft.com
has multiple possible return codes.

http://relays.osirusoft.com/faq.html#_Toc533558164

* 127.0.0.2 Verified Open Relay
* 127.0.0.3 Dialup Spam Source
  Dialup Spam Sources are imported into the Zone file from other sources
  and some known sources are manually added to the local include file.
* 127.0.0.4 Confirmed Spam Source
  A site has been identified as a constant source of spam, and is
  manually added. Submissions for this type of spam require multiple
  nominations from multiple sites. Test Blockers also find themselves
  in this catagory.
* 127.0.0.5 Smart Host (In progress)
  A Smart host is a site determined to be secure, but relays for those
  who are not, defeating one level of security. When this is ready, it
  will be labeled outputs.osirusoft.com. NOTE: I strongly discourage
  using outputs due to it being way too effective to be useful.
* 127.0.0.6 A Spamware software developer or spamvertized site. This
  information is maintained by spamsites.org and spamhaus.org.
* 127.0.0.7 A list server that automatically opts users in without confirmation
* 127.0.0.8 An insecure formmail.cgi script. (Planned)
* 127.0.0.9 Open proxy servers

  Similarly, some people block certain countries.  Rather than querying
cn.countries.nerd.dk, kr.countries.nerd.dk, tw.countries.nerd.dk, etc,
you can query an IP address in the zz.countries.nerd.dk "superzone".  It
returns 127.0.X.Y where (X * 256) + Y = the ISO numeric country code of
the country of origin of the IP address.

  Rather than re-working that which already works, how about looking to
the future, where standards designed today can actually be implemented
from square one?  IPv6 uses ::1 as the loopback address, rather than a
whole 2 ^ 24 addresses.  Under IPv6, do DNSbls continue to return
addresses in the ::127.0.0.0/104 CIDR?  Is there a *GUARANTEED*
will-never-be-used range elsewhere that might be better suited?  In
which case, how do DNSbls handle the transition period?

      Then there is the possiblity of a protocol that fits the question
      "should I accept a message from this IP address or sender" better
      than DNS PTR RRs.

  Given that the current DNSbl "protocol" (ad-hoc as it may be) works, I
think the proper question is what's-broken/needs-fixing/can-be-improved.
And the changes, if any, should be implemented in IPv6 only so they don't
have to be re-done a few years from now.

-- 
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg