ietf-asrg
[Top] [All Lists]

Re: [Asrg] Nucleus of a draft BCP on filtering

2003-03-08 07:21:09
Jon Kyme wrote:

Well, no, but I believe we must form a consensus on a
definition of "consent-based communication". That's what the RG is chartered for.

Ie: from the charter:

The definition of spam messages is not clear and is not consistent across different individuals or organizations. Therefore, we generalize the problem into "consent-based communication". This means that an individual or organization should be able to express consent or lack of consent for certain communication and have the architecture support those desires.

I see that. On the other hand, as Paul's welcome to the list also comments, we should consider whether that's too confining.

I agree, being able to express consent and have the architecture support those desires is an interesting topic. But, unless you strain the definition of consent implementation to the limit (and build automatic classifiers, which we're a long way away from), you're faced with "merely" a technical infrastructure that implements something that spammers will ignore. It only works if the spammer "consent" to telling the truth.

Rule #1: spammers lie.

Like voluntary classification systems, if the incentive to get around it is enough, they will. And they do. We have ample demonstration of that. Even relatively legitimate operations do things to ensure that their message gets through, because of measures we're taking to stop the totally spammish are believed by the more legitimate operations to be overbroad.

For example, you can consider SpamAssassin to be a consent implementation that automatically classifies (coarsely) the emails. There are already "services" available to tune your message against SpamAssassin - equally attractive to both spammers, and legitimate bulk mailers.

Which defeats the purpose of consent systems.

I think that one of the early, yet valuable, things that the ASRG can do is level-set the "anti-spam" effort: identify which definition of "spam" warrants the efforts (UBE, IMHO), classify existing solutions, make them play nice with each other, establish best-current-practises for various aspects of spam control - ie: BCPs on how anti-spam gateways should behave, BCPs on how DNSBLs should operate (ie: truth in advertising), BCPs on how false positives should be handled (ie: rejects, versus bouncing, versus silent blackholing), BCPs on privacy concerns of distributed bulk detection (hi Vernon! ;-), etc.

BCPs not necessarily as "musts", but guidance to administrators and filter designers when they're designing, building, deploying and operating stuff.

Through this, we also begin to understand what works better, as well as answering the age old question, "is it going to be enough to prevent striker meltdown of the entire Internet?" (IMHO, no, just a last ditch defence that's ultimately doomed without "help" from non-technical means).


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg