-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
Caught connection error in SMTP (localhost:1587) : <class 'ssl.SSLError'> with message: ac.robinson.email-oauth2-proxy #121
Comments
I got exactly this error yesterday. Changed |
Setting I suspect this may be related to #118, though don't have any particular suggestions beyond the ones listed there as I cannot replicate this myself. If you can isolate the issue and find a way to replicate it reliably that would be really helpful. |
I wouldn't call |
It is not technically a timeout in that sense (it does not measure time as such), but it is used as a way to to abort connections where the SSL handshake seems to be failing. SMTP connections prior to STARTTLS shouldn't be affected because they are marked as an insecure connection until the STARTTLS command is received. Only reads/writes relating to the handshake are included when incrementing this counter. |
I have not set When I get the error reported here, the log message is not printed. But clearly I am still seeing this issue. Any further diagnosis I can do? |
It may just be that your particular SMTP configuration is requiring more negotiation to complete the handshake. I haven't seen anywhere near as many as 2^16 (65,536; the default maximum that is used as a way to abort failed attempts) calls to the handshake function during a successful attempt, but @nbdd0121 is correct that this value is the source of the error you are seeing. What happens if you increase |
And/or we could just see how high the count could get. If I were to set it to say, email-oauth2-proxy/emailproxy.py Line 800 in a26edc6
|
You could add the count ( |
Interesting variation in counts:
|
I would guess that the ~12k ones are during STARTTLS negotiation, and the subsequent one is in a Regardless, these are all well below 65,536. What is the value when you get the error? |
I just had one hit 68,010 and yet another at 67,473. Both were followed immediately by a value of 1. |
Seeing additional handshakes (the Could you keep track of the values you get over a few days and suggest a new higher maximum? |
Slow/unreliable connections can reach `MAX_SSL_HANDSHAKE_ATTEMPTS` before the handshake has completed; this allows more time for completion in that case, but still catches misconfigured connections. See #121.
Reading through the other issue you have open, I realised that poor network connectivity might be part of the issue here – on a slow or unreliable connection, it could easily be possible for the handshake method to be called enough times to unintentionally pass the threshold. So, the issue-121 branch adds a 1ms delay each time this method returns in a "want read" or "want write" state. This should have essentially zero impact on fast connections, but does resolve the issue for me on simulated slower or intermittent networks. Please could you try this branch? |
Sure. What exactly is it that is happening anywhere from 1 to over 64K times? Is it an operation that should only ever happen once under ideal conditions and that it takes over 64K times sometime is indicating some kind of resource constraint that requires sometimes over 64K attempts to finally succeed? |
The proxy needs to begin the TLS handshake and wait for it to complete, but has no knowledge about the underlying protocol that is being used. The handshake duration can be variable, and it also requires negotiation with the remote server (i.e., network communication). For this reason, the handshake method is designed to be called repeatedly until it does not throw an error. See the documentation. Please try the issue-121 branch, which adds a 1ms delay between failed handshake attempts. |
With the 1ms delay:
Certainly seems better! |
That looks much better! Please let me know if you encounter the issue again, but if not I'll merge this branch in the next week or so. Thanks for the help in identifying and resolving this. |
0ef9f9e further improves this by using |
|
This seems to be working well (and similarly in my own testing). I plan to merge this branch in the next week or so unless any issues arise. |
I frequently get:
But this only happens a while after I have successfully authorized an O365 account and have successfully sent mail through it so it doesn't seem like it could/should be #14. And then a while later it might go back to being successful again, but then complaining again:
Any ideas?
The text was updated successfully, but these errors were encountered: