DNSBL BCP v.2.0

[Matt Sergeant-2]

On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote:

> On the other hand, "I have received spam from <ip>" is data that does
> not change (once true).

I'm not sure whether you're just trying to be contrary of if you have  
a real point. If the latter please state it more clearly.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Seth Breidbart wrote:

> Matt Sergeant <msergeant@...> wrote:
>> On 14-Feb-07, at 5:30 PM, Douglas Otis wrote:
>
>>> A delisting interval is strictly related to DNSBL policy.  The  
>>> draft is not describing how to delist, but specifically when.  This  
>>> is about policy.  Nothing but policy.
>> Lets be more specific then: Your posts are all about listing  
>> criteria. This draft does not (and never will with me as an author)  
>> mandate listing criteria. That way lies madness.
>
> Consider dsnbl.noprimes.org.
>
> How often do you think it's reasonable to require me to check whether
> a given number has turned composite while I wasn't looking?

With today's processors, it should be easy to go thru 2^^32 numbers in
six months.  But I think you'd be forgiven in assuming that the
prime/nonprimeship of a number won't change spontaneously.

Or, are you expecting some to do so? ;-)


DNSBLs aren't punishment methods.  First and foremost they're methods on
blocking abuse.  If a bad actor isn't acting bad enough to be obvious
that they're abusing for a period of six months, the loss of a listing
means nothing in the scheme of things, and soon corrected if it turns
out to be wrong/being gamed.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

Seth Breidbart wrote:

> Matt Sergeant <msergeant@...> wrote:
>> On 14-Feb-07, at 6:46 PM, Seth Breidbart wrote:
>
>>> Consider dsnbl.noprimes.org.
>>>
>>> How often do you think it's reasonable to require me to check whether
>>> a given number has turned composite while I wasn't looking?
>> Quoting the BCP:
>>
>>    With the exception of DNSBLs that that are based on data that does
>>    not change...
>
> On the other hand, "I have received spam from <ip>" is data that does
> not change (once true).

Then a 6 month timeout wouldn't apply, would it?

Entirely aside from the fact that a DNSBL listing on that basis would,
in the fullness of time, list just about every IP in existance.

Everybody leaks.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Seth Breidbart]

Matt Sergeant <msergeant@...> wrote:
> On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote:

>> On the other hand, "I have received spam from <ip>" is data that does
>> not change (once true).
>
> I'm not sure whether you're just trying to be contrary of if you have  
> a real point. If the latter please state it more clearly.

"Facts that don't change" isn't quite what I'd want to say; true facts
can become irrelevant or outdated (that is, useless) while remaining
true.

Seth

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 14-Feb-07, at 8:42 PM, Seth Breidbart wrote:

> Matt Sergeant <msergeant@...> wrote:
>> On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote:
>
>>> On the other hand, "I have received spam from <ip>" is data that  
>>> does
>>> not change (once true).
>>
>> I'm not sure whether you're just trying to be contrary of if you have
>> a real point. If the latter please state it more clearly.
>
> "Facts that don't change" isn't quite what I'd want to say; true facts
> can become irrelevant or outdated (that is, useless) while remaining
> true.

True enough. That portion of the BCP is aimed at DNSBLs such as  
blackholes.us and Steve Champion's Enemies List, which are basically  
targeted at static data. Though to be honest after having the  
discussion here I'm not sure that even matters much - because the  
listing criteria just continues to exist for those DNSBLs.

If you have better wording we'd appreciate assistance.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Wed, 2007-02-14 at 20:33 -0500, Chris Lewis wrote:
>
> DNSBLs aren't punishment methods.  First and foremost they're methods on
> blocking abuse.  If a bad actor isn't acting bad enough to be obvious
> that they're abusing for a period of six months, the loss of a listing
> means nothing in the scheme of things, and soon corrected if it turns
> out to be wrong/being gamed.

DNSBLs are to block messages, which in itself might be considered a form
of punishment.  There is a cost that is not being considered in the
draft.

Maintaining records of spam received, as recommended, represents a
sizable expense.  When a particular ASN does not enforce AUPs that
prohibit spamming, then ignoring traffic from their listed IP addresses
for some extended period offers significant savings in storage, servers,
and network bandwidth.  The difference is significant.

When the ASN is large and offers bandwidth without enforcement, each
delisting has the effect of making their service more attractive to
spammers, even if only for a brief period.  Changing accounts is the
spammers' cost of doing business.  When an ASN lacks self enforcement
and hosts a high density of spammers, a best practice should be to pause
the logging of abuse for some period, and delay the individual IP
address' delisting.  Concerns about the next user of ASNs that lack
enforcement rightfully diminishes.  There is a good chance the next user
will also be a spammer anyway.

A recommendation for maximal delisting interval of 6 months for ASNs
that make an effort to enforce anti-spam AUPs is not a problem for DNSBL
operations.  However, the current draft wishes to ignore spam-friendly
behavior of some ASNs, and that would constitute a bad practice from the
perspective of economically running DNSBLs, as well as ensuring DNSBLs
remain effective at abating spam.

The network provider plays a critical role in abating spam.  When the
network provider is not a partner in abatement, it is unfair and costly
to allow those without enforcement to consume additional resources in
order to maintain a constant automatic delisting interval.  ASNs that
enforce anti-spam AUPs deserve these limited resources.  A best practice
MUST consider the behavior of the network provider as denoted by the
ASN.  This should be part of any DNSBL best practice.

-Doug

   









_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Mon, 2007-02-12 at 22:46 -0500, Matt Sergeant wrote:

> On 12-Feb-07, at 5:28 PM, Douglas Otis wrote:
>
> > A year is likely to be a typical interval for bulk service agreements.
>
> I'm not sure why you keep persisting on this point. If the criteria  
> for the DNSBL is something like "a known spammer has service on this  
> IP/range" then after (or before) the timeout period the DNSBL must re-
> check that the spammer still has service on that IP/range, and  
> confirm that indeed the spammer does. Thus the listing is extended  
> beyond the 6 month period. It could last forever for all we care, as  
> long as the listing criteria STILL EXISTS.

The network provider owns the IP address.  They own an entire range of
IP addresses as determined by their ASN.  The entity that is spamming is
often NOT the network provider, but instead is one of their customers.
Only in very rare cases would a listing be based upon the ASN.  Listing
criteria often requires monitoring for spam from a specific IP address.
Monitoring for spam has a cost.


> I'll repeat myself again: this BCP in NO WAY forces delisting after  
> the timeout period. It makes that clear - you just choose not to read  
> that part for some reason.

The suggested text requires that these IP addresses be monitored in
order to delist within the interval being recommended, unless of course
the entire ASN is being listed, which is rare.

> I'm done arguing this with you now. We'll discuss between the authors  
> if we think 6 months is the wrong time period but you haven't  
> presented any decent argument for it IMHO.

The premise that 6 months is okay seems based upon Spamhaus suggesting
that this their policy.  There are a few differences with respect to
what Spamhaus can do and what an enterprise working with United States
can do.  England, where Spamhaus resides makes spamming illegal.  There
is also a substantially different liability with respect legal fees when
being sued in the United States versus England as well.

Every listing by a company that has residence within the United States
must be prepared with a full set of records tracking everything related
to the ASN, the IP address, complaints, replies, etc. This tracking
system is likely to be much larger and far more expensive as a result.
I wish the spam laws for the United States were more like that found in
England.  They are not however.  Please don't suggest that this draft is
NOT dictating a listing policy and then recommend when an IP address
should be delisted!

-Doug




_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Al Iverson]

Hello all,

I'm new to the list. A lot of familiar names here. If you don't know
me, I've created a few different DNSBLs, mostly back they were
lovingly crafted out of shell scripts using stone knives and
bearskins. Lately I've started cataloging dead DNSBLs and writing up
DNSBL reviews on www.dnsbl.com, a site of mine.

Forgive me if I'm rehashing something already talked about; didn't
seem that way to me from my cursory research.

One thing that strikes me as missing from the BCP is some guidance on
usage and implementation in spam filtering and blocking applications.
In particular, technical guidance regarding whether or not a DNSBL
actually exists and can be queried. As I am learning from diving back
in to the thick of DNSBL-related things lately, I see
- Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
years after the RBL moved away from that FQDN.
- Other lists randomly vanishing with no warning and continuing to get
DNSBL traffic for years
- Blars, for example, vanished in December and now lists the world.
- LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
hits years later, resorting to listing the world.
- The occasional ignorant sod who queries something like
random.dnsbl.maps.com which causes unwanted traffic (and potential
unwanted mail blocking) from various sites. (You'll note that maps.com
has a wildcard, for example.)

