ietf-asrg
[Top] [All Lists]

Re: [Asrg] Adding a spam button to MUAs

2010-01-29 12:04:21
On 1/29/10 5:44 AM, Rich Kulawiec wrote:
On Thu, Jan 28, 2010 at 09:41:03AM -0800, Michael Thomas wrote:
The entire thing strikes me as rather elitist: like only Certified 
Spamologists(tm)
can determine for you what you don't want to receive.
Not quite.  But maybe so.

We don't (at least I sure *hope* we don't) permit users to determine which
packets will/won't be permitted into our networks.  We set those policies
to maximize security, because we recognize that malicious/dubious network
traffic is a threat.  So for example, we might have in place a mechanism
which begins to reject ssh connection attempts after a certain number of
failures.  There is no real difference between that and rejecting SMTP
traffic -- recognizing that spam is *also* a security threat -- other than
the application protocol involved.

Users are not qualified to make decisions about (for example) SSH traffic
management in perimeter firewalls.  Nor are they qualified to make decisions
about about SMTP traffic management in mail servers.  That is why they
are users and not network/server managers.  (They probably get to make
some other decisions that network/server managers don't.  It works both
ways: each according to their expertise and responsibilities.)

This is NOT the same thing as determining for a user (to go back to your
remarks) what "[they] don't want to receive". That's a personal preference
and users are of course free to formulate/express it as they wish.

I don't think this is elitist, I think it's a matter of recognizing that
the spam/not-spam classification process requires expertise *vastly* in
excess of that possessed by almost all users.  This is not their "fault"
per se because it's not a fault: it's simply a lack of area-specific
experience and knowledge.
Well said. Labeling a feedback button as "this is junk" (TIJ) avoids inaccurately describing its identification as absolute indications of the purported sender having sent spam. Often within the feedback, who the sender is remains uncertain as well. Even the Authentication Results header fails to capture the important IP address seen at the administrative border needed to identify the immediate sending administrative entity.

Of course, any email administrator receiving negative feedback describing a problem should ascertain its nature, and take corrective steps when found abusive. Unfortunately, even when accurate and prioritized information of spamming is provided, administrators instead tend to rely upon their own actionable criteria, where even strong evidence is often dismissed. After all, dealing known spam sources likely involves customers having 0wned systems or accounts. Often the response is we don't see any problem.

Perhaps when TIJ correlates with actual spam detections, administrators might find themselves with fewer excuses. This issue is growing in importance, because bad actors are getting better at compromising accounts as well as customer's systems.

-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg