Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)

Douglas Otis <dotis@mail-abuse.org> Thu, 25 June 2009 19:41 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 EB83F3A6DFB for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 12:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.015
X-Spam-Level:
X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
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 1N5zOODjAubN for <asrg@core3.amsl.com>; Thu, 25 Jun 2009 12:41:08 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 10C503A6972 for <asrg@irtf.org>; Thu, 25 Jun 2009 12:41:08 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 531D2A94439 for <asrg@irtf.org>; Thu, 25 Jun 2009 19:40:19 +0000 (UTC)
Message-Id: <94CA8D5B-3281-4884-8221-B3330F689EBF@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <4A43B696.2000106@cybernothing.org>
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: Thu, 25 Jun 2009 12:40:19 -0700
References: <4A43B696.2000106@cybernothing.org>
X-Mailer: Apple Mail (2.935.3)
Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)
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, 25 Jun 2009 19:41:09 -0000

On Jun 25, 2009, at 10:40 AM, J.D. Falk wrote:

> Danny Angus wrote:
>
>> I tried some time ago to articulate some tests which any proposal  
>> ought
>> to at least acknowledge, which you can find here..
>> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
>>
>> You may find them helpful.
>
> Nicely done; I think this could be the start of a very useful  
> document.  Any interest in starting up work on it again?
>
> First steps could be:
> - update terminology to match draft-crocker-email-arch
> - include some examples taken from other RFCs, both successful and  
> non-

This draft overlooked an important area.  It assumes a viable and  
scaleable means to identify initial senders when confronting massive  
levels of abuse.  Simply put, without a two tier approach to abuse  
that begins by identifying outbound MTAs, email will not remain  
viable.  This paper overlooks that need.

- Include a means for efficient and efficacious host name  
identification and domain level authorization of systems granting  
access for outbound public (non-authenticated port 25) SMTP messages.

Even reverse DNS queries often impose a too great of a burden on  
resources due to bot-net related abuse. :^(

Reducing the number of systems that need vetting are best consolidated  
by identifying the outbound MTA explicitly signified as providing this  
service within the forward facing name space.  A means to explicitly  
facilitate this function becomes more necessary with increased  
inclusion of IPv6 and further growth of bot-nets.  Once outbound MTAs  
provide stable and specific identifications within the domain name  
space, the immediate vetting this allows provides a much needed  
reduction on the resource burdens imposed upon SMTP by abuse.   These  
schemes should also not cause undue burden on DNS either.

-Doug