ietf-smtp
[Top] [All Lists]

Re: Pipelining vs. multiple failure codes

2005-02-02 19:34:42


Hello.

On Wed, 2005-02-02 at 11:13, Tony Finch wrote:
On Wed, 2 Feb 2005, Richard Dawe wrote:

The RFC on pipelining (RFC2920
<ftp://ftp.rfc-editor.org/in-notes/rfc2920.txt>) doesn't discuss what to
do on a temporary failure on, say, MAIL FROM.

The pipelining spec is hopelessly wooly.

It hasn't proved to be so in practice.

Maybe it's worth doing an update to the spec, to make it clearer?

If a sufficient number of problems are found, sure. And while I agree that this
particular point could be clearer, IMO it is not enough to warrant
republication. I have noted it in the event additional issues come to light.

Consider the following sequence:

  MAIL FROM
  4xx
  RCPT TO
  5xx (no MAIL FROM => RCPT TO not valid)
  DATA
  5xx (no recipients)

What should the SMTP client conclude in this case? Should it bounce the
message or try again later?

Try again later.

It should try again later. The client should interpret the responses as if
it hadn't pipelined the commands. The first error is the important one.

Good, that's what I was hoping.

It's the only reasonable thing to do.

(Outlook gets this grievously wrong and will uselessly report to users
"Valid RCPT command must precede DATA". Not advertising PIPELINING doesn't
help because it pipelines anyway.)

If so, that's very seriously broken. The reason PIPELINING was done  as
extension is because there are servers out there that cannot tolerate
pipelining.

Lotus Domino also appears to break. I'm not sure if this is all versions
or just a particular version. I have no information about the version
number in the case I've seen.

I suspect it is version-specific; I have noted no problems of this sort
with Lotus Domino.

Are there any other MTAs that have this problem?

About the only problem I have ever seen with pipelining (and I deal with SMTP
issues all time) has been with firewalls that allow the pipelining
advertisement through even though they are incapable of dealing with its effect
on the SMTP dialogue.

                                Ned