Re: [Asrg] Re: Spam, why is it still a problem?

Douglas Otis <dotis@mail-abuse.org> Wed, 18 January 2006 02:54 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3SU-0003lI-RA; Tue, 17 Jan 2006 21:54:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3ST-0003kz-T4 for asrg@megatron.ietf.org; Tue, 17 Jan 2006 21:54:01 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25246 for <asrg@ietf.org>; Tue, 17 Jan 2006 21:52:35 -0500 (EST)
Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez3ai-0005w3-WD for asrg@ietf.org; Tue, 17 Jan 2006 22:02:33 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0I2rleo008998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for <asrg@ietf.org>; Tue, 17 Jan 2006 18:53:48 -0800
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <RY4n4+N85XzDFw8x@siliconglen.com>
References: <9qBEYaDyZ2yDFwj7@siliconglen.com> <20060117095618.GB16889@nic.fr> <43CCC3B6.40706@linuxbox.org> <RY4n4+N85XzDFw8x@siliconglen.com>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <63E00039-3AC0-4FAB-ADB3-B856C3FC5B8B@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [Asrg] Re: Spam, why is it still a problem?
Date: Tue, 17 Jan 2006 18:53:48 -0800
To: Anti-Spam Research Group Group <asrg@ietf.org>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Content-Transfer-Encoding: 7bit
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org

On Jan 17, 2006, at 3:32 PM, Craig Cockburn wrote:

> Moving on then to the next stage, if these technologies are still  
> deemed inadequate because of false positives or an unacceptable  
> quantity of spam (+ phishing + viruses and worms etc) arriving   
> then a global upgrade of email in some form needs to happen. Whilst  
> I'm not denying this is a difficult job I don't think it's quite as  
> hard as people make out. Especially for those people who find their  
> legitimate email blocked they could easily be persuaded to join in  
> some form of sender reputation based framework as there's something  
> in it for them. e.g.
> http://mipassoc.org/dkim/specs/draft-allman-dkim-ssp-01.txt

I find it interesting one would equate protection from email blocking  
with SSP.  While I could understand how the DKIM signature could be  
used for establishing a framework for reputation, I am at a loss how  
one could go about safely or fairly using SSP for this purpose.    
Indeed there are likely many who will try to use SSP in this manner.   
In which case, protecting reputations will likely require publishing  
closed policies.  Closed policies 'o=!' would indicate no signatures,  
invalid signatures, or third-party signatures are indicative of  
messages not conforming to the policy referenced by the From email- 
address.

Closed policies will disrupt many email services, while the claimed  
protection will still be circumvented.  This disruption may soon  
become problematic for the average user when a large domain offers  
higher ratings for messages containing email-addresses with an SSP  
policy.  Of course, when the email-address does become abused,  
especially when the policy is open-ended, the natural reaction would  
then be to lower ratings for messages that contain the abused email- 
address.  Some may consider the email-address domain owner to be  
culpable for their policy as justification for this strategy.  SSP  
already sends complaints to the email-address domain owner, but not  
the signer.  Of course, larger domains will likely be white-listed,  
as who would want to disrupt messages from millions of users.   
Nevertheless, the smaller domains may still need to respond by  
publishing a closed policy, even though this will disrupt many email  
services, such as posting to this list. : (

List-servers will then need to either replace the From email-address  
or add multiple From email-addresses in an attempt to overcome this  
limitation.  In the end, the From email-address will less reflect who  
authored the message.  Users in general may need to forgo the use of  
their smaller and more personable domains for an email-address  
provided by a larger domain.  Although a larger domain may have a  
poor record of controlling abuse, these domains would still able to  
offer an email policy compatible with current services with much less  
fear of being block-listed.

How is SSP a means to avoid having your email-address block-listed?   
It seems DKIM without SSP is the only sure method.  Allow banks to  
publish closed policies if they wish.  An email recipient or a top or  
second level domain provider will not relishing label tree walking  
when every message initiates a new set of queries for these few  
polices.  A commerce related accreditation list from an RSS feed  
could offer far greater value.  The list could indicate domains like  
bigbank.com are trustworthy and always sign their email and online- 
bigbank.com are not trustworthy even though they too sign their  
messages and publish closed policies.  The bottom-line, only a  
verified source identifier offers a reasonable framework for  
reputation.  SSP is not that framework.

-Doug


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg