Proxy can not handle common SMTP EHLO responses

[felixauringer]

I wanted to use the proxy to enable services (e.g. nextcloud) to send emails with our new James SMTP service which does only support XOAUTH2 / OAUTHBEARER.

James sends the following EHLO response:

250-<my domain> Hello <client hello> [<ip>])
250-AUTH OAUTHBEARER XOAUTH2
250-AUTH=OAUTHBEARER XOAUTH2
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 8BITMIME

The proxy inserts the additional authentication mechanisms which transforms the response above to the following:

250-<my domain> Hello <client hello> [<ip>])
250-AUTH PLAIN LOGIN
250-AUTH=OAUTHBEARER XOAUTH2
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 8BITMIME

The James response that sends the authentication mechanisms twice (one with equal sign and once with space) does not seem to comply with RFC 5321.
I sent an email to their mailing list asking for the reason for this behavior.
However, James is not the only email server behaving like this and postfix (at least some instances of it) behave the same.
We tested maybe a dozen email servers on the internet and maybe half of them behaved like James does.

As postfix is a very common email server, it would be nice if this proxy would support this kind of EHLO responses.
If this is something you would like, I could open a PR :)

[simonrob]

Thanks for reporting this. At the moment, the proxy only handles EHLO responses that fit the specification (there are multiple versions of this, including 1425/1651/1869, but broadly they are the same here). Postfix has an interoperability setting that enables the AUTH= version. Maybe James has a similar one?

[felixauringer]

I looked at the source code and James sadly does not have such a setting. But as they are not properly implementing the standard, it makes sense to change that. I will be advertising for that on the mailing list 👍