Re: [Asrg] SMTP pull anyone?

Ian Eiloart <iane@sussex.ac.uk> Mon, 17 August 2009 10:05 UTC

Return-Path: <iane@sussex.ac.uk>
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 E63773A681A for <asrg@core3.amsl.com>; Mon, 17 Aug 2009 03:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185]
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 decDNs0HU9K0 for <asrg@core3.amsl.com>; Mon, 17 Aug 2009 03:05:47 -0700 (PDT)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id D80233A672E for <asrg@irtf.org>; Mon, 17 Aug 2009 03:05:46 -0700 (PDT)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49541) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KOIMPK-0008UF-HX for asrg@irtf.org; Mon, 17 Aug 2009 11:05:44 +0100
Date: Mon, 17 Aug 2009 11:05:44 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: asrg@irtf.org
Message-ID: <2E9DB38172DCD7955B90C74C@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4A884C68.7020301@billmail.scconsult.com>
References: <922a897b0908160420w4554837aj684e86eb586823af@mail.gmail.com> <4A884C68.7020301@billmail.scconsult.com>
Originator-Info: login-token=Mulberry:01fHD1aeXRY8693UnL6Jbv5Wjc4ugWw9+W8ds=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] SMTP pull anyone?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <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: Mon, 17 Aug 2009 10:05:48 -0000

--On 16 August 2009 14:14:00 -0400 Bill Cole <asrg3@billmail.scconsult.com> 
wrote:

>
>> 3. If the IP that contacted is legitimate(can be verified by say SPF?),
>> it contacts the sender and provides the message ID with other details.
>
> The *most* that SPF can provide towards showing "legitimacy" is to
> confirm that the envelope sender address of a message is not forged. It
> is very rare for large senders of any sort to deploy records that can do
> that strongly. There is nothing about SPF that directly attacks spamming.
> It could in theory be used to attack sender forgery, but the collateral
> damage has proven to be too great for either sending or receiving systems
> to actually apply it strongly to that end. Meanwhile, a lot of spammers
> are sending a lot of spam with senders that are validated to the degree
> that SPF can validate anything.

SPF deployment has grown rapidly from 5% of 2,000,000 sampled domains to 
17% over the past three years, apparently including most USA banks. About 
half of spf publishing domains, including some large senders like facebook, 
use "-all" records. Apart from anything else "-all" on its own is a good 
way of saying "this isn't an email domain", and it's probably a good idea 
to publish it for every A record that doesn't point to a mail server.

Furthermore, some large recipients like gmail use these records to help 
assign reputation to senders. Forwarded email is likely already suffering 
from deliverability problems when the sender address is not rewritten (at 
least in cases like forwarding facebook mail to gmail, for example), and 
these problems will continue to get worse, not better as SPF deployment 
increases, and as records are increasingly respected.

People who want to offer a reliable forwarding service to their users 
already need to be thinking about rewriting sender addresses.

It might take a few years, but I'm convinced that we'll look back on SPF 
deployment in the same was that we look back on the campaign against open 
relays some years ago.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/