I found it! Instead of looking in main.cf, I looked in master.cf. There was a line:
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
smtp inet n - n - - smtpd -o myhostname=mail.mydomain.com
and it was still set to AT&T's internal ptr for their name for the IP. I changed it to my domain name and has the new ISP set a PTR, and I think it is normal now. We shall see if I get any more rejections.
MX Toolbox is still reporting this warning, though:
Reverse DNS Mismatch Reverse DNS does not contain the hostname
So I don't know what detail has it concerned. PTR does now report to mail.mydomain.com
I am afraid not...that ISP wouldn't even give me a SMTP to use. I'm not relaying through anyone (as far as I know!) I'm stumped as to where it gets the information - it is as if it stored it from before I switched...
I just changed ISPs, and got a new static IP address, updated my A record, etc. After having the usual email rejection issues, and testing with MX Toolbox, etc, I found that my SMTP header is incorrect. It identifies as:
220 mobile-166-130-xxx-xxx.mycingular.net ESMTP Postfix (2.6.6) [813 ms]
(actual IP removed)
This is the IP for the ISP (AT&T mobile) I am no longer on, and not connected to. Where is postfix getting this? I even added a line to /var/postfix/main.cf:
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
and restared the service. This seems to make no difference. Where is it getting the stale info, and how do I set it to my domain name to match my MX record?
The laptop was added after, and it works with several laptops, so we can rule out MAC issues. I did reset the WiMax unit, but no luck. This is a whole-house type unit, outdoor mounted and Power- over-Ethernet.
Any other thoughts?
My ignorance never ceases! After all the problems and expense of using AT&T LTE as my ISP, I gave up and found a WiMAX provider. It was installed today, and it works just fine connected to a laptop configured for DHCP. Doing a IPCONFIG /ALL, all the IP, gateway, and DNS addresses looked normal.
But when I connect this WiMAX box to the COS server external interface, also set to DHCP, I never get an IP address. Just endless twirly. What problem could cause the WiMAX radio to provide a DHCP to my laptop, but not to ClearOS?
PS - IP config on the laptop showed a seperate address for "DHCP Server". It was in the DNS block of addresses, not the IP block. I am not used to seeing this. Possible hint?
Many thanks to all of you, as always.
Sorry, I was away a few days. Your theory is brilliant! I wouldn't have thought of it but it makes perfect sense. Thanks so much for seeing that, I will call AT&T and explain it basically as a "routing problem". The network is basically "unreachable" from my phone. I'm betting they will blow me off on this (after I go through the first 15 people who can't understand it) but at least I won't keep knocking my head against the wall. Might be an unsolvable problem, given their likely disinterest for one guy using an odd (to them) ISP solution.
Yes, all port are definately open. These failure *ONLY* happens from any of the family's AT&T cell phones, when WiFi is off.
I performed a service firewall restart. No difference.
I can run the command you noted above, but when do I run it and what am I looking for?
Here is the output from IPTABLES below. I don;t see anything in my /var/log/messages file except what appear to be legitimate DHCP requests from the server to the cellular modem. I've never seen my cell phone IP in any table or in any file anywhere.
I am saying that there is nothing in my blocked list, and I have added nothing manually. But, there are lots of chinese IP addresses in my security file showing attempted logins. Isn't the system supposed to see that and eventually blacklist them?
[root@me ~] # iptables -nvL INPUT
Chain INPUT (policy DROP 2713 packets, 124K bytes)
pkts bytes target prot opt in out source destination
119 9044 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 state RELATED,ESTABLISHED
63 3780 DROP all -- * * 188.8.131.52 0.0.0.0/0
4 240 DROP all -- * * 184.108.40.206 0.0.0.0/0
4 240 DROP all -- * * 220.127.116.11 0.0.0.0/0
0 0 DROP all -- * * 18.104.22.168 0.0.0.0/0
0 0 DROP all -- * * 22.214.171.124 0.0.0.0/0
214 8668 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
3428 669K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth4 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth4 * 169.254.0.0/16 0.0.0.0/0
582K 169M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
402K 47M ACCEPT all -- eth3 * 0.0.0.0/0 0.0.0.0/0
524 15196 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
29 1828 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth4 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
1 344 ACCEPT udp -- eth4 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth4 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
1 44 ACCEPT tcp -- * * 0.0.0.0/0 126.96.36.199 tcp dpt:1875
1 44 ACCEPT tcp -- * * 0.0.0.0/0 188.8.131.52 tcp dpt:20
1 44 ACCEPT tcp -- * * 0.0.0.0/0 184.108.40.206 tcp dpt:21
8945 882K ACCEPT tcp -- * * 0.0.0.0/0 220.127.116.11 tcp dpt:80
24 1717 ACCEPT tcp -- * * 0.0.0.0/0 18.104.22.168 tcp dpt:443
1 44 ACCEPT tcp -- * * 0.0.0.0/0 22.214.171.124 tcp dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 126.96.36.199 tcp dpt:135
1 44 ACCEPT tcp -- * * 0.0.0.0/0 188.8.131.52 tcp dpt:110
2 88 ACCEPT tcp -- * * 0.0.0.0/0 184.108.40.206 tcp dpts:60000:60999
4940 4092K ACCEPT tcp -- * * 0.0.0.0/0 220.127.116.11 tcp dpt:25
2760 594K ACCEPT tcp -- * * 0.0.0.0/0 18.104.22.168 tcp dpt:22
1 44 ACCEPT tcp -- * * 0.0.0.0/0 22.214.171.124 tcp dpt:83
34 5366 ACCEPT tcp -- * * 0.0.0.0/0 126.96.36.199 tcp dpt:236
0 0 ACCEPT tcp -- * * 0.0.0.0/0 188.8.131.52 tcp dpt:237
5891 760K ACCEPT udp -- eth4 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
564 186K ACCEPT tcp -- eth4 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Nick and Jeff,
Thanks for the replies. I have looked up my public IP, and there is nothing noting that IP either in the security log or the response to the IPTABLES command. I just see no reason for it at all. I also don't understand why there is nothing in my IDS blacklist when the security is obviously full of Chinese brute force login attempts.
I don;t know much about this sort of thing, just how to us the COS UI. But I am completely stumped why I cannot look at my web page with a cell phone when WiFi is fine. There's got to be some place where blocked IPs are stored! Shouldn't this be simple? I am so frustrated...