Maybe this is outside of the scope, and if so, I apologize. But if
appropriate, it seems wise to have some guidance included about how to
avoid these situations, preferably recommended that checks be
implemented in software to confirm that a list an application is
checking actually exists and really is a DNSBL. It not only protects
ignorant DNSBL users from themselves (which I grant some folks
probably don't care much about), but it helps reduce pain for anyone
who gracefully shuts down a DNSBL (and their upstream, and the root
zones, depending on how it's done).

In the future, I'd love to be able to point to something RFC-like that
says what best practice is in this area, and be able to point that out
to companies who try to build a marketing strategy around selling
fancy rackmount anti-spam devices that are actually just linux boxes
with SpamAssassin and DNSBL support on them.

Would love to hear your thoughts and feedback.

Regards,
Al Iverson
--
Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Stephanie Erin Daugherty-2]

Al Iverson wrote:
> Hello all,
>
> I'm new to the list. A lot of familiar names here. If you don't know
> me, I've created a few different DNSBLs, mostly back they were
> lovingly crafted out of shell scripts using stone knives and
> bearskins. Lately I've started cataloging dead DNSBLs and writing up
> DNSBL reviews on www.dnsbl.com, a site of mine.
Good to see that you are still around. :) I think I remember at least a
couple of
those stone knife and bearskin lists.

> One thing that strikes me as missing from the BCP is some guidance on
> usage and implementation in spam filtering and blocking applications.
> In particular, technical guidance regarding whether or not a DNSBL
> actually exists and can be queried. As I am learning from diving back
> in to the thick of DNSBL-related things lately, I see
> - Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
> years after the RBL moved away from that FQDN.
> - Other lists randomly vanishing with no warning and continuing to get
> DNSBL traffic for years
> - Blars, for example, vanished in December and now lists the world.
> - LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
> hits years later, resorting to listing the world.
> - The occasional ignorant sod who queries something like
> random.dnsbl.maps.com which causes unwanted traffic (and potential
> unwanted mail blocking) from various sites. (You'll note that maps.com
> has a wildcard, for example.)
>

One of the best pieces of advice I can give for this is to put a DNSBL
on a domain specifically registered for the purpose -- while it's
possible to run one within a subdomain, I would recommend strongly
against it, getting rid of the query traffic if you later shut down is
truly next to impossible, and if you have a dedicated domain, it's
easier to kill the nameservers for it that it would for a domain that
has to remain active even after the DNSBL dies. In other words, a DNSBL
on a domain pretty much poisons it for years to come with substantial
volumes of traffic.

Needless to say, this also places a special responsibility on DNSBL
operators for making sure that their domain registrations stay active
and secure - if allowed to expire prematurely, the impact to downstream
users can be significant, and if allowed to be hijacked malicious
entries could be placed which may result in a denial of service to
legitimate users.


> Maybe this is outside of the scope, and if so, I apologize. But if
> appropriate, it seems wise to have some guidance included about how to
> avoid these situations, preferably recommended that checks be
> implemented in software to confirm that a list an application is
> checking actually exists and really is a DNSBL.
A standard "listed" test entry and standard "not listed" test entry are
a good way to test that. Standard practice right now usually uses  
2.0.0.127.dnsbl.example.com or some variant as the "always listed"
address - adding a requirement for a "never listed" address would be a
good way to implement an additional check to make sure the DNSBL is
still active, and hopefully that it's not listing the world. I'm not
sure that we have a standard convention for a "never listed" test
address (one that should always return a whitelist record or NXDOMAIN
depending on the type of list.)




_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Steve Atkins]

On Feb 15, 2007, at 12:07 PM, Stephanie Erin Daugherty wrote:

>
> A standard "listed" test entry and standard "not listed" test entry  
> are a good way to test that. Standard practice right now usually  
> uses  2.0.0.127.dnsbl.example.com or some variant as the "always  
> listed" address - adding a requirement for a "never listed" address  
> would be a good way to implement an additional check to make sure  
> the DNSBL is still active, and hopefully that it's not listing the  
> world. I'm not sure that we have a standard convention for a "never  
> listed" test address (one that should always return a whitelist  
> record or NXDOMAIN depending on the type of list.)

1.0.0.127.

There. We have an always listed and a never listed address that are  
already done by the vast majority of blacklists[1]. All we need is  
client side support for those two checks and we're done.

