On 09/Feb/10 13:08, Ian Eiloart wrote:
--On 8 February 2010 16:44:18 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
Problem A: report spam for complaining (was #3)
Problem B: tune servers' filters (was #2)
I don't think it's useful to try and solve both of them at the same time.
I'm completely confused by this message. I really don't understand at
all what it is that you're saying. Problem B is about how you handle
reports once you have them. I don't understand what "Problem A: report
spam for complaining" means at all.
Problem B imposes a tight matching between where the original message
has been filter and where the report is going to be handled. In
addition, it needs both spam and ham info. Since the main purpose of
server-based (as opposed to client-based) filtering is to save
bandwidth, efficiency is a relevant concern.
Problem A has a somewhat wider horizon, as it assumes that reported
spam may be routed through some trust-chained operators, possibly
reaching the author of the original message. Although the report may
also be used for tuning or assessing anti-spam filters, its main
purpose is to affect the source of the original message. This is a
generalization --and regularization-- of the FBLs currently used
between giant mailbox providers and ESPs. My expectation is that it
will result in important advances in the collective understanding of
spam, so that massive abuse reporting will not be needed forever. In
the latter respect, relatively inefficient (inelegant) procedures may
be acceptable, if they widen the chances of adoption.
Hope this clarifies my point, sorry for the unintended confusion.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg