On Wed Mar 15 19:52:14 2006, Tony Finch wrote:
> > The REPLAY spec is currently weak in descibing the line between
a retry
> > and a replay. For example, the 555 response to MAIL would be
better as a
> > 455 that would cause the client to retry with a new transaction
(i.e. a
> > fresh <txn-id>). The corresponding situation with an improved
CHUNKING
> > would be an unexpected 355 response. The problem here is what
happens if
> > the client has pipelined some data after the erroneous command?
>
> I don't follow all of this.
I'm worried about transaction ID collisions, which I suppose are
most
likely to be caused by a client going insane (unless someone
manages to
successfully attack a client's txn-id generation algorithm). At the
moment
the replay spec makes this problem detectable by the 555 response
to MAIL
(though I plan to change this to 455). Checkpoint assumes this
situation
is OK since it looks to the server like a normal transaction
restart.
Right, gotcha.
You're saying that in the case where a transaction id collides, or,
for some reason, the client thinks it's sending the transaction anew
instead of resuming, then there's a problem here that 1845 missed
because of the lack of pipelining.
A solution is to state that use of TRANSID= denotes either resumption
or new, and the client must wait for the response unless it knows
what it will be in advance (by having previously issued a REPLAY
command and examined the response). Then add an additional parameter
which indicates to the server that the TRANSID is expected to be
fresh, and if not, to reject this transaction. (Perhaps a
TRANSID-NEW assertion parameter)
This means that RFC1845bis (ie, this spec) clients use:
MAIL FROM:<foo(_at_)example(_dot_)org> TRANSID=xyz TRANSID-NEW
for starting a new transaction, and do not need to synchronize,
whereas RFC1845 clients don't use the additional parameter, but do
synchronize.
That handles the collision case, but the case where two clients
simultaneously attempt to resume a TRANSID, is much more difficult to
deal with.
You could define REPLAY as an assertion that subsequent usage of this
TRANSID in a MAIL command in this session is a resumption, which
prevents accidental duplication, and then you merely have to deal
with failing DATA, BDAT, and BURL commands if a TRANSID is resumed by
another session. (And, one assumes noting this in logs or to the
sender as a possible bug or security issue.)
Dave.
--
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw