--On 2 March 2010 08:18:10 -0500 Rich Kulawiec <rsk(_at_)gsp(_dot_)org> wrote:
I'm going to try to summarize and enumerate some of the arguments against
the general idea of a report-as-spam button. My position is that several
of these points (individually) make the case that it's a truly bad idea
and should be abandoned immediately and permanently, and that
collectively, they're an overwhelming rationale. Others differ, of
course.
This is a *summary* and not an attempt to provide every nuance
of every argument, so nitpicking is discouraged. You may rest
assured that I read the traffic on this list and have been paying
close attention to the spam problem for the past several decades. ;-)
1. User incompetence
Crowd sourcing should be used to gather confidence in reports when they're
many. Admin inspection can be used when they're few.
2. User time
Nobody is asking them to classify every message. This is tool that they can
choose to use, or not. Indeed, the mechanisms that we're discussing are
about how the user system can communicate classification to the
administrator. This could be done by the user client filter. Remember, the
user is already trusting the filter to hide email.
3. User exposure
Many clueless users, unfortunately, use web browsers or otherwise
HTML-enabled mail clients to read their mail. (Of course we can
safely presume that competent professional postmasters or abuse
desk personnel don't do this, but the report-as-spam button is
intended for the masses, and they, sadly, do.)
It is certain that in the process of trying to perform classification
tasks, they'll click on links "just to see what's there". This
not only provides very useful information to spammers, but it will
assist phishers, trojan downloaders and others whose goal isn't
really spamming per se, but using spamming to penetrate
systems/networks or perform reconnaissance on them.
That depends on where the reports go. On my system, they'll be coming to
me.
4. User influence on security policy
Anti-spam defenses are similar to firewall rules: they control
site security. End-users should not be permitted to override
or otherwise modify firewall settings: neither should they
be permitted to override or otherwise modify anti-spam settings.
First, because it's not their job, second, because they're
not responsible for the consequences, third, because they
lack expertise in this area.
(This is not to say that they shouldn't have input. But all such
input should be manually, carefully reviewed by qualified and very
skeptical personnel before any decisions are made about using it.)
Ah, so that's not an argument against providing a junk button at all,
merely a caution. Noted.
5. Duplicates existing functionality
All competently-run sites support the RFC 2142-stipulated
"abuse" role address and have appropriately experienced,
trained, qualified and diligent staff reading every message
sent there. It's trivially easy for any user to forward
questionable mail traffic (with full headers of course)
Right, but most don't know that the address exists, and don't know what
full headers are. A junk button *could* (A) expose the reporting mechanism
to the user, and (B) ensure that the reports are useful by ensuring that
they include full headers.
In fact, I think that you've just given a convincing argument FOR a junk
mail button.
to the abuse address of their own mail provider, who can then
decide what to do about it. These personnel are far better
situated to decipher headers, correlate against logs,
assess threat severity, etc. They're also much less likely --
presuming that they're competent -- to hand over useful
information to the enemy. See next point as well.
6. Free useful intelligence for spammers
My reports won't be going to spammers. Have you really been reading this
thread?
7. Creating more Internet mail traffic is a bad move
Agreed. That's why I'm advocating IMAP flags or annotations as a better
solution.
8. Report-as-spam button repurposed as weapon
We've already seen how spammers have repurposed any number of
ill-conceived anti-spam concepts (e.g., SAV) as weapons.
They'll do that with this too, should it profit them to do so.
I trust at least a few methods are obvious on inspection;
there's also a few non-obvious ones that I will not be discussing
on a public mailing list, some of which relate to the next point.
9. The zombie problem
Again, the mechanism should only generate reports to the administrator, and
the administrator needs to have quality assurance mechanisms in place.
You've suggested some. Others are available.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg