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

Ian Eiloart <iane@sussex.ac.uk> Thu, 02 July 2009 09:41 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 EC1623A6C3F for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 02:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6]
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 x3-Zbk+3CSfx for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 02:41:27 -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 60BE028C1F6 for <asrg@irtf.org>; Thu, 2 Jul 2009 02:40:09 -0700 (PDT)
Received: from seana-imac.staff.uscs.susx.ac.uk ([139.184.132.137]:58236) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KM5EVW-0004DQ-R4 for asrg@irtf.org; Thu, 02 Jul 2009 10:40:45 +0100
Date: Thu, 02 Jul 2009 10:40:25 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <126E753184A13926E471EE27@seana-imac.staff.uscs.susx.ac.uk>
In-Reply-To: <20090701150032.GB15652@verdi>
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> <DC4825E67EC4297FF587671B@seana-imac.staff.uscs.susx.ac.uk> <20090701150032.GB15652@verdi>
Originator-Info: login-token=Mulberry:01lWTtOP7FW53W0UGaAYoI2WCr+9wOkviKCs8=; 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: Thu, 02 Jul 2009 09:41:29 -0000

--On 1 July 2009 11:00:32 -0400 John Leslie <john@jlc.net> wrote:

> Ian Eiloart <iane@sussex.ac.uk> wrote:
>>
>> The point of SPF is to authenticate the sending domain.
>
>    I don't believe SPF does any such thing. Domains can publish SPF RRs,
> but those can't reasonably be said to "authenticate" anything, least of
> all the "sending domain."
>
>> If the IP address is authorised (by the domain owner) to send mail from
>> the sender domain,
>
>    That's closer... But I'd argue that no SPF construct "authorizes"
> sending email. In practice, I think it's quite clear that SPF constructs
> merely express probabilities.

OK, so it's authorization rather than authentication. By "probabilities", 
are you referring to the probability of forwarding, or the use of some 
unauthorized MSA? Certainly, the latter need to be stamped out in the same 
way that open relays were. There are other ways to deal with the forwarding 
problem, and they'll be adopted in time as the value of SPF increases with 
take up.

>> then bouncing mail into that domain isn't going to be causing
>> backscatter,  unless the domain lacks internal controls over message
>> submission.
>
>    Of course, rather few domains other than corporate domains with
> administrators more-than-average familiar with SMTP have reasonable
> "internal controls over message submission". :^(

Yes, but they need to improve. They won't, unless they're held accountable.

>> If it does lack those internal controls, then the users of the domain
>> can blame the domain owner.
>
>    Indeed they can... does that actually accomplish anything?

Yes. Not usually as fast as you'd like. But, companies (email service 
providers) go out of business if people stop using the service. For 
commercial users

>> I guess there can also be issues where two distinct domains share the
>> same outbound IP addresses, through an email service provider.
>
>    Indeed, that is common...
>
>> In that case, the email service provider is the responsible party that
>> needs to be held to account.
>
>    (which, BTW, is what CSV set out to do...)
>
>> They need to ensure either (a) separation of domains by outbound IP
>> address combined with accurate SPF records,
>
>    Assuming they control either multiple IP addresses _or_ the SPF
> records is risky. But even if they did, how would this lead to assigning
> the responsibility correctly?

It prevents cross-domain abuse. When good.example shares IP addresses with 
bad.example on the outbound MTA, then users of bad.example can forge mail 
in the domain good.example and get themselves a free ride on the reputation 
of good.example - thus damaging the reputation of good.example

If the two domains have separate outbound IP addresses (very feasible with 
IPv6) then proper use of SPF can protect them from that abuse. Given that 
this is all in the control of a single ESP, that ESP can put in place the 
necessary protection for forwarding. This means that they can safely 
publish +ve records for a domain's allocted IP addresses, -ve records for 
the rest of the ESP's IP address space, and (for now) neutral or softfail 
for the rest of the world.

Assignment of responsibility should be to the domain owner, or the email 
address owner. It doesn't much matter which - they can sort that out 
themselves. This would be a huge improvement over the current situation, 
where you can only assign responsibility to an IP address. The main 
improvement is that non-technical people have some understanding of 
domains, but no understanding of IP addresses.

>> or (b) proper implementation of MSA on all the domains that they
>> provide service for.
>
>    That is at least practial... But how does it lead to assigning the
> responsibility correctly?

The point is that the ESP needs to prevent the sort of cross-domain abuse 
that I've referred to above. With proper implementation of MSA, they can 
detect or prevent the cross-domain abuse. That ensures that an SPF pass 
doesn't result in reputation being assigned to the wrong domain. It also 
ensures that bounce messages aren't delivered into the wrong domain.

> --
> John Leslie <john@jlc.net>
> _______________________________________________
> 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/