Another possible thing, I don't know what the bug is or if it is fixed,
but few years ago Thunderbird (on CentOS 7) for me refused to connect to
Port 993 or Port 465 if I used a self-signed certificate even though the
same certificate worked when using STARTTLS and port 143 and 587. The
error
Comcast DNS servers enforce dnssec, AT does not (last I checked). If
by chance your zone has DNSSEC enabled but mis-configured then it is
possible the domain name you use for the dovecot server is not resolving
because of a dnssec validation failure.
I have never heard of comcast or any ISP
On Tue, 22 Jan 2019 at 06:17, Patrick Mahan wrote:
> Dovecot 2.3.4, FreeBSD 11.2
>
> Due to comcast buisness ISP intercepting imaps I need to have my clients
> connect to non-standard port (). Previously I had been using stunnel
> to receive the imaps connection and forward it to the imap
On 21 Jan 2019, at 21:58, Patrick Mahan wrote:
> Re needing to say ssl = yes, I thought that was implied for imaps?
I would think so, but all the examples I found in a quick search explicitly set
it when changing the port.
Also, unlike regular comcast, I have found the tech support on their
Yes, I am pretty sure about that. I originally was connected via AT DSL
but wanted the fast access of cable modem. I need permanent IPs which
required me to contract with Comcast buisness. Once I switched over, I was
no longer able to access my imap server, which was as I mentioned, stunnel
On 21 Jan 2019, at 20:17, Patrick Mahan wrote:
> Due to comcast buisness ISP intercepting imaps
At you sure about that? I've been using comcast business for 7 years and the do
not block 143, 993 587 or 25. they do block 110, but that's fine, I stopped
supporting POP around 2001.
Other than
Dovecot 2.3.4, FreeBSD 11.2
Due to comcast buisness ISP intercepting imaps I need to have my clients
connect to non-standard port (). Previously I had been using stunnel
to receive the imaps connection and forward it to the imap port over
127.0.0.1. But I would like to retire stunnel and