Cheers,
   Steve

[1] OK, I run two blacklists and neither of them supports both of  
those records, but they're kinda special cases...

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Al Iverson]

On 2/15/07, Stephanie Erin Daugherty <stephanie@...> wrote:

> > One thing that strikes me as missing from the BCP is some guidance on
> > usage and implementation in spam filtering and blocking applications.
> > In particular, technical guidance regarding whether or not a DNSBL
> > actually exists and can be queried. As I am learning from diving back
> > in to the thick of DNSBL-related things lately, I see
> > - Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
> > years after the RBL moved away from that FQDN.
> > - Other lists randomly vanishing with no warning and continuing to get
> > DNSBL traffic for years
> > - Blars, for example, vanished in December and now lists the world.
> > - LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
> > hits years later, resorting to listing the world.
> > - The occasional ignorant sod who queries something like
> > random.dnsbl.maps.com which causes unwanted traffic (and potential
> > unwanted mail blocking) from various sites. (You'll note that maps.com
> > has a wildcard, for example.)
> >
> One of the best pieces of advice I can give for this is to put a DNSBL
> on a domain specifically registered for the purpose -- while it's
> possible to run one within a subdomain, I would recommend strongly
> against it, getting rid of the query traffic if you later shut down is
> truly next to impossible, and if you have a dedicated domain, it's
> easier to kill the nameservers for it that it would for a domain that
> has to remain active even after the DNSBL dies.

I agree that it is probably unwise to use a DNSBL domain for anything
else, or to expect to be able to reclaim it when done with the DNSBL.

The recent shutdown of ORDB makes me suspect that abandoning the
domain after you're done with the DNSBL might not be good enough.
Here's why.

If I'm recalling this correctly, what happened was that ORDB killed
the DNSBL and left the domain configured with no nameservers in place.
This left the queries to die at the .org root level, and it basically
pounded the .org infrastructure flat. One of the folks in charge of
.org reached out to an anti-spam community and was able to reach back
to the blacklist maintainers and some other folks, to come up with a
plan to solve it. But, things definitely sucked for a few days, and
not every situation like this is so quickly resolved. And I assume the
fix simply siphons the traffic off to somebody else's network, instead
of actually stopping it.

So, leaving the domain behind definitely helps the network that
previously hosted the DNSBL, but it could potentially just push gobs
of queries upstairs.

(Some of this detail came from a discussion on a private mailing list;
I got permission from the person behind that discussion to reference
it here. I woudl also add that this isn't a shot at the ORDB folks;
more than anything it just highlights that there isn't a BCP to handle
these kind of things.)

Regards,
Al Iverson
--
Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant-2]

On 15-Feb-07, at 3:40 PM, Steve Atkins wrote:

>> A standard "listed" test entry and standard "not listed" test  
>> entry are a good way to test that. Standard practice right now  
>> usually uses  2.0.0.127.dnsbl.example.com or some variant as the  
>> "always listed" address - adding a requirement for a "never  
>> listed" address would be a good way to implement an additional  
>> check to make sure the DNSBL is still active, and hopefully that  
>> it's not listing the world. I'm not sure that we have a standard  
>> convention for a "never listed" test address (one that should  
>> always return a whitelist record or NXDOMAIN depending on the type  
>> of list.)
>
> 1.0.0.127.
>
> There. We have an always listed and a never listed address that are  
> already done by the vast majority of blacklists[1]. All we need is  
> client side support for those two checks and we're done.

Yup, this was suggested earlier in this thread (before it diverged  
into the timeout thread) and I think it's a worthwhile addition to  
the DNSBL.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[sm-7]

At 13:22 08-02-2007, Nick Nicholas wrote:
>1.2.  Guidance for DNSBL Users
>
>    When choosing to adopt a DNSBL, an administrator should keep the
>    following questions in mind:
>
>    1.  What is the intended use of the list?

DNSBLs don't always specify SMTP blocking as the intended use.  Maybe
this should be "What is the listing policy?"

>    7.  What are the demographics and quantity of the list's user base?

Such information is rarely published.  Point 8 is a better guideline.

>2.1. Transparency.
>
>    A DNSBL SHOULD carefully describe the criteria which are the cause
>    for adding, and the criteria for removing an IP address or domain

Shouldn't this be a MUST so that the user has better guidance in
choosing a DNSBL?

