Misbehaving clients are never disconnected

[edeca]

It's possible to exhaust resources on the server in a number of ways:

• Connect and never send a valid command
• Connect and repeatedly send NOOP
• Connect and waste time in the SMTP transaction, e.g. send multiple HELO, reset,

Eventually Python will run out of file handles and exceptions will occur in code that tries to open any file, socket, etc.

[edeca]

Merge #146 fixes the case when clients do not send data.

Other cases need further consideration. One blunt method would be a time limit on the overall transaction. Slightly more clever mechanisms could time progress through each part of the SMTP transaction, count commands like NOOP etc.

[waynew]

It seems to me that the blunt approach would be a great first step.

If we tracked a misbehavior score on the clients somehow, and just start with a (configurable) time limit, then we could start adding other behaviors (e.g. repeated NOOPS, number of NOOPS per email/successful email, etc.)

Then I think there may be a convenient choke point where we can just check the client score, and if they've exceeded the limit then we can disconnect them.

There might be alternate approaches that also work! That's just the first thing that popped into my head 🙂

[cnicodeme]

I agree on these. I have a server that accepts a lot of connections per day, and too many stay open because of DOS like servers connecting to mine.

A combination of the following might help:

• Setting up a timeout for each command (independant for each/globally for the whole connection - which would solve the NOOP loop too)
• Counting and limiting the number of requests, allowing a certain amount (as a variable) for each command. (defaults to 3? - might be good to limit each commands separately, like VRFY could be used more)

This would greatly help!

[pepoluan]

-- this comment should've gone into the PR 😅 --