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

"Chris Lewis" <> Wed, 19 August 2009 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4EDC3A6C3C for <>; Tue, 18 Aug 2009 23:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oTblPh2lkjTk for <>; Tue, 18 Aug 2009 23:53:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BAAE33A6BB9 for <>; Tue, 18 Aug 2009 23:53:19 -0700 (PDT)
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id n7J6G8123953 for <>; Wed, 19 Aug 2009 06:16:08 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 02:16:07 -0400
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 19 Aug 2009 02:16:06 -0400
Message-ID: <>
Date: Wed, 19 Aug 2009 00:16:05 -0600
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090605 Lightning/0.9 Thunderbird/ Mnenhy/
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
X-OriginalArrivalTime: 19 Aug 2009 06:16:07.0268 (UTC) FILETIME=[89CD9240:01CA2094]
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: Wed, 19 Aug 2009 06:53:20 -0000

Douglas Otis wrote:
> 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.

>> 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.

This does not provide any new mechanisms for deciding what is, in fact, 

Step back.  The "hard part" of this proposal is deciding what email is 
desired.  The proposal makes no suggestions on something "new" that 
could be used to do this.  As it stands, it's simply a more convoluted 
and expensive version of SMTP.

What does "pull" provide that existing "push" does not in terms of 
improved filtering?  Until and unless you can answer that, it's moot.

Does it provide a innovative way of deciding what email is desired?  No.

That you don't transfer the DATA if the email is undesired?  Given that 
the vast majority of spam is well under 10K in size, this pales in 
comparison to the complexity and network loading of actually performing 
the pull.

Certainly, you can extend the push to include additional stuff.  Like 
DKIM or something different.  But that's just as easily done/possible in 
push, and already is.

Letting the MUA fill up with offers, and forcing the user to to decide 
what's wanted has the same problems as junk folders.  The legit email 
gets lost in the noise.

In fact, junk folders are "pull".  How well do they work?  Not well.