Pegasus Mail & Mercury

Hi everyone,

I just messed up my 4.51 by installing the new 4.62. 

The POP3 Server now takes ages to respond, up to 1200 sec.

Connection History: 

"Connected from 192.168. ... "

"User xyz, (10) 11 messages, 87830 bytes"

"1297 sec. elapsed, connection closed" 

I'm using Thunderbird as client and it does not recive a single message anymore.

Just an error-message connection timed out.

I tried raising the timeouts, but no chance. 

Any clues to get it back to 4.51 ? 

Checkout your settings in the POP3 server.  There have been a number of updates to the server and one of them relates to how the messages are stored on the server.  If you have the new setting then all mail on the server will be downloaded and that could be taking a long time.

"Use 'Daylight Savings-proof' message IDs  Without getting too technical, part of the POP3 protocol involves assigning what are known as unique IDs (UIDs) to messages. A message's UID should never change during its time in the POP3 mailbox and it is intended as a means by which POP3 client programs can remember whether or not they have seen a particular message during a previous connection. In the past, Mercury calculated a message's UID based partly on the file creation time maintained by the Windows operating system, but it turns out that there is a serious and long-standing bug in Windows that makes this unreliable: put simply, Windows applies the current Daylight Savings Time (DST) adjustment to all file timestamps, even files that were created when the DST adjustment did not apply!  So, after a DST change, many files on your hard drive or server will suddenly appear have different times. This bug impacts on Mercury by throwing out its calculated UIDs: as a result, after a DST change, your POP3 clients will see new UIDs for the messages in the mailbox and will typically download them all again. Checking this control tells Mercury to use a different method of calculating the UIDs for messages - one not affected by the Windows bug, but you should be aware that changing to it will result in all your POP3 clients re-retrieving all their mail one last time, as a reaction to the new UIDs that are generated. After that one final redundant download, though, there will be no future occurrences. We strongly recommend that you check this control as soon as circumstances permit, or if it is already checked, that you never uncheck it." 

In any case, turn on MercuryP session logging to provide us with more details of the problem.

What does a session log (turn it on for this purpose in MercuryP) of such POP3 connection give?

Maybe it's less effort to solve this by debugging than downgrading?

What does a session log (turn it on for this purpose in MercuryP) of such POP3 connection give?

Shows you exactly what is going on between the server and the client at the TCP/IP level Without this you are just guessing about what is really happening to cause the delay.

 

Dear Thomas,

I turned on the "Daylight Savings" at the start, because it was recommended.

Here is a session logging from a thunderbird-client and Mercury:

10:10:42.209: Connection from 192.168.1.xx, Fri Jul 04 10:10:42 2008
10:10:42.209: << +OK <xxx@xxx.yy>, POP3 server ready.<cr><lf>
10:10:42.209: >> CAPA<cr><lf>
10:10:42.209: << +OK Capability list follows<cr><lf>
10:10:42.209: << USER<cr><lf>
10:10:42.209: << TOP<cr><lf>
10:10:42.209: << UIDL<cr><lf>
10:10:42.209: << EXPIRE NEVER<cr><lf>
10:10:42.209: << .<cr><lf>
10:10:42.229: >> USER Test<cr><lf>
10:10:42.229: << +OK Test is known here.<cr><lf>
10:10:42.249: >> PASS xxxxxxxxxx<cr><lf>
10:13:52.262: << +OK Welcome! 6 messages (3702 bytes)<cr><lf>
10:13:52.272: --- Connection closed normally at Fri Jul 04 10:13:52 2008. ---
10:13:52.272: 

as you can see it took 10 sec between the PASS and the respond.

Thunderbird is pissed then and gives me a timeout message, I have raised the timeout on the client, no way.

The only "working" client over here is an old Mozialla 1.7.1(!)  - this thing stays cool till everything is deliverd.

By the way it was 4.52 not 4.51 

More Info needed ?

Best regards

Based on the timestamps in the log I would say it took 3 minutes 10 secs to verify login and scan the mailbox. This is quite abnormal behavior. My first guess would be some kind of disk error that causes lots of retries on the OS level. Check the event log on the server and run Chkdsk. It might also be a good idea to make sure that no realtime anti-virus software tries to monitor the mailbox directories.

/Rolf 

10:10:42.249: >> PASS xxxxxxxxxx<cr><lf>
10:13:52.262: << +OK Welcome! 6 messages (3702 bytes)<cr><lf>

As noted it took 3 minutes and 10 seconds to respond.  I've been trying to think of any reason at all for this delay caused by a configuration error and I cannot.  Now we need to know more about your actual setup.

1.    Do you get this delay for all users? one user?  some users?

2.    Does the Mozilla client user session log also show this abnormal delay?

3.    Is there anything at all special about your setup?  Novell?  Raid? Virtual box?

I will check later on with chkdsk if there are any OS file errors, right now I have to

"remote" my girlfriend, so I prefer to mess up my system myself ;-)

I do not have any virus scanner on the server, I can smell them.

Best regards

1. On ALL users, execpt the ones with NO mail, they are below a sec. Mail takes them 20-120 sec.

2. I have to check, Thunderbirds just give up with a time-out error. Mozilla just keeps on working, the good old modem version is relaxed.

3. OS is W2K - SP4, no virus, no Novell or raid, nothing only OS and Merury.  I had spamhalter and disabled it. Seems to make no differenz.

The funny thing is OUTGOING Mail is as fast as ever. 

Best regards 

Sauger53:

1. On ALL users, execpt the ones with NO mail, they are below a sec. Mail takes them 20-120 sec.

The 20 seconds is no big deal, the 120 could also be normal if they are storing a lot of mail on the server.   

2. I have to check, Thunderbirds just give up with a time-out error. Mozilla just keeps on working, the good old modem version is relaxed.

Do you have any other POP3 mail client around you can test with? 

3. OS is W2K - SP4, no virus, no Novell or raid, nothing only OS and Mercury.  I had spamhalter and disabled it. Seems to make no differenz.

Pretty straight forward, Spamhalter should not make any difference to the login.

The funny thing is OUTGOING Mail is as fast as ever. 

Best regards 

Thanks for all the help to everyone !

Here is what I did over the weekend - in short.

I took the whole Mercury over to a other pc with more "power".

Everthing works fine now, guess it was "just" my shitty pc that could not keep up with the new tasks :-(

 
Thanks again for all the assist and help !

Best regards 

A POP3 check in itself won't require much computing power, actually. But it's good to hear it works now!

/Rolf