net/smtp Client.hello() returns a single error and drops the ehlo error entirely

[Matthew Altman]

https://github.com/golang/go/blob/master/src/net/smtp/smtp.go#L76-L79

This method can make two distinct SMTP calls. First an EHLO and then a HELO.

If the EHLO fails it attempts HELO. However, if the connection was closed remotely after EHLO the HELO will of course also fail but the error message returned will be a simple EOF from the HELO and the real response will be dropped.

This can be duplicated by sending to a postfix smtp-sink with the flag -Q EHLO,HELO   which returns a 4xx response and disconnects.

Since two separate calls are made, maybe it would make sense for this method to return two errors? Or perhaps a single composite error?

[Ian Lance Taylor]

I suggest that if EHLO returns a non-nil error and HELO returns an
EOF, then the hello method should return the EHLO error.

That said, does this case actually happen in the real world?

Ian

[Matthew Altman]

I believe it can. MTAs are highly configurable to return any sort of errors and/or disconnects on various conditions, thus the postfix smtp-sink capabilities to test out all of those settings, and that's how we encountered this issue.

Matthew Altman

Sr. Software Engineer

[will....@sendgrid.com]

The handling outside of a HELO,HELO appear to work correctly.  Setting the Postfix smtp-sink to return a soft bounce on DATA, for instance, presents to issues whatsoever.  Just HELO,EHLO.

Here's the full command line for the Postfix sink:
sudo /usr/sbin/smtp-sink -Q EHLO,HELO -u root -v 0.0.0.0:25 40

[Matthew Altman]

Should I perhaps create a github issue to address this?

[chris...@igneoussystems.com]

On Friday, July 1, 2016 at 2:16:24 PM UTC-7, Ian Lance Taylor wrote:

I suggest that if EHLO returns a non-nil error and HELO returns an
EOF, then the hello method should return the EHLO error.

That said, does this case actually happen in the real world?

YES this happens!  And it is really annoying that the standard library STILL eats and discards the real error.

For me this happens when connecting to smtp-relay.gmail.com:25 or smtp-relay.gmail.com:587

The first error from  EHLO is "421 4.7.0 Try again later, closing connection. (EHLO) v128sm135072ywf.1 - gsmtp"

The second error from HELO is "EOF" which makes sense because the server told us it was "closing connection"

So all a client sees is EOF with no further diagnostic information.