postfix smtp relay fail after recent virtualmin upgrade

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.

can post .cf files if needed

thanks in advance


Hmm, upgrading Virtualmin shouldn’t affect the Postfix configuration.

See your Postfix config would help – could you paste in the output of “postconf -n”?


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.

alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix fallback_relay = home_mailbox = Maildir/ ignore_mx_lookup_error = yes inet_interfaces = all mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME mailbox_size_limit = 0 mydestination =,, , localhost myhostname = mynetworks = [::ffff:]/104 [::1]/128 myorigin = /etc/mailname readme_directory = no recipient_delimiter = + sender_bcc_maps = hash:/etc/postfix/bcc smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_delay_reject = no smtpd_sasl_auth_enable = yes smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes virtual_alias_maps = hash:/etc/postfix/virtual postconf: warning: /etc/postfix/ unused parameter: smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated reject_unauth_destination


Hmm, it doesn’t appear that there is a smtpd_recipient_restrictions line in your /etc/postfix/

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,.

See /usr/share/postfix/ 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

#delay_warning_time = 4h

readme_directory = no

TLS parameters

smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for

information on enabling SSL in the smtp client.

myhostname =
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination =,, , localhost
mynetworks = [::ffff:]/104 [::1]/128
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
ignore_mx_lookup_error = yes
fallback_relay =
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_delay_reject = no

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:

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

And change it to read as follows:

smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

And then restart Postfix:

/etc/init.d/postfix restart

Let us know if that fixes it up for you!


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.,


When that happens, what error shows up in the email log in /var/log/mail.log?


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:[]: SASL LOGIN authentication failed: generic failure
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: warning:[]: SASL LOGIN authentication failed: generic failure
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: lost connection after AUTH from[]
Nov 18 13:06:29 ns313 postfix/smtpd[3114]: disconnect from[]
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: lost connection after AUTH from[]
Nov 18 13:06:29 ns313 postfix/smtpd[3116]: disconnect from[]

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 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.

that was the case and i chose new package without thinking about it

3741 0.0 0.1 4388 804 pts/0 S+ 18:23 0:00 grep --color=auto sasl

this is what i get for the command.

Okay, looks like the saslauthd is not running. What about the second command I listed?