Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Douglas Otis <dotis@mail-abuse.org> Tue, 13 December 2005 21:15 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmHV3-0003K4-D1; Tue, 13 Dec 2005 16:15:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmHV1-0003Jc-Gw for ietf@megatron.ietf.org; Tue, 13 Dec 2005 16:15:51 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26902 for <ietf@ietf.org>; Tue, 13 Dec 2005 16:14:54 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmHW5-0001w6-NP for ietf@ietf.org; Tue, 13 Dec 2005 16:16:58 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id jBDLFeeh022799 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Dec 2005 13:15:41 -0800
In-Reply-To: <x4slswke7k.fsf@footbone.schlitt.net>
References: <200512092141.NAA00720@gra.isi.edu> <x4fyp1n5xs.fsf@footbone.schlitt.net> <tslbqznbcem.fsf@cz.mit.edu> <x48xuqksa1.fsf@footbone.schlitt.net> <1134489989.5110.47.camel@bash.adsl-64-142-13-68> <439F0E4C.1493@xyzzy.claranet.de> <x4slswke7k.fsf@footbone.schlitt.net>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F7153948-7108-4DC0-B89E-F8B4A19CCCC1@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Date: Tue, 13 Dec 2005 13:16:12 -0800
To: wayne <wayne@schlitt.net>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Dec 13, 2005, at 11:07 AM, wayne wrote:

> However, his complaints could not have possibly had any impact on  
> the current limits in the SPF spec.

The reduction to 111 DNS lookups is not a resounding impact with  
respect to this concern.  Defending this sequential lookup  
requirement will likely never be tested, as it must become an  
impediment for abusers first.  Abusers remain a substantial portion  
of the initial adopters.  SPF will not likely become a replacement  
for black-hole lists, but instead may be used to implement unfair  
reputations based upon email-address domain owners authorizations.   
This problem is a good reasons for ensuring scope is defined.

SPF is not about validating the purported author of a message.  SPF  
deals with forged return-paths.  For this protection, SPF depends  
upon wide adoption by others before a benefit is obtained, hence the  
reluctance to correct the lack of scope.  BATV, on the other hand,  
provides immediate benefits when forged return-paths are used in DSNs  
(the only place where a return-path is intended to be used).  This  
forged return-path technique is often used to evade black-hole  
lists.  Even with BATV, there are about 6 packets exchanged without  
any data phase for the message, which pales against the benefits  
obtained from a black-hole list which often limits the exchange to no  
more than four when an error message is returned.

Without BATV, another 8 to 30 exchanges often occurs with a forged  
return-path DSN where content is commonly returned.  The DSNs must be  
filtered as the forged return-path has become a common exploit.  The  
heavy filtering of DSNs is troubling as this will reduce the  
integrity of a store and forward SMTP system.  One of the greatest  
benefits of store and forward scheme is efficiency.  Holding open a  
session with the upstream server to check acceptance or for AV and  
Spam filtering completion, is not optimal.  BATV does not require any  
additional DNS lookups or published DNS records.  The BATV tag is  
transparent and can be handled by all existing MTAs.  BATV offers the  
same challenges as any authentication scheme, where the admin must  
know where all their outbound MSAs are located for the domain that  
wishes to filter BATV tags at the MDA.  If the admin misses an MSA,  
or a sender uses the wrong MSA, only the DSN would be at risk.

The forged DSN is a serious problem.  Castigating those willing  
accept email on good faith and then issue DSNs is counter to  
establishing either integrity or efficiency.  Making the forged  
return-path exploit not offer any value for the sender is what _must_  
be done.  There are black-hole list protections at the front-door,  
but no protections at the back-door.  At this point, ensuring common  
acceptance criteria upstream is the only sensible stop-gap measure.   
Something like BATV can return integrity and efficiency to SMTP.  SPF  
does not offer an efficient model going forward, and is in jeopardy  
of establishing a wholly unfair reputation scheme based upon  
authorization and not the actual sending of messages.

-Doug


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf