Re: [Asrg] Adding a spam button to MUAs

Douglas Otis <> Fri, 29 January 2010 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A5BE3A67EC for <>; Fri, 29 Jan 2010 10:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yrt5bh-BJhF8 for <>; Fri, 29 Jan 2010 10:03:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4146328C177 for <>; Fri, 29 Jan 2010 10:03:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B55D9A94442 for <>; Fri, 29 Jan 2010 18:03:31 +0000 (UTC)
Message-ID: <>
Date: Fri, 29 Jan 2010 10:03:31 -0800
From: Douglas Otis <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jan 2010 18:03:32 -0000

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.