ietf-smtp
[Top] [All Lists]

RE: Mail Data termination

2011-08-17 04:54:55



--On Tuesday, August 16, 2011 22:58 -0700 "Murray S. Kucherawy"
<msk(_at_)cloudmark(_dot_)com> wrote:


-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Murray S.
Kucherawy Sent: Tuesday, August 16, 2011 10:03 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: Mail Data termination

SMTP has always held
that the client is responsible for retrying delivery until
the server gives a 250 or 5xx back after DATA, at which point
the server is now responsible for the message.

Sorry, that's not quite right:

SMTP has always held that the client is responsible for
retrying delivery until the server gives a 250 or 5xx back
after DATA, at which point the server has either accepted or
finally rejected the message; if the message is accepted, the
server is now responsible for its relay or delivery.

Still not quite right.  

        "...if the message is accepted, the server is now
        responsible for its relay, delivery, or rejection via an
        NDN ('bounce') message."

See the text quoted in my immediately-previous note and the
comments I made about it.

This whole "formal acceptance of responsibility" bit really just
says that a server must not casually discard a message and that
it must be designed to be robust against that happening in
anything but the most drastic situations.  Because the spec was
deliberately intended to permit a server to defer all actual
processing of the message until it got around to it (see
previous note), the "receive EOD, issue Success response"
sequence guarantees only that the responsibility handoff has
occurred.   It is completely conforming for the server to come
back some time later with an NDN that says that none of the
addresses were deliverable.

At one time, with different server speeds and typically
available bandwidth, we believed that "accept, defer all address
and message  processing until after EOD, and bounce if needed"
was a much better strategy than trying to do as much as possible
at SMTP time.  Today, the pendulum has swung in the other
direction, propelled by concerns about blowback, discarded NDNs,
and so on.  But SMTP hasn't changed: decisions about when and
how the message should be examined and processed are strictly up
to the server as long as it doesn't try to avoid responsibility
for messages it has accepted.

   john



<Prev in Thread] Current Thread [Next in Thread>