|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
|
|
Re: Re: DNSBL BCP v.2.0On 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.0On 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.0On 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.0On 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.0I 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.0At 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.0On 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.0At 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.0On 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.0On 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.0On 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.0On 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.0On 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.0On 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.0On 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.0On 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.0On 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.0Matt 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.0On 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.0Matt 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 > |
| Free embeddable forum powered by Nabble | Forum Help |