Dr. Jeffrey Race wrote:
> 
> On Mon, 19 Apr 2004 12:40:23 -0400, Yakov Shafranovich wrote:
> 
>>>For most users, the need is to stop the spam without blocking legitimate
>>>mail from the same host. This is what drives the concept of filtering
>>>over using a DNSBL.
>>
>>Collateral damage is an issue.
> 
> 
> Collateral damage is the OBJECTIVE.  It is the only thing
> that gains the attention of the abuse-enablers.   This is proven
> beyond doubt. 
> 

The road is littered with corpses of users who are unable to send mail 
due to their upstream's upstream provider being blocked. There are 
numerous cases where blocking a specific ISP or network has done more 
bad than good.

In any case, just like beauty collateral damage is in the eye of the 
beholder. I just don't think that most ISPs will agree to do anything 
that may cause their users to complain about being unable to email their 
grandmother. While for some of us the collateral damage is acceptable, 
in practice businesses will be hesitant to do anything that may cause it.

This is the same reason why the top six ISPs do not use blacklists 
en-masse but rather rely on their own internal blacklists supplemented 
by third parties.

> 
>>Another issue is the fact that blocking 
>>is not communicated to the sender in many cases but the messages are 
>>swallowed silently.
> 
> 
> That is an RFC violation.
> 

If the mail is filtered after SMTP level and bounce address is suspected 
to be false, some may argue that it is not. There is some work on a BCP 
on that (Keith Moore?).

But in any case, the fact that a standard exist does not mean it is 
used. Perhaps, we should look into how to better enforce existing RFCs.

> 
>>As for community-based systems, rule of the mob is not always good.
> 
> 
> No 'mob' is involved, but users who do not agree to have their
> systems polluted.  Procedures are clear and public in the document I
> drafted.
> 

Quis custodiet ipsos custodes” – “Who will watch the watchers”?

Laws are useless unless they are enforced, same for standards. Who will 
make sure that the procedures you drafted are actually used in a correct 
fashion? What happens if people start blocking ISPs and networks without 
a good enough reason like some blacklist operators have done?

Additionally, what happens if a portion of the community colludes 
against a specific network or operator? Why would this approach be any 
better than the existing practice of blacklists?

> 
>>I am not saying this approach is bad, rather it has issues that must be 
>>worked out. If all of these issues are taken into account, such system 
>>may very well do a lot of good.
>>
>>For example, if there are standards for communications among ISPs and 
>>networks for both blocking and abuse reporting, 
> 
> 
> There is ia standard; it is in the RFC pertaining to mandatory role
> accounts.

I assume you are referring to RFCs 2821 and 2142. They define the 
postmaster@ and abuse@ addresses. However, it seems that in many cases 
ISPs want to have additional mailboxes or simply do not honor the RFC, 
which is why systems like abuse.net are used.

However, knowing where to send something is half the puzzle - it still 
costs. If some automated solutions can be introduced that would allow 
ISP's abuse desk systems communicate among themselves, that would reduce 
their costs and allow for better handling of abuse reports.

As for blocking, there are not existing standards aside from RFC 2821 
that cover it, and blocking is not being communicated until the SMTP 
transaction takes place, or if the filtering is done post SMTP, it may 
never communicated.

Yakov