net/smtp: func Rcpt buries SMTP response code

[gopherbot]

by czaries:

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).

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-none.

[horgh]

It is still the case today (Go 1.8) that the Rcpt() function does not return the specific SMTP response code. The function returns only an error.

According to RFC 5321, the RCPT command can return one of these codes:

Success: 250, 251

Error: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555

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.

[bradfitz]

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.