>    Availability of documentation concerning a DNSBL SHOULD NOT be
>    dependent on the continued operation of DNS for the DNSBL zone file.
>    In other words, if the DNSBL documentation is located at
>    http://example.com/dnsbl/, the documentation web site SHOULD remain
>    available even if the DNSBL zone file is not available. See also
>    Section 3.2

If a DNSBL ceases operations, the domain registration may lapse or
else the web server is unreachable.  The above requirement is
generally not followed.

>3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>
>    When a DNSBL ceases operations and is taken out of circulation,
>    it MUST do so in a graceful manner so that it does not create
>    excessive DNS queries or list the entire Internet.
>
>    The recommended approach is to put the DNSBL in its own second
>    level domain, and then point the DNS NS records for that second
>    level domain to 127.255.255.255.  The TTL for that record should be
>    set at the maximum allowed period of one week.

Using a broadcast address may have unintended consequences.  I
suggest using 192.0.2.2.

Some DNSBL operators list the entire Internet because they keep
receiving queries years after the DNSBL has ceased operation.  It may
be better to include a note for people implementing DNSBL features in
their software to prevent such behavior.  They could use a test point
to determine whether the DNSBL is still active.  This is the best way
to avoid excessive DNS queries.

Regards,
-sm


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SM wrote:
> At 13:22 08-02-2007, Nick Nicholas wrote:

>>    7.  What are the demographics and quantity of the list's user base?
>
> Such information is rarely published.  Point 8 is a better guideline.

I think the intent here is not that the DNSBL publishes it (they often
don't know), but the user should consider this - eg: do other site like
me use it?

>> 2.1. Transparency.
>>
>>    A DNSBL SHOULD carefully describe the criteria which are the cause
>>    for adding, and the criteria for removing an IP address or domain
>
> Shouldn't this be a MUST so that the user has better guidance in
> choosing a DNSBL?

This is compromise wording.  Some DNSBLs can't publish full criteria,
because that would allow spammers to avoid it.  Rather than get into
quibbles over what constitutes "criteria", soften it a bit to SHOULD.

>> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>>
>>    When a DNSBL ceases operations and is taken out of circulation,
>>    it MUST do so in a graceful manner so that it does not create
>>    excessive DNS queries or list the entire Internet.
>>
>>    The recommended approach is to put the DNSBL in its own second
>>    level domain, and then point the DNS NS records for that second
>>    level domain to 127.255.255.255.  The TTL for that record should be
>>    set at the maximum allowed period of one week.
>
> Using a broadcast address may have unintended consequences.  I suggest
> using 192.0.2.2.

Which would have lower risk?  Somewhere in upper 127, or 192.0?
>
> Some DNSBL operators list the entire Internet because they keep
> receiving queries years after the DNSBL has ceased operation.  It may be
> better to include a note for people implementing DNSBL features in their
> software to prevent such behavior.  They could use a test point to
> determine whether the DNSBL is still active.  This is the best way to
> avoid excessive DNS queries.

Part of the issue about this is John's DNSBL protocol BCP.  We perhaps
shouldn't get too far into detail of this, unless we subsume John's.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iQCVAwUBRduchp3FmCyJjHfhAQJ3uAQAuFz0JHNFxpIOCu7gPx+KbkVxRlpMMwE1
PmYHHosCe0Ms3+k41kXRJJ1dzHlG2GrO6oK9NF55Ow1QRVb6qor8kIz3eNlCB5Cy
jQnQgaKjJ2btpS6hgU9q0efZpgzYPBefqXsPJRJuzod9YI9NKv8dJ09/Ahcem2tX
3EzE6yVDSnA=
=PVIH
-----END PGP SIGNATURE-----

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 20, 2007, at 5:12 PM, Chris Lewis wrote:

>>
>> Using a broadcast address may have unintended consequences.  I  
>> suggest
>> using 192.0.2.2.
>
> Which would have lower risk?  Somewhere in upper 127, or 192.0?

The values used in the example given in nanog:

http://www.merit.edu/mail.archives/nanog/msg04555.html

Used the address space defined in rfc3330
         192.0.2.0/24         Test-Net

While it would be nice to establish a test method, the test should be  
both the return of an RR and that of an NXDOMAIN just incase the  
network provider decides to intercept NXDOMAINs.  Depending upon test  
vectors being installed in the various MTAs at this point is likely  
too late.  The example using several NS records should generate  
enough pain to induce removal of the defunct DNSBL.

-Doug




_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Al Iverson]

On 2/20/07, Chris Lewis <clewis@...> wrote:

> >>    7.  What are the demographics and quantity of the list's user base?
> >
> > Such information is rarely published.  Point 8 is a better guideline.
>
> I think the intent here is not that the DNSBL publishes it (they often
> don't know), but the user should consider this - eg: do other site like
> me use it?

In your opinion, how is that easily determinable?

Al
--
Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[sm-7]

At 17:12 20-02-2007, Chris Lewis wrote:
>I think the intent here is not that the DNSBL publishes it (they often
>don't know), but the user should consider this - eg: do other site like
>me use it?

Generally DNSBL operators don't publish such information.  The
information is also not published in comparative evaluations.  Your
question "Do other sites like me use it?" is more to the point.  The
Guidance for DNSBL users questions are straight-forward except for question 7.

>Which would have lower risk?  Somewhere in upper 127, or 192.0?

The 192.0.2.0/24 block is assigned as "TEST-NET".  It should not
appear on the public Internet (RFC 3330).  Pointing the DNS NS record
to 192.0.2.2 will cause a query timeout.  The DNSBL user may notice
the slow down in mail delivery and take appropriate action.  The
purpose is not to cause any harm.  In my opinion, 192.0.2 should have
a lower risk than the upper 127 as it is not associated with the
loopback address.  I suggested 192.0.2.2/32 as it makes troubleshooting easier.

Thank you for the clarifications.

Regards,
-sm


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SM wrote:
> At 17:12 20-02-2007, Chris Lewis wrote:
>> I think the intent here is not that the DNSBL publishes it (they often
>> don't know), but the user should consider this - eg: do other site like
>> me use it?
>
> Generally DNSBL operators don't publish such information.

In addition to not really knowing, most DNSBLs will be reluctant to
publish the info even if they knew it.  While (the better) DNSBLs would
probably like to, parading the security measures of other sites is, er,
"poor form".

> The
> information is also not published in comparative evaluations.

I've seen it, but not published.

> Your
> question "Do other sites like me use it?" is more to the point.  The
> Guidance for DNSBL users questions are straight-forward except for
> question 7.

Nick - I think i like this suggestion...

For Al: how would the prospective user know?  Google works ;-)

>> Which would have lower risk?  Somewhere in upper 127, or 192.0?
>
> The 192.0.2.0/24 block is assigned as "TEST-NET".  It should not appear
> on the public Internet (RFC 3330).

But it may occur locally.  Wouldn't want your DNSBL queries to go off to
a test DNS server.  Tho, perhaps it's unlikely to result in a listing...

> Pointing the DNS NS record to
> 192.0.2.2 will cause a query timeout.

Most 127s would as well, would they not?

> The DNSBL user may notice the
> slow down in mail delivery and take appropriate action.  The purpose is
> not to cause any harm.  In my opinion, 192.0.2 should have a lower risk
> than the upper 127 as it is not associated with the loopback address.  I
> suggested 192.0.2.2/32 as it makes troubleshooting easier.

Thanks for the discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iQCVAwUBRdy6PJ3FmCyJjHfhAQJlxgQAxL6Fg+JX+8o5pXymemTVl4IzxiD3tVPa
ZgvlekEfJlnue/aw0qHy8pBHmC4OcteJn0WyCN7qoofpKRqMQaxuUkh2WpJkaa+L
66A5W6b9ZytKgdx0qeoNvW7M58KfWDl8J4waDlewYKvZLH6UBRKGRloFvmHWKYQQ
MMRkQ6tu+l8=
=fO5a
-----END PGP SIGNATURE-----

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg

[sm-7]

At 13:31 21-02-2007, Chris Lewis wrote:
> > The
> > information is also not published in comparative evaluations.
>
>I've seen it, but not published.

What's important is not what we see but what the DNSBL user can see
so that they can make an informed decision.

>But it may occur locally.  Wouldn't want your DNSBL queries to go off to
>a test DNS server.  Tho, perhaps it's unlikely to result in a listing...

Yes, it may occur locally.  But it's not like the DNSBL operator is
pointing the NS to the user's loopback (127/8).

>Most 127s would as well, would they not?

Yes it would.

Regards,
-sm


_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg