ietf-smtp
[Top] [All Lists]

Re: BDAT, RFC 3030 protocol clarification?

2003-06-14 10:37:00


Keith Moore writes:
> my understanding was  that the client should not send BDAT commands
> unless it had received a 2xx response from MAIL and at least one of
> the RCPT commands.

Well, 1854 says sending DATA is okay, 3030 says BDAT and DATA are the
same, and AFAIK nothing says that in this respect the two are
different. IMO the successor to 3030 should say so.

The key difference is that DATA implements a two-stage state change while
BDAT does it in a single stage. So, although the semantics of the command
may be the same, the protocol interaction is very different.

> failure to do so could cause synchronization problems if the server
> then said 5xx in response to BDAT because it wasn't going to accept
> the message anyway.

> IMHO if a server is ignoring data in the TCP buffer when it claims to
> support PIPELINING, that server is broken and we shouldn't try to fix
> it in the spec. but if a server complains when a client sends BDAT
> for no valid recipients,
> I don't blame the server for that.

I suggest that if a BDAT-capable server receives BDAT, it SHOULD either
receive and discard the data, or else send its response and drop the
connection. Shouldn't need saying, but I guess it does not hurt.

I concur, but for a different reason: I don't like the implication that
a successful MAIL FROM and at least one successful RCPT TO means BDAT
will also be successful. It is entirely reasonable for a transaction to
success all the way up to the BDAT but fail at that point. In such a case
the implementation must be prepared to deal with the data attached to the
BDAT whether it likes it or not.

The rule should therefore be that a server which supports BDAT MUST honor the
state change implied by the command and deal with the attached data in some
way. Small amounts of attached data SHOULD be dealt with by accepting it and
discarding it. Large amounts MAY be dealt with by returning an error and shutting down the connection.

                                Ned