Re: Mail has quit working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




> Date: Sunday, August 26, 2018 21:10:48 -0400
> From: TE Dukes <tdukes@xxxxxxxxxxxxxxxxxxx>
> 
>> From: CentOS [mailto:centos-bounces@xxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx>
>> > 
>> >> From: CentOS [mailto:centos-bounces@xxxxxxxxxx] 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.]


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux