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

Ian Eiloart <iane@sussex.ac.uk> Wed, 01 July 2009 10:17 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 1AE803A6A01 for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 03:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 YkXXPkp+fflz for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 03:17:18 -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 6F4543A6F21 for <asrg@irtf.org>; Wed, 1 Jul 2009 03:17:17 -0700 (PDT)
Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:49392) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KM3LXN-000L85-7F for asrg@irtf.org; Wed, 01 Jul 2009 11:17:47 +0100
Date: Wed, 01 Jul 2009 11:17:32 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <DC4825E67EC4297FF587671B@seana-imac.staff.uscs.susx.ac.uk>
In-Reply-To: <20090630111105.GA12502@gsp.org>
References: <mailman.5.1245610801.29559.asrg@irtf.org> <4A3F76B8.2030409@terabites.com> <BBBA1F6A3752AE7B96888ECB@lewes.staff.uscs.susx.ac.uk> <4A48FB80.10709@billmail.scconsult.com> <800E7AE85B690B4BAC93F2CD@seana-imac.staff.uscs.susx.ac.uk> <20090630111105.GA12502@gsp.org>
Originator-Info: login-token=Mulberry:01WD0yrcGeoBKZqoYPxGPLsqUgvrVTB7tjzag=; 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: Wed, 01 Jul 2009 10:17:20 -0000

--On 30 June 2009 07:11:05 -0400 Rich Kulawiec <rsk@gsp.org> wrote:

> On Tue, Jun 30, 2009 at 10:55:04AM +0100, Ian Eiloart wrote:
>> However, I do believe that people should take SPF records into account
>> when deciding whether to generate bounce messages.
>
> Despite the ostentatious claims made by its originator ("Spam as a
> technical problem is solved by SPF"), SPF has no anti-spam value.

Given that you don't have a precise definition of spam, that's a pretty 
strong claim in itself.

> Nor should it be used when deciding whether to generate a bounce:
> the answer to that is always "no".  It's far better to reject (not
> to mention far simpler, with any sane MTA) and thus greatly diminish
> the possibility of outscatter/backscatter spam.

The point of SPF is to authenticate the sending domain. If the IP address 
is authorised (by the domain owner) to send mail from the sender domain, 
then bouncing mail into that domain isn't going to be causing backscatter, 
unless the domain lacks internal controls over message submission. If it 
does lack those internal controls, then the users of the domain can blame 
the domain owner.

I guess there can also be issues where two distinct domains share the same 
outbound IP addresses, through an email service provider. In that case, the 
email service provider is the responsible party that needs to be held to 
account. They need to ensure either (a) separation of domains by outbound 
IP address combined with accurate SPF records, or (b) proper implementation 
of MSA on all the domains that they provide service for.

Backscatter is a problem, but bounce messages do have advantages over 5xx 
error codes when it comes to communicating with the sender. For example, 
you can't know what the sending MTA is going to do with a 5xx error code - 
they might just drop it. DSNs were invented for a reason, and it's a shame 
to lose them entirely - even when you have reason to believe that the 
return-path (or at least the return-path domain) isn't forged.


> ---Rsk
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



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