I'm not having any trouble with Office 2010 -- but I don't use IMAP/SMTP. Instead I am running
Sogo on my server and telling Outlook that my SME is an "Exchange Server"
Having said that --
When SME first started supporting TLS on port 25 (SME 7.?) it didn't work for me - ever since then one of the first things I do when setting up a new SME server is disable "TLS Before Auth" for qpsmtpd (
config setprop qpsmtpd TlsBeforeAuth 0; signal-event email-update), then setup clients to use SSL on port 465 instead of TLS on port 25.
As to why this problem might pop up on a system that used to work:
- More and more browsers are losing support for older versions of TLS and older cipher suites. This may be generating corresponding updates to default settings in SME, or you may have made some custom changes to improve server security. Any change intended to update or improve TLS might affect Outlook 2010 without affecting newer versions. I don't see any recent updates to SME components that are obvious candidates for TLS misbehavior, though.
- The recent emergency patches from Microsoft for
Windows 7 and
Office 2010 may have made changes related to TLS, SSL, and/or CipherSuite settings, and may be to blame. Or - if you haven't installed those patches yet, your Win7 systems may all have been infected using the wormable vulnerability addressed in the Windows 7 patch.
- I recently saw a system (albeit a mac, not a win7 system) infected with a malicious local proxy that hijacked dns and attempted to decrypt all communications as a man-in-the-middle. Luckily the software didn't work all that well and left the system misbehaving. I mention this because the misbehavior you're describing sounds similar to what I saw on that system.
Use
netstat -an |find /i "est" or
netstat -an |find /i "127.0.0" in a CMD prompt on the workstation while it is misbehaving to check. Unless your antivirus software includes a local proxy for email traffic, checking email should not create any connections to localhost.