Re: [Asrg] What are the IPs that sends mail for a domain?

Ian Eiloart <iane@sussex.ac.uk> Tue, 30 June 2009 09:55 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 2D39F3A6CE4 for <asrg@core3.amsl.com>; Tue, 30 Jun 2009 02:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
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 sxPLidjenJbP for <asrg@core3.amsl.com>; Tue, 30 Jun 2009 02:55:44 -0700 (PDT)
Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 166603A6AF6 for <asrg@irtf.org>; Tue, 30 Jun 2009 02:55:43 -0700 (PDT)
Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:52533) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KM1Q90-000E60-69 for asrg@irtf.org; Tue, 30 Jun 2009 10:55:48 +0100
Date: Tue, 30 Jun 2009 10:55:04 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: asrg@irtf.org
Message-ID: <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk>
In-Reply-To: <4A48FB80.10709@billmail.scconsult.com>
References: <mailman.5.1245610801.29559.asrg@irtf.org> <4A3F76B8.2030409@terabites.com> <BBBA1F6A3752AE7B96888ECB@lewes.staff.uscs.susx.ac.uk> <4A48FB80.10709@billmail.scconsult.com>
Originator-Info: login-token=Mulberry:01vvpVTydbw7T/Z6mxKiAxb8jCJHJ2qSEgM2U=; 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] What are the IPs that sends mail for a domain?
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: Tue, 30 Jun 2009 09:55:45 -0000

--On 29 June 2009 13:36:00 -0400 Bill Cole <asrg3@billmail.scconsult.com> 
wrote:

>
>> There is, actually. If you publish SPF records with a strong -all, then
>> recipients can easily decide to reject (not bounce) messages. Add DKIM
>> signatures, and they'll be able to tell when someone has forwarded your
>> legitimate email.
>
> Do you have any evidence that this actually works to any detectable
> degree?
>
> I have solid proof that it is far from perfect, but I only have a handful
> of addresses that ever had significant bogus bounce flow in the one
> domain I could safely use in a SPF '-all' effectiveness test. The first 5
> years of that test have shown a slow drop in the rate of bad bounces in
> general offered to that domain, but it isn't much more proportionally
> than the drop from a dribble to a trickle that I've seen for a domain
> with no SPF record. The noise in my minuscule and weakly controlled data
> makes it quantitatively worthless, but on a qualitative basis it makes
> clear that strong SPF records are not yet a strong universal tool for
> preventing blowback bounces.
>
> If you are aware of SPF being any more useful than prayer at controlling
> blowback, please share it.

Well, my claim is a theoretical one, and perhaps a hope for the future. It 
probably isn't yet effective. I do believe that it will be one day.

However, I do believe that people should take SPF records into account when 
deciding whether to generate bounce messages. It should not be a problem if 
there's a positive SPF or DKIM match. You shouldn't do it if there's an SPF 
fail. It's harder to decide what to do in the absence of SPF, or a neutral 
or softfail result.

I'd suggest that to drive up adoption of SPF, don't bounce for a neutral or 
softfail result (instead give a 5xx error), but (this will be 
controversial) feel free to bounce into domains that aren't trying to help 
- ie domains that don't publish SPF records at all. (ducks).


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