postfix smtp relay fail after recent virtualmin upgrade

13 posts / 0 new
Last post
#1 Wed, 11/13/2013 - 20:55
adminjay

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

Wed, 11/13/2013 - 22:42
andreychek

Howdy,

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

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

-Eric

Wed, 11/13/2013 - 23:21
adminjay

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 = ns313.atozstoresonline.info, localhost.atozstoresonline.info, , localhost
myhostname = ns313.atozstoresonline.info
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/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/main.cf: unused parameter: smtpd_relay_restrictions=permit_mynetworks permit_sasl_authenticated reject_unauth_destination
Thu, 11/14/2013 - 07:56
andreychek

Howdy,

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.

-Eric

Thu, 11/14/2013 - 22:20 (Reply to #4)
adminjay

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
#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_use_tls=yes
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 = ns313.atozstoresonline.info
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ns313.atozstoresonline.info, localhost.atozstoresonline.info, , localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/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
Fri, 11/15/2013 - 08:39
andreychek

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!

-Eric

Sat, 11/16/2013 - 18:47
adminjay

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

Mon, 11/18/2013 - 07:59
andreychek

Howdy,

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

-Eric

Mon, 11/18/2013 - 14:12
adminjay

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

Wed, 11/20/2013 - 03:43
Locutus

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.

Wed, 11/20/2013 - 17:37
adminjay

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.

Wed, 11/20/2013 - 19:04
Locutus

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

Wed, 11/20/2013 - 19:28
adminjay

/usr/sbin/

Topic locked