Yes, I am pretty sure about that.  I originally was connected via AT&T 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 listening on the imaps port and forwarding to dovecot listening on the imap port.

I was getting connection refused on my laptop (thunderbird) email client when I was not at home.  I validated that it was not because it was reaching my email server.  So who ever was rejecting it, I assumed it was somewhere inside the comcast network.  Once I switch to a non-standard port, I was able to connect again.

Re needing to say ssl = yes, I thought that was implied for imaps?

I can go back to stunnel, just thought it was an unnecessary layer.

Thanks,

Patrick


On Mon, Jan 21, 2019 at 8:46 PM @lbutlr <kremels@kreme.com> wrote:
On 21 Jan 2019, at 20:17, Patrick Mahan <plmahan@gmail.com> 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 110, they block DHCP, NETBIOS, SNMP, and ports 445, 520, and 1080. They will block port 25 on a individual basis, but I've no idea what their criteria is for that.

> I need to have my clients connect to non-standard port (9999).  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 have my imap clients connect remotely.

An stunnel or a reverse proxy is the best way to do this, honestly.

As for why your config isn't working, my only guess is maybe you need to specify ssl?

 inet_listener imaps {
      port = 999
      ssl = yes
   }

?


--
If you write the word "monkey" a million times, do you start to think you're
Shakespeare? -- Steven Wright