I've spent a few days trying to diagnose this myself but I've not got anywhere, so I hope for some help from the forums.
My server has two IP addresses: 213.229.76.7 (the main eth0) 85.234.150.186 (eth0:1)
I noticed that one of the domains on the shared main IP (213.229.76.7) is not receiving inbound emails. I tested the site on the other IP and it's receiving emails as normal. . .
I ran the following in command line:
[root@en3 ~]# netstat -an | grep :25
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 85.234.150.186:25 0.0.0.0:* LISTEN
As you can see, it's listening on the second IP but not the first. I have checked to make sure Postfic configuration is set to listen on all addresses and it is. I have also taken a screengrab of Server Processes screen in Postfix: http://lannait.com/serverprocesses.png
Something looks wrong with the above. Can anyone suggest what I need to do to get Postfic listening on the main IP?
Forgot to add, there are no clues in the mail log.
Howdy,
Ah, yeah, I don't seem to be able to connect to your one IP address. It may just be a matter of configuring Postfix to listen on that IP.
What is the output of this command:
postconf -n
We can use that to review the Postfix config, and determine what exactly is tying it to that one IP address.
-Eric
Thank goodness you've come along to help me with this Eric, it's driving me insane. As per your request:
[root@en3 ~]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, en3.lannait.com
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/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 reject_rbl_client sbl.spamhaus.org
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
Howdy,
Hmm, the "inet_interfaces = all" parameter should be causing Postfix to listen on all your IP addresses.
Could you try restarting Postfix:
/etc/init.d/postfix restart
After that, does it then listen on all your interfaces? You can test that with this command:
netstat -an | grep :25
I already tried restarting everything, including multiple reboots :-(
Well, just to make sure we've tried everything -- can you run the two commands mentioned above?
Although what you did should work -- there are circumstances that could cause rebooting to not work, but the above two commands might still resolve it.
If that doesn't help -- what is the output of this command:
/sbin/ifconfig
Yes, I executed the commands you posted. Output of ifconfig is: (The as0 stuff is OpenVPN stuff)
as0t0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.224.1 P-t-P:172.27.224.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.226.1 P-t-P:172.27.226.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.228.1 P-t-P:172.27.228.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.230.1 P-t-P:172.27.230.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.232.1 P-t-P:172.27.232.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.234.1 P-t-P:172.27.234.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t6 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.236.1 P-t-P:172.27.236.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
as0t7 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.27.238.1 P-t-P:172.27.238.1 Mask:255.255.254.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:200 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 00:16:3C:EF:FE:41
inet addr:213.229.76.7 Bcast:213.229.76.7 Mask:255.255.255.255 inet6 addr: fe80::216:3cff:feef:fe41/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:90027 errors:0 dropped:0 overruns:0 frame:0 TX packets:62786 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9341836 (8.9 MiB) TX bytes:46897996 (44.7 MiB) Interrupt:11 Base address:0x6000
eth0:1 Link encap:Ethernet HWaddr 00:16:3C:EF:FE:41
inet addr:85.234.150.186 Bcast:85.234.150.186 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0x6000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:27014 errors:0 dropped:0 overruns:0 frame:0 TX packets:27014 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:24635587 (23.4 MiB) TX bytes:24635587 (23.4 MiB)
Investigating further, I notice some serious DNS/BIND issues going on. The following is an example from the system log:
Jan 26 19:36:32 en3 named[11827]: client 127.0.0.1#53258: query (cache) '79.32.65.50.in-addr.arpa/PTR/IN' denied
Further, doing an nslookup in CLI gives me the following:
[root@en3 ~]# nslookup en4.lannait.com ;; Got recursion not available from 127.0.0.1, trying next server Server: 8.8.8.8 Address: 8.8.8.8#53
Non-authoritative answer: Name: en4.lannait.com Address: 213.229.75.37
Then I ping the same host:
[root@en3 ~]# ping en4.lannait.com ping: unknown host en4.lannait.com
Note that the main www.lannait.com hostname is hosted as a virtual server on the problem box. It appears it refuses to ping any subdomains of that root hostname.
Maybe this is a clue, maybe somehow related to the Postfix issue?
Regarding my above post, it turned out to be unrelated, I have listed the localhost IP in the wrong order in networking.
Getting back to the topic at hand, I've managed to get things working by pointing the mailserver DNS of the problem domains to the IP that is actually listening for mail. While it's working, I feel this is a dirty kludge and I would like to get things fixed properly.
Eric, were you able to look at the screengrab I posted in the OP of this thread? Something looks awry, why are the IP listed with submission/SMTP process, and why are some processes listed twice? Is this normal behaviour?
It sounds like you may have some per-IP SSL certificates setup in Postfix. That can occur when users with a private IP address use the "Copy to Postfix" button on their SSL certificates. That is normal though (well, at least now it is, that's a fairly new feature).
-Eric
OK I understand. If that is indeed what has happen, how might I reverse it so that Postfix will start listening on all IPs again?
I'm trying to help myself here and use my imagination. I've managed to get Postfix listening on both IPs now by copying the following lines in Postfic master.conf file and replacing the IP. . .
85.234.150.186:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/orientex/ssl.cert -o smtpd_tls_key_file=/home/orientex/ssl.key -o smtpd_tls_CAfile=/home/orientex/ssl.ca
127.0.0.1:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes
85.234.150.186:submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/orientex/ssl.cert -o smtpd_tls_key_file=/home/orientex/ssl.key -o smtpd_tls_CAfile=/home/orientex/ssl.ca
127.0.0.1:submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes
The lines I added (with the IPs replaced) are as follows. . .
213.229.76.7:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o
213.229.76.7:submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o
Is this a safe fix?
What about the certificate paths? How do I get the system to generate those in the above lines?
Actually it still doesn't work. Even though Postfix is now listening on both IPs, mail is never delivered when it is sent to the main server IP, even though the recipient addresses are hosted on virtual servers that use that IP. I've once again had to point the mail.example.com subdomains to the other IP address to get mail delivered again.
This is really driving me mad, I've blown a lot of time on this and apparently hardly moved :(
Howdy,
Yeah it should be as simple as copying the lines that you were looking at (especially the ones beginning with "smtp", and then putting the other IP addresses in there.
If that doesn't work -- what error(s) do you see in /var/log/mail.log or /var/log/maillog when trying to send an email to a user on your server?
-Eric
I'm first going to do some experimentation with postfix/dovecot per-IP certificates and then I'll revert to this topic again. . .
By the way, is there any reason I can't use a single mail.example.com hostname to handle mail traffic for ALL virtual servers?
I have this working now it appears. I will post what I have in my Postfix and Dovecot cf files, as I think they woulld be useful to be copied into the following topic, maybe will help others (I have managed to get per-IP certificates working properly, even over IMAPS and SMTPS). . . https://www.virtualmin.com/node/34385
Eric, please take a look over this and see if you can see any gotchas I missed. . .
First, the end of my Postfix master.cf contains (obviously you must change the IPs and paths to your own). . .
127.0.0.1:smtp inet n - n - - smtpd
127.0.0.1:submission inet n - n - - smtpd
1.1.1.1:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example/domains/mail.example.com/ssl.cert
-o smtpd_tls_key_file=/home/example/domains/mail.example.com/ssl.key
1.1.1.1:submission inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example/domains/mail.example.com/ssl.cert
-o smtpd_tls_key_file=/home/example/domains/mail.example.com/ssl.key
2.2.2.2:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example2/domains/mail.example2.com/ssl.cert
-o smtpd_tls_key_file=/home/example2/domains/mail.example2.com/ssl.key
2.2.2.2:submission inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example2/domains/mail.example2.com/ssl.cert
-o smtpd_tls_key_file=/home/example2/domains/mail.example2.com/ssl.key
3.3.3.3:smtp inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example3/domains/mail.example3.com/ssl.cert
-o smtpd_tls_key_file=/home/example3/domains/mail.example3.com/ssl.key
3.3.3.3:submission inet n - n - - smtpd
-o smtpd_tls_cert_file=/home/example3/domains/mail.example3.com/ssl.cert
-o smtpd_tls_key_file=/home/example3/domains/mail.example3.com/ssl.key
127.0.0.1:smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
127.0.0.1:submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
1.1.1.1:smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example/domains/mail.example.com/ssl.cert
-o smtpd_tls_key_file=/home/example/domains/mail.example.com/ssl.key
1.1.1.1:submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example/domains/mail.example.com/ssl.cert
-o smtpd_tls_key_file=/home/example/domains/mail.example.com/ssl.key
2.2.2.2:smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example2/domains/mail.example2.com/ssl.cert
-o smtpd_tls_key_file=/home/example2/domains/mail.example2.com/ssl.key
2.2.2.2:submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example2/domains/mail.example2.com/ssl.cert
-o smtpd_tls_key_file=/home/example2/domains/mail.example2.com/ssl.key
3.3.3.3:smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example3/domains/mail.example3.com/ssl.cert
-o smtpd_tls_key_file=/home/example3/domains/mail.example3.com/ssl.key
3.3.3.3:submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_tls_cert_file=/home/example3/domains/mail.example3.com/ssl.cert
-o smtpd_tls_key_file=/home/example3/domains/mail.example3.com/ssl.key
Note that the earlier smtps line towards the start of the file must be commented out so the above settings will work instead.
In Dovecot's ssl.conf add the following. . .
local 1.1.1.1 { # instead of IP you can also use hostname, which will be resolved
protocol imap {
ssl_cert = </home/example/domains/mail.example.com/ssl.cert
ssl_key = </home/example/domains/mail.example.com/ssl.key
}
protocol imaps {
ssl_cert = </home/example/domains/mail.example.com/ssl.cert
ssl_key = </home/example/domains/mail.example.com/ssl.key
}
}
local 2.2.2.2 { # instead of IP you can also use hostname, which will be resolved
protocol imap {
ssl_cert = </home/example2/domains/mail.example2.com/ssl.cert
ssl_key = </home/example2/domains/mail.example2.com/ssl.key
}
protocol imaps {
ssl_cert = </home/example2/domains/mailexample2.com/ssl.cert
ssl_key = </home/example2/domains/mail.example2.com/ssl.key
}
}
local 3.3.3.3 { # instead of IP you can also use hostname, which will be resolved
protocol imap {
ssl_cert = </home/example3/domains/mail.example3.com/ssl.cert
ssl_key = </home/example3/domains/mail.example3.com/ssl.key
}
protocol imaps {
ssl_cert = </home/example3/domains/mail.example3.com/ssl.cert
ssl_key = </home/example3/domains/mail.example3.com/ssl.key
}
}
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
Let me know your comments. It all appears to be working well, did I get this completely right?
OK well I'll just assume this works now because it appears to be functioning perfectly. . .
However, Virtualmin's interpretation of SSL per-IP is buggy as hell, and every time Virtualmin deleted or creates a Virtual server, it completely breaks my above master.cf directives. Is there any way to prevent Virtualmin messing around my above code?
Howdy,
Well, if you find it that buggy, we should probably talk about what's breaking exactly so it can be fixed :-)
What problem are you seeing when removing a domain?
Normally, Virtualmin adds and removes the lines from the Postfix and Dovecot configs when adding/removing an SSL certificate.
The lines you currently have in your configs for SSL -- were those added by Virtualmin, or did you need to add those on your own?
-Eric
Hi Eric,
I have been bitten by this as well.
I have a server shared IP of X.Y.Z.10
If I have SSL certificates for mail on multiple sites so that the master.cf file looks like this:
127.0.0.1:smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes
127.0.0.1:submission inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes
X.Y.Z.10:smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes
X.Y.Z.10:submission inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes
X.Y.Z.11:smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/homedir11/ssl.cert -o smtpd_tls_key_file=/home/homedir11/ssl.key -o smtpd_tls_CAfile=/home/homedir11/ssl.ca
X.Y.Z.11:submission inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/homedir11/ssl.cert -o smtpd_tls_key_file=/home/homedir11/ssl.key -o smtpd_tls_CAfile=/home/homedir11/ssl.ca
X.Y.Z.12:smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/homedir12/ssl.cert -o smtpd_tls_key_file=/home/homedir12/ssl.key -o smtpd_tls_CAfile=/home/homedir12/ssl.ca
X.Y.Z.12:submission inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_cert_file=/home/homedir12/ssl.cert -o smtpd_tls_key_file=/home/homedir12/ssl.key -o smtpd_tls_CAfile=/home/homedir12/ssl.ca
If I happen to remove one of the shared servers, the two lines referring to X.Y.Z.10 disappear, thus there is no SMTP listening on the .10 IP any more. However, this line is required to keep the mail flowing for the remaining shared servers.
I will try and reproduce it and narrow down what is happening, but it has happened on 3 different servers over the last year.
Hi,
The lines above were all added by myself. I used the lines added by Virtualmin as a starting point for research into how to properly set up per-IP SSLs. Due to a problem elsewhere on the server (removing a virtual server and it's sub servers also removed their dedicated IP from the networking interface!) the relevant section of the postfix.master (the lines I added) became mangled as virtualmin attempted to update the per-IP settings information with it's own version of what it should look like. . .
I noticed this when emails stopped working and once again postfix stopped listening on all IPs.
Why am I now being mod queued? Have I broken some forum rules?