Okay, I did the following things:

a) changed the timeout to 360 seconds

b) got an advanced log:

    --- Wed, 24 Dec 2008 23:29:23 ---
    Connect to 'pop.googlemail.com' port 995, timeout 360.
    23:29:24.468 [*] Connection established to 64.233.183.16
    23:29:25.546 [*] SSL/TLS session established: RC4, OFB mode, keysize 128 bits
    23:29:25.546 [*] Certificate user is cn=pop.googlemail.com, o=Google Inc, l=Mountain View, sp=California, c=US
    23:29:25.546 [*] Certificate is valid from Fri Mar 14 23:23:24 2008 to Sat Mar 14 23:23:24 2009
    23:29:25.546 [*] Certificate fingerprint is 1625F9975881CC05029737ACABDE0103
    23:29:25.562 >> 0065 +OK Gpop ready for requests from 92.24.33.204 h1pf6139116nfh.25\0D\0A
    23:29:25.562 << 0032 USER richardsem@googlemail.com\0D\0A
    23:29:26.500 >> 0015 +OK send PASS\0D\0A
    23:29:26.500 << 0013 PASS XXXXXX\0D\0A
    23:29:27.250 >> 0014 +OK Welcome.\0D\0A
    23:29:27.250 << 0006 STAT\0D\0A
    23:29:28.843 >> 0017 +OK 109 9692770\0D\0A
    23:29:28.843 << 0006 LIST\0D\0A
    23:29:28.156 >> 0034 +OK 109 messages (9692770 bytes)\0D\0A
    23:29:28.156 >> 0008 1 1527\0D\0A
    23:29:28.156 >> 0009 2 16711\0D\0A
    23:29:28.156 >> 0008 3 1478\0D\0A
    23:29:28.156 >> 0009 4 18296\0D\0A
    23:29:28.156 >> 0009 5 50950\0D\0A
    23:29:28.156 >> 0008 6 7871\0D\0A
    23:29:28.156 >> 0009 7 15746\0D\0A
    23:29:28.156 >> 0009 8 16015\0D\0A
    23:29:28.156 >> 0009 9 11651\0D\0A
    23:29:28.156 >> 0010 10 20348\0D\0A
    23:29:28.156 >> 0010 11 21056\0D\0A
    23:29:28.156 >> 0009 12 6631\0D\0A
    23:29:28.156 >> 0009 13 1373\0D\0A
    23:29:28.156 >> 0010 14 15351\0D\0A
    23:29:28.156 >> 0010 15 39260\0D\0A
    23:29:28.156 >> 0011 16 111522\0D\0A
    23:29:28.156 >> 0009 17 8333\0D\0A
    23:29:28.156 >> 0011 18 112048\0D\0A
    23:29:28.156 >> 0010 19 30587\0D\0A
    23:29:28.156 >> 0008 20 927\0D\0A
    23:29:28.156 >> 0009 21 1532\0D\0A
    23:29:28.156 >> 0010 22 31602\0D\0A
    23:29:28.156 >> 0010 23 21936\0D\0A
    23:29:28.156 >> 0010 24 27338\0D\0A
    23:29:28.156 >> 0010 25 27825\0D\0A
    23:29:28.156 >> 0010 26 20521\0D\0A
    23:29:28.156 >> 0009 27 2569\0D\0A
    23:29:28.156 >> 0009 28 2940\0D\0A
    23:29:28.156 >> 0010 29 56894\0D\0A
    23:29:28.156 >> 0009 30 8404\0D\0A
    23:29:28.156 >> 0010 31 20137\0D\0A
    23:29:28.156 >> 0009 32 5186\0D\0A
    23:29:28.156 >> 0010 33 34367\0D\0A
    23:29:28.156 >> 0009 34 7965\0D\0A
    23:29:28.156 >> 0010 35 60740\0D\0A
    23:29:28.156 >> 0009 36 8837\0D\0A
    23:29:28.156 >> 0009 37 1476\0D\0A
    23:29:28.156 >> 0009 38 2706\0D\0A
    23:29:28.156 >> 0009 39 2019\0D\0A
    23:29:28.156 >> 0009 40 5663\0D\0A
    23:29:28.156 >> 0009 41 1361\0D\0A
    23:29:28.156 >> 0009 42 5364\0D\0A
    23:29:28.156 >> 0010 43 38377\0D\0A
    23:29:28.156 >> 0010 44 65946\0D\0A
    23:29:28.156 >> 0010 45 25351\0D\0A
    23:29:28.156 >> 0009 46 3379\0D\0A
    23:29:28.156 >> 0009 47 3327\0D\0A
    23:29:28.156 >> 0011 48 256787\0D\0A
    23:29:28.156 >> 0009 49 4100\0D\0A
    23:29:28.156 >> 0010 50 82143\0D\0A
    23:29:28.156 >> 0010 51 13280\0D\0A
    23:29:28.156 >> 0010 52 13547\0D\0A
    23:29:28.156 >> 0009 53 9936\0D\0A
    23:29:28.156 >> 0009 54 3956\0D\0A
    23:29:28.156 >> 0009 55 2678\0D\0A
    23:29:28.156 >> 0010 56 61019\0D\0A
    23:29:28.156 >> 0009 57 8780\0D\0A
    23:29:28.156 >> 0010 58 62972\0D\0A
    23:29:28.156 >> 0009 59 7661\0D\0A
    23:29:28.156 >> 0010 60 11970\0D\0A
    23:29:28.156 >> 0009 61 6935\0D\0A
    23:29:28.156 >> 0010 62 14390\0D\0A
    23:29:28.156 >> 0012 63 1141331\0D\0A
    23:29:28.156 >> 0009 64 5043\0D\0A
    23:29:28.156 >> 0010 65 51759\0D\0A
    23:29:28.156 >> 0009 66 3195\0D\0A
    23:29:28.156 >> 0010 67 11615\0D\0A
    23:29:28.156 >> 0010 68 58537\0D\0A
    23:29:28.156 >> 0010 69 29371\0D\0A
    23:29:28.156 >> 0010 70 18033\0D\0A
    23:29:28.156 >> 0011 71 438752\0D\0A
    23:29:28.156 >> 0009 72 5310\0D\0A
    23:29:28.156 >> 0009 73 4811\0D\0A
    23:29:28.156 >> 0009 74 2239\0D\0A
    23:29:28.156 >> 0011 75 438418\0D\0A
    23:29:28.156 >> 0009 76 2299\0D\0A
    23:29:28.156 >> 0010 77 75708\0D\0A
    23:29:28.156 >> 0010 78 27530\0D\0A
    23:29:28.156 >> 0012 79 3392882\0D\0A
    23:29:28.156 >> 0010 80 10525\0D\0A
    23:29:28.156 >> 0009 81 2421\0D\0A
    23:29:28.156 >> 0009 82 1349\0D\0A
    23:29:28.156 >> 0009 83 5664\0D\0A
    23:29:28.156 >> 0009 84 3962\0D\0A
    23:29:28.156 >> 0009 85 8557\0D\0A
    23:29:28.156 >> 0010 86 13707\0D\0A
    23:29:28.156 >> 0009 87 3885\0D\0A
    23:29:28.156 >> 0009 88 2233\0D\0A
    23:29:28.156 >> 0010 89 74971\0D\0A
    23:29:28.156 >> 0010 90 65056\0D\0A
    23:29:28.156 >> 0010 91 64077\0D\0A
    23:29:28.156 >> 0010 92 10464\0D\0A
    23:29:28.156 >> 0009 93 2902\0D\0A
    23:29:28.156 >> 0009 94 8764\0D\0A
    23:29:28.156 >> 0010 95 34330\0D\0A
    23:29:28.156 >> 0009 96 7582\0D\0A
    23:29:28.156 >> 0009 97 7479\0D\0A
    23:29:28.156 >> 0011 98 730530\0D\0A
    23:29:28.156 >> 0009 99 1233\0D\0A
    23:29:28.156 >> 0010 100 1955\0D\0A
    23:29:28.156 >> 0011 101 13814\0D\0A
    23:29:28.156 >> 0013 102 1284925\0D\0A
    23:29:28.156 >> 0010 103 6299\0D\0A
    23:29:28.171 >> 0011 104 11536\0D\0A
    23:29:28.171 >> 0010 105 6683\0D\0A
    23:29:28.171 >> 0011 106 17732\0D\0A
    23:29:28.171 >> 0010 107 7866\0D\0A
    23:29:28.171 >> 0011 108 12390\0D\0A
    23:29:28.171 >> 0010 109 1449\0D\0A
    23:29:28.171 >> 0003 .\0D\0A
    23:29:28.171 << 0008 UIDL 1\0D\0A
    23:29:28.515 >> 0031 +OK 1 GmailId11e3ab7d94b89720\0D\0A
    23:29:28.515 << 0009 TOP 1 1\0D\0A
    23:29:29.906 >> 0021 +OK message follows\0D\0A
    23:29:29.906 >> 0076 Received: by 10.151.116.1 with HTTP; Mon, 15 Dec 2008 04:56:14 -0800 (PST)\0D\0A
    23:29:29.906 >> 0075 Message-ID: <4d8649f50812150456m18585313i8837bab5e1408e41@mail.gmail.com>\0D\0A
    23:29:29.906 >> 0039 Date: Mon, 15 Dec 2008 12:56:14 +0000\0D\0A
    23:29:29.906 >> 0049 From: "Michael Richards" <richardsem@gmail.com>\0D\0A
    23:29:29.906 >> 0047 To: "Phil Covell" <pcovell@forest-trends.org>\0D\0A
    23:29:29.906 >> 0032 Subject: FT calendar of events\0D\0A
    23:29:29.906 >> 0019 MIME-Version: 1.0\0D\0A
    23:29:29.906 >> 0039 Content-Type: multipart/alternative; \0D\0A
    23:29:29.906 >> 0052 \09boundary="----=_Part_28912_9772686.1229345774018"\0D\0A
    23:29:29.921 >> 0036 Delivered-To: richardsem@gmail.com\0D\0A
    23:29:29.921 >> 0002 \0D\0A
    23:29:29.921 >> 0042 ------=_Part_28912_9772686.1229345774018\0D\0A
    23:29:29.921 >> 0003 .\0D\0A
    23:29:29.921 << 0008 UIDL 2\0D\0A
    23:29:29.250 >> 0031 +OK 2 GmailId11e3ac341ec77bc7\0D\0A
    23:29:29.250 << 0009 TOP 2 1\0D\0A
    23:29:29.640 >> 0021 +OK message follows\0D\0A
    23:29:29.640 >> 0076 Received: by 10.151.116.1 with HTTP; Mon, 15 Dec 2008 05:08:41 -0800 (PST)\0D\0A
    23:29:29.640 >> 0075 Message-ID: <4d8649f50812150508s424df607uc5f4e02492ad92ed@mail.gmail.com>\0D\0A
    23:29:29.640 >> 0039 Date: Mon, 15 Dec 2008 13:08:41 +0000\0D\0A
    23:29:29.640 >> 0049 From: "Michael Richards" <richardsem@gmail.com>\0D\0A
    23:29:29.640 >> 0056 To: "Luttrell, Cecilia (CIFOR)" <C.LUTTRELL@cgiar.org>\0D\0A
    23:29:29.640 >> 0152 Subject: Re: FW: Invitation: Moving Ahead with REDD - Forest Day 2 Side event, 6 Dec. 2008, 4.30pm, Room 323 of the Adam Mickiewicz University, Poznan\0D\0A
    23:29:29.640 >> 0085 In-Reply-To: <CB272BA23AECE648A656E83082F759FF0852E857@cifor2k12.CIFOR.CGIARAD.ORG>\0D\0A
    23:29:29.640 >> 0019 MIME-Version: 1.0\0D\0A
    23:29:29.640 >> 0039 Content-Type: multipart/alternative; \0D\0A
    23:29:29.640 >> 0053 \09boundary="----=_Part_29018_17060106.1229346521604"\0D\0A
    23:29:29.640 >> 0084 References: <CB272BA23AECE648A656E83082F759FF0852E857@cifor2k12.CIFOR.CGIARAD.ORG>\0D\0A
    23:29:29.640 >> 0036 Delivered-To: richardsem@gmail.com\0D\0A
    23:29:29.640 >> 0002 \0D\0A
    23:29:29.640 >> 0043 ------=_Part_29018_17060106.1229346521604\0D\0A
    23:29:29.640 >> 0003 .\0D\0A
    23:29:29.640 << 0008 UIDL 3\0D\0A
    23:29:30.062 >> 0031 +OK 3 GmailId11e3ac8e32eed500\0D\0A
    23:29:30.062 << 0009 TOP 3 1\0D\0A
    23:29:31.937 >> 0021 +OK message follows\0D\0A
    23:29:31.937 >> 0076 Received: by 10.151.116.1 with HTTP; Mon, 15 Dec 2008 05:14:50 -0800 (PST)\0D\0A
    23:29:31.937 >> 0075 Message-ID: <4d8649f50812150514o417b5a94l90d799f3fdf819d0@mail.gmail.com>\0D\0A
    23:29:31.937 >> 0039 Date: Mon, 15 Dec 2008 13:14:50 +0000\0D\0A
    23:29:31.937 >> 0049 From: "Michael Richards" <richardsem@gmail.com>\0D\0A
    23:29:31.937 >> 0031 To: c.parker@globalcanopy.org\0D\0A
    23:29:31.937 >> 0027 Subject: Little REDD Book\0D\0A
    23:29:31.937 >> 0019 MIME-Version: 1.0\0D\0A
    23:29:31.937 >> 0039 Content-Type: multipart/alternative; \0D\0A
    23:29:31.937 >> 0053 \09boundary="----=_Part_29071_14672545.1229346890705"\0D\0A
    23:29:31.937 >> 0036 Delivered-To: richardsem@gmail.com\0D\0A
    23:29:31.937 >> 0002 \0D\0A
    23:29:31.937 >> 0043 ------=_Part_29071_14672545.1229346890705\0D\0A
    23:29:31.937 >> 0003 .\0D\0A
    23:29:31.937 << 0008 UIDL 4\0D\0A
    23:29:31.546 >> 0031 +OK 4 GmailId11e3aca953711908\0D\0A
    23:29:31.546 << 0009 TOP 4 1\0D\0A
    23:30:31.546 8: Socket read timeout.
    23:30:52.078 --- Connection closed normally at Wed, 24 Dec 2008 23:30:52. ---\0A\0A

