Re: [Asrg] [ASRG] SMTP pull anyone?

Douglas Otis <> Tue, 18 August 2009 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2FD628C356 for <>; Tue, 18 Aug 2009 13:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.675
X-Spam-Status: No, score=-5.675 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2VB-MJDFo9BU for <>; Tue, 18 Aug 2009 13:45:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FDA128C36C for <>; Tue, 18 Aug 2009 13:45:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C8E8A9443A for <>; Tue, 18 Aug 2009 20:45:46 +0000 (UTC)
Message-ID: <>
Date: Tue, 18 Aug 2009 13:45:46 -0700
From: Douglas Otis <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] [ASRG] SMTP pull anyone?
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: Tue, 18 Aug 2009 20:45:56 -0000

On 8/18/09 10:17 AM, Chris Lewis wrote:
> Bill Cole wrote:
>> I don't see how this reduces the effort required on the receiving side in
>> comparison to currently common practices.
> Precisely - in fact, it increases the work the receiver has to do,
> probably substantially.

As accepted IP addresses are reduced, there will be increased abuse of 
existing services, that were likely exposed through information gleaned 
from compromised computers.  This will eventually move the problem to 
the point where the IP address of the client offers fewer clues about a 
message source.  Without some simply means to identify undesired 
messages, the sheer volume of undesired email will provide a growing 
burden.  Especially when content filtering must be deployed.  It is hard 
to imagine a more resource intensive strategy.

> Consider: the offer/callback approach is identical to SMTP up to the
> DATA keyword.

Not if MUA or specialized MDAs gather the messages marked as desired. A 
selection based upon the offers should reduce the overhead considerably.

> The "offer" would have to have more-or-less the same information as the
> pre-DATA SMTP information in normal SMTP.

No. Unlike that of an SMTP exchange, when reference information is not 
valid, the reference does not work.  This removes the validation steps.