Re: [Asrg] ARF traffic, was Spam button scenarios

["Chris Lewis" <[e-mail]>]

Alessandro Vesely wrote:
> On 09/Feb/10 19:29, Chris Lewis wrote:
>> Alessandro Vesely wrote:
>>> form abuse@domain is standardized by rfc 2142. Some people (e.g.
>>> Abusix) may plan to send machine generated complaints at such addresses.
>> And they'll learn very very soon that that doesn't work.
>>
>> Been there/done that in a limited fashion, and even in that limited
>> fashion, it don't work.
> 
> Why not, _what_ goes wrong?

The extant methods for determining where abuse reports are (a) usually 
wrong or missing and we're not going to bail that ocean, (b) 
insufficiently granular (both report types, but worse, breakdowns of 
space to responsible parties, ie resellers) and (c) without aggregation, 
too high volume even for automation.

[e-mail] is for reports of abuse originating _at_ 
[e-mail], not for reports of abuse (eg: spam) originating 
elsewhere that example.com's users want to report.

In other words, our TiS should _not_ go to [e-mail].  It goes 
elsewhere.  If I changed my mind for convenience, I wouldn't change the 
TiS to go to [e-mail], I'd change the mail system to alias it.

I did some experimentation with automatic aggregation and 
hand-configured destinations for a small fraction of reports.  That 
worked somewhat, but not worth the effort to keep touching the config.

> It seems to me that a simple filter could determine ARF/non-ARF 
> quality of a message in a fraction of the time that spamassassing 
> would take to process it, assuming abuse@ boxes are whitelisted.

A single bot run could fill up the abuse box so quickly that a "simple 
filter" can't do anything about it.

For the rare occasion that you want your TiS button goes to abuse@<you>,
a simple forwarding alias is far easier than the more common 
circumstance of having to construct some sort of content filter to split 
ARFs from non-ARFs.  And less likely to completely break down during a 
flood.