Re: [Asrg] Soundness of silence

Bill Cole <asrg3@billmail.scconsult.com> Tue, 16 June 2009 17:21 UTC

Return-Path: <asrg3@billmail.scconsult.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85683A6A61 for <asrg@core3.amsl.com>; Tue, 16 Jun 2009 10:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAXK9TuWWRmT for <asrg@core3.amsl.com>; Tue, 16 Jun 2009 10:21:18 -0700 (PDT)
Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 2E84A3A6DA1 for <asrg@irtf.org>; Tue, 16 Jun 2009 10:21:18 -0700 (PDT)
Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id D50118D4DA1 for <asrg@irtf.org>; Tue, 16 Jun 2009 13:21:20 -0400 (EDT)
Message-ID: <4A37D490.3030900@billmail.scconsult.com>
Date: Tue, 16 Jun 2009 13:21:20 -0400
From: Bill Cole <asrg3@billmail.scconsult.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4A329E38.9010609@tana.it> <4A36904E.8040908@billmail.scconsult.com> <4A3781D4.3020303@tana.it>
In-Reply-To: <4A3781D4.3020303@tana.it>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Soundness of silence
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: asrg@irtf.org
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 17:21:19 -0000

Alessandro Vesely wrote, On 6/16/09 7:28 AM:
> Bill Cole wrote:
>> Different people (and mail systems) have different spam problems.
>
> I tend to understand that as different classes of spam. For an example,
> consider a creditor of mines who solicits payment by sending me
> reminders. Assume I'm not going to pay and I just discard them. If, by
> chance, they end up in the spam folder, would I be willing to train my
> Bayesian filter to avoid that? Probably no. And, are those reminders
> spam? In some acceptation of the term, yes. Thus, a fax or a registered
> letter is better than email...

It goes beyond that sort of edge case of defining spam as "mail I don't 
like". There are envelope characteristics that exist in distinct types of 
mail that are mostly seen by different sets of receiving systems, such as 
messages with more than 10 recipients. For microdomains and mass-market mail 
providers, such mail is almost always archetypal spam: sent without any 
prior relationship to addresses harvested from the net or bought from a 
harvester. For many businesses, such mail is almost entirely legitimate mail 
from existing business partners: service providers, suppliers, etc.  On 
different mail systems, the same low-cost rule may correlate well to the 
spam/non-spam classification, *but in opposite directions.*



>> Many people have come up with "good enough" solutions for their own
>> spam problems, but they are no all the same solutions. The idea that
>> there is or could be one solution that works for everyone has largely
>> fallen into disrepute because all of the attempts at it have fallen
>> far short of the goal. Unfortunately, many of the de facto best
>> current practices are completely unsuited for technical
>> standardization. I don't think anyone wants to see any sort of RFC
>> that recommends using any specific DNSBL, but for many people running
>> mail systems of a wide variety the use of the Spamhaus Zen DNSBL is
>> their most effective single anti-spam tactic. Recommending the
>> shunning of specific whole countries certainly does not belong in
>> anything that anyone might see as a "standard" but as a matter of
>> practicality, many mail systems do so to great benefit and at no
>> tangible cost.
>
> I don't see why such techniques are not amenable to standardization.
> Actually, there is a couple of DNSBL drafts that are slowly moving forward.

Which are good efforts, but they don't actually tell readers which DNSBL's 
are highly effective and which are dangerous to their mail. Or which might 
be both. For the overwhelming majority of mail systems, the most effective, 
cost-effective, and safe tool to shun spam is the Spamhaus Zen list, but it 
would be a very bad idea for any RFC to say that. Similarly, there are very 
safe, cheap, and effective ways to stop spam before DATA based on rDNS and 
HELO names that could never pass muster for an RFC.

> It should be possible for my SMTP server to accept mail only from, say,
> an office opposite with whom I do most business, and shunning all the
> rest except, say, Gmail, thereby relying on their filtering. There's
> nothing wrong with that, except for technical problems that make it
> difficult to set it up properly.

No RFC will (or should) ever recommend such an approach.

That is not because such an approach will never be the best one for any 
system, but because it is not a widely deployable solution and it relies 
upon a characteristic of the mail world that may well be transient.

>> Because spam is fundamentally a social problem rather than a technical
>> problem, the technical approaches to fixing it are all imperfect, many
>> subsets are subject to "arms race" problems, and the only
>> generalizable solution is that everyone running a mail system should
>> apply a mix of tactics suited to their spam and their non-spam (based
>> on the locally relevant definition of "spam") and pay attention to how
>> those tactics work *for them* rather than seek to locally deploy some
>> global solution.
>
> Yes, that's the conclusion I also reached. Spam is a universal plague
> and we must live with it. It is indecent to egoistically take oneself
> away from it. Therefore, solutions to get rid of spam are not wanted,
> not even discussed. BTW, discussion implies that someone will try to
> also get rid of direct marketing, in the bargain. So, let's keep all of
> it, even the inadmissible zombie-generated spam.

I disagree. :)

I think you are misunderstanding my point. The existing tools are good 
enough that most mail system operators can put together some set of them to 
assure that a large majority of their users see spam rarely and have very 
little legitimate mail blocked, while the non-zero level of errors in both 
directions have made users more acclimated to and forgiving of such 
imperfections. This has raised the bar significantly for new technical 
approaches, which will not even get attention unless they are very good, 
very low-cost, and very easy to deploy.


[...]
>> Your proposal is complex enough that making a careful analysis takes
>> real effort. A casual scan of the document doesn't yield obvious fatal
>> flaws, nor does it provide any instant 'AHA!' response of how the VHLO
>> mechanism would provide a clear fix for a major problem. That results
>> in it seeming like a low-yield chore to go through 23 pages of details
>> to figure out whether this idea is sound and useful. Maybe improving
>> sections 1.1-1.3 to more directly and concisely define the problem
>> VHLO is meant to address would encourage more attention.
>
> That's what I've been trying to do in the last two rounds. Any explicit
> hint?

Replace the tutorial on mail filtering fundamentals with a concise problem 
definition and concise explanation of how VHLO provides a solution.

[...]
>> More telling: I'm not convinced that any new technical approach to
>> spam control has any chance of widespread adoption or even careful
>> attention. The jungle of existing tactics combined with a drop in user
>> expectations has resulted in a circumstance where the demand for
>> better mail service is not enough to get significant new technical
>> approaches deployed.
>
> Great! I cannot tell it better than that. It obviously implies that
> email is going to die out.

Not at all. I just don't expect that it will every be like 1993 again. I 
think we've reached something like a dynamic equilibrium over the past few 
years, and it will take a really big push to change that. There are many 
mail systems out there shunning 97%+ of all messages while delivering less 
than a spam per week per user and stopping less than one legitimate message 
per year per user. 5 years ago, that sort of accuracy took an anti-spam 
craftsman tending a garden of homegrown tools (and customizations of open 
tools) with users screaming bloody murder over every error. Today you can 
buy it in a box or as a service, and the users are largely resigned to the 
fact that sometimes mail goes missing and sometimes they get solicited for 
dubious drugs and money-making schemes. Perversely, users have also become 
shockingly dependent on Internet email, and expect it to do things that they 
never would have asked back before mail administrators evolved into a breed 
of artful destroyers of most mail.

 > Newcomers don't perceive it as something new
> and exciting, but rather as an obsolete communication system used
> predominantly by elder people, generally left in a state of regrettable
> neglect.

That perception is IMHO largely shaped by the fact that the newest of 
newcomers are people who do not actually operate as autonomous adults.