-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
net/textproto: does not accept multiline error message #10230
Comments
@DSpeichert, if you want to send a CL for this change, please add a test.
|
Change submitted: https://go-review.googlesource.com/#/c/18172/ |
CL https://golang.org/cl/18172 mentions this issue. |
I haven't seen anyone mention that Gmail's SMTP reply given at the top of this issue of a long message spread over multiple "550␣" lines is wrong, violating the SMTP RFC; only the last line should have a space after the 550, the rest having a minus sign. Shouldn't Gmail change? |
@RalphCorderoy I'm not sure how I got that quoted message back in March. I've ran another test and got a properly-formatted error message which I included in the unit test for this CL. At least now everything seems good on Gmail's side when it comes to following RFCs. |
Summary
(r *Reader) ReadResponse(expectCode int)
does not properly read all lines of a single error message (here's why: https://github.com/jnwhiteh/golang/blob/master/src/net/textproto/reader.go#L251).Use case
The above behavior causes a multitude of problems. In my use case case I use
net.smtp
to open a single SMTP session to Gmail MX server, and then I repeat multiple times (below is a gist of it) for every message I have in a queue for this server (to avoid opening & closing a separate connection for every message).:Assuming that a recipient's email address doesn't exist, Gmail would return a multiline 550 error message, like this one:
However,
err
returned byc.Rcpt()
would only have the first line.Following lines will be returned by
c.Reset
in the following iteration of the loop, line by line!This completely prevents me from reusing the connection, as there is no reliable way of flushing the remaining error message lines to get a "clean" smtp.Client. If
c.Reset()
doesn't do that, what will?Workaround
I have written the following patch which fixes the problem. It passes the current reader test for a multi-line message but there is no test for a multi-line error (and I did not write one yet). The logic seems correct and I have tested this with smtp.Client - the problem mentioned above goes away and
c.Rcpt()
correctly returns a multiline error and smtp.Client may be reused for another message.The text was updated successfully, but these errors were encountered: