> Date: Sunday, August 26, 2018 16:25:14 -0400
> From: TE Dukes <tdukes at palmettoshopper.com>
>
>> -----Original Message-----
>> 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
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.
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]
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.
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.
While you are at it, could you show the current state of your
/etc/hosts file (as well as its ownerships and permissions).