You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am building a program that relies on an SMTP status code being returned after a call
to RCPT over SMTP, and the go net/smtp buries this result with an underscore variable,
and the Rcpt function returns nothing on success, instead of the SMTP status code it
could return to be more useful:
http://golang.org/src/pkg/net/smtp/smtp.go line #240 (at time of writing)
Is there any way I can get the SMTP status code from a RCPT call another way?
Looking for one of these: http://www.greenend.org.uk/rjk/tech/smtpreplies.html
RCPT will typically either return 250 (okay) or 550 (no such user).
The text was updated successfully, but these errors were encountered:
As Rcpt() uses a textproto.Conn with a ReadResponse() expected code of 25, the codes for any response other than 250 or 251 (or 25*) are available in the returned error's Code field. It may be this would suffice for the original requester's use case. It is not possible to determine whether a 250 or 251 code was received though currently. But the importance of knowing which 25* code occurred is probably low. Their meanings are similar (accepting delivery).
If we wanted to make the response code available to callers, I wonder if adding a field to the Client struct would work. The field could contain the last received response code as responses are read. This would be as opposed to adding a new RCPT function that returns the code, or changing Rcpt()'s return value which I believe would not be acceptable.
Would adding such a field constitute a feature? I see a comment in smtp.go saying the package is frozen.
Yeah, frozen also means we don't have the bandwidth to maintain this or even review code. I recommend you find & contribute to one of the existing smtp forks on Github, or start your own.
I'm going to close this since the package is frozen as of Go 1.8. Sorry.
by czaries:
The text was updated successfully, but these errors were encountered: