You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hm. Tricky! I don't think sending a DATA END is appropriate there either, because the message sending is incomplete, so I think it would be expected to simply drop the connection instead of cleaning up nicely - the server will deal with it. Unless you are proposing to wait until the send is finished?
No, I think you're right, at present I've added some code to my copy that sets inData to either true or false in the data() method, and if true it skips sending the QUIT and just closes the connection.
I think that's the right action, as part delivering a partial email is definitely not in spec.
I'd suspect it would apply to any SMTP command, not just DATA, it's just that DATA is the one most likely to be in progress if a send takes more than a few milliseconds. That said, DATA (maybe AUTH?) is the only one that involves more than one call to fwrite, which is about all the granularity we can do.
Problem description
If my code is killed (e.g. with a SIGTERM), then the destructor calls smtpClose() which then calls smtp->quit().
But if data is being sent, then the quit comment is ignored, and what actually happens is that the remote end eventually times out with a 421.
I think we need a status to indicate that we are in the DATA mode, and send the DATA END before the QUIT?
Or better, we need a status to indicate that we are in data and we need to return an error to the caller, as we don't want to send a truncated email.
The text was updated successfully, but these errors were encountered: