On Fri, Nov 22, 2002 at 06:22:53PM -0600, Adam Heath wrote: > In case it hasn't been mentioned, one could use sequence numbers, ala tcp.
You need to keep track (at both ends of the link) of the last sequence number sent. Or, if you allow emails to be sent from multiple hosts, you need to keep track of the last sequence number from each host. This is very much similar to TCP. However, unlike TCP, there is no concept of a "connection" or "session" (unless you create one), so sequence numbers have to be kept indefinitely. hmmm... come to think of it, session tracking might be an interesting idea. sessions could also keep track of environment variables and/or CWD. eg (one email by line, server is S, sender is C): C --> S: open session S --> C: session X is open C --> S: session X command 1 execute "cd /tmp" S --> C: session X command 1 output was "" (OPTIONAL) C --> S: session X command 2 execute "rm *" S --> C: session X command 2 output was "" (OPTIONAL) C --> S: session X command 3 close S --> C: session X is closed, session text was "..." OR if received in duplicates or out of order: C --> S: open session S --> C: session X is open C --> S: session X command 2 execute "rm *" S --> C: session X command 2 received out of order; delayed. (OPTIONAL) C --> S: session X command 1 execute "cd /tmp" S --> C: session X command 1 output was "" (OPTIONAL) C --> S: session X command 1 execute "cd /tmp" S --> C: session X command 1 received duplicated. (OPTIONAL) S --> C: session X command 2 output was "" (OPTIONAL) (after n hours) S --> C: session X is closed, session text was "..." C --> S: session X command 3 execute "cd /tmp" S --> C: session X command 3 session was closed. (OPTIONAL) Except for the optional warnings that something has gone wrong, I think this is very similar to TCP (except only one sequence per message is all thats really required). You just need to make sure it is not possible to replay the open session command; this could be done by having the session number (X) a sequence number that is always incremented by one. So even if a session open is replayed, the session number would be different, making it useless to replay the commands. I think the worst an attacker could do with this protocol would be to delay the last commands until after the session expires. This is effectively a Denial-Of-Service attack, which is possible even with ssh (eg. pull the plug out of the network), and nothing you can really do about it. This effectively means it is a challange/response protocol like somebody else suggested, but the challange response is only required once per session. Any errors are entirely my own ;-). -- Brian May <[EMAIL PROTECTED]>