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

Ian Eiloart <> Fri, 19 June 2009 08:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A6783A68F8 for <>; Fri, 19 Jun 2009 01:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y+1WzWyT6zZQ for <>; Fri, 19 Jun 2009 01:55:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 293233A67F0 for <>; Fri, 19 Jun 2009 01:55:00 -0700 (PDT)
Received: from ([]:56260) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KLHA5T-000JVO-2M for; Fri, 19 Jun 2009 09:56:17 +0100
Date: Fri, 19 Jun 2009 09:55:12 +0100
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <> <> <> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <>
Originator-Info: login-token=Mulberry:01iBKVzfFzAzLJf+kv9Dj7hwhA7oq2J+s4/X0=;
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-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Jun 2009 08:55:01 -0000

--On 19 June 2009 08:41:57 +0200 Alessandro Vesely <> wrote:

> der Mouse wrote:
>> Responsibility, in the sense of accountability for (potential) abuse,
>> is a meatspace thing, not amentable to being part of a network
>> protocol, so at least _some_ of this must be done out-of-band with
>> respect to the protocol.
> On thefreedictionary I read
>    Synonyms:  responsible, answerable, liable, accountable, amenable
>    These adjectives share the meaning obliged to answer, as for one's
>    actions, to an authority that may impose a penalty for failure.
> Because the IETF cannot even enforce protocol compliance, addressing
> responsibility implies identifying an authority that has the power of
> imposing some kind of penalty.

It's our respective governments, and such international law as they agree 

As an internet community, we must work towards forcing people to 
authenticate senders - by making it harder and harder for unauthenticated 
mail to get delivered. Once we know who's sending the email, they can be 
held to account by (a) reputation services, and (b) the law.

>>> Providers MUST be held _directly_ accountable.
>> Right.  But until this is fixed at the top, I see little hope it will
>> happen in the lower levels, except sporadically.  (The places that do
>> do it are exceptional, and, in the cases where I'm in a position to
>> know why they do it, they do it not because they are held accountable
>> by whoever assigned the resources to them but because they are ethical
>> enough to feel a compulsion to do what's right even when they're _not_
>> overtly held accountable.  While this mindset is common enough for us
>> to have words for it, it is not nearly common enough to save the net
>> from the disasters that governmental disconnect between authority and
>> responsibility leads to.)
> I think we can safely withdraw the naive picture where carriers act as
> authorities, and forget about the possibility that anything will be
> eventually "fixed at the top", except for possible devout beliefs. On
> this Earth, ethical mindsets are still powerful intellectual tools that
> bring visions and may allow to plan for decades. Although such planning
> usually results in optimization of revenues in the long run, uncertainty
> about the future wreaks those greedy and short-sighted behaviors that
> currently are the norm.
> To cope with that, protocols need to introduce ad-hoc authorities
> whenever responsibility is required. For mail, those may involve DNSBLs,
> CAs, VBR vouchers, and similar kinds of independent organizations. We are
> already relying on them, unofficially. For increased cooperation, we
> better make that explicit.
> _______________________________________________
> Asrg mailing list

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see