Forum archive
confconsole sendinblue and default setup not working
Hi Jeremy, guys,
(this is a "2-parter")
I've just launched a "tkcore" EC2 instance, following the path of least resistance at every step. I did enter a name under the ____ .tklapp.com and confirm that I can login as root using my SSH key provisionned by the launching process (/usr/lib/inithooks/firstboot.d?).
The one thing that was interesting to me was the ability to have a cronjob which can email the output to me.
So I issued a `sendmail root` to fire a test email. Didn't work. /var/log/mail.log reveils the error as: "status=bounced (host ****determined by destination MX****.com[1.2.3.4] said: 504 Need Fully Qualified Address (in reply to MAIL FROM command))"
(Not very familiar with mail/postfix issues) Right off the bat, I am thinking it has something to do with the hostname being set to "core" instead of jfdtestec2.tklapp.com perhaps? /etc/mailname is absent also, could it have something to do with it? Or could it be that the host trying to accept the mail is very paranoid? Changing the system mail recipient to a @gmail.com email using /usr/lib/inithooks/firstboot.d/85secalerts worked. Seems google servers are more permissive perhaps.
So that's issue number one. I thought I'd work around this but the "key" didn't turn so well then either ;)
I thought it might make things simpler if I setup mail relaying. So I launched confconsole to setup SMTP. Again, following the path of least resistance, I used the suggested sendinblue setup. I have the account setup and used my email as login, and the password given under "Master password" SMTP key name.
Then issued "sendmail root" for testing yields "SASL authentication failed; cannot authenticate to server smtp-relay.sendinblue.com[52.14.65.8]: no mechanism available"
What gives? What am I doing wrong?
Replies (4)
Looks like there's a package missing?!
Reply 1Hi Earl
Reply 2Thanks for your note. Unfortunately, you are correct and actually, from what I can gather, all v15.x appliances are affected...
FWIW, it's been fixed in the latest version of Confconsole, but that isn't (yet) available from the TurnKey repo. If you'd like to generate Let's Encrypt SSL/TLS certificates, then you'll need to upgrade Confconsole as per the release notes (scroll down to "How to install/update"). If you don't want/need a free valid SSL/TLS certificate (i.e. to avoid the "security warning" when viewing HTTPS) and only want to set up an SMTP email relay, then you don't need to upgrade Confconsole, installing libsasl2-modules is all you need.
Thanks for letting me know about the missing dependency.
Reply 3Thanks for letting me know about the missing dependency. We'll have to fix that in the next release.
Also, thanks for sharing your feedback re hostname. That's a great idea! IIRC there is a "set hostname" option in Confconsole, but we should probably add an inithook so we can pre-seed it via the Hub. I've created a "feature request" for that (on our issue tracker). Unfortunately, I'm not sure when we'll get to it (I'm currently really bogged down working on v16.0). I've (extremely optimistically) pinned it to the "16.0" milestone...
Hi Jeremy,
Reply 4Hi Jeremy,
I understand and agree with you on the direct delivery of emails. I am sticking with the relay strategy. It is however unexpected, wouldn't you agree, in the great turnkey philosophy, that the hostname is set to "core" when I clearly set it in the turnkey hub's "launch a new server"? Am I missing something?
And thanks about libsasl2-modules that did fix it. I am using tk core appliance v15:
# cat /etc/turnkey_version turnkey-core-15.0-stretch-amd64
libsasl2-modules was not installed apparently.
Cheers!
First up, sending email directly from AWS servers (or any hosting platform; or dynamic DNS IP address) is very hit and miss (in my experience, AWS IPs in particular are more likely to miss...). That's because spammers often abuse them and the IPs get blacklisted as spam addresses.
As you note, many mail providers simply bounce email from unknown/blacklisted domains/IPs. As you also note, Google tend to be more permissive (and usually just tag it as spam, rather than blocking completely).
Resolving the points you raise would likely be a good start, plus other factors such as adding the relevant PTR and TXT DNS records. And perhaps for some domains/IPs and many email servers (i.e the receiving end) that may be enough. Even then, if you are sending any volume of email (i.e. not just to yourself) you need to constantly watch IP blacklists and apply to have your IP/domain removed from them (as it invariably gets added). Regardless, it can be quite involved to ensure reliable email deliver-ability. I would argue, that generally, using an SMTP relay is the "right" answer.
Regarding #2 - the issue with SendinBlue, that sounds suspiciously like a missing dependency?! I would like to think that that's not the case, but it certainly does sound like it! To confirm, please try installing the 'libsasl2-modules' package and see if it works then. I.e.:
There is a possibility that you may need to restart postfix afterwards.
If that fixes it, could you please confirm which particular appliance and version you are using, because AFAIK, that should be installed by default on all v15.x appliances.