So, this is on a pretty fresh install of FreePBX via the beta iso.
Slapped the premium admin module on so I can do SMTP, gone to set up SMTP with my provider of choice. This is running over TLS and using username/password auth, with the host being outbound.mailhop.org:587.
So I think I’ve got everything set up right, but looking at the debug I don’t think it’s getting as far as even using the credentials I’ve given it. I’m seeing the below in the debug screen on trying to send an email:
2025-06-15T16:01:29.304775+01:00 freepbx01 postfix/smtp[8065]: 10B6F7FC5F: SASL authentication failed; cannot authenticate to server outbound.mailhop.org[35.157.29.171]: no mechanism available
2025-06-15T16:01:29.465785+01:00 freepbx01 postfix/smtp[8065]: warning: SASL authentication failure: No worthy mechs found
Looking at historical examples of Debian folks bumping into this, I’ve seen some folks suggesting that installing the libsasl2-modules module has resolved this for them, but these are decade old threads, so I wanted to see if there are alternate options. Pretty sure this is a bug of some flavour.
Make sure your SMTP server provider supports authentication and isn’t blocking the connection. Some providers (like Gmail, Outlook, or Zoho) may require app-specific passwords or special settings.
Alternative you can contact SMTP server provider like SMTPget, SMTP2Go, iDealSMTP for better understanding and they will help you with everything.
If all you are doing is using SMTP in FreePBX to send voicemails to your users you don’t need authentication. Instead, if for example you and your users are using mail.google.com for their mailboxes, you can just setup mail.google.com as your outbound mailserver, no authentication, then port 25 destination.
This means that no mechanism was found that mailhop.org wants. Based on their documents they want either PLAIN or LOGIN and postfix needs to be configured to use those.
That is still a requirement. From the CLI do dpkg -l | grep libsasl2-modules you should end up with this output:
root@fpbx17:~# dpkg -l | grep libsasl2-modules
ii libsasl2-modules:amd64 2.1.28+dfsg-10 amd64 Cyrus SASL - pluggable authentication modules
ii libsasl2-modules-db:amd64 2.1.28+dfsg-10 amd64 Cyrus SASL - pluggable authentication modules (DB)
If you don’t see that, you need to install the libsasl2-modules package.
When suggesting this as a solution you need to keep in mind that you advising them to turn the system into an Internet Direct MTA which means other actions must be taken because when the server tries to connect to another MTA like mail.google.com there are expectations.
– Proper SFP records. The receiving mail server is going to do an SFP lookup against the domain trying to send the mail. If the PBX’s IP doesn’t exist in that domain’s SFP record or the record doesn’t exist…red flag.
– Proper DKIM. Again, the receiving mail server is going to check for DKIM on the domain sending the mail. Those keys need to live somewhere and be configured by Postfix to use them. No DKIM, red flag.
– Proper DMARC. This is becoming more and more common especially among major providers like Google.
– Proper rDNS. Lower check but it will be done and could cause a read flag.
Just like DMARC, more and more major providers are wanting STARTTLS or SMTPS based connections.
Your PBX shouldn’t be a Direct Send MTA because now you are literally running a mail server with all the requirements and trimmings needed to talk to every other mail server. STMP Auth is the best and most efficient way for your PBX to deliver mail.
your source IP address is pre-registered with Google;
you have to authenticate with Google for each message; or
the destination address has to be a google mail one (there may be some other restrictions, if I re-read the rules - please read the original to be sure of the exact rules).
Hey folks! Thanks for coming back. It was a user error ultimately, the libsasl2-modules thing was a red herring. I just needed to do quite a bit more reading on what Postfix was expecting me to use in all the fields as it looked a bit different to what I was used to.
Not exactly. You are correct that all of that is needed if you want to send to any random mailserver on the Internet. And, yes, it probably IS needed if you are actually using Google as your mailserver because Google’s a jerk now about subscribers. I don’t know - since I don’t use Google for a mailserver. However, I used the name “google” because Google’s universally recognized as a mail host, just like Microsoft’s hotmail or office.com is universally recognized as a mailserver, and I was writing the post for the lowest common denominator of reader.
With the majority of ISP’s if you are a business customer setting up to use them to send and receive email from IMAP/SMTP clients, during onboarding they will ask if you have a static IP - most business customers will - and the ISP will then whitelist that in their mailserver so that it bypasses all of the need for DKIM, DMARC, etc. It’s a defensive measure to reduce technical support costs. And it also makes it very easy if the customer wants to send mail from printers, scanners, etc. Also, I -suspect- if you are actually PAYING google for mailservices, with your own domain name and all that, that they have a double-secret list of customer static IPs. Once more what else are they going to tell a customer who is PAYING THEM MONEY who calls their support line and says “I have a super important fax machine made in 1986 that we do “thousands of dollars of business through” (the usual excuse) and does not support auth-smtp”. After all, the rules change when you are paying for services as opposed to being a freeloader with the free google accounts.
Anyway, my gut feeling is if they are setting up their own PBX on premise using an Asterisk system like FreePBX - they likely will also have their OWN mailserver on-premise. Why would you go to the trouble of doing an on-premise PBX and not an on-premise mailserver? Mailservers are far easier to set up than PBXes. But, I didn’t want to say “just relay it through your own mailserver without authentication” because that’s like saying “why don’t you do the obvious, Sherlock” and I’d have a bunch of people like you jumping on me with “what if they don’t have a mailserver” But since you did it anyway I might as well explain it now.
My gut feeling also is if they are running Fail2Ban on their PBX and all of that nonsense, that they are doing it so they can port-forward to their mailserver and have remote softphones from any IP on the Internet. So right there, they are going to have a static IP. Which means it’s easy EVEN IF they are using Google to setup a local mailserver with DKIM/DMARC/rDNS and relay all their photocopiers, alerting systems, pbxes and other junk on the inside that wants to send email, through that host. Far easier than setting all that junk up to authenticate SMTP to some smartmailer on the Internet.
Anyhow, the OP really needs to talk to the admin of their mailserver and see if they can just setup a direct send option from their PBX, if their mailhost allows it, it will save them a ton of work.
There is also SPF on the incoming side. WRT Google, I know that Google now do SPF checks on mail inbound to @gmail.com, as I had to set it up for my outbound email, which uses a personal domain name, as Google started rejecting mail form my ISPs mailhost without an SPF entry, in my DNS.
Any system, including your own mail server, that is sending mail on behalf of your domain needs proper SFP and DKIM these days. In the case of your own mail server, that is where the DKIM keys are generated.
This is why when you sign up for services like StatusPage, etc that send e-mail alerts from their systems will provide you with a SFP include: entry and CNAME entries for their DKIM.
Even as a business customer of Google and they are hosting your email, you still need to setup SFP and DKIM entries for Google’s service so that when you send an email to Hotmail, Hotmail knows that Google has permission to send mail on behalf of your domain.
That was probably done because of the enormous number of people using free gmail accounts for photocopiers, using auth SMTP in the copier to a free gmail account. In the past a number of years ago a bunch of my customers all one day started complaining their copiers wouldn’t scan. When I investigated it I found the copy machine company (who shall remain nameless) SOP was to tell people to get a gmail account to relay mail scans from the copier. Originally Google started requiring auth-smtp, then encrypted auth smtp then I think tls 1.3 and now I guess SPF
They aren’t particularly friendly to the gmail.com users which is really irritating considering how much money they are making from telemetry off Android smartphones that have gmail.com accounts…