Authentication MS365 Problem - compatible client secret
SMTP email proxy and relay server
Brought to you by:
graeme_walker
Menu
▾
▴
#130 Authentication MS365 Problem - compatible client secret
Hello,
We have set up the email relay with Microsoft 365 OAuth2 with tokens according to the instructions in your project. We use the .auth file to store the credentials. For MS365, we regularly generate a new token and update it.
However, we are now experiencing problems with authorization on the MS server. The following errors are displayed.
emailrelay: 20260213.170251.540: info: smtp client error: smtp error: cannot do authentication required by remote server (LOGIN,XOAUTH2): check for a compatible client secret
emailrelay: 20260213.170251.543: info: failing file: "emailrelay.10316.1770998570.2.envelope.busy" -> "emailrelay.10316.1770998570.2.envelope.bad"
emailrelay: 20260213.170251.553: error: forwarding: smtp error: cannot do authentication required by remote server (LOGIN,XOAUTH2): check for a compatible client secret
What have we done wrong here? Do you have any ideas?
regards,
Michael
FYI: we use Version 2.4.1
Does the secrets file look properly formatted with a "client oauth" line? What happens if you just do another token update? Or use a text editor to add a blank line to the file?
You should check whether your update script does an atomic update to the emailrelay secrets file, typically by writing to a new file with a temporary name and then renaming it. Otherwise there can be a race condition where emailrelay sees the file before it has been fully updated.
Hello,
In the ermailrelay.auth file, we have a line with the following structure, which is assigned a new token by the task scheduler every 45 minutes. The token is generated by the ps1 script.
client auth:b name@domain.com DHFUAZDH....
Every time the taks is running, a new token is generated and the secret file ist updated.
We even created a blank file with a blank line an without it. The result is always the same.
Unfortunately, yesterday SPAMHAUS has listed our IP as a "spammers" and currently refuses to remove us from their blacklist. Could this be also an issue?
regard,
Michael
That should be "oauth:b", not "auth:b".
The idea of adding a blank line was just to update the file timestamp. If that made no difference then your problem is not a race condition on the file's contents.
The error message ("check for a compatible secret") comes from emailrelay when first talking to the MS server. It is unlikely that MS will check with spamhaus at that point.
Sorry, my mistake. Actually, "oauth" is entered in the file.
The token is converted into base64 and over has over 2800 characters. Can this be a problem?
The immediate problem is that emailrelay cannot find a suitable secret in the secrets file. The MS server has said that it can authenticate with two mechanisms, LOGIN and XOATH, but emailrelay cannot find a plaintext password (for LOGIN) or an OAuth token (for XOAUTH) in its secrets file.
There are no line length limits in reading the secrets file. Any parsing errors will be logged in the emailrelay log file and you can find those by searching for the secrets filename (typically "emailrelay.auth"). You could also search the logs for "invalid secrets file" and "cannot read secrets file".
Also, you should also "re-reading secrets file" some time after the secrets file is updated. As a sanity check you should edit the file with notepad or whatever and look for that message in the log file.
Also check that the "client oauth" line only has four space-delimited fields. A fifth field would be interpreted as a client selector and that in that case the secret would be ignored with nothing in the log file.
The secret file has only 4 fields for any entry. We have a "server plain" entry and one "client oauth:b name@domain.de ZETUDFTG887...." entry. I cannot see the error in here.
Maybe our configuration in the batch file isn't correct? it worked on port 25 before. Can you see any failures?
Last edit: Michael J 2026-02-14
I think I got it. I deleted the ":b" from the "oauth" parameter and the Connection was successful now. I will continue to monitor the behavior and then provide feedback on whether this was the final solution.
Thank you for your help so far.
Ah yes, in v2.4 the ":b" suffix (indicating base64 encoding rather than xtext) is only supported for "plain" password, not "oauth". I will work on improving the warnings in this area.
So to use the latest version of EMailrelay do we have to exchange the exe files an put ":b" to the secret files again?
Another question: We use the software to forward Mails from many different devices like inverter, printers, iot devices etc. For now we had for each device a different mail address like dev1@domain.com oder mymail@iot-domain.com.
As the mails are forwarded to MS365 the service user in the secret file is sending the mails.
Is there a secure way to continue using the existing device email addresses without having to create countless mailboxes in 365 and give the service user the “send as” right for them?
Do you have any better idea?
In 2.6 the ":b" decoration on "oauth" is parsed out (unlike 2.4), but ignored.
This whole area is a bit confusing because there might be a 'native' encoding of a token, like ASN.1-BER or UCS-4, which is then nearly always base64-encoded as a convenience so that it can be presented on a web page and manually copied into a configuration file. In principle the service provider's chosen presentation-layer encoding could be recorded in the secrets file with an "oauth" suffix (perhaps ":u" for uuencoding) and then emailrelay could un-encode it into its opaque native form and then re-encode into base64 for the SMTP AUTH command. But in practice tokens are always presented with base64 encoding and the native form is unlikely to be compatible with the secret file's printable ASCII, so it is reasonable for emailrelay to ignore any "oauth" suffix and just copy the value in the secrets file straight into the SMTP AUTH command.
The reason you didn't get a warning for "oauth:b" is that the "type" field in the secrets file can be the name of a hash function used for CRAM-XXX authentication, but the set of usable hash functions is only available at run-time. The secrets file parsing code is quite liberal in that regard because you don't want the parsing to fail completely just because a particular hash function is no longer available. CRAM authentication is deprecated nowadays so for future releases I will be able to tighten up the parsing and only support CRAM-MD5 for backwards compatibility and drop CRAM-SHA256 etc.
As to your question, you can use a "--filter" script to examine the submitter's IP address (stored in the envelope file's "Client" field) or the EHLO id (in the content file's top-most Received header). Then edit the "From", "Sender" and "Reply-To" headers in the content file and/or the "From" address in the envelope file to identify the originator. (There is also a "MailFromAuthOut" field in the envelope file to change the "MAIL ... AUTH=..." id but I'm not sure that will help you at all.)
Service providers have rules to stop email spoofing, so you might find that MS365 requires the "From" header and the SMTP "From" address match the authentication id. If you can't even set the "Sender" or "Reply-To" headers freely then you will have to add your own header or edit the message body.
Thaht worked great, Thank you.