Evaluate handling of non-RFC compliant server responses.

[wneessen]

I'll check if I can implement some way to work around this non-compliance on the server end.

Originally posted by @wneessen in #463

There seems to be some SMTP servers, that do not send proper status codes (i. e. send a "0" instead of "221" as response to an "QUIT" command). Let's see if we can work around this in some way.

[james-d-elliott]

I think the ability to provide a map or interface which uses server hostnames as keys and maps bad status codes with good ones for particular commands. This would allow deterministic behavior but allow implementers to figure this out and make informed decisions. It might be problematic to work around this by default as it may hide errors that should be handled depending on how it's done (introducing legitimate bugs).

It should also be noted that qq.com has a history of sending long sequences of escape characters along with its status codes, as well as many other really difficult to work around issues.

Maybe something along the lines of the following JSON representation:

{
    "qq.com": {
        "commands": {
            "QUIT": {
                "equivalentStatusCodes": {
                    "0": "221"
                }
            }
        }
    }
}

[wneessen]

Good suggestion @james-d-elliott. That might be something to evaluate.

I dug a bit deeper into the issue and you are right about the "sequences of escape characters". The issue is not that qq.com is not sending the correct status code, but they are sending a 16-byte binary sequence between the "QUIT" and the "221 Bye." which causes the textproto reader to fail.

I can reproduce this behaviour when I send a simple "RSET" after the "EHLO" on a TLS-secured connection (non-TLS is fine).

The hex dump of the response looks like this:

00001400: 4954 4d49 4d45 0d0a 3235 3020 4f4b 0d0a  ITMIME..250 OK..
00001410: 0000 001a 0000 000a 0000 0000 0000 0000  ................
00001420: 3232 3120 4279 652e 0d0a                 221 Bye...

And the 0000 001a 0000 000a 0000 0000 0000 0000 sequence is read by textproto and fails as "short response".

[james-d-elliott]

Is the byte sequence a TLS handshake? It didn't look like it to me but it's been a while since I last looked.

[wneessen]

I don't think it's a TLS handshake. That's too many zero bytes for that. I've asked the same question on the mail-op mailing list and people were able to reproduce and classified it as "junk".

Out of curiosity I've contacted the Tencent postmaster@ address. I don't really expect a response, but who knows.

It would be easy to work-around if I could tell net/textproto to ignore any non-ascii character. Maybe at some point it would make sense to implement our own textproto version that gives us more freedom. In any case this issue seems to be very "qq.com" specific.

[wneessen]

Hi @james-d-elliott et all,

I finally found some time to look into this and came up with this: https://github.com/wneessen/go-mail/tree/feature/464_smtp-error-registry

It implements a ErrorHandlerRegisty interface, that allows the implementer to assign custom error handling methods for specific hostname/command combinations. I feel this provides lots of flexibility while being easy to implement for any kind of server reponse error (based on the connected host and the command that throws the error).

For our "smtp.qq.com" example, one could handle the error like this:

type QQMailQuitErrorHandler struct{}

func (q *QQMailQuitErrorHandler) HandleError(_, _ string, err error, conn *textproto.Conn) error {
	var tpErr textproto.ProtocolError
	if errors.As(err, &tpErr) {
		if !bytes.Equal([]byte(tpErr.Error()[16:]), []byte("\x00\x00\x00\x1a\x00\x00\x00")) {
			return err
		}
		_, _ = io.ReadFull(conn.R, make([]byte, 8))
		return nil
	}
	return err
}

func main() {
	qqMailQuitErrorHandler := &QQMailQuitErrorHandler{}

	client, err := mail.NewClient("smtp.qq.com",
		mail.WithPort(465),
		mail.WithSSL(),
		mail.WithDebugLog(),
	)
	if err != nil {
		log.Fatalf("failed to create client: %s\n", err)
	}
	client.ErrorHandlerRegistry.RegisterHandler("smtp.qq.com", "quit", qqMailQuitErrorHandler)

	ctx, cancel := context.WithTimeout(context.Background(), time.Second*10)
	defer cancel()
	if err = client.DialWithContext(ctx); err != nil {
		log.Fatalf("failed to dial client: %s\n", err)
	}
	defer func() {
		if err := client.Close(); err != nil {
			log.Fatalf("failed to close client: %s\n", err)
		}
	}()
	if err = client.Reset(); err != nil {
		log.Fatalf("failed to reset client: %s\n", err)
	}
}

On my end this tests fine:

2025/07/11 15:24:17 DEBUG: C --> S: EHLO typhoon
2025/07/11 15:24:17 DEBUG: C <-- S: 250 newxmesmtplogicsvrszc13-0.qq.com
PIPELINING
SIZE 73400320
AUTH LOGIN PLAIN XOAUTH XOAUTH2
AUTH=LOGIN
MAILCOMPRESS
SMTPUTF8
8BITMIME
2025/07/11 15:24:17 DEBUG: C --> S: NOOP
2025/07/11 15:24:17 DEBUG: C <-- S: 250 OK from 37.85.224.55 to newxmesmtplogicsvrszc13-0.qq.com.
2025/07/11 15:24:17 DEBUG: C --> S: RSET
2025/07/11 15:24:17 DEBUG: C <-- S: 250 OK
2025/07/11 15:24:17 DEBUG: C --> S: QUIT
2025/07/11 15:24:17 DEBUG: C <-- S: 221 Bye.

We could add example handlers for common errors like this in the Wiki so everybody can use them and contribute if they find similar behaviours with other servers.

Any comment/suggestions are welcome!

[wneessen]

This has now been merged to HEAD.