Thanks for the confirmation, Thomas.  As it's the security of mobile (public AP) connections that I am most concerned about, what Xoom/K9 offers with CRAM-MD5 will do the job.  The use of CRAM-MD5 will provide protection for my logins (I will be the only mobile user using my server), specifically just the password, I suppose.  However, it seems that Mercury will still also accept plain logins.  It would seem better if CRAM-MD5 had to be used to login, but I don't know whether it is normally used in that way by IMAP4 servers.

Thank you

Gordon

The background to this is partially explained in an earlier thread I started concerned with SSL.  I have started a new thread because this all refers to Thunderbird as the mail client.  In summary, I want to to be able to use a Motorola Xoom tablet to access accounts on Mercury and also access these same accounts from several computer on my home LAN.  To do this, I switched from using no authentication to SSL.  As it is a one or the other situation for IMAP4 (no authentication or SSL, but not both), the computers on my home LAN also need to use SSL.  I am using IMAP4.

What I don't know is whether the following issues are problems with Thunderbird (3.1.10) or with Mercury (still 4.72) or some combination.

I am currently having four issues showing up when I start Thunderbird:

1. A temporary pop-up message appears saying "The current operation on "Inbox" did not succeed.  The mail server account [username] responded: Folder in use by other connections".  This happens when one of the other computers on the LAN is also running Thunderbird and includes the same account [username].  I can see that there are sometimes issues when two computers are accessing the same mailbox, but I have never had a failure situation arise (e.g. when using Windows Live Mail or Outlook Express, with no authentication set up for clients or server).  Despite this, I seem to be receiving mail in all of the user accounts.  If no other computers on the LAN are running Thunderbird I don't see this pop-up message.  The e-mail application (K9) on my Xoom can still be running and it doesn't cause the pop-up to appear.

2. A temporary pop-up message appears saying "The IMAP server [account name] does not support the selected authentication method.  Please change the authenitcation method in the Account/Server settings".

