> Date: Sunday, August 26, 2018 21:10:48 -0400 > From: TE Dukes <tdukes at palmettoshopper.com> > >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> Richard Sent: Sunday, August 26, 2018 8:31 PM >> >> > Date: Sunday, August 26, 2018 16:25:14 -0400 >> > From: TE Dukes <tdukes at palmettoshopper.com> >> > >> >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> >> Alexander Dalloz >> >> Sent: Sunday, August 26, 2018 3:46 PM >> >> >> >> Am 26.08.2018 um 20:48 schrieb TE Dukes: >> >> >> You see a basic error message "Could not connect to >> >> >> localhost:143". So test that without using additional >> >> >> software. Foremost consult the maillog, in this case the log >> >> >> content produced by dovecot. And test connectivity on the >> >> >> lowest level. >> >> >> >> >> >> echo QUIT | openssl s_client -connect localhost:143 -starttls >> >> >> imap >> >> > I'm getting what appears to be help file with various options >> >> > when trying to run the above commad >> >> >> >> Can we guess that you don't offer TLS for IMAP connections? >> >> >> > I added this to /etc/postfix/main.cf from >> > https://access.redhat.com/solutions/120383 >> > >> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 >> > smtpd_tls_protocols = !SSLv2, !SSLv3 >> > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 >> > smtp_tls_protocols = !SSLv2, !SSLv3 >> > >> >> Randomly adding lines to a config file isn't going to help things. >> Those lines, which you added to the postfix config (which will have >> no impact on dovecot), are -- as the RH documentation indicates -- >> to turn off weak protocols, they don't turn anything on, other >> directives are used for that. >> >> > >> >> >> That must be successful first. You can too test "lsof -i >> >> >> :143" or "ss -tulpen | grep 143". And tail your maillog. >> >> >> >> >> > Running lsof -i :143, I get: >> >> > >> >> > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> >> > dovecot 1576 root 37u IPv4 32014 0t0 TCP *:imap >> >> > (LISTEN) dovecot 1576 root 38u IPv6 32015 0t0 TCP >> >> > *:imap (LISTEN) >> >> > >> >> > Running ss -tulpen | grep 143 : >> >> > >> >> > tcp LISTEN 0 100 *:143 *:* >> >> > users:(("dovecot",pid=1576,fd=37)) ino:32014 >> >> > sk:ffff913e953e2e80 <-> tcp LISTEN 0 100 >> >> > :::143 >> >> > :::* users:(("dovecot",pid=1576,fd=38)) ino:32015 >> >> > sk:ffff913b2e90a100v6only:1 >> >> > <-> >> >> >> >> So port 143 is listening. Are we back to the point that your DNS >> >> or NSS is broken so that even >> > >> > I think so. Everything else work, I don't get it. >> >> >> >> telnet localhost 143 >> >> >> >> fails while >> >> >> >> telnet 127.0.0.1 143 >> >> >> >> is successful? >> >> >> > >> > Yes, that is correct localhost fails but 127.0.0.1 responds. >> > >> >> In your pastebin: >> >> <https://paste.fedoraproject.org/paste/MMNEJmqIrEzK-A4N3MR0ZA> >> >> you show three nameservers: >> >> nameserver 166.102.165.13 >> nameserver 207.91.5.20 >> nameserver 127.0.0.1 >> > > The first two nameservers belong to my ISP. Should I move 127.0.0.1 > to the top? > > >> I can't tell if that's what you still have in place, but note that >> your dns queries will query those DNS servers in that order. Based >> on that order, the "localhost" (127.0.0.1) server is the last one >> that will be queried. Unless explicitly queried (e.g., with an >> @<nameserver> syntax) it will only be queried if the other two >> fail. >> >> Could you confirm the current order (and perhaps list) the >> nameservers in your /etc/resolv.conf file - so we are aware of any >> changes. > > They are still in that order. > >> >> I did a "localhost" query against the first two and they respond >> correctly, e.g., >> >> ;; QUESTION SECTION: >> ;localhost. IN A >> >> ;; ANSWER SECTION: >> localhost. 86400 IN A 127.0.0.1 >> >> ;; Query time: 100 msec >> ;; SERVER: 166.102.165.13#53(166.102.165.13) >> >> Somewhat related to the: >> >> > telnet localhost 143 >> > >> > fails [while it works when you try 127.0.0.1] >> > > Not sure what I have done, but telnet localhost 143 now works but > telnet 127.0.0.1 143 fails. > > >> In an earlier message (from Sunday, August 26, 2018 14:37:57) you >> state: >> >> > I have all the files shipped with CentOS. I created 2 zone >> > files >> >> could you please enumerate the "named.*" files that you have under >> your defined directory. Note, if you've chrooted named that's a >> different location than in a non-chrooted setup. >> > > total 28 > -rw-r--r-- 1 root named 391 Aug 26 17:44 192.168.1.zone > drwxrwx--- 2 named named 127 Aug 26 03:46 data/ > drwxrwx--- 2 named named 31 Aug 26 16:28 dynamic/ > -rw-r--r-- 1 root root 0 Aug 26 20:54 named > -rw-r----- 1 root named 2281 May 22 2017 named.ca > -rw-r----- 1 root named 152 Dec 15 2009 named.empty > -rw-r----- 1 root named 152 Jun 21 2007 named.localhost > -rw-r----- 1 root named 168 Dec 15 2009 named.loopback > -rw-r--r-- 1 root named 793 Aug 26 17:44 palmettodomains.zone > -rw-r--r-- 1 root root 1001 Aug 26 13:29 > palmettodomains.zone.082618 drwxrwx--- 2 named named 6 Apr 12 > 14:48 slaves/ > >> Then there's this: >> >> > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost localhost >> > +short >> > ; (1 server found) >> > ;; global options: +cmd >> > ;; connection timed out; no servers could be reached >> >> do you *really* have a name server running on your local machine? >> Just thought I'd ask. >> > root 600 0.0 0.0 112704 968 tty2 S+ 21:02 0:00 > grep --color=auto named > named 21096 0.0 0.3 391636 60160 ? Ssl 17:45 0:00 > /usr/sbin/named -u named -c /etc/named.conf > >> While you are at it, could you show the current state of your >> /etc/hosts file (as well as its ownerships and permissions). >> > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 ># 127.0.0.1 localhost.localdomain localhost > 192.168.1.110 ts130.palmettodomains.com ts130 > 192.168.1.110 mail.palmettodomains.com mail > > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 ># ::1 localhost6.localdomain6 localhost6 > 192.168.1.102 edukes1.palmettodomains.com edukes1 > 192.168.1.105 hp8200.palmettodomains.com hp8200 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > -rw-r--r-- 1 root root 509 Aug 26 14:02 hosts Since your: dig @localhost localhost failed, try: dig @127.0.0.1 localhost a (in this context, i like the longer output as it reveals more). If that fails, then there is, at minimum, a problem with your local dns server. If that works, try: dig @localhost4 localhost a This will explicitly use the ipv4 127. entry in your /etc/hosts, while "localhost" could use either. [by the way, you appear to have redundant ipv6 "localhost" entries in your /etc/hosts file. mostly to have things clean, i'd get rid of the bottom one.]