Using ssl/tls instead of starttls (port 465) would appear to bypass this issue.
However, that usage is depreciated in favour of starttls I believe so possibly not a wise move just to address this issue.
And local clients would be using port 587 anyway not 25 (or should be), you can enforce ssl on login events using:
g_ssl_require_login "*"
Thats probably the most secure fix if your users can all use ssl.
ChrisP.
In light of the information described from the link below, I was wondering what might be the best strategies to insure that our users aren’t having their e-mail connections unwittingly reduced to the non-SSL variety, despite their mail client settings:
We currently have our servers configured with SSL enabled on the appropriate ports for all mail services (IMAP, SMTP, Surgeweb), but we’ve also left the default parts, namely 25, 110, 143, open for clients that seem to use these to initiate and then escalate to StartTLS (pardon the errors in my characterization), if I’m understanding that process correctly. I’d like to lock down our servers to restrict all communications to SSL protected ones. A quick scan of the status pages shows that all users are currently already connecting via SSL.
Is the only way to do this to simply shut down the default non-SSL ports? Is there another flag that could be set to allow initial contact for the sake of launching StartTLS but then rejecting further communications if SSL is not established?
If disabling the non-SSL ports is the best method, I’m assuming that I simply insert “disabled” in place of the port numbers. If doing so for the POP 110 ports, does this affect Surgemail mirroring? I have my g_mirror_nossl unchecked since my servers are connected via the open internet, but I don’t know if it uses the same port for SSL connections or uses 995 exclusively.
Thanks for any advice.
-Mike
