[CentOS] Mail has quit working

Richard
2018-08-27T02:25:28Z

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