3. On one of the LAN computers (my wife's, so I need to get this fixed!), some attached received pictures are not completely shown by Thunderbird.  The top half of the picture is shown correctly, but the bottom half is just grey.  This has only happened when pictures have been attached wich are large, e.g. ~1MB or more.  Small pictures (<100KB) have never caused this problem so far.  Also, when there are several attached pictures, I have only seen one of them with this problem.  If I terminate Thunderbird and restart it, the pictures all show correctly.  I have tried synchonization to only download headers or the whole message and this makes no difference.

 4.  In the Thunderbird error log, I am seeing:

mydomain.com : server does not support RFC 5746, see CVE-2009-3555 .

I have looked at the Mercury IMAP4 error logs (general and session) and I see the following:

General Logging (just a sample)

[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 06:03:19 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 06:03:19 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 06:03:19 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 06:03:19 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:03:19 2011
Connection from 192.168.1.1, Thu Jun 16 06:04:12 2011
[Not-logged-in] at 192.168.1.1: 2 sec. elapsed, connection closed Thu Jun 16 06:04:14 2011
Connection from 192.168.1.1, Thu Jun 16 06:04:15 2011
Connection from 192.168.1.1, Thu Jun 16 06:10:12 2011
Connection from 192.168.1.1, Thu Jun 16 06:15:32 2011
Connection from 192.168.1.1, Thu Jun 16 06:35:48 2011
User2 at 192.168.1.1: 2120 sec. elapsed, connection closed Thu Jun 16 06:45:32 2011
User2 at 192.168.1.1: 1803 sec. elapsed, connection closed Thu Jun 16 06:45:35 2011
Connection from 192.168.1.1, Thu Jun 16 07:05:09 2011
User2 at 192.168.1.1: 1850 sec. elapsed, connection closed Thu Jun 16 07:06:38 2011
User2 at 192.168.1.1: 257 sec. elapsed, connection closed Thu Jun 16 07:09:26 2011
User2 at 192.168.1.1: 3911 sec. elapsed, connection closed Thu Jun 16 07:09:26 2011
Connection from 192.168.1.1, Thu Jun 16 07:10:48 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Thu Jun 16 07:10:48 2011
Connection from 192.168.1.1, Thu Jun 16 07:10:48 2011

Session Logging (in file TCP0000)

05:07:53.187: Connection from 192.168.1.104, Wed Jun 08 05:07:53 2011<lf>
05:07:53.187: << * OK mydomain.com IMAP4rev1 Mercury/32 v4.62 server ready.<cr><lf>
05:07:53.187: >> xag1 CAPABILITY<cr><lf>
05:07:53.187: << * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED X-MERCURY-1<cr><lf>
05:07:53.187: << xag1 OK CAPABILITY complete.<cr><lf>
05:07:53.187: >> 4ne8 LOGIN "account-name" "password"<cr><lf>
05:07:53.187: << 4ne8 NO LOGIN is not allowed unless STARTTLS has been issued.<cr><lf>
05:07:53.187: --- Connection closed normally at Wed Jun 08 05:07:53 2011. ---
05:07:53.187:
05:03:59.812: Connection from 192.168.1.1, Thu Jun 16 05:03:59 2011<lf>
05:03:59.812: << * OK mydomain.com IMAP4rev1 Mercury/32 v4.62 server ready.<cr><lf>
05:03:59.937: >> 1 CAPABILITY<cr><lf>
05:03:59.937: << * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED X-MERCURY-1<cr><lf>
05:03:59.937: << 1 OK CAPABILITY complete.<cr><lf>
05:03:59.140: >> 2 STARTTLS<cr><lf>
05:03:59.140: << 2 OK Begin SSL/TLS negotiation now.<cr><lf>
05:04:00.906: 22: Error -41 activating SSL session (locus 0, type 0, code 0, 'No data was read because the remote syst')
05:04:00.906: --- Connection closed normally at Thu Jun 16 05:04:00 2011. ---
05:04:00.906:

I don't understand why there are two dates in this file, unless the file is re-used in some way.  I think that the connection detail for Wed June 08 can be ignored, because I definitely had SSL incorrectly set-up at that time.

I have set up MercuryI to listen on Port 993; "Refuse access when no password is defined: is checked; Under the SSL tab, I have checked "Enable support for SSL/TLS secure connections" and "Disable plaintext logins for non-SSL connections".  I generated a self-signed certificate and allowed this to be accepted by the clients on first connection.

In Thunderbird, for the server settings, I have defined Port 993, Connection Security as STARTTLS and Authentication method as "Normal password".  (I wasn't sure about this, but using "Encrypted password" wouldn't work at all.

Any help on these issues would be much appreciated.

Thank you

Gordon

> In Thunderbird, for the server settings, I have defined Port 993,

Connection Security as STARTTLS
> and Authentication method as "Normal

password".  (I wasn't sure about this, but using "Encrypted
> password"

wouldn't work at all.

Port 993 is used for Direct SSL connections, have you tried using T-bird set to use SSL/TLS and password instead of STARTTLS?  I've got it working that way here with Mercury v4.73 and it works for me.

Thank you, Thomas.  That did the trick!  I updated to 4.73. and then used SSL/TLS and plaintext password and I no longer receive the pop-up error messages.  This wouldn't work at all with 4.72.  I don't know yet whether the problem with partially greyed-out pictures has also been solved, but I'll keep an eye on this.

Gordon

Not good news ....  As previously noted, using SSL/TLS and port 993 with Thunderbird (and SSL-only with K9 on my Xoom) seemed to cure the problem of the pop-up error messages and the other issues noted in the Mercury logs.  However, this morning, I found that none of the clients on any of the machines on my LAN would connect to Mercury.  According to Mercury's IMAP4 general log (unfortunately, I had turned off session logging, thinking that the problem was solved) the attempted connections were "Not logged in".  By coincidence (or not), the problems started to occur immediately (to the minute) after Mercury had undertaken the daily maintenance tasks (I follow this by an automatic re-start).

The error message from Thunderbird (there is nothing from K9) is:

 An error occurred during a connection to mydomain.com:993.<!--?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /-->

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

 In an attempt to try to get mail at all, I changed to STARTTLS/993 (TLS-only on K9) and this worked, except that I am back with the pop-up error messages from Thunderbird (K9 doesn't complain).

I have done a bit of research on this problem and it seems that the TB error shown above is fairly common.  However, it appears that this is specifically affecting the 3.1.XX branch of TB.  I am using 3.1.10 (I wonder what you are using Thomas?), which is the most recent stable version.  The solution for some TB users has been to use a 3.0.xx version of TB.  However, given that I also experienced problems with K9, the issue is not isolated to TB.

Any thoughts on this?

Thank you

Gordon

There were several problems again this morning.  None of the machines on the network would connect to the Mercury server. 

Again, as with the different problem the previous day, from the general IMAP log, the problem seemed to start very shortly after Mercury's daily maintenance at 2330.

 SSL direct-connect failure from 192.168.1.1, Sat Jun 18 23:33:33 2011

Thunderbird was reporting:

 Unable to connect to your IMAP server. You may have exceeded the maximum number of connections to this server. If so, use the Advanced IMAP Server Settings dialog to reduce the number of cached connections

I checked that the cached connections in TB were 1 (they were) for all accounts (there are 7 accounts on one machine and one on another).  I changed TB's mail checking so that it was less often (4 minutes) and disabled checking on start-up.  Session logging had been off, so I turned it back on.  After this last step, mail started to be downloaded to the clients again.

However, although mail seems to be being received, I am still seeing errors in the IMAP logs.  For example, I am seeing many cases on "[Not-logged-in]" ...... 

Connection from 192.168.1.1, Sun Jun 19 10:42:22 2011
[Not-logged-in] at 192.168.1.1: 0 sec. elapsed, connection closed Sun Jun 19 10:42:22 2011

I am also seeing the following type of error indication, several times in the IMAP session log .....

10:07:30.921: Connection from 192.168.1.1, Sun Jun 19 10:07:30 2011<lf>
10:07:30.921: << * OK mydomain.com IMAP4rev1 Mercury/32 v4.73 server ready.<cr><lf>
10:07:30.937: >>
10:07:30.937: << * BAD Malformed command or oversize literal.<cr><lf>
10:07:30.937: >> l÷»~gE†h¹Ñ
10:07:30.937: << * BAD Malformed command or oversize literal.<cr><lf>
10:07:30.937: >> ÀÀÀ
10:07:30.937: << * BAD Malformed command or oversize literal.<cr><lf>
10:07:30.937: >> ÀÀ<cr>ÀÀ
10:07:30.937: << * BAD Malformed command or oversize literal.<cr><lf>
10:07:30.937: >>
10:07:30.937: << * BAD Malformed command or oversize literal.<cr><lf>
10:07:31.203: 7: Socket read error 10054 (connection aborted by remote host)
10:07:31.203: --- Connection closed normally at Sun Jun 19 10:07:31 2011. ---
10:07:31.203:

I am still suspicious that the version of TB that I am using (3.1.10) is causing problems.  Could someone please confirm that they are successfully using this latest version with Mercury, using IMAP4 and SSL/TLS?  My next step, for lack of any other ideas, is to install an older version of TB, probably 3.0.11.

Any thoughts, anyone?

Thank you

Gordon

Gordon,

I'm using Mercury 4.73 and Thunderbird 3.1.10 under WinXP.  I've been using StartTLS with IMAP4 to a Nokia Smartphone for some time, with unencrypted local Thunderbird connections. I didn't think it necessary to encrypt traffic within my own subnet.   In response to your query I've enabled SSL/TLS in Thunderbird, and I can retrieve messages. The Mercury session log, however, suggests that authentication is by StartTLS, not SSL/TLS - presumably the fact that StartTLS is enabled in Mercury is meaning that SSL/TLS is not, although the MercuryI config doesn't actually say that.(It has the box checked for 'Enable support for SSL/TLS connections' but also 993 as the port in the section for 'Enable support for deprecated direct connection')

Does that help you at all? I'm reluctant to start reconfiguring Mercury as I'm only an amateur at this and have largely forgotten how I set it up 2 years ago; I don't want to break my current smartphone setup and I haven't time at present to re-educate myself in SSL.

Chris

Thank you for the reply, Chris.  We seem to have similar set-ups .... Thunderbird 3.1.10 under WinXP.  However, how are you getting Mercury to handle both remote STARTTLS and unencrypted local connections.  Are you, perhaps, not checking the box "Disable plaintext logins for non-SSL connections"?  I had avoided doing this, thinking that it was a security risk.  However, I don't have port 143 open on my firewall (993 is open), so maybe this is OK.  I am not sure.  If someone tried to connect through port 993 with a planetext login, would Mercury accept it, I don't know?  I am not bothered about encryption within my home LAN, so I don't really need to use STARTTLS or SSL/TLS for that purpose.  Thank you for trying out the local SSL/TLS connection.  It's useful to know that Thunderbird 3.1.10 is working for you for SSL/TLS.  In fact this worked for me until the daily maintenence check was completed, then I got errors (this might be a coincidence, of course).  Yes, my log seems to suggest that STARTTLS is involved, even when the Thunderbird setting is SSL/TLS.  I don't understand this either.

Don't break your setup for me [:)] 

Thank you.

Gordon

> I am still suspicious that the version of TB that I am using (3.1.10) is causing problems.  Could someone please confirm that they are
> successfully using this latest version with Mercury, using IMAP4 and SSL/TLS?  My next step, for lack of any other ideas, is to install an
> older version of TB, probably 3.0.11.

I am using Thunderbird v3.1.10 with Mercury/32 v4.73 with Direct SSL/TLS I have not disabled plain text login via port 143.  Sorry for the delayed answer, I was in Reno for the last couple of days.  I was doing my mail with a laptop but I did not know what version I was using with my test setup.

Thank you for the confirmation about your Thunderbird version, Thomas.  SSL/TLS seems to running satisfactorily here at the  moment, at least so far as the IMAP session log files seem to say.  I am not so sure about the IMAP general log.  It is still showing a lot of [Not-logged-in] lines.  I had assumed that this indicated connection failures, but maybe this is not correct.

I am guessing that, similar to Chris, you are probably doing plain logins within your LAN and SSL/TLS when you are travelling with your laptop etc.  I'll maybe allow the plaintext logins, though I am a bit concerned that someone could do an external plain login on the non-standard port 993.

Gordon

Things are getting very frustrating .... "management" here at home is being very patient, but this may not last [:)]  On 16 June, following Thomas' advice, I changed the Thunderbird clients on all of the networked machines to SSL/TLS/Port 993.  By 18 June, this had stopped working and I was getting:

An error occurred during a connection to mydomain.com:993.

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

 So, I changed all of the clients back to STARTTLS, and mail started to be received by the clients again, though there were some pop-up error messages from time-to-time in Thunderbird.

Then the STARTTLS connections stopped again and I switched back to SSL/TLS and mail was received once more!

(Very) Early this morning, SSL/TLS again stopped working, so I switched back to STARTLS and again all was well.

Later this morning, yet again mail stopped.  This time I set Mercury IMAP to allow plaintext logins on the SSL tab and set all of the clients on the LAN to use plain logins.  This now works, though I had to use Port 993.  I presume that this port is to be expected.  The LAN clients were using "mydomain.com" as the IMAP server.  However, I have now changed these to use to the server's IP address, 192.168.xxx.xxx and all is still well.  A bonus is that, if anyone tries to login with plaintext from outside of the LAN, Thunderbird recognizes this and asks for a password (even though a password has already been saved by Thunderbird's password manager, when connecting within the LAN).  It seems that Thunderbird recognizes the login source as different between account_name@mydomain.com and account_name@192.168.xxx.xxx .... so that provide a certain level of security.

So I have had to flip-flop between using SSL/TLS and STARTTLS to keep the mail flowing and I have no idea why.  Any ideas on this?

I am hopeful that the plaintext logins on the LAN will conitnue to work.  The other good news is that the Xoom K9 mail client is still working, though I have to use "TLS Only" rather than "SSL Only" ... there is no option that mentions STARTTLS.

Gordon

> I am guessing that, similar to Chris, you are probably doing plain logins within your LAN and SSL/TLS when you are travelling with your
> laptop etc.  I'll maybe allow the plaintext logins, though I am a bit concerned that someone could do an external plain login on the
> non-standard port 993.

But what's  the real problem if they do they and do this?  If it's a bad guy and gets the users credentials then they could login using the SSL/TLS.  If you maintain good password requirements (i.e. changing them every 90 days, require secure type passwords, limit the username and password to e-mail only, etc) generally this is not going to be a problem.

Thank you once again Thomas.  I have so far only been using within-LAN connections for IMAP4,  so I have rarely changed passwords.

I am assuming (I hope correctly) that by "using secure type passwords" you mean passwords with a random set of meaningless characters, e.g. 3Gyd1aA4g (that's not one of my actual passwords!) and not an encrypted password.  In Thunderbird, for the within-LAN clients, I have the IMAP server information set up with Connection Security - None and Authentication Method - Password, transmitted insecurely (the alternatives are Encrypted Password, Kerberos, GSSAPI or NTLM).  For the external mobile K9 mail client, I have TLS Always with Authentication - Plain (the only other alternative is CRAM_MD5).  I don't think that Mercury provides support for any of these alternatives (if it does, I can't see it anywhere).

Is what I have done what you would expect to see, for what I am trying to do?

Sorry that this is become such a long drawn-out issue!

Gordon

I also allow plain text logins. My logic was that access is protected by password; an unauthorised person attempting to login doesn't have the password. To get it, they would have to intercept my login; if it's on my LAN, it's not visible unless things have gone seriously wrong, by which point an email password would be of trivial value. But it can be intercepted if I login from outside my LAN, therefore it must be encrypted in that instance.

When I set up Thunderbird to use StartTLS or SSL/TLS, I did nothing with regard to port selection; I don't know where in Thunderbird I would do that. StartTLS automatically used 143, SSL/TLS automatically used 993. I use static IPs on my LAN so use the IP to identify the server in Thunderbird, so I did have to tell Thunderbird that the certificate which belonged to mydomain.com was acceptable to log in to the IP address.   On reflection, Thunderbird already knew about the certificate so it's possible I did set up SSL previously and then removed it.

Is it possible there's a firewall blocking you somewhere?

When you mention Thunderbird having cached the password, and then using it from outside the LAN, I assume you have it on a laptop and connect from different places, with a different account to allow for the change in server address?

For info, here's my SSL configuration. I've blanked the name of my certificate file, otherwise it's unedited.

> Thank you once again Thomas.  I have so far only been using within-LAN connections for IMAP4,  so I have rarely changed passwords.
>
> I am assuming (I hope correctly) that by "using secure type passwords" you mean passwords with a random set of meaningless characters, e.g.
> 3Gyd1aA4g (that's not one of my actual passwords!) and not an
> encrypted password.  

Ideally a password should be 10 characters long and contain both numbers and characters.  With my setups the e-mail username and password is different that the username and password that is used to protect other data.  The critical (classified) data is also held on separate servers with no connection to the outside.  

> In Thunderbird, for the within-LAN clients, I have the IMAP server information set up with Connection Security - None and Authentication
> Method - Password, transmitted insecurely (the alternatives are Encrypted Password, Kerberos, GSSAPI or NTLM).  

I use both STARTTLS and TLS/SSL connections to Mercury.  And password authentication.

> For the external mobile K9 mail client, I have TLS Always with Authentication - Plain (the only other alternative is CRAM_MD5).  I
> don't think that Mercury provides support for any of these alternatives (if it does, I can't see it anywhere).

David Harris has implemented ESMTP AUTH CRAM-MD5 for WinPMail.  It does a SMTP authentication in accordance with RFCs 2554 and 2195.  It will also do the LOGIN and the strange MS AUTH=LOGIN.  I use CRAM-MD5 for the clients that support is since it encrypts the username and password sent to the server.

Chris - Thank you for the detailed explanation.  Your requirement and set-up sounds almost identical to what I have at the moment.  The portable machine, as mentioned earlier is a Motorola Xoom tablet and I plan to always having it living outside of the LAN.  When I first set-up all of this, all of the machines were using my Internet domain address as the server address and on first connection, I accepted the certificate on each of them.  When I changed the server address for the machines inside the LAN to the local IP address, there was no new certificate acceptance and mail still arrived in the clients, with the chequered history that I have already described.  At various times, I was switching the Thunderbird clients between SSL/TLS and STARTTLS and I changed the default port of 143  for STARTTLS to 993 (this is easy to do on the Server Settings section of Thunderbird accounts).  This was because I had set up port-forwarding in my router for port 993 and not 143.  Maybe, I should have changed this port-forwarding to 143 when I was using STARTTLS.  I am not sure whether this matters.

So far, since this morning, I have had no problems using the same within-LAN set-up as you and using "TLS always" on K9.  I don't know whether K9 is using STARTTLS.  An option specifically named STARTTLS isn't provided by K9.  From what I have read about K9, I don't think that passwords are transmitted in the clear when using "TLS always", but I am not 100% sure about this.

The setup that I am trying to use may well be temporary as my preference would be use a VPN, which provides much more flexibility than just for protecting e-mail, i.e. using network shares, as the travelling machine effectivley lives inside the LAN.  I have used this approach with my netbook.  However, my new tablet can't use my preferred VPN solution (OpenVPN) unless it is "rooted", which voids the warranty.  So, I want to wait  until I get past a reasonable "infant mortality" point before rooting.

Thomas has raised some points that I don't understand, but I'll have to wait unitl tomorrow to take these up with him, as it's getting late here.

Thank you

Gordon

Well, I didn't think things could get any worse, but they have!  I have been happily using TB with Mercury for the last 3 or 4 days.  The TB set-up I have been using for the locally (LAN) connected machines, which worked, is:

Server name: The local IP address .... 192.168.1.101

Port: 993

Security Settings: Connection Security - None, Authentication method - Password, transmitted insecurely.

Server settings/Advanced/Maximum number of server connections to cache: 1

On the Mercury side, I have:

Under General

Listen on port: 993

Under Connection control

Nothing refused.

Under SSL 

Enable support for SSL/TLS connection - Checked

Disable plaintext logins fo non-SSL connecitons - Unchecked

Support for depracated direct-connect SSL, Port 993

However, TB is now no longer connecting to Mercury and I get a pop-up message in TB, saying tht there are too many cached connections.  The number of cached connections set in TB is 1, so I don't see how this is the problem.

The Mercury session log is showing a time-out, i.e.

09:17:00.687: Connection from 192.168.1.104, Thu Jun 23 09:17:00 2011<lf>
09:17:30.703: 22: Error -25 activating SSL session (locus 0, type 0, code 0, 'Timeout on read (select()) after 30 seconds')
09:17:30.703: --- Connection closed normally at Thu Jun 23 09:17:30 2011. ---
09:17:30.703:

This is happening to both machines that I have running TB on the LAN.

The only change, of which I am aware, that has recently happened is that there has been an automatic update from TB 3.1.10 to 3.1.11.  This happened yesterday, and TB/Mercury continued to work together immediately after the update.  Whenever I have problems, they seem to happen overnight!

So, another plea for help [:(]  Any ideas?

Thank you

Gordon

A P.S. to my previous post .... I am now able to receive mail but, to do this, I have had to set TB to use SSL/TLS under Connection security.  This continues the circle that I have found myself in.  I fully expect that, tomorrow, SSL/TLS will stop working and I will have to switch to STARTTLS or no security.

Another oddity is that for just one account (there are 7 set up on this particular machine), using SSL/TLS, there was a pop-up error message from TB, stating that it couldn't connect, because the connection to that account was already in use (I forget the exact words).  This has happened before from time-to-time and seems to be inconsistent with the use of IMAP).  Ten minutes later, without me changing any of the TB settings for this account, the account started to receive mail and there were no longer any error messages!

Gordon

I have a little more evidence ....  At 1550 today, I changed the time for performing Daily Maintenance Tasks to 1600.  It has normally been at 2330 each day.  I also checked the box to restart Mercury after the check (as I have always done).  I don't think that the restart is necessary, but I wanted to change as few things as possible.  Prior to the Maintenance time, all accounts were working well with Thunderbird set to SSL/TLS.  After the Maintenance time, none of the accounts worked and I received the TB error:

An error occurred during a connection to 192.168.1.101:993.

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

I then changed all of the accounts back to STARTTLS/993 and mail service was restored again to all accounts.  At 1615, I tried to force another maintenance check, to see if STARTTLS would stop functioning.  The maintenance check didn't happen.  Maybe there is a minimum time before another check can be made or maybe there can only be one per calendar day.

I realize that I am not using the normal port for STARTTLS, as the default seems to be 143.  Maybe this is a problem, but I don't see why it should stop SSL/TLS from functioning.

Gordon

P.S. A very trivial question .... When I am using the PMail forum, when I want to add a new line, it always appears double-spaced.  Is this to be expected?

In Thunderbird, the default port changes automatically depending on whether you're using StartTLS, SSL/TLS or nothing. I've let mine follow the default. My Mercury is set to 'Listen on 143' - otherwise I think the settings are the same as yours. I do have a Thunderbird client on the same box as Mercury; the IP for that is 127.0.0.0 to avoid conversations going via the router. I'm still on 3.1.10 as auto-update doesn't work for me.

 Are you sure the problems are due to using encryption, or might it just be co-incidence? The error messages suggest a different cause entirely. I also get messages about not being able to carry out an operation, because of another connection. This is by design, a result of Mercury not supporting deletion (EXPUNGE) when more than one client is connected to the account. Prior to 4.73, they only appeared occasionally, even though I usually had two clients connected. A few oddities occurred after I went to 4.73, until I edited the Thunderbird config to set mail.server.default.fetch_by_chunks to false- since then, if I move or delete a mail, I get that error. I ignore them but when I've finished I close Thunderbird, and Mercury then only has one client - so it carries out all the saved operations. When I restart it, everything has moved as I intended. But only since I changed that config to false - prior to that I was getting random odd behaviour.

The other thing that made Thunderbird behave randomly was the Synchronisation introduced in version 3.0 - it spend so much time syncing it was unusable, so I turned Synchronisation off.

Chris

Composed without seeing your latest post, Gordon. It's possible that not using the default port in TB is confusing Mercury, since you have set 993 in in the IMAP4 SSL config.