Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sigterm when in DATA state causes QUIT to fail #2994

Open
Stevehans opened this issue Dec 12, 2023 · 3 comments
Open

sigterm when in DATA state causes QUIT to fail #2994

Stevehans opened this issue Dec 12, 2023 · 3 comments

Comments

@Stevehans
Copy link

Stevehans commented Dec 12, 2023

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.

@Synchro
Copy link
Member

Synchro commented Dec 12, 2023

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?

@Stevehans
Copy link
Author

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.

@Synchro
Copy link
Member

Synchro commented Dec 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants