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.
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOLE LUNDY FASTNET SOUTH IRISH SEA: EAST 4 OR 5, OCCASIONALLY 6 LATER.
SHOWERS, BECOMING WINTRY FOR A TIME. MODERATE OR GOOD, OCCASIONALLY POOR AT