For many years I’ve been enjoying very performant and stable e-mail service provided by Google’s “G-Suite” while Google’s been enjoying sniffing through all my organisation’s users e-mail communication in return. Obviously for sensitive info an extra encryption layer is employed but since this was a tiny minority of the general e-mail volume, it was basically a type of symbiosis. This win-win relationship was recently abruptly severed as Google was kind enough to inform us about imminent upgrade to the services we were using. The said “upgrade” was of course to be performed free of any charges. It’s just that the “upgraded” services are supposed to be paid more or less double the industry average per user fee. No need to tell that nowhere in the letter, there was any mention about the prices. The text was focused purely on how much we are all going to love all the new wonders we’d get if we were quick to “switch now and save!” (sic!).

Time to set another mail system up. Just this time not for an external customer but for my company.

Surely that was a job, which interfered with current important tasks but since it’s been chewed over and postponed a good number of times already, this time there were no excuses left. So… thing’s been set up, users and all their crazy aliases migrated, rather sizeable e-mail base synchronised over, MX-es switched, another sync and boom! Or rather “voila” It Just Works™ Every e-mail client around the organisation seems to be happy with the new setup. Not that there are so many of them to choose from 🙂

Except… Synology NAS servers admin notifications arrive now as e-mail rejection notifications rather than regular messages XD

If you ever encounter the problem of e-mail admin notifications (not to be confused with users mail if you use those on the NAS – we don’t) being rejected with

535 5.7.8 Error: authentication failed: Invalid authentication mechanism

then you may realise that Synology expects only one authentication method to be always available on the server it communicates with: LOGIN and there’s no way to select a different one. Good that they don’t insist on sending credentials in plain text without SSL/TLS! Nor insist on employing TLSv1.0 for example as some still do.

I see basically only two options for tackling the issue:

• use another, external mail/submission server, which supports LOGIN (sender’s domain restrictions may apply)
• enable LOGIN on the server you initially didn’t want to have it enabled on

None of the two is perfect but well, you can’t have everything, right? Where would you put it?