Re: [Asrg] SMTP pull anyone?

Bart Schaefer <> Tue, 18 August 2009 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2BFF3A6B3A for <>; Tue, 18 Aug 2009 10:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EUWorfKFa33D for <>; Tue, 18 Aug 2009 10:04:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C17828C2E2 for <>; Tue, 18 Aug 2009 10:03:59 -0700 (PDT)
Received: from ([]) by (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <> for; Tue, 18 Aug 2009 03:01:42 -0500 (CDT)
Received: from (localhost.localdomain []) by (8.13.1/8.13.1) with ESMTP id n7I81aq8029372 for <>; Tue, 18 Aug 2009 01:01:36 -0700
Received: (from schaefer@localhost) by (8.13.1/8.13.1/Submit) id n7I81aLB029371 for; Tue, 18 Aug 2009 01:01:36 -0700
From: Bart Schaefer <>
Message-id: <>
Date: Tue, 18 Aug 2009 01:01:36 -0700
In-reply-to: <>
Comments: In reply to John Levine <> "Re: [Asrg] SMTP pull anyone?" (Aug 18, 3:47am)
References: <>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: Anti-Spam Research Group - IRTF <>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: Re: [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:04:38 -0000

On Aug 18,  3:47am, John Levine wrote:
> The disadvantage is that it requires that senders and receivers all
> be connected to the same network all the time, which is a lot closer
> to true now than it was in the 1980s, but still a long way from
> universally true.

I'm not a proponent of the pull model, but it seems to me this could
be overcome if each receiver in a store-and-forward sequence were
able to inform its immediate upstream when it is not able to perform
the pull.

E.g., transmit the "pull handle" as far as possible, then have the
last relay that is capable of doing so, issue the pull request.

This could probably even be done with one new SMTP verb plus ETRN.
E.g. DATA FROM:<message-id> where the domain part of the message-id
must resolve to the host that will cough up the message.  If the
receiver responds 50z or 455, the sender must do the pull.  If the
receiver responds 354, sender sends dot, and eventually some receiver
connects to <message-id-domain> and issues ETRN #<message-id-local>.

All sorts of security implications to be worked out, Tumbleweed
problems aside.