c) tried the Selective Mail Download option - this time it got 7 headers rather than 5 before halting and then giving the same socket read timeout error.

d) checked the chipset on the Dell Latitude D630 I'm using - it's got an Intel 965GM chipset.

e) installed the TCP Optimiser, checked to see what the maximum MTU size for pop.googlemail.com was for me, found out that it was 1450, altered all network adapters to use this value and turned off MTU discovery, restarted to apply this value, and then tried to download mail. I'm afraid it still gives the same error!

I'm afraid I'll be away on holiday from tomorrow, so may not be able to respond to anything until the New Year - but thank you very much for your prompt response, especially at this time of year!

Hi!

 I've just installed PMail 4.41 on the computer I'm using at work, and I'm using it do retrieve mail from our mail server, which is part of the package that we signed up with our web host. Up to the time I registered in this community, I was able to download mail from the server without any major hitches. After signing up, PMail was "stuck" at downloading the first message in the queue. I've already increased the TCP/IP timeout in the POP3 settings to  300 seconds, but PMail still isn't able to retrieve mail from the server. I checked my mail thru the web interface and found out that the message that PMail couldn't download is the automated message that was sent when I signed up. I could delete that message, and hopefully be able to retrive the rest of my messages, but I was wondering if there's a way to get PMail to download the message without deleting any messages.

 Any help/instructions on how to go about this is greatly appreciated. :D

