PaulS:
delay(wait); /* wait for a response */
If you are waiting for a response, shouldn't you then read the response? Or else remove the incorrect comment. Even better, remove the useless delay() calls.
Some [older] SMTP servers don't support pipelining (i.e. receiving a new command before the current command is responded to), and even for servers that support pipelining, some commands are in herently not pipelineable, so sending commands in quick succession without a bit of delay might be problematic (especially if the sketch is not handling server errors. It might be safer to keep some sort of delay.
Not reading the server response should not be a big deal and the receive buffer should just fill up with unread responses. Downside is of course it can't process server errors. I'm not sure how the Serial stack on the Arduino handles full buffers but if it follows general parctice it will just silently drop the new bytes.
I think the safer way (if reliability is an issue), is to replace the constant wait with a function call that loops to wait for client.available() > 0, and just read and discard the bytes beefore sending the next command. This ensures the server had responded, and to account for transient network delays that causes replies to come back more than the constant wait period.
I realized that I might be getting off topic here ...