On Mon, Apr 26, 2004 at 05:22:19AM -0500, Edgar Lovecraft wrote:
> Tony Finch wrote:
> > On Mon, 26 Apr 2004, Edgar Lovecraft wrote:
> > > Also, if you are suggesting that your 'group' also
> > > contains the actual DATA of the message then your client is broken.
> > RFC 2920, section 3.1 paragraph 3
> > The actual transfer of message content is explicitly allowed to be
> > the first "command" in a group. That is, a RSET/MAIL FROM sequence
> > used to initiate a new message transaction can be placed in the same
> > group as the final transfer of the headers and body of the previous
> > message.
> Yes I know that but what he siad was this:
> "Imagine that I send (in one TCP command) all the commands in a group. It
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> doesn't *actually* say I need to wait for an answer."
Yes, that is what I said. By that I meant that you follow the rules for
group terminators.
> So I was properly stating that if his "all the commands in a group" refered
> to all MAIL FROM, RCPT TO, DATA, message content, and QUIT, then his client
> would be broken.
Agreed, according to the spec.
> He needs to clarify what commands he is including in his group definition
> as what I gather is that he meant if he sent the entire SMTP transaction
> including the actual message content in one group, not 2 or more as is
> required.
No, that's not what I meant. What I meant was that the group definition is
such that it doesn't say that the group as a whole is a synchronisation
element.
In fact, re-reading it, it doesn't define what a "group" is. What it says is:
| the client SMTP may then elect to transmit groups of SMTP commands in
| batches without waiting for a response to each individual command. [...]
| The [...] commands can only appear as the last command in a group [...]
| (NOOP is included in this group so it can be used as a synchronization
| point.)
It doesn't say what happens at the end of a group at all. What this means is
that according to the spec, it's possible, if you turn off Nagle, to send
off a new group (with correct termination), without waiting for responses
to the first group (with correct termination). Now, this may be silly, but
it seems reasonable for, say, VRFY...
eg.
| for(i=0; addresslist[i]!=NULL; i++) {
| smtp_write("VRFY %s\r\n", addresslist[i]);
| }
| for(j=0; j<i; j++) {
| vrfy_address[j]=smtp_get_code();
| }
where smtp_write() and smtp_get_code() are implemented with internally
buffered non-blocking I/O, but where a call to smtp_write() causes a
single write() to the socket, and the appropriate setsockopt has been
called. That bit of code conforms to RFC2920 as RFC2920 is written, but
not to the spirit.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
(Please use this address to reply)