-- Thor --

I do not know why your system hangs on this particular message. Have you tried using File | Selective mail download to get your mail?  With this function you can work your mail on the server to either download and delete or simply leave the message on the server. 

Hi Thomas,

 First of all, I'd like to thank you for your reply. I've tried it, but I can't seem to perform a selective mail download.What I do get is the following message:

[*] Connection established to xxx.xxx.xxx.xxx
>> 0049 +OK <xxxxx@xxxx.xxxx.xxxx>
<< 0034 USER xxxx@xxxxxx.xxx
>> 0006 +OK
<< 0014 PASS XXXXXXX
>> 0006 +OK
<< 0006 STAT
>> 0015 +OK 38 870480
<< 0006 LIST
>> 0006 +OK
<< 0008 RETR 1
>> 0017 +OK 2963 octets
 

And even after I've deleted the email that's "blocking" the rest of the emails, I still can't download the rest of them. :(

-- Thor --

That is not a complete response and it shows no error at all. Go to File | Network configuration | General and turn on "Create Internet session logs (advanced diagnostic use only)"  

Checking this control tells Pegasus Mail to create special log files that show the entire exchange of information between it and the servers it connects to. Each session will be created in a file called TCPxxxx.WPM in your home mailbox directory (the "xxxx" is replaced by four digits). Creating session logs will slow down the performance of your system somewhat, and you should be aware that any username and password information exchanged between Pegasus Mail and the server will be shown in the log, *even* if you use SSL to secure the connection. Session logs are primarily useful if you need to debug a problem between Pegasus Mail and one of the servers it connects to - you should enable the option only on instructions from a system administrator or from Pegasus Mail technical support. [ Technical note: this control has the same effect as using a "-Z 32" commandline switch when you run Pegasus Mail ]

