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

"Chris Lewis" <> Tue, 18 August 2009 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D263928C31B for <>; Tue, 18 Aug 2009 10:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qJjLqnf9nqzR for <>; Tue, 18 Aug 2009 10:17:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DDB933A6B5A for <>; Tue, 18 Aug 2009 10:17:38 -0700 (PDT)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id n7IHFWQ05065 for <>; Tue, 18 Aug 2009 17:15:33 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2009 13:17:33 -0400
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 18 Aug 2009 13:17:32 -0400
Message-ID: <>
Date: Tue, 18 Aug 2009 11:17:32 -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: "" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Aug 2009 17:17:33.0889 (UTC) FILETIME=[C6759B10:01CA2027]
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 17:17:39 -0000

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.

The "offer" would have to have more-or-less the same information as the 
pre-DATA SMTP information in normal SMTP.  A SMTP server can just as 
easily reject on that data pre-DATA, as to "choose not to do" the call 
back.  So, up to this point, the offer/callback approach doesn't do any 
less work than normal SMTP.

Then offer/callback actually has to call back and retrieve the message. 
  You also have to build in mechanisms to make sure that someone _else_ 
isn't doing the retrieval.

Then, if you do any DATA filtering, _both_ approaches have to do similar 
levels of work.

In other words, the offer/callback approach only causes you to expend 
more work actually implementing the callback _itself_, plus checking it 
for validity.