I restored a virtualmin backup and numerous sites after a fresh install on Centos 5.7 but I cannot connect via SMTP to send mail. I don’t know if there was a way to back up all webmin settings but I did not do that.
Initially when trying to send email Thunderbird would just hang. After creating /etc/postfix/sender_access and postmapping it it would then connect but immediately say the password was wrong and ask for a new one - checking mail was fine though and all passwords are fine. I tinkered with some items in main.cf with no success but restored to original.
Also note this is a dedicated server with no blocked ports from the ISP and no problem exists with firewall disabled
My first errors in the log were:
fatal: open database /etc/postfix/sender_access.db: No such file or directory
warning: process /usr/libexec/postfix/smtpd pid 461 exit status 1
warning: /usr/libexec/postfix/smtpd: bad command startup – throttling
after creating /etc/postfix/sender_access I now get:
connect from c-xx-xx-xx-xx.xx.xx.xx.net[xx.xx.xx.xx]
warning: connect to Milter service inet:localhost:8891: Connection refused
warning: SASL authentication failure: Password verification failed
warning: c-98-196-99-9.hsd1.tx.comcast.net[220.127.116.11]: SASL PLAIN authentication failed: authentication failure
warning: c-98-196-99-9.hsd1.tx.comcast.net[18.104.22.168]: SASL LOGIN authentication failed: authentication failure
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
home_mailbox = Maildir/
html_directory = no
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 20000000
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost, www.munseymedia.com, munseymedia.com
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_bcc_maps = hash:/etc/postfix/bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_sender_access hash:/etc/postfix/sender_access check_policy_service unix:/var/spool/postfix/postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
I’m pretty sure it has something to do with this and is the same problem I had before:
But any pertinent info that may have existed in those posts is not longer accessible on this site!!! So can someone chime in and rewrite this solution? I have no idea what it is and have been up for over 30 hours straight and need this thing to work asap.
I had to go to Google to search for posts by me since the search here doesn’t work…
Here is the answer:
It doesn’t look like you have the -r flag enabled… you can add that by editing “/etc/sysconfig/saslauthd”, and changing the FLAGS= line at the end to read: (no quotes btw)
After setting that, you can restart saslauthd with:
I’m glad you got that figured out!
One other thing in there that we may be able to tweak for the better… it looks like Postfix is trying to connect to a service on port 8891, but it doesn’t look like that service is running.
Do you know what that might have been?
If not, you could simply comment out this line in your Postfix config:
non_smtpd_milters = inet:localhost:8891
Or, if you do know what that is, you could install and configure that service.
Sheesh I have no idea what that is for…
ok I googled it and I think it has to do with DKIM/Domainkeys…
Okay, I realize now that the other similar sounding post that I’ve been responding to is also you:
I think the issue you’re seeing here in this thread is related to your post in the above thread – and rather than spreading out the replies between both threads, I’m going to respond here
I think at least some of what we’re seeing here is a Virtualmin bug.
Certain things that you set in the Server Templates – those should make tweaks to your config files when those are set.
For example, when you specify user@domain for the username format, it knows to add the -r parameter to saslauthd in the config files.
And I think what we’re seeing is a bug, where those config file tweaks aren’t being reset when importing settings from a backup.
According to your other post, it sounds like you were attempting to use DKIM – and it looks like from your logs here that DKIM isn’t running. That sounds like a similar kind of bug.
What we can do is work with Jamie to get this fixed, and make sure it doesn’t happen to you or anyone else again.
In terms of settings you think Virtualmin should be corrected to handle – have you seen issues with more than the just the username format and DKIM settings?
If so, is there any chance you could offer a summary of what settings you had that weren’t properly enabled after importing the Virtualmin config backup?
So far what I can tell is:
DKIM was not running or installed upon recovery
Greylisting was not running or installed - I said I lost the data but I am not 100% on that. I’ll try to check.
The settings for the e-mail format at usernames was not configured properly.
I will try to remember if there was anything else. I do not it wasn’t a simple restore and done kind of deal. there was some work to do. I wasn’t upset because frankly it seems such a task would be very difficult…
Thanks again. I will chime in again to let you know if there was anything else.
Hmm not related but I noticed under “scheduled backups” when I scheduled some backups of a group of sites I had inadvertently check some items under “Virtualmin settings to also backup”… I backup virtualmin settings only in a separate backup so I don’t want this. No matter how many times I unclick those check boxes and save they remain when I reload scheduled backups.
So yes this means I restored some virtualmin setting from not only the single virtualmin backup but also apparently each time I restored a site. Keep in mind every backup I restored had been backed up on the same night…