You can now try again to send/receive the mail and then look at the resulting TCP/IP debug file.  Review of this file will tell you exactly what is going on between WinPMail and the server.  You can post the results here but make sure you munge your password.

Hi Thomas,

 I was just looking at the log files, and I found these peculiar lines:

12:29:07.000 9: Socket write error 276D.
12:29:07.000 11: Close error??! (276D).

 And a few lines that said "Socket read timeout," which I may consider as "normal."

 Could you give please give me more info on what is socket write error 276D?

 Thank you very much.

 -- Thor --

I'm afraid I'm having this trouble as well, when trying to download messages from my GMail account. I've posted my log below:

 [*] Connection established to 64.233.183.29
[*] SSL/TLS session established: RC4, OFB mode, keysize 128 bits
[*] Certificate user is cn=pop.googlemail.com, o=Google Inc, l=Mountain View, sp=California, c=US
[*] Certificate is valid from Fri Mar 14 23:23:24 2008 to Sat Mar 14 23:23:24 2009
[*] Certificate fingerprint is 1625F9975881CC05029737ACABDE0103
>> 0066 +OK Gpop ready for requests from 92.24.33.204 k5pf10289018nfh.55
<< 0032 USER myusername@googlemail.com
>> 0015 +OK send PASS
<< 0013 PASS XXXXXX
>> 0014 +OK Welcome.
<< 0006 STAT
>> 0017 +OK 109 9692770
<< 0006 LIST
>> 0034 +OK 109 messages (9692770 bytes)
<< 0008 RETR 1
8: Socket read timeout.

The status message on the bottom of the Pegasus Mail window shows "POP3: Downloading message 1 of 109...". Interestingly, when I try to selectively download emails, it pulls down four or five headers before stopping and showing a log with the same last line as the one above. My router is a Belkin F5D9630-4 if that's any help, with up-to-date firmware. Are there any other tests I can run to find out precisely where the problem lies? I've tried to set up POP3 and IMAP access to GMail in both Pegasus Mail and Outlook 2003, and so far though all the programs seem to connect to the GMail servers none of them have been able to download or access any mail.

> I'm afraid I'm having this trouble as well, when trying to download
> messages from my GMail account. I've posted my log below:
>
> Connection established to 64.233.183.29
>
> SSL/TLS session established: RC4, OFB mode, keysize 128 bits
>
> Certificate user is cn=pop.googlemail.com, o=Google Inc, l=Mountain View, sp=California, c=US
>
> Certificate is valid from Fri Mar 14 23:23:24 2008 to Sat Mar 14 23:23:24 2009
>
> Certificate fingerprint is 1625F9975881CC05029737ACABDE0103
> >> 0066 +OK Gpop ready for requests from 92.24.33.204 k5pf10289018nfh.55
> << 0032 USER myusername@googlemail.com
> >> 0015 +OK send PASS
> << 0013 PASS XXXXXX
> >> 0014 +OK Welcome.
> << 0006 STAT
> >> 0017 +OK 109 9692770
> << 0006 LIST
> >> 0034 +OK 109 messages (9692770 bytes)
> << 0008 RETR 1
> 8: Socket read timeout.

