Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 23 Feb 2006 10:09:10 -0600

>Cool, thanks. Yes, it's much clearer, and allows full pipelining of
>multiple messages :-)

Allowing multiple messages was not the intent.  Help me figure out why you see this as acceptable so I can fix it when I align the language with RFC 2920 :-)

>Also, "Receivers MUST accept the BDAT command even where there are no
>valid recipients." - why not allow them to reject in this situation?

Can you suggest better language?  The receiver has to ingest BDAT segments when there are no valid recipients... the sender will place these segments in-flight before they know if there are valid recipients.  The receiver has to eat the full chunk, and then discard if there is no one to relay the data to.  I called the process of eating the bytes in flight and preparing for the next command "accept".

Greg V.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Feb 2006 17:07:33 +0000

On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote:
>
> Allowing multiple messages was not the intent.  Help me figure out why
> you see this as acceptable so I can fix it when I align the language
> with RFC 2920 :-)

>From the client point of view, as with normal pipelining you would need to
keep track of all the commands that you had issued but not yet received
replies to. The difference is that these commands & replies can relate to
multiple outstanding message transmissions. When the client receives a
reply corresponding to a BDAT LAST command, it performs the processing it
would perform after the reply to a <CRLF>.<CRLF> in trad SMTP (e.g.
marking the message as completed).

One thing to worry about might be RFC 1047 message duplication, but this
pipelining should not add any extra latency to the round trip between the
clientftinishing transmission of the message and receiving the server's
reply, so it should not make the problem worse.

> Can you suggest better language?

Ah, I had read "accept" as "give a success reply to" (as opposed to
reject). I suggest the following text for the paragraph about pipelining:

If the receiver-SMTP has declared support for the PIPELINING extension
[PIPE], the BDAT command MAY appear at any point in a pipelined group of
commands. That is, the sender-SMTP MAY send BDAT commands immediately
after the MAIL FROM and RCPT TO commands, and it is not necessary to wait
for the response to determine if there is a valid recipient. The
receiver-SMTP MUST be prepared to read and reply to BDAT commands even
when there are no valid recipients. As when pipelining after the DATA
command, the sender-SMTP MAY also send MAIL FROM and other commands for
the next message immediately after sending the BDAT LAST of the current
message. The sender-SMTP MAY use the NOOP command to introduce a
synchronization point.

And in the paragraph about BDAT failures:

A 250 response MUST be sent to each successful BDAT data block within a
mail transaction. If a failure occurs after a BDAT command is received,
the receiver-SMTP MUST read and discard the associated message data before
sending the appropriate 5XX or 4XX code. If a 5XX or 4XX code is received
by the sender-SMTP in response to a BDAT chunk, the transaction SHOULD be
considered failed and the sender-SMTP SHOULD NOT send any additional BDAT
segments. If the receiver-SMTP has declared support for command pipelining
[PIPE], it MUST be prepared to read additional BDAT chunks already in the
pipeline after the failed BDAT; it SHOULD reply to them with the same 5XX
or 4XX error as the preceding failed chunk.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES: VARIABLE 4 BECOMING NORTH OR NORTHEAST 4 OR 5. FAIR. GOOD.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Feb 2006 18:43:34 +0000

> > you see this as acceptable so I can fix it when I align the 
I've no problem at all with sending the next transaction pipelined 
with the end of the first.

> message. The sender-SMTP MAY use the NOOP command to introduce a

Why? Surely if you want to synchronize, you just wait for all 
outstanding commands to be completed? A NOOP at the end is just extra 
data.

Dave. (On the train via GPRS.)
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Feb 2006 19:07:04 +0000

On Thu, 23 Feb 2006, Dave Cridland wrote:
>
> > The sender-SMTP MAY use the NOOP command to introduce a
> > synchronization point.
>
> Why?

RFC 2920 says NOOP is included in the group of commands that can only
appear as the last command in a group so that it can be used as a
synchronization point. Perhaps I'm suggesting defences against bugs that
don't exist...

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING
VARIABLE 4. MAINLY FAIR. GOOD.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Feb 2006 19:19:39 +0000

> synchronization point. Perhaps I'm suggesting defences against bugs 

I think so.

The only way that would help is if the client couldn't track 
completion of the individual commands. In which case it's really not 
going to work anyway.

Dave.