Ok, I read the miniproject description but spell it all out for me one more time.
The communication between the client and server occurs over TCP. While TCP guarantees reliable delivery, it does not necessarily guarantee that data sent at the same time on the client will be received at the same time on the server (and vice versa). For instance, if the client sends the string "HELO abc12\n", the string can be chopped into three packets delivered separately at the servers, containing "HE", "LO ", and "abc12\n". You will most likely want to write a "collect_input" function that performs recv() operations in a loop until a whole message has been received, instead of trying to parse the first packet (containing only "HE") received.
As with all network protocols, you must code defensively and do something reasonable even in the presence of bad inputs. Part of the assignment is to decide what is reasonable. If you find yourself stuck, feel free to consult course staff.
Because of the way the filesystem is structured and because of the sector-based atomicity of file writes, you may not easily notice an interleaving of messages, even if you neglect to perform your file operations without any synchronization. If you write a proper test client that writes large messages, however, you should be able to see that concurrent accesses to a file without a lock can cause messages to be interleaved. You should perform your file operations as part of a critical section to avoid such interleavings.
How will my code be evaluated?
Your code will be evaluated not only for correctness but for elegance, maintainability, and the thoroughness of accompanying test code. Please read the preceding sentence carefully, and make sure your submission excels at all cited criteria.
Are commands case-sensitive?
No. The HELO command may be provided as helo, HELO, or hElO (or any of the other possible ways to capitalize it).
What happens if the client never sends a HELO?
The client must send a HELO in order to send other commands. More heavyweight SMTP serves often verify the HELO using DNS and reverse DNS to check the identity of a client.
What happens if the client sends two HELOs?
You may optionally send a 503 error to the client. You're not required to send this message, but if you want to detect this case, you can use a message like:
503 Error: duplicate HELO
Does HELO need to come in any specific order relative to MAIL FROM and RCPT TO? Do the other commands need to come in any specific order?
Your commands should come in the order HELO, MAIL FROM, RCPT TO, and DATA. If the commands come out of order, you can generate error messages like:
503 Error: need XXX command
Does DATA need to come in any specific order relative to other commands?
DATA must come after HELO, MAIL FROM, and RCPT TO.
How do we handle extra whitespace in the HELO, MAIL FROM, and RCPT TO commands?
Commands may contain extra whitespace around valid tokens. For instance, there may be two or more spaces after the colon in MAIL FROM or RCPT TO. There may also be trailing spaces after the argument. It is not acceptable to allow whitespaces in email addresses or hostnames.
Leading spaces, or spaces before the colon are acceptable, but will not be tested. Do not worry about adding extra logic to handle them.
Are multiple RCPT TO commands allowed? If so, is email delivered multiple times, or once?
The RCPT TO command may be specified multiple times. Doing so will result in multiple "To:" headers in the delivered mail, but the mail will only be delivered once, and will be assigned one number.
When a client sends two emails in one session, which commands are for both emails?
The HELO command will carry over between messages. No other command persists after a message is delivered.
Where do the "From:" and "To:" lines in the mailbox example in the README come from? I see that client.py sends these lines as well. Where do these lines come from?
In a standards-compliant environment, these lines are provided by the client. In your implementation, we ask that you output the "From:" line with the address corresponding to the address sent in MAIL FROM, and one "To:" line for each RCPT TO command.
If the client provides these lines, they should not be treated special. In the above mailbox example, the message body is separated from the server-specified headers by one blank line. If the client provides these lines, they simply appear in the message body.