DNSBL BCP v.2.0

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 - 4 | Next >

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 13, 2007, at 6:21 AM, Matt Sergeant wrote:

> On 13-Feb-07, at 12:57 AM, Douglas Otis wrote:
>
>> There are at least two entities to be considered with respect to a  
>> reasonable listing duration.  One might be the individual entity  
>> administering the system directly associated with the IP address.  
>> Another would be the entity providing the IP address and routing  
>> from their ASN.  The duration of any listing must consider the  
>> behavior of _both_.  A high density of bad actors within an ASN  
>> SHOULD extend duration well into a year and be sure to cover a  
>> typical contract period.   The goal of the DNSBL operator is often  
>> to alter the behavior of the network provider.  In such cases it  
>> is pointless to focus upon individual IP addresses when the  
>> network provider is truly negligent.
>
> Nothing in this draft prevents this.

,---
|For more aggressive spammers (e.g., those operating their
|own ISP) the temporary period MAY be as much as six (6) months.
|However, longer periods SHOULD NOT be used since it is possible
|that an IP address or domain can change hands, possibly being
|allocated to a non-abusive user.
'---

The foremost goal of a DNSBL is to prevent spam!  This is largely  
accomplished by changing the behavior of the _network_ providers  
(ISPs).  The typical maximal duration SHOULD bridge contracts and  
impact the _network_ provider's revenue.  This makes the the DNSBL  
effective at changing the behavior of the network provider.  Of  
course, cooperative providers deserve continuous evaluation, but is  
draft is written from an obtuse perspective of individual IP  
addresses and has ignored the role of the network providers.

What is the goal of the DNSBL?  There are at least two entities  
involved in sending spam, email and network providers.  DNSBL needs  
to ensure that preventing spam remains in everyone's mutual interest  
and is prohibited within the network provider's AUPs.  A short  
duration of 6 months is not likely to cover a typical contract _as  
stated in the draft_!  If anything, this alone justifies a longer  
maximal listing duration when the provider permits spam.

How about:

To affect network providers that permit spam as evidenced by a high  
percentage of spam sources within their ASN, the maximal listing  
duration SHOULD BE a period of one year or more.  This is to  
specifically affect their ability to profit from spam.  When the  
provider is otherwise effective at prohibiting spam, the maximal  
duration SHOULD BE less than an year, where a duration of six months  
is likely adequate.

-Doug


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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 13-Feb-07, at 2:02 PM, Douglas Otis wrote:

>> Nothing in this draft prevents this.
>
> ,---
> |For more aggressive spammers (e.g., those operating their
> |own ISP) the temporary period MAY be as much as six (6) months.
> |However, longer periods SHOULD NOT be used since it is possible
> |that an IP address or domain can change hands, possibly being
> |allocated to a non-abusive user.
> '---

,---
|   Note that all listings being temporary does not mean that some
|   listings will not remain after the initial timeout period. If the
|   DNSBL administrator determines that the conditions for listing
|   still exists, then the timer for determining timeouts MAY be
|   renewed.
'---

______________________________________________________________________
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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 13-Feb-07, at 2:39 PM, Matt Sergeant wrote:

> ,---
> |   Note that all listings being temporary does not mean that some
> |   listings will not remain after the initial timeout period. If the
> |   DNSBL administrator determines that the conditions for listing
> |   still exists, then the timer for determining timeouts MAY be
> |   renewed.
> '---

Maybe I could put this better as: What is the purpose of stating that  
listings should time out?

The purpose is to ensure that DNSBL owners continue to check the  
reason for listing. Otherwise they aren't solving the spam problem,  
they are just listing because they're too lazy to check.

______________________________________________________________________
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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 13, 2007, at 11:48 AM, Matt Sergeant wrote:

> On 13-Feb-07, at 2:39 PM, Matt Sergeant wrote:
>
>> ,---
>> |   Note that all listings being temporary does not mean that some
>> |   listings will not remain after the initial timeout period. If the
>> |   DNSBL administrator determines that the conditions for listing
>> |   still exists, then the timer for determining timeouts MAY be
>> |   renewed.
>> '---
>
> Maybe I could put this better as: What is the purpose of stating  
> that listings should time out?
>
> The purpose is to ensure that DNSBL owners continue to check the  
> reason for listing. Otherwise they aren't solving the spam problem,  
> they are just listing because they're too lazy to check.

,---
|For more aggressive spammers (e.g., those operating their
|own ISP) the temporary period MAY be as much as six (6) months.
|However, longer periods SHOULD NOT be used since it is possible
|that an IP address or domain can change hands, possibly being
|allocated to a non-abusive user.
'---

Matt,

The percentage of abusive IP addresses within an ASN must determine  
the duration established in listing specific IP addresses within the  
ASN.  The goal is to stop the source of spam, which can only happen  
when network providers enforce AUPs prohibiting spam.  Some DNSBLs  
ignore listed sources over a period as necessitated by overall spam  
volumes.  Revisiting traffic sooner than an interval effective at  
stopping a network provider's behavior requires significant  
expenditures by DNSBL operators.  Audit trails and network bandwidth  
have a cost.

What justifies increasing the costs of DNSBLs to facilitate marketing  
of services by a spam friendly network provider, as this draft  
suggests?  Even credit agencies are not required to issue a report in  
less than a year without compensation.  Why ensure a spam friendly  
provider's next customer is not affected by the provider's  
negligence?  How will this reduce the level of spam?

This draft's recommended practice allows providers to ignore spam, as  
it ignores the role a network provider must play in stopping spam.

-Doug




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

Re: Re: DNSBL BCP v.2.0

by Tom Petch :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I think that this I-D would benefit from additional paragraphs of 'stating the
obvious'.

Specifically, you assume a detailed knowedge of what a DNSBL is and make
reference to various fields therein; I think you should summarise in two or
three sentences what DNS records there are likely to be containing what data.

Second, perhaps before that, you should explain who uses a DNSBL and how, even
though, or perhaps because, such people are not the target audience - currently
you only mention the why; again one paragraph of two or three sentences.

Finally, you assume a detailed knowledge of (r)DNS and zones - again, I think
that you should explain more and include a normative reference to the relevant
RFC.

I think too that most of your existing references are normative, ie something
that must be understood if the I-D is to make any sense.

Tom Petch


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

Re: Re: DNSBL BCP v.2.0

by Bill Cole-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

At 9:57 PM -0800 2/12/07, Douglas Otis wrote:

>On Feb 12, 2007, at 7:46 PM, 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.
>
>There are at least two entities to be considered with respect to a
>reasonable listing duration.  One might be the individual entity
>administering the system directly associated with the IP address.  
>Another would be the entity providing the IP address and routing
>from their ASN.  The duration of any listing must consider the
>behavior of _both_.  A high density of bad actors within an ASN
>SHOULD extend duration well into a year and be sure to cover a
>typical contract period.   The goal of the DNSBL operator is often
>to alter the behavior of the network provider.  In such cases it is
>pointless to focus upon individual IP addresses when the network
>provider is truly negligent.
>
>>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.
>>
>>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.
>
>On the contrary.  You have not presented cogent arguments as to why
>6 months is a suitable listing duration, especially when a provider
>is negligent.

Because the BCP does not say that and you are inventing that concept
by not reading carefully enough.

If the listing criteria remains true, the entire paragraph talking
about 6 months is completely irrelevant.



>Individual treatment of IP addresses must be predicated upon the
>provider enforcing an AUP policy that precludes spamming.

Says who?

That appears to be fodder for listing policy of a specific DNSBL, not
for an operational BCP document.

There are DNSBL's that are insensitive to ISP policy or its
enforcement. The CBL is an example, and it is arguably the most
useful primary DNSBL in operation, with only the aggregates that
include it being more comprehensive.


>Any provider that offers unlimited services to spammers should never
>expect IP address delisting within an interval as short as 6 months.
>This is being far to generous.  In the case of individual IP
>addresses within a well managed ASN, a request can be made to
>expedite delistings.  Again, when the typical contract is by the
>year, automatic delisting within six months is still likely too soon.

This would only make sense if you believed the BCP prohibits listing
standards that look at ASN-level behavior as a contributing factor to
a listing. I don't think it does.

For example, one could operate a DNSBL where a listing is documented
to mean "This address space has a history of being assigned by its
RIR-registered owner to people with 4-letter surnames."  When that
DNSBL listed the space I use, and I found it untenable to remain in
the space because of the geniuses who think all DNSBL's mean the same
thing, the 6-month clock would not start. What would start the
6-month clock would be AT&T  going bankrupt and returning the block
to ARIN.


>While a six month duration might be selected as a means to reduce
>delisting requests, a poorly managed ASN should still delay a
>delisting over a much longer period.  Incidents of abuse can not
>always be considered by individual IP addresses, but in conjunction
>with the ASN as a whole.

There's nothing in the BCP that requires listing standards to ignore
ASN behavior, or to include ASN behavior. That is a detail that is
out of scope for the BCP, but including ASN behavior as a factor in a
particular list (e.g. something like SPEWS but run competently and
rigorously to documented testable standards)


>Please don't say this should be based upon what _sounds_ reasonable.  
>Perspectives differ between network and email providers, and those
>operating DNSBLs.  The goal of DNSBL operators is to reduce the tide
>of spam,

Not always. Historically the goals have seemed to include defaming
creditors, making political statements about the ethics of various
network operators, and demonstrating the clue deficiencies of the
mail technical community.

In that last class of DNSBL, the target members have been people who
think all DNSBL's are about the same things.





--
Bill Cole                                  
bill@...


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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 14, 2007, at 6:02 AM, Bill Cole wrote:

> At 9:57 PM -0800 2/12/07, Douglas Otis wrote:
>> On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote:
>>
>> On the contrary.  You have not presented cogent arguments as to  
>> why 6 months is a suitable listing duration, especially when a  
>> provider is negligent.
>
> Because the BCP does not say that and you are inventing that  
> concept by not reading carefully enough.
>
> If the listing criteria remains true, the entire paragraph talking  
> about 6 months is completely irrelevant.

Listing policies regarding duration must consider behaviors of  
specific IP addresses and that of that of the network provider  
associated with the ASN.
,---
|For more aggressive spammers (e.g., those operating their
|own ISP) the temporary period MAY be as much as six (6) months.
|However, longer periods SHOULD NOT be used since it is possible
|that an IP address or domain can change hands, possibly being
|allocated to a non-abusive user.
'---

This statement ignores network provider's role, and rewards bad  
behavior by ensuring their ability to market IP addresses within  
their poorly managed ASN.  The goal is not about making DNSBLs  
essential by coddling spam-friendly providers, as this statement  
recommends.  The goal of the DNSBL is to convince network providers  
it is in their interest to enforce AUPs that prohibit spamming.  I  
hope you agree.

>> Individual treatment of IP addresses must be predicated upon the  
>> provider enforcing an AUP policy that precludes spamming.
>
> Says who?
>
> That appears to be fodder for listing policy of a specific DNSBL,  
> not for an operational BCP document.

This draft states that bad behavior of the network provider SHOULD be  
accommodated by ensuring their ability to market their IP address  
space.  Best Current Practices of a DNSBL is to convince network  
providers they SHOULD enforce AUPs prohibiting spamming.  As such,  
the BCP must consider the level of abuse from the ASN of the network  
provider as a significant factor in establishing the duration of a  
block listing.  The current draft insists on the opposite, and this  
can NEVER be considered a BCP!

> There are DNSBL's that are insensitive to ISP policy or its  
> enforcement. The CBL is an example, and it is arguably the most  
> useful primary DNSBL in operation, with only the aggregates that  
> include it being more comprehensive.

The CBL of abuseat.org is an automated listing that specifically  
excludes intended SMTP clients.  The goal of the CBL is to prevent  
proxy and infected related abuse.  You are not saying that Spam is  
okay as long as it is intended, or that this represents a best practice?

>> Any provider that offers unlimited services to spammers should  
>> never expect IP address delisting within an interval as short as 6  
>> months.
>> This is being far to generous.  In the case of individual IP  
>> addresses within a well managed ASN, a request can be made to  
>> expedite delistings.  Again, when the typical contract is by the  
>> year, automatic delisting within six months is still likely too soon.
>
> This would only make sense if you believed the BCP prohibits  
> listing standards that look at ASN-level behavior as a contributing  
> factor to a listing. I don't think it does.

Carefully read the last sentence of the quoted text.   Limiting the  
duration of a listing to 6 months is specifically to ensure the  
network provider's ability to market address space.  When network  
providers are spam-friendly, the duration of the listing SHOULD  
extend beyond the typical service contract.  Don't think of DNSBLs as  
only stopping abuse after it arrives.  Well managed DNSBLs prevent  
spam from ever being sent, and stopping spam at the source represents  
a Best Best Practice.

> For example, one could operate a DNSBL where a listing is  
> documented to mean "This address space has a history of being  
> assigned by its RIR-registered owner to people with 4-letter  
> surnames."  When that DNSBL listed the space I use, and I found it  
> untenable to remain in the space because of the geniuses who think  
> all DNSBL's mean the same thing, the 6-month clock would not start.  
> What would start the 6-month clock would be AT&T  going bankrupt  
> and returning the block to ARIN.

This is irrelevant.  Again, there are two actors benefiting from  
spam.  One actor might be the network provider selling an IP address  
and network bandwidth.  There is also the bad actor that might  
briefly be able to send spam from a network provider that enforces an  
AUP prohibiting spam.  Whether a block duration should extend beyond  
the typical contract duration should depend upon whether there is a  
substantial amount of spam abuse emerging from the ASN.  Resources  
are required to track abuse.  These resources should be reserved for  
those network providers attempting to enforce an AUP prohibiting spam.

>> While a six month duration might be selected as a means to reduce  
>> delisting requests, a poorly managed ASN should still delay a  
>> delisting over a much longer period.  Incidents of abuse can not  
>> always be considered by individual IP addresses, but in  
>> conjunction with the ASN as a whole.
>
> There's nothing in the BCP that requires listing standards to  
> ignore ASN behavior, or to include ASN behavior. That is a detail  
> that is out of scope for the BCP, but including ASN behavior as a  
> factor in a particular list (e.g. something like SPEWS but run  
> competently and rigorously to documented testable standards)

DNSBL best practices should consider ASN behavior when establishing a  
listing duration.  ASN behavior must not be out of scope in any DNSBL  
best practices draft.  SPEWS considers the behavior of the network  
provider, and recognized the futility of attempting to play wack-a-
mole with IP addresses alone.  Network providers must enforce AUPs  
that prohibit spamming, if spam is to be abated.  Considering ASN  
behavior is clearly a best practice.

>> Please don't say this should be based upon what _sounds_  
>> reasonable.  Perspectives differ between network and email  
>> providers, and those operating DNSBLs.  The goal of DNSBL  
>> operators is to reduce the tide of spam,
>
> Not always. Historically the goals have seemed to include defaming  
> creditors, making political statements about the ethics of various  
> network operators, and demonstrating the clue deficiencies of the  
> mail technical community.
>
> In that last class of DNSBL, the target members have been people  
> who think all DNSBL's are about the same things.

The best practices for the operation of a DNSBL is to be effective at  
abating spam from being sent in the first place.  Spam is a vector  
for infection either directly or indirectly by offering dangerous  
links.  Spam can lead to DDoS attacks (especially with SPF/Sender-ID  
being used by the recipients).  At more than 80% of the current email  
traffic, spam has dramatically placed the resource burden onto the  
recipient.  The industry and the Internet internationally must  
prohibit spamming.  The CAN-SPAM law must be changed to prohibit  
spamming.  The best practices of a DNSBL should be aimed specifically  
at convincing network provider to enforce AUPs that prohibit  
spamming, which is a tool still allowed by CAN-SPAM.

Blocking durations should not be based on personal grudges, dislikes,  
or politics.  Policies should be consistently applied, not by  
treating each IP address individually, but in conjunction with the  
ASN as a whole.  Any DNSBL policy worth its salt must consider how to  
persuade the cooperation of network providers.  Such persuasion can  
only occur when ASNs as a whole plays a role in DNSBL policies.

-Doug



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

Re: Re: DNSBL BCP v.2.0

by Bill Cole-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

At 10:49 AM -0800 2/14/07, Douglas Otis wrote:

>On Feb 14, 2007, at 6:02 AM, Bill Cole wrote:
>
>>At 9:57 PM -0800 2/12/07, Douglas Otis wrote:
>>>On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote:
>>>
>>>On the contrary.  You have not presented cogent arguments as to
>>>why 6 months is a suitable listing duration, especially when a
>>>provider is negligent.
>>
>>Because the BCP does not say that and you are inventing that
>>concept by not reading carefully enough.
>>
>>If the listing criteria remains true, the entire paragraph talking
>>about 6 months is completely irrelevant.
>
>Listing policies regarding duration must consider behaviors of
>specific IP addresses and that of that of the network provider
>associated with the ASN.
>,---
>|For more aggressive spammers (e.g., those operating their
>|own ISP) the temporary period MAY be as much as six (6) months.
>|However, longer periods SHOULD NOT be used since it is possible
>|that an IP address or domain can change hands, possibly being
>|allocated to a non-abusive user.
>'---
>
>This statement ignores network provider's role, and rewards bad
>behavior by ensuring their ability to market IP addresses within
>their poorly managed ASN.


As Matt and I have already pointed out, you are ignoring what the
draft actually says in favor of believing that it says something you
feel like arguing with. Feel free to do so wherever you like. I won't
bother you with responses you refuse to even read.


--
Bill Cole                                  
bill@...


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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 14, 2007, at 11:27 AM, Bill Cole wrote:

> At 10:49 AM -0800 2/14/07, Douglas Otis wrote:
>>
>> Listing policies regarding duration must consider behaviors of  
>> specific IP addresses and that of that of the network provider  
>> associated with the ASN.
>> ,---
>> |For more aggressive spammers (e.g., those operating their
>> |own ISP) the temporary period MAY be as much as six (6) months.
>> |However, longer periods SHOULD NOT be used since it is possible
>> |that an IP address or domain can change hands, possibly being
>> |allocated to a non-abusive user.
>> '---
>>
>> This statement ignores network provider's role, and rewards bad  
>> behavior by ensuring their ability to market IP addresses within  
>> their poorly managed ASN.
>
>
> As Matt and I have already pointed out, you are ignoring what the  
> draft actually says in favor of believing that it says something  
> you feel like arguing with. Feel free to do so wherever you like. I  
> won't bother you with responses you refuse to even read.

No where within this entire draft is the role of the network provider  
mentioned or properly considered.  This represents a _major_  
shortcoming in a draft purporting to provide advice to DNSBL  
operators!  The note Matt referenced pertains to condition continuing  
with respect to a _specific_ IP address.  This ignores the role of  
the network provider.  While listings are indeed of individual IP  
addresses, policy should not be limited to individual IP addresses.  
The entire ASN _must_ be considered.

Do you understand what is meant by ASN?

Do you agree network providers plays a significant role in abating spam?

It is completely absurd to recommend spam-friendly ISPs have their IP  
addresses delisted promptly.  What incentive is there for spam-
friendly ISPs to change their behavior?  Shouldn't this aspect of  
policy be considered in any DNSBL best practices?

-Doug





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

Re: Re: DNSBL BCP v.2.0

by Bugzilla from peter@bowyer.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 14/02/07, Douglas Otis <dotis@...> wrote:

>
> On Feb 14, 2007, at 11:27 AM, Bill Cole wrote:
> > As Matt and I have already pointed out, you are ignoring what the
> > draft actually says in favor of believing that it says something
> > you feel like arguing with. Feel free to do so wherever you like. I
> > won't bother you with responses you refuse to even read.
>
> No where within this entire draft is the role of the network provider
> mentioned or properly considered.  This represents a _major_
> shortcoming in a draft purporting to provide advice to DNSBL
> operators!

That's presumably because the draft addresses the operational
processes of a DNSBL, not its policies. Your points are advice on
policy - which, however sensible, are not within the scope of the
draft as currently written.

> The note Matt referenced pertains to condition continuing
> with respect to a _specific_ IP address.  This ignores the role of
> the network provider.  While listings are indeed of individual IP
> addresses, policy should not be limited to individual IP addresses.
> The entire ASN _must_ be considered.

If that's part of the published policy of the DNSBL, and hence the
users of the DNSBL are expecting it, then certainly. But again, this
is policy, not process.

>
> Do you understand what is meant by ASN?

A little disingenuous, perhaps?

> Do you agree network providers plays a significant role in abating spam?

Not relevant within the scope of the draft.

> It is completely absurd to recommend spam-friendly ISPs have their IP
> addresses delisted promptly.

The recommendation is that DNSBL operators have a refresh cycle, where
they delist IPs that no longer meet their published criteria. If the
operator has a policy of persistent listing as you suggest they
should, then the refresh cycle will not result in de-listing because
the criteria still apply. No problem there?

> What incentive is there for spam-
> friendly ISPs to change their behavior?  Shouldn't this aspect of
> policy be considered in any DNSBL best practices?

No, because it's not part of operational best practice, it's part of
the operator's policy-making process - which is subjective,
politically-charged, and doesn't belong in the BCP.

Peter

--
Peter Bowyer
Email: peter@...

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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 14-Feb-07, at 2:59 PM, Douglas Otis wrote:

> No where within this entire draft is the role of the network  
> provider mentioned or properly considered.

Correct. That's as it should be. The creator of a DNSBL decides its  
listing criteria. The draft does not hope to mandate on listing  
criteria, and nor should it.

> The note Matt referenced pertains to condition continuing with  
> respect to a _specific_ IP address.

    Note that all listings being temporary does not mean that some
    listings will not remain after the initial timeout period. If the
    DNSBL administrator determines that the conditions for listing
    still exists, then the timer for determining timeouts MAY be
    renewed.

It seems to say "listing", not "IP address". I think you need reading  
glasses :~)

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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 14, 2007, at 12:18 PM, Matt Sergeant wrote:


> On 14-Feb-07, at 2:59 PM, Douglas Otis wrote:
>
>
>> No where within this entire draft is the role of the network  
>> provider mentioned or properly considered.
>>
>
> Correct. That's as it should be. The creator of a DNSBL decides its  
> listing criteria. The draft does not hope to mandate on listing  
> criteria, and nor should it.
>

Matt,

This draft however recommends a delisting policy (interval) that  
_specifically_ ignores the behavior of the ISP.


>> The note Matt referenced pertains to condition continuing with  
>> respect to a _specific_ IP address.
>>
>
>    Note that all listings being temporary does not mean that some
>    listings will not remain after the initial timeout period. If the
>    DNSBL administrator determines that the conditions for listing
>    still exists, then the timer for determining timeouts MAY be
>    renewed.
>
> It seems to say "listing", not "IP address". I think you need  
> reading glasses :~)
>

A DNSBL listing is by IP address.  This uses references similar to a  
reverse IP address lookup for PTR records.  Surely you know that.

I have not suggested that IP addresses be grouped by ASN, only that  
DNSBL delisting intervals be structured to induce the cooperation of  
network providers.  Longer listings also reduce DNSBL resource  
expenditures, which is appropriate when the next network provider's  
customer, if there is one, is also likely to spam.

-Doug


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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote:

> On 14/02/07, Douglas Otis <dotis@...> wrote:
>>
>> No where within this entire draft is the role of the network  
>> provider mentioned or properly considered.  This represents a  
>> _major_ shortcoming in a draft purporting to provide advice to  
>> DNSBL operators!
>
> That's presumably because the draft addresses the operational  
> processes of a DNSBL, not its policies. Your points are advice on  
> policy - which, however sensible, are not within the scope of the  
> draft as currently written.

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.

>> The note Matt referenced pertains to conditions continuing with  
>> respect to a _specific_ IP address.  This ignores the role of the  
>> network provider.  While listings are indeed of individual IP  
>> addresses, policy should not be limited to individual IP  
>> addresses. The entire ASN _must_ be considered.
>
> If that's part of the published policy of the DNSBL, and hence the  
> users of the DNSBL are expecting it, then certainly. But again,  
> this is policy, not process.

A delisting interval is purely about policy, especially when it  
specifically seeks to ignore the behavior of network providers.  
Short listing intervals for spam friendly network providers (as noted  
by the ASN as a whole) is recommending a bad practice.  Don't be  
pedantic about IP addresses only to ignore the role of the network  
provider.

>> Do you understand what is meant by ASN?
>
> A little disingenuous, perhaps?

Don't you think this definition belongs in a BCP related to DNSBLs?

>> Do you agree network providers plays a significant role in abating  
>> spam?
>
> Not relevant within the scope of the draft.

Network providers and their behavior are not relevant to a DNSBL  
operator?

If this draft is attempting to mandate that the role played by  
network providers are to be ignored, then yes.  If this draft is  
attempting to define best practices aimed at abating spam, then  
absolutely not.  Network provider's roles are significant.

>> It is completely absurd to recommend spam-friendly ISPs have their  
>> IP addresses delisted promptly.
>
> The recommendation is that DNSBL operators have a refresh cycle,  
> where they delist IPs that no longer meet their published criteria.  
> If the operator has a policy of persistent listing as you suggest  
> they should, then the refresh cycle will not result in de-listing  
> because the criteria still apply. No problem there?

Who said anything about a persistent listing?  This is about an  
automatic delisting interval policy to favor those network providers  
that enforce an AUP that prohibits spamming.  A automatic delisiting  
that extends beyond their typical contract period can act as an  
incentive for the network provider to change their policy.

>> What incentive is there for spam-friendly ISPs to change their  
>> behavior?  Shouldn't this aspect of policy be considered in any  
>> DNSBL best practices?
>
> No, because it's not part of operational best practice, it's part  
> of the operator's policy-making process - which is subjective,  
> politically-charged, and doesn't belong in the BCP.

Then remove the nonsense about when to delist, and then don't fail to  
mention the role ASN plays with respect to the _operation_ of a DNSBL.

-Doug




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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 14-Feb-07, at 5:30 PM, Douglas Otis wrote:

> On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote:
>
>> On 14/02/07, Douglas Otis <dotis@...> wrote:
>>>
>>> No where within this entire draft is the role of the network  
>>> provider mentioned or properly considered.  This represents a  
>>> _major_ shortcoming in a draft purporting to provide advice to  
>>> DNSBL operators!
>>
>> That's presumably because the draft addresses the operational  
>> processes of a DNSBL, not its policies. Your points are advice on  
>> policy - which, however sensible, are not within the scope of the  
>> draft as currently written.
>
> 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.



______________________________________________________________________
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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 14-Feb-07, at 5:06 PM, Douglas Otis wrote:

> This draft however recommends a delisting policy (interval) that  
> _specifically_ ignores the behavior of the ISP.

You are the only person who thinks that. Everyone else can see that's  
not the case.

>>> The note Matt referenced pertains to condition continuing with  
>>> respect to a _specific_ IP address.
>>
>>    Note that all listings being temporary does not mean that some
>>    listings will not remain after the initial timeout period. If the
>>    DNSBL administrator determines that the conditions for listing
>>    still exists, then the timer for determining timeouts MAY be
>>    renewed.
>>
>> It seems to say "listing", not "IP address". I think you need  
>> reading glasses :~)
>
> A DNSBL listing is by IP address.  This uses references similar to  
> a reverse IP address lookup for PTR records.  Surely you know that.

We use the term "listing" in the draft to indicate a particular  
listing for a particular criteria. If the criteria causes the DNSBL  
to list a particular ASN for bad behaviour then the listing would  
consist of the range(s) belonging to that ASN.

> I have not suggested that IP addresses be grouped by ASN, only that  
> DNSBL delisting intervals be structured to induce the cooperation  
> of network providers.

That's a policy decision that the DNSBL can make. Nothing in this  
draft prevents that.

> Longer listings also reduce DNSBL resource expenditures, which is  
> appropriate when the next network provider's customer, if there is  
> one, is also likely to spam.

Sure. So there are two scenarios here to look at:

1) The listing is for the spammer. As long as he's spamming the  
listing remains. When he stops spamming we suggest that the maximum  
remaining time his IPs be listed is 6 months. Anything else is unfair  
to innocent parties who end up on a spammer's old IPs.

2) The listing is for the ASN/ISP for providing service to spammers.  
If the ISP stops signing up spammers then the listing will time out 6  
months after the ISP stops signing up spammers. If they clean up  
their act we see no reason they should continue to be blocked.

Whether the listing is for the spammer's individual IPs or for the  
ASN as a whole is, and should be, ENTIRELY up to the owner of the  
DNSBL. In no way do I advocate this BCP telling people what criteria  
they SHOULD use for their DNSBL, that way lies madness.


______________________________________________________________________
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

Re: Re: DNSBL BCP v.2.0

by Bugzilla from peter@bowyer.org :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 14/02/07, Matt Sergeant <msergeant@...> wrote:

> On 14-Feb-07, at 5:30 PM, Douglas Otis wrote:
>
> > On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote:
> >
> >> On 14/02/07, Douglas Otis <dotis@...> wrote:
> >>>
> >>> No where within this entire draft is the role of the network
> >>> provider mentioned or properly considered.  This represents a
> >>> _major_ shortcoming in a draft purporting to provide advice to
> >>> DNSBL operators!
> >>
> >> That's presumably because the draft addresses the operational
> >> processes of a DNSBL, not its policies. Your points are advice on
> >> policy - which, however sensible, are not within the scope of the
> >> draft as currently written.
> >
> > 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.

Absolutely. Diversity of policy amongst DNSBLs is good. Mandating
process in order to make a given DNSBL's policy transparent and
demonstrably adhered to is good. Mandating the policy is bad.

Peter


--
Peter Bowyer
Email: peter@...

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

Re: Re: DNSBL BCP v.2.0

by Douglas Otis :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Feb 14, 2007, at 2:36 PM, Matt Sergeant wrote:

> On 14-Feb-07, at 5:06 PM, Douglas Otis wrote:
>
>> This draft however recommends a delisting policy (interval) that  
>> _specifically_ ignores the behavior of the ISP.
>
> You are the only person who thinks that. Everyone else can see  
> that's not the case.

,---
| For more aggressive spammers (e.g., those operating their
| own ISP) the temporary period MAY be as much as six (6) months.
| However, longer periods SHOULD NOT be used since it is possible
| that an IP address or domain can change hands, possibly being
| allocated to a non-abusive user.
'---

Restated:

"Aggressive spammers operating their own ISP SHOULD NOT be blocked  
longer than 6 months following cessation of abuse, because the IP  
address might be subsequently allocated to a non-abusive user."

When an ASN contains a high percentage of spammers, the likelihood  
that the next user (customer) is also a spammer is more likely than  
not.  Policies and histories should not be limit to specific IP  
addresses, but measured by ASNs as well.  The ASN measurement should  
be a factor in determining the duration before delisting, and not  
solely that of the IP address alone.

>>>    Note that all listings being temporary does not mean that some
>>>    listings will not remain after the initial timeout period. If the
>>>    DNSBL administrator determines that the conditions for listing
>>>    still exists, then the timer for determining timeouts MAY be
>>>    renewed.
>>>
>>> It seems to say "listing", not "IP address". I think you need  
>>> reading glasses :~)
>>
>> A DNSBL listing is by IP address.  This uses references similar to  
>> a reverse IP address lookup for PTR records.  Surely you know that.
>
> We use the term "listing" in the draft to indicate a particular  
> listing for a particular criteria. If the criteria causes the DNSBL  
> to list a particular ASN for bad behaviour then the listing would  
> consist of the range(s) belonging to that ASN.

At times, a complete ASN might be listed.  However, this does not  
change the erroneous statement made regarding a _policy_ of when to  
delist.

>> I have not suggested that IP addresses be grouped by ASN, only  
>> that DNSBL delisting intervals be structured to induce the  
>> cooperation of network providers.
>
> That's a policy decision that the DNSBL can make. Nothing in this  
> draft prevents that.

"However, longer periods [more than 6 months] SHOULD NOT be used  
since it is possible that an IP address or domain can change hands,  
possibly being allocated to a non-abusive user."  Damn, if that is  
not stipulating a listing policy that ignores the behavior of the  
network provider.

How about this for replacing the two offensive sentences:
,'''
: Blocked IP addresses should be reassessed on some regular basis.
: The rate and criteria used to reassess a blocked IP address
: should consider the number of sources within the ASN, as well as
: the abuse cessation interval from the specific IP address.  In
: some cases, no assessment over an interval may be used to reduce
: an expenditure of resources.  For ASNs where there is not a
: prevalence of IP addresses issuing spam, an automatic delisting
: interval should be adjusted to avoid unnecessary delisting requests.
'...

This would avoid a BCP paper that stipulates policy.

>> Longer listings also reduce DNSBL resource expenditures, which is  
>> appropriate when the next network provider's customer, if there is  
>> one, is also likely to spam.
>
> Sure. So there are two scenarios here to look at:
>
> 1) The listing is for the spammer. As long as he's spamming the  
> listing remains. When he stops spamming we suggest that the maximum  
> remaining time his IPs be listed is 6 months. Anything else is  
> unfair to innocent parties who end up on a spammer's old IPs.

Almost.  Looking a the density of abuse within an ASN provides a good  
indication as to whether their next customer will also be a spammer.  
The idea is to make spam friendly ISPs look less attractive to  
spammers.  This is not about treating all of their customers as if  
they are spammers, only that the delisting interval should carefully  
consider measurements of the ASN when determining their automatic  
delisting interval.

> 2) The listing is for the ASN/ISP for providing service to  
> spammers. If the ISP stops signing up spammers then the listing  
> will time out 6 months after the ISP stops signing up spammers. If  
> they clean up their act we see no reason they should continue to be  
> blocked.

Only in the most extreme cases would ASN listing be reasonable.  BCP  
for DNSBLs should elucidate the role ASNs might play.  ASNs are  
extremely important when the DNSBL is noting ISP policy, for example.

> Whether the listing is for the spammer's individual IPs or for the  
> ASN as a whole is, and should be, ENTIRELY up to the owner of the  
> DNSBL. In no way do I advocate this BCP telling people what  
> criteria they SHOULD use for their DNSBL, that way lies madness.

Please understand that saying when to delist is really the same as  
saying when to list.   If you want to avoid saying when to list, then  
by all means avoid saying when to delist.  That aside, there should  
also be a section that describes the role of the ASN.

-Doug




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

Re: Re: DNSBL BCP v.2.0

by Seth Breidbart :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

Seth

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

Re: Re: DNSBL BCP v.2.0

by Matt Sergeant-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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...

______________________________________________________________________
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

Re: Re: DNSBL BCP v.2.0

by Seth Breidbart :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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).

Seth

_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg
< Prev | 1 - 2 - 3 - 4 | Next >