AUTH PLAIN from Grafana not recognised: “Proxy config file entry missing for account"

[aldosr]

I'm configuring my Grafana instance (v10.4.2) to send emails via SMTP, using your proxy to authenticate with an Office 365 account through OAuth2.

I'm running the proxy using the Docker version deployed in a Kubernetes pod. Everything works correctly when I test the connection manually, both using the non-Dockerized version locally and by connecting directly to the SMTP server with openssl and AUTH LOGIN.

However, when Grafana attempts to send an email, I receive the following error:
Proxy config file entry missing for account

The smtp_user configured in Grafana is identical to the one used in my successful manual tests.

The only notable difference I've observed is that Grafana appears to use AUTH PLAIN, whereas my manual tests use AUTH LOGIN.

Could this mismatch in authentication method be the reason for the error?

emailproxy.log

emailproxyconf.txt

[simonrob]

There should not be any difference in behaviour between authentication methods, so I suspect there is some difference in how Grafana sends the login details that is causing this issue.

I'd first verify this by double-checking that AUTH PLAIN works when you log in manually via OpenSSL, then disable credential censoring and look at what values are actually being sent. Credentials for the PLAIN method should be in this format.

[aldosr]

I suspect there is some difference in how Grafana sends the login details that is causing this issue

Thanks, I suspected the problem was Grafana, but couldn't figure out how to find what it was passing to the proxy.

When I test manually using openssl and construct the AUTH PLAIN blob like this:
printf '\0my_mail@example.com\0dummy' | base64 -w0
It works without issues.

I then disabled credential censoring in Grafana. Here's what I found in the logs:

SMTP (...) --> b'AUTH PLAIN `base64withrealcreds\r\n'
SMTP` (...) --> b'AUTH PLAIN base64withrealcreds\r\n'

After decoding the base64 string, I get:

my_mail@example.com
dummy

This seems structurally correct, but I’m wondering if the newline or formatting differences might be causing the issue.

Any ideas?

Edit:
This is what I got when base64-decoding with Python:
[b'', b'my_mail@example.com\n', b'dummy\n']

[aldosr]

I can confirm that the issue was indeed caused by trailing newlines in the credentials.

After modifying the decode_credentials function to include the following lines:

clean_user = bytes_username.decode('utf-8').strip()
clean_pass = bytes_password.decode('utf-8').strip()
return clean_user, clean_pass

(and removing the original return statement), I was finally able to get Authentication successful.

Do you see any potential issues with this change, or would it be safe to open a PR with this fix?

[simonrob]

Thanks for following up – I'm glad you were able to find the issue.

Re: PR – while that fix will work for your local use, I wouldn't be able to merge it because the specifications explicitly state that these values can contain any UTF-8 encoded Unicode value except the \0 separator (i.e., \n, while probably highly unlikely/unusual, is still technically valid). So this is something that needs to be fixed on the Grafana side longer-term.

[aldosr]

Thanks for the clarification.

I'll open an issue on the Grafana side and, in the meantime, I'll use my changes for our use-case.

Thank you very much!