--On Wednesday, August 11, 2010 11:48 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
On Tue, 10 Aug 2010, John C Klensin wrote:
--On Tuesday, August 10, 2010 09:48 -0700 Dave CROCKER
<dhc(_at_)dcrocker(_dot_)net> wrote:
As I recall, delivermail didn't do queuing. So, yes, the
delivery attempt was immediate.
Sendmail behaved the same way, for a first attempt, and did
queuing only if that attempt failed.
MMDF always did queuing first, spawning a delivery attempt
afterward. (Submission and delivery were independent Unix
processes.)
And IIR, several of the small computer-based things, including
PC/TCP, would make a direct attempt to deliver and send mail
to what we would now call a submission server only if that
single direct delivery attempt failed.
Dave and I are talking about server side processing. You seem
to be talking about client retry logic.
Well... The reason why 821 talked about SMTP-Sender and
SMTP-Receiver (and variations) rather than "client" and "server"
was precisely tied up with that bit of confusion. I was a
little reluctant to change it with 2821, but that seemed to be
the Right Thing to do (as well as WG consensus). If one is
going to do queuing in the ways that Dave discusses, then one is
acting as an SMTP-Sender. Before we tried to more clearly
delineate the notion of "submission server", a client (even what
we traditionally think of as an originating MUA) that used SMTP
to get to whatever was next was acting as an SMTP-Sender. And a
server that was queuing mail for a potential next hop was an
SMTP-Sender too, regardless of whatever else it might be doing.
Things would obviously be different if a system or process had
already accepted mail for final delivery and was then
considering queuing it for delivery to a mail store. But,
afaik, none of the systems Dave discussed did that, at least
until much later.
Arnt's comment that only the terminology changes is probably
relevant here.
john