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

Socket timeouts #14

Open
drkhunter opened this issue Apr 25, 2018 · 4 comments
Open

Socket timeouts #14

drkhunter opened this issue Apr 25, 2018 · 4 comments

Comments

@drkhunter
Copy link

Hey again,

I'm trying to implement timeouts on the server sockets as detailed in rfc5321 4.5.3. Sizes and Timeouts. I don't think it needs to be much cleverer than a minute between commands. I was hoping adding a timeout to the socket would be enough to kill the client but that doesn't work. Any ideas?

@TheFox
Copy link
Owner

TheFox commented Apr 25, 2018

RFC 5321 isn't supported at all, yet. This would mean that we also have to implement all other core feature of RFC 5321. Not even RFC 821 is yet fully implemented.

What to you want to achieve with timeouts for the client?

@drkhunter
Copy link
Author

At the moment if you telnet into the smtpd it holds open the socket for as long as the server or client doesn't timeout for any other reason. I'd like to be able to timeout the client connection after a few minutes of inactivity and close it much like a postfix smtp server does.

I'm guessing more clients connected like that would cause unwanted CPU or memory usage.

I appreciate this is probably far beyond where the project is right now.

@drkhunter
Copy link
Author

RFC 821 was obsoleted by RFC 2821 and then RFC 5321. Which RFC are you working toward, for reference?

@TheFox
Copy link
Owner

TheFox commented Apr 25, 2018

I started with RFC 821, see README.md.

I appreciate this is probably far beyond where the project is right now.

Correct. I would rather finish implementing RFC 821, then RFC 2821, instead of implementing some features from RFC x and then some features from RFC y, and so on. I don't want to go to the next RFC when still the previous isn't fully implemented yet, although we already did that (as you can see in the readme).

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