-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
Exception when trying to log in to SMTP #1575
Comments
@martinjanda Could you try replacing 234 with 334 on the line below? The 234 looks like a typo, I don't recognize it as a valid smtp response code. 334 means "continuation data", which this is. Other lines above/below are also checking for 334. |
Thank you. It fails faster, but error in log of snappymail is the same:
|
@martinjanda i suspect the smtp client code is assuming the auth handshake is finished after the first hash. it is expecting 235 "auth ok" when it is getting "334 [hash2]". the code may be based on cram-md5 (with fewer roundtrips). for comparison, see the code in imap client, which does another write & read before verify: i'm not familiar enough with this code base or php to make changes (in a reasonable time frame). |
When i'm reading RFC 5802 correctly, there should only be one 334 (server challenge) response. |
https://datatracker.ietf.org/doc/html/rfc5802#section-5 has this as example:
This is a session of mutt authenticating to mox (localserve):
And this is the same session, but with the base64 of scram decoded so it looks more like what we're seeing in the RFC:
So even before the first message from the client, the server will have sent the first 334. It may be possible for the first client message after the AUTH command to be sent immediately as parameter in the AUTH command (SASL has a concept mode for that, I believe called immediate reply/response. IMAP has a capability SASL-IR that announces server support for it, but a quick search doesn't turn it up for SMTP). Btw, I think SASL libraries are commonly designed/intended to be used without the protocol handling code (i.e. the imap/smtp clients/servers) knowing about the details of the SASL exchange. The SASL library would have an interface (API method) that indicates that there is another line to write (to the server). So as a client you could implement the sasl authentication as a loop that reads the next line from the sasl object, writes it to the server, then reads a (continuation/success/failure) line from the server. Those libraries would also do the selection of the authentication mechanism (plain, cram-md5, scram-* variants). This doesn't always work that well in practice, mox just handles SASL itself in its imap and smtp server. |
I couldn't find the following in the RFC nor SMTP implementation So i assumed that "server-final-message" was equal to 235. SMTP 334 response is the "Server challenge". the text part contains the Base64-encoded challenge SMTP 235 response is "Authentication succeeded" As the RFC 5802 "server-first-message" contains data for the challenge (nonce, salt, iterator). But the "server-final-message" has a challenge for the client to verify.
|
Thanks to:
SCRAM is more and more used and replaces old/unsecure CRAM-MD5/DIGEST-MD5. Commits: |
Describe the bug
I get PHP Exception in log, when trying to log in to SMTP. In admin GUI I get Timeout.
I've tried no TLS, STARTTLS SSH/TLS with the same exception.
I'm not sure if this is a bug or if I'm doing something wrong.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Success log in to SMTP. User and pass works fine in Thunderbird etc.
Please complete the following information:
Debug/logging information
Log from mox server:
The text was updated successfully, but these errors were encountered: