While using the net/smtp package, I ran into some behavior that (I think) doesn’t quite comply with RFC 5321, or at least makes things a little confusing. The RFC defines reply codes that accompany server replies to client commands. These codes are categorized, based on their first digit, as Positive Completion replies, Positive Intermediate replies, Transient Negative Completion replies, or Permanent Negative Completion replies. Per the RFC, “SMTP clients SHOULD, when possible, interpret only the first digit of the reply and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only.” However, it also notes that, “An SMTP client MUST determine its actions only by the reply code, not by the text (except for the ‘change of address’ 251 and 551 and, if necessary, 220, 221, and 421 replies).”
In general, smtp.Client methods do not report the reply code directly. Instead, they return an error if a reply code does not match an expected result. The handling of these reply codes by smpt.Clients is inconsistent. In particular, Client.Verify returns a non-nil error only if a 250 reply code is received, and the documentation for that method notes that, “A non-nil return does not necessarily indicate an invalid address.” The “Specific sequences” subsection of section 4.3.2 of the RFC indicates that reply codes 250, 251, and 252 are all successful responses to VRFY commands. In contrast, the Client.Rcpt method, which does not document its interpretation of reply codes, returns non-nil errors for any reply code beginning with 25. This is presumably intended because 250 and 251 reply codes are normal and expected, but it means that there is no way for the caller to access the text that accompanies the 251 reply. It also means that there is no way for the caller to distinguish between 250 reply codes, 251 reply codes, 252 reply codes (which would not make sense in the context of a RCPT command), and server/extension-defined reply codes beginning with 25 (even though a server-defined reply code not beginning with 25 would produce an error).
It would be nice to be able to access the text of any non-250 reply to a RCPT command, but I understand if this is a feature request. At least, I think the documentation should note that any reply to the Client.Rcpt method that begins with a 25* reply code is treated by the Client as a reply beginning with a 250 reply code.