Jimmy Hess wrote: > > On Fri, Apr 6, 2012 at 8:48 AM, <valdis.kletni...@vt.edu> wrote: > > If it was industry-wide standard practice that just notifying a provider > > resulted in something being done, we'd not need things like Senderbase, > > which is after all basically a list of people who don't take action > > when notified... > > > [snip] > Pot calling the kettle black. Before we talk about industry-wide > practice about the providers "doing something". We should talk about > industry-wide practice for "Black lists" doing something to correct > entries, instead of just building up indiscriminate or irresponsibly > maintained lists of networks or "scores" of networks that were > targetted by a spammer at one time in the past.
Sorry, but blocklists _came_into_existance_ ONLY because of large numbers of providers *ignoring* the problems their networks were causing the rest of the world. The very existance of 'widely used' blocklists is a damning indictment of the entire services provider industry. _Everybody_, including the major blocklist operators, would prefer that blocklists were _not_ needed -- that all providers would simply 'do the right thing', and insure that their users did =not= abuse other people's systems. Were that pipe-dream to come to pass, the major blocklists would *happily* shut down. They are all 'money sinks', operating at a loss, 'for the good of the community as a whole'. Before blocklists. 'policing your own network' was a pure expense item with no return. _Not_ policing one's own users *added* to profitability. There was no 'business incentive' to be a "good neighbor". With the advent of blocklists, providers have an 'economic self interest' justification in remaining out of the major/widely used ones. It is still an expense item, but "not doing anything" costs _more_ in 'lost revenues'. It is a sad comment on the state of affairs that _all_ the major providers have repeatedly demonstrated they simply "cannot be trusted to 'do the right thing'" *without* a loaded gun held to their heads -- but that *is* the reality of today's marketplace. Today, for any of the major spam-based blocklists, a single entry consisting of more than a single address is indiicative of a _failure_ of a provider's self-policing. It is the height of hubris for a provider to 'demand' (or even 'expect') prompt/immediate response from a blocklist, *when* the provider 'demonstrably' couldn't be bothered to act that way themselves. (What's 'sauce for the goose' _is_ sauce for the gander. :) IF the provider had been actively self-policing, the blocklist entry would not have been escalalated to larger than the single offending address. Yes, it would be "nice" if everybody responded promptly; but, in the real world, that simply doesn't happen -- on either side of the fence. I once got an ack about a spam complaint *over*five*months* after sending it. (For 'some strange reason', that provider is no longer in business. Thank goodness! > It's just as bad for a blacklist operator to not respond and "do > something" for a network operator legitimately trying to resolve spam > problems with their network and clear the listing as it is for a > network abuse contact to not respond to a network operator. This is provably not true. There is no recourse/remedy for an unresponsive network operator. The 'network abuse' ccontinues to flow, _unabated_, from that network. A blocklist, on the other hand, tends to be self-regulating. If it is not responsive to changing conitions, especially the 'cleaning' of formerly 'bad reputation' addresses/blocks, it generates an 'unacceptably high' number -- as determined by it's USERS, not the senders -- of 'false positive' evaluations, *wherepon* increasing numbers of users =stop= using that service. Resulting in an automatic _lessening_ of the impact of being listed on that blocklist. See the APEWS list for a 'textbook' demonstration of this self-regulation in action. > We should talk about industry-wide practices for how providers should > be notified, what providers are actually supposed to do to "authenticate > reports", because > sometimes the report/notification itself is > malicious or false abusive attempt to harass an innocent email user, > and what exactly providers are actually expected to do with certain kinds > of notification. > > The informal standard of "just call or send an e-mail to an abuse > contact" is poorly specified. The informal standard of "the abuse > contact should investigate and take immediate action" is poorly > specified. > > Some of these things that are not specified by RFC should be specified > by RFC as best practice. There should be abuse notification and response > notification mechanisms other than free form e-mail. It would appear that you are not familiar with RFC 5965.
