Thanks for the report. As you say, it does not show any unexpected messages.

The problem might simply be something to do with the volume of mail varying between the various accounts. By default the Windows version of POPFile only processes one email account at a time, so if Pegasus uses POPFile to checks accounts A, B, C, D, and E then POPFile will process all of the new mail for account A before it moves on to check all of the new mail for account B, then all of the new mail for account C, and so on.

Therefore it is possible that sometimes Pegasus will timeout and complain about a lack of response - even though nothing has gone wrong.

You might be able to stop this from happening if you increase the timeout Pegasus uses to detect this "lack of response" problem.

Here is some information from the Release Notes that explains this phenomenon:

<snip>

2. ON WINDOWS I WANT TO CHECK MULTIPLE EMAIL ACCOUNTS SIMULTANEOUSLY.

Because the time taken to start a new process on Windows is long under Perl there is an optimization for Windows that is present by default: when a new connection is made between your email program and POPFile, POPFile handles it in the 'parent' process. This means the connect happens fast and mail starts downloading very quickly, but it means that you can only download messages from one server at a time (up to 6 other connections will be queued up and dealt with in the order they arrive) and the UI is unavailable while downloading email.

You can turn this behavior off (and get simultaneous UI/email access and as many email connections as you like) on the Configuration panel in the UI by making sure that "Allow concurrent POP3 connections:" is Yes, or by specifying --set pop3_force_fork=1 on the command line.

The default behaviour (no concurrent POP3 connections) can cause email clients to time out if several accounts are being checked (because POPFile only handles one account at a time it can take a while to process all of the accounts).

If SSL support is being used then the default setting (no concurrent POP3 connections) _MUST_ be used otherwise POPFile crashes.

</snip>

Brian

Are we then at a dead end?

Not yet.

Perhaps the problem is that the POP3 server is taking a while to respond. Apparently, it doesn't send any greeting:

12:36:16 1444: pop3: 559: Connection returned:

We should expect to see the server's banner after that colon.

You could simply try to raise your timeout in POPFile to some larger value and see whether this makes the problem go away. Go to POPFile's configuration tab and find the timeout widget on the lower left. Double the current value and test.

Manni

Are we then at a dead end?

No, I don't think so.

If you have POPFile configured to use the default POP3 listen port (110) I suggest you change this to, say, port 123 and change Pegasus to use port 123 for the accounts which are handled by POPFile. So your setup will then be like this:

Pegaus -- port 123 -- POPFile -- port 110 -- mail server

There is more information about this in the wiki (e.g. Proxy Chaining). That wiki page mentions more than just changing the POP3 listen port but I think only that setting needs to be changed.

In theory Pegasus should be able to use port 110 to communicate with POPFile but I've never trusted that sort of setup and have always used a non-standard POP3 listen port.

Another thing to look at is what the POPFile log file shows when Pegasus is able to collect mail via POPFile - is there a text string shown after the "Connection returned:" part of the relevant log entry?

Brian