Go to File | Network configuration | General and turn on "Create Internet session logs (advanced diagnostic use only)"  

Checking this control tells Pegasus Mail to create special log files that show the entire exchange of information between it and the servers it connects to. Each session will be created in a file called TCPxxxx.WPM in your home mailbox directory (the "xxxx" is replaced by four digits). Creating session logs will slow down the performance of your system somewhat, and you should be aware that any username and password information exchanged between Pegasus Mail and the server will be shown in the log, *even* if you use SSL to secure the connection. Session logs are primarily useful if you need to debug a problem between Pegasus Mail and one of the servers it connects to - you should enable the option only on instructions from a system administrator or from Pegasus Mail technical support. [ Technical note: this control has the same effect as using a "-Z 32" commandline switch when you run Pegasus Mail ]

You can now try again to send/receive the mail and then look at the resulting TCP/IP debug file.  Review of this file will tell you exactly what is going on between WinPMail and the server.  In addition check Tools | Internet options | (Receiving)POP3  and note the timeout setting.  It might be set too low.
>
> The status message on the bottom of the Pegasus Mail window shows
> "POP3: Downloading message 1 of 109...". Interestingly, when I try to
> selectively download emails, it pulls down four or five headers before
> stopping and showing a log with the same last line as the one above. My
> router is a Belkin F5D9630-4 if that's any help, with up-to-date
> firmware. Are there any other tests I can run to find out precisely
> where the problem lies? I've tried to set up POP3 and IMAP access to
> GMail in both Pegasus Mail and Outlook 2003, and so far though all the
> programs seem to connect to the GMail servers none of them have been
> able to download or access any mail.

What happens with you try File | Selective mail download?  It's just possible there is one message on the server that is blocking the download.

Also this may be a packet fragmentation problem.  The POP3/SMTP transmissions may fail if the MTU packet size is so large that a packet is fragmented.  In many cases the receiving system router blocks the receiving servers "packets fragmented" response to the sending system using "MTU Discovery".  These oversize packets are not accepted and so are resent.  This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process.  You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492.  You might simply want to turn off the MTU Discovery operation.

You might want to get a copy of SG TCP Optimizer that I find quite handy.  http://www.speedguide.net/downloads.php  This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers.  If will also make it easy to adjust the MTU.  

And finally, does this computer, by chance, happen to have an NVidia NForce 4 chipset on the motherboard?  If so, many other have had this exact problem, and it turned out to be an optimization setting for the built in NIC which caused the problems with packet fragmentation. Disabling the advanced optimization capability called "checksum offload" made all the problems of sending SMTP mail via WinPMail disappear.