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

Douglas Otis <dotis@mail-abuse.org> Mon, 22 June 2009 06:34 UTC

Return-Path: <dotis@mail-abuse.org>
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 340E03A6A4C for <asrg@core3.amsl.com>; Sun, 21 Jun 2009 23:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.396
X-Spam-Level:
X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 8LbmC3E5bTQC for <asrg@core3.amsl.com>; Sun, 21 Jun 2009 23:34:09 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 326F83A6A28 for <asrg@irtf.org>; Sun, 21 Jun 2009 23:34:09 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F2D26A94439 for <asrg@irtf.org>; Mon, 22 Jun 2009 06:34:19 +0000 (UTC)
Message-Id: <BD23C7D8-9E95-45CA-93F3-80F9726F889C@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <4A3D366E.2020304@tana.it>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 21 Jun 2009 23:34:16 -0700
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <Pine.GSO.4.64.0906161906450.27272@nber6.nber.org> <4D8E56D2-CB37-4713-94E5-0F0C2A1B1F94@blighty.com> <2F26F23C-F1B4-4FD4-BAEB-53168072FF5D@mail-abuse.org> <200906180105.VAA21834@Sparkle.Rodents-Montreal.ORG> <C8F0F10E-E1A4-4D25-AF20-31E3F0DB68DF@mail-abuse.org> <200906182044.QAA05200@Sparkle.Rodents-Montreal.ORG> <FED77586-8800-4BA6-99EA-30A1D9C089B6@mail-abuse.org> <200906190149.VAA06902@Sparkle.Rodents-Montreal.ORG> <B5252B96-F0AB-4D4A-A0DA-8314AA8E038F@mail-abuse.org> <4A3D366E.2020304@tana.it>
X-Mailer: Apple Mail (2.935.3)
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: Mon, 22 Jun 2009 06:34:10 -0000

On Jun 20, 2009, at 12:20 PM, Alessandro Vesely wrote:

> Douglas Otis wrote:
>> SMTP is heavily abused, and soon IPv6 is about to become a  
>> necessity.   To remain practical, connectivity must be based upon  
>> _immediate_ and _stable_ evidence of legitimate email operation,  
>> and not upon any number of authorization transactions.  Each  
>> additional transaction to support an authorization scheme will be  
>> multiplied by the typical number of attempts made by abusive  
>> senders.   This means providers need to exclude problematic users,  
>> and not become a task pushed toward recipients.  Such pushing is  
>> not practical and often leads to unfortunate mistakes.
>
> What do you mean by "problematic users"? Providers of residential  
> cables, WiMAX, and similar connections could block or redirect port  
> 25, just like most universities and companies do. They used to do  
> it, as long as they provided mailboxes as a bonus and ISP and ESP  
> were synonyms. Submission port 587 is not yet universally employed,  
> and some customer may not accept to be unable to reach their  
> favorite server's ports 25 or 465. "Blocking port 25 except for a  
> set of servers used for submission" is not something that can be  
> easily defined and maintained by ISPs, IMHO.

Each recipient will likely attempt to accept either none or some  
amount of public email based upon normal profiles.  To remain on the  
safe size typical profiling, this requires the output issued by bad  
actors be mitigated in some fashion.  This might be done by using rate  
limiting combined with disabling accounts faster than bad actors can  
re-subscribe.  Funny how little anti-spam efforts concentrate on  
account setup.  Things like Open-ID might help in this area, for  
example.

> OTOH, sender identification by domain could also be a way to  
> attribute responsibility. Strictly speaking, it is not necessary to  
> use a domain in order to send as an SMTP client. However, in  
> practice one needs an email address to do any legitimate use of  
> SMTP, and hence a domain is required.

Technically speaking, a domain is not required for SMTP.   CSV was to  
offer a DNS record type that explicitly declared a host as being an  
outbound MTA.  This would not in itself prevent abuse, but would help  
to determine which compromised systems might be sending email and  
resolving which domain is administrating the MTA.

SPF does not work well at resolving a domain that should be held  
accountable for a few reasons-

  a) risks high and impractical transaction overheads at attempts to  
indirectly reference the customers of a provider.

  b) may not qualify any specific IP address for a positive result.

  c) Mail From or PRA references do not resolve which domain  
administered the MTA or actually sent the message.

  d) holds customers of a provider accountable for the provider's  
stewardship without any solid evidence of their involvement.

>>>> Schemes that pass accountability onto what might be feckless  
>>>> domain owners are inherently evil.
>>>
>>> I disagree, _provided_ accountability is actually passed on.
>
> +1

There should be greater concern accountability is correctly applied.

>> The fact that a trusting and naive user had their domain authorize  
>> a provider just to have their email accepted, does not mean other  
>> messages emitted might not be mistaken as also belonging to that  
>> user's domain.  Should providers check for SPF or Sender-ID  
>> compliance?  How many SLA include this requirement?  When the  
>> "passing-on" is based upon receptions at spam traps, acceptance  
>> reliance based on "authorization" is likely to downgrade acceptance  
>> of the domain, especially when A-R headers exclude the IP address  
>> of the provider.  Will providers really care the wrong entity had  
>> been blamed?
>
> You can never know whether that domain's owners are really so  
> foolish to trust a criminal provider, rather than participating  
> accessories. Assuming their bad faith, one should downgrade  
> acceptance of their domain.

Who said providers need to be criminal for naive users to be harmed by  
SPF?  A recipient may check PRAs, where providers may check Mail- 
Froms.  Once a user's domain reputation is damaged due to receiver  
error, how can reputations be restored and then protected?  When asked  
in the past, those customers are advised to obtain their own IP address.

>>> What you appear to be thinking of is not accountability but mere  
>>> identification (albeit moderately strong identification).
>> Moderately strong?  Without knowing the IP address of the provider,  
>> it would be extremely foolish to conclude any level of  
>> identification assurance, especially "moderately strong".
>
> IMHO, the domain registrants (resulting from whois records) provide  
> an identification that is comparable in strength, but finer in  
> granularity.


It is wrong to hold someone accountable for authorizing a provider  
once authorization becomes a requisite for acceptance.  Users are  
thereby extorted into assuming risks well beyond their control.

Instead, providers should be held accountable by requiring CSV records  
with a limited number of EHLO host names over time.

This approach better defends receiving MTAs from abuse with lower  
overhead, and better controls DNS related exploits that threaten the  
entire Internet.

-Doug