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

Douglas Otis <dotis@mail-abuse.org> Mon, 22 June 2009 22:45 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 0AFBC28C21C for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 15:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.402
X-Spam-Level:
X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 LhRgXuu8S6EX for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 15:45:19 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3F61D3A68BB for <asrg@irtf.org>; Mon, 22 Jun 2009 15:45:19 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 215F0A9443D for <asrg@irtf.org>; Mon, 22 Jun 2009 22:45:32 +0000 (UTC)
Message-Id: <9C2ED955-306F-4633-ACFB-B99BBF226900@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <7ae58c220906221313n6e39d3c1o6591596f6c2b8b9@mail.gmail.com>
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: Mon, 22 Jun 2009 15:45:31 -0700
References: <9112777.1871245190785748.JavaMail.franck@iphone-4.genius.local> <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> <BD23C7D8-9E95-45CA-93F3-80F9726F889C@mail-abuse.org> <247DB2D923FD71677CC1D4FA@lewes.staff.uscs.susx.ac.uk> <41937DE9-BAF3-486B-953E-8C638F3A49D2@mail-abuse.org> <7ae58c220906221313n6e39d3c1o6591596f6c2b8b9@mail.gmail.com>
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 22:45:20 -0000

On Jun 22, 2009, at 1:13 PM, Dotzero wrote:

> Doug,
>
> I'd take your discussions of SPF more seriously if you would stop  
> conflating SPF and Sender-ID. They are two different animals. SPF  
> (the specification) does not include anything called PRA. Sender-ID  
> includes the concept of PRA. PRA is broken in the spec so there  
> isn't any purpose in spending time discussing it. All one needs to  
> do is look at the paragraph that states that if a sender field  
> exists you set the PRA to that. This bypasses any SPF record  
> published for the Mail From (envelope sender) domain. End of  
> discussion.


The SPF (RFC 4408) lacks a means to constrain the scope of  
authorization records to just Mail-From.  Sender-ID (RFC 4406) section  
3 allows SPF (RFC 4408) records to authorize MTAs based upon PRA  
headers, and perhaps failing that, upon the Mail-From parameter.  RFC  
4406 section 3.1 modifies RFC 4408 versioning and adds a scope  
parameter.  Per RFC 4406 section 3.4, the unmodified SPF record is to  
be considered the same as spf2.0/mfrom,pra. :^(

Section 3.4 of RFC 4406 also states:
,---
If the information in a "v=spf1" record is not correct for a PRA  
check, administrators SHOULD publish either an "spf2.0/pra" record  
with correct information or an "spf2.0/pra ?all" record indicating  
that the result of a PRA check is explicitly inconclusive.
'---

Per RFC 4406, when PRA authorization fails, an attempt to verify Mail- 
 From authorization might be attempted.  When only RFC 4408 has been  
relied upon, the Mail-From domain may inadvertently offer  
authorization based upon PRA headers.  In this case, how SPF records  
are used is uncontrolled.  From an overhead standpoint, RFC 4406  
potentially doubles the overhead related to SPF record resolution.   
Although RFC 4406 recommends against use of MTAs that "lie" about  
local-parts, it failed to exclude macro use, or to consider what  
happens when providers do not restrict the use of domains in  
originating headers, in addition to the use of local-parts.

Email would have likely faired much better by recommending immediate  
rejection, use of RFC 3464, and minimal DSN content with"multipart/ 
report" content types.

-Doug