after recent virtual min upgrade, postfix smtp authentication for outlook/thunderbird and other mail clients, getting error message relay access denied.
mail is sent and received from usermin properly, only the smtp authentication area is messed up after the upgrade and i can’t figure out why.
thanks Eric and yes i never ever had a problem before, i been using the virtualmin GPL version on over 30 servers for over 6 years and nothing like this, i login and see things changed that shouldn’t be but i can’t figure out all the issues with this one server, thanks again.
Hmm, it doesn’t appear that there is a smtpd_recipient_restrictions line in your /etc/postfix/main.cf.
Also, it appears that there is a line smtpd_relay_restrictions, containing what should be in the smtpd_recipient_restrictions.
Is it possible that someone accidentally changed that?
The smtpd_relay_restrictions parameter isn’t actually valid though, except on very recent Postfix versions – more recent than any Virtualmin distro provides by default.
In theory though, it may be as simple as renaming smtpd_relay_restrictions to smtpd_recipient_restrictions, and then restarting Postfix.
Hi Eric, i checked everything and i don’t see anyway it could have been changed manually, i don’t see any flags by our security dept. that monitors all traffic and no one here had changed it (2 other admins)
it was caused after a ubuntu update to 12.04.3
Postfix version 2.9.6
are u able to make the change to the below that i can paste right into the cf file,.
main.cf
See /usr/share/postfix/main.cf.dist for a commented, more complete version
Debian specific: Specifying a file name will cause the first
line of that file to be used as the name. The Debian default
is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
appending .domain is the MUA’s job.
Uncomment the next line to generate “delayed mail” warnings
Hmm, that’s very odd! Ubuntu 12.04 is one of the most common distros running Virtualmin, and I use that for the majority of my systems – but we hadn’t received any reports of that happening before.
That parameter isn’t valid on that Postfix version, so if that happened to anyone else, it would have broken their installation as well.
The fix should be straight forward though – you’d just need to find this line:
Hi Eric, it fixed the relay message but when email is to be sent it pops up with bad username/password instead now, wonder if someone tried to fix the relay issue and turned off something else but the server receives mail and users can send mail using usermin but not smtp through outlook, thunderbird, etc.,
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: warning: 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]: SASL LOGIN authentication failed: generic failure
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: warning: 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]: SASL LOGIN authentication failed: generic failure
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: lost connection after AUTH from 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: disconnect from 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: lost connection after AUTH from 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: disconnect from 50-202-171-113-static.hfc.comcastbusiness.net[50.202.171.113]
here is a error from the log
looks like a director is missing for SASL authentication
It looks like your SASL installation is incorrect… What output do you get for these command?
ps aux | grep sasl
which saslauthd
I’m surprised a simple Ubuntu update should cause all this to happen. I have serious doubts that an update modifies your main.cf and replaces the client_restrictions directive with relay_restrictions, that doesn’t make any sense.
IF there is an update that modifies the config (it can happen - when there’s a new config file in the package), you’re asked if you want to keep your version of the config, use the new package one, or merge the two. And the default action (which is applied during unattended updates) is to keep the existing config.