--On Wednesday, August 11, 2010 11:48 +0100 Tony Finch
<[email protected]> wrote:
>
> On Tue, 10 Aug 2010, John C Klensin wrote:
>> --On Tuesday, August 10, 2010 09:48 -0700 Dave CROCKER
>> <[email protected]> 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
