Community Discussions and Support
Email getting stuck in incoming mail queue

[quote user="ccomley"]

Can I stick my oar in here as we've been trying to resolve this problem for Johnny and getting nowhere.

It's not MTU or similar. The problem exists even if the Pegasus workstation is on the same LAN as the server. It's not time-out either. The session dies off, no amount of waiting for it to come back helps.

The server is Microsoft Exchange Server 2003 (SBS2003 version) with SP2, being accessed in this case via POP3. (MS's standard POP3 server module, no special add-ins.)  

The problem seems to be a specific mail item in the queue. The "manual" resolution is to use OutlookWebAccess to open up the mailbox, and move the offending item to a subfolder, or delete it, then PMail is able to fetch the other items in the queue entirely normally.

We do not think the "rogue" email is corrupt. The problem recurrs whenever that sender sends a similar missive. They tend to send mail with complex HTML content - but so far as I can work out *what* is contained within the message body shoujld just be regarded as "payload" by the POP process so it really shouldn't matter, even if the resulting email is one which Pmail can't display properly, etc. it should still download it.

I am investigating to see if it's a known issue with ES2003(POP).

I believe the *server* has a Nvidia chipset, I'll investigate changing this setting on the server and see if that makes any difference!! <later> It's a Nvidia board with an Nvidia Gig nic but there isn't a parameter called "checksum offload".


 [/quote]

Agreed, POP3 process should only get hung if there was some highbit character stream in the body that could block the TCP/IP process.  You might need to use "Selective mail download" on this specific message type while you have turned on the session logging. 

FWIW, the server itself can cause the packet fragmentation if there is a firewall running blocking outbound packets.  However is the packet discovery is turned off on the client side then this becomes a non-problem.

You might also try turning on blocking sockets using the -Z 1024 commandline option to see if this helps.

 1024    Use blocking sockets; may be needed for some
    defective WINSOCK implementations.
 

[quote user=&quot;ccomley&quot;]&lt;p&gt;Can I stick my oar in here as we&#039;ve been trying to resolve this problem for Johnny and getting nowhere. &lt;/p&gt;&lt;p&gt;It&#039;s not MTU or similar. The problem exists even if the Pegasus workstation is on the same LAN as the server. It&#039;s not time-out either. The session dies off, no amount of waiting for it to come back helps. &lt;/p&gt;&lt;p&gt;The server is Microsoft Exchange Server 2003 (SBS2003 version) with SP2, being accessed in this case via POP3. (MS&#039;s standard POP3 server module, no special add-ins.) &amp;nbsp;&lt;/p&gt;&lt;p&gt;The problem seems to be a specific mail item in the queue. The &quot;manual&quot; resolution is to use OutlookWebAccess to open up the mailbox, and move the offending item to a subfolder, or delete it, then PMail is able to fetch the other items in the queue entirely normally. &lt;/p&gt;&lt;p&gt;We do not think the &quot;rogue&quot; email is corrupt. The problem recurrs whenever that sender sends a similar missive. They tend to send mail with complex HTML content - but so far as I can work out *what* is contained within the message body shoujld just be regarded as &quot;payload&quot; by the POP process so it really shouldn&#039;t matter, even if the resulting email is one which Pmail can&#039;t display properly, etc. it should still download it. &lt;/p&gt;&lt;p&gt;I am investigating to see if it&#039;s a known issue with ES2003(POP). &lt;/p&gt;&lt;p&gt;I believe the *server* has a Nvidia chipset, I&#039;ll investigate changing this setting on the server and see if that makes any difference!! &amp;lt;later&amp;gt; It&#039;s a Nvidia board with an Nvidia Gig nic but there isn&#039;t a parameter called &quot;checksum offload&quot;. &lt;/p&gt;&lt;p&gt; &amp;nbsp;[/quote]&lt;/p&gt;&lt;p&gt;Agreed, POP3 process should only get hung if there was some highbit character stream in the body that could block the TCP/IP process.&amp;nbsp; You might need to use &quot;Selective mail download&quot; on this specific message type while you have turned on the session logging.&amp;nbsp; &lt;/p&gt;&lt;p&gt;FWIW, the server itself can cause the packet fragmentation if there is a firewall running blocking outbound packets.&amp;nbsp; However is the packet discovery is turned off on the client side then this becomes a non-problem.&lt;/p&gt;&lt;p&gt;You might also try turning on blocking sockets using the -Z 1024 commandline option to see if this helps.&lt;/p&gt;&lt;p&gt;&amp;nbsp;1024&amp;nbsp;&amp;nbsp;&amp;nbsp; Use blocking sockets; may be needed for some &amp;nbsp;&amp;nbsp;&amp;nbsp; defective WINSOCK implementations. &amp;nbsp;&lt;/p&gt;

 

[Moderator: this email continued from earlier message sent when partially complete] 

 

The question is whether there is a better way to deal with this problem?

Is there perhaps some Pegasus feature or an addon which identifies which message in the incoming queue is the causing the bottleneck?

Thanks

JohnnyK

&lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;[Moderator: this email continued&amp;nbsp;from earlier message sent when partially complete]&amp;nbsp;&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;The question is whether there is a better way to deal with this problem? &lt;/P&gt; &lt;P&gt;Is there perhaps some Pegasus feature or an addon which identifies which message in&amp;nbsp;the incoming&amp;nbsp;queue is the causing the bottleneck? &lt;/P&gt; &lt;P&gt;Thanks&lt;/P&gt; &lt;P&gt;JohnnyK&lt;/P&gt;

[quote user="JohnnyK"]

 

[Moderator: this email continued from earlier message sent when partially complete] 

 

The question is whether there is a better way to deal with this problem?

Is there perhaps some Pegasus feature or an addon which identifies which message in the incoming queue is the causing the bottleneck?

Thanks

JohnnyK

[/quote]

 

Not sure what you are talking about, could you expand on the problem.  Are you talking about Pegasus Mail or Mercury?

 

[quote user=&quot;JohnnyK&quot;]&lt;p mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/p&gt; &lt;p&gt;[Moderator: this email continued&amp;nbsp;from earlier message sent when partially complete]&amp;nbsp;&lt;/p&gt; &lt;p mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/p&gt; &lt;p&gt;The question is whether there is a better way to deal with this problem? &lt;/p&gt; &lt;p&gt;Is there perhaps some Pegasus feature or an addon which identifies which message in&amp;nbsp;the incoming&amp;nbsp;queue is the causing the bottleneck? &lt;/p&gt; &lt;p&gt;Thanks&lt;/p&gt; &lt;p&gt;JohnnyK&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Not sure what you are talking about, could you expand on the problem.&amp;nbsp; Are you talking about Pegasus Mail or Mercury?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

I find that infrequently some rogue email sticks in my incoming mail queue, and all incoming mail then hangs.

I can use the selective download and, by trial and error, eliminate any mail that looks suspicious and have also used "Mailwasher" that allows preview of queued mail at the server, prior to downloading.

The question is whether there is a better way to deal with this problem?

Is there perhaps some Pegasus feature or an addon which identifies which message in the incoming queue is the causing the bottleneck?

Thanks

JohnnyK

&lt;P&gt;I find that infrequently some rogue email sticks in my incoming mail queue, and all incoming mail then hangs. &lt;/P&gt; &lt;P&gt;I can use the selective download and, by trial and error, eliminate any mail that &lt;EM&gt;looks&lt;/EM&gt; suspicious and have also used &quot;Mailwasher&quot; that allows preview of queued mail at the server, prior to downloading.&lt;/P&gt; &lt;P&gt;The question is whether there is a better way to deal with this problem? &lt;/P&gt; &lt;P&gt;Is there perhaps some Pegasus feature or an addon which identifies which message in&amp;nbsp;the incoming&amp;nbsp;queue is the causing the bottleneck? &lt;/P&gt; &lt;P&gt;Thanks&lt;/P&gt; &lt;P&gt;JohnnyK&lt;/P&gt;

 

The email stuck in the incoming mail queue problem occurs using Pegasus, v4.41.

&lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;The email stuck in the incoming mail queue problem occurs using Pegasus, v4.41.&lt;/P&gt;

You really need to determine what it the problem with the downloads.  May be a simple timeout, may be a packet fragmentation problem. 

Have you tried using session logging to see exactly what is happening with the bad message?

Have you increased the timeout setting to see if that  fixes the problem?

 

&lt;p&gt;You really need to determine what it the problem with the downloads.&amp;nbsp; May be a simple timeout, may be a packet fragmentation problem.&amp;nbsp; &lt;/p&gt;&lt;p&gt;Have you tried using session logging to see exactly what is happening with the bad message? &lt;/p&gt;&lt;p&gt;Have you increased the timeout setting to see if that&amp;nbsp; fixes the problem?&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Hi Thomas, thanks for your assistance so far.

I have looked in the MS Event Viewer under Administrative Tools, and don't see anything that seems suspicious. And its not a timeout problem; the rogue email will generally get to, say 6% downloaded, and then hang. Even if I changed timeout to 24 hours, I don't think it would make any difference.

The question is whether there is any way, using Pegasus, the user can identify the rogue, other than by using a third party application (or Selective mail download) and and a bit of tedious trial and error. And is this query unique? Am I the only user who has incoming email stuck in mid-download, from time to time?

 

&lt;P&gt;Hi Thomas, thanks for your assistance so far.&lt;/P&gt; &lt;P&gt;I have looked in the MS Event Viewer under Administrative Tools, and don&#039;t see anything that seems suspicious. And its not a timeout problem; the rogue email will generally get to, say 6% downloaded, and then hang. Even if I&amp;nbsp;changed timeout to 24 hours, I don&#039;t think it would make any difference.&lt;/P&gt; &lt;P&gt;The question is whether&amp;nbsp;there is any way,&amp;nbsp;using Pegasus,&amp;nbsp;the user can identify the rogue, other than by using a third party application (or Selective mail download)&amp;nbsp;and and a bit of tedious trial and error. And is this query unique? Am I the only user who has incoming email stuck in mid-download, from time to time?&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt;

> Hi Thomas, thanks for your assistance so far.
>
> I have looked in the MS Event Viewer under Administrative Tools, and
> don't see anything that seems suspicious. And its not a timeout
> problem; the rogue email will generally get to, say 6% downloaded, and
> then hang. Even if I changed timeout to 24 hours, I don't think it
> would make any difference.

You really need to do a session log.  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 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 want to see what is happening at the point of failure or hang.  If you find that the system is timing out do to lack of response from the server then you increase the timeout.  If you are using a timeout of about 300 and it's still failing then it's a TCP/IP problem.

>
> The question is whether there is any way, using Pegasus, the user can
> identify the rogue, other than by using a third party application (or
> Selective mail download) and and a bit of tedious trial and error. And
> is this query unique? Am I the only user who has incoming email stuck
> in mid-download, from time to time?

Pretty much unique, however failures to to packet fragmentation where the download fails is quite common.  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.




&amp;gt; Hi Thomas, thanks for your assistance so far. &amp;gt; &amp;gt; I have looked in the MS Event Viewer under Administrative Tools, and &amp;gt; don&#039;t see anything that seems suspicious. And its not a timeout &amp;gt; problem; the rogue email will generally get to, say 6% downloaded, and &amp;gt; then hang. Even if I&amp;nbsp;changed timeout to 24 hours, I don&#039;t think it &amp;gt; would make any difference. You really need to do a session log.&amp;nbsp; Go to File | Network configuration | General and turn on &quot;Create Internet session logs (advanced diagnostic use only)&quot; &amp;nbsp; 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 &quot;xxxx&quot; 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 &quot;-Z 32&quot; commandline switch when you run Pegasus Mail ] You can now try again to receive the mail and then look at the resulting TCP/IP debug file.&amp;nbsp; Review of this file will tell you exactly what is going on between WinPMail and the server.&amp;nbsp; You want to see what is happening at the point of failure or hang.&amp;nbsp; If you find that the system is timing out do to lack of response from the server then you increase the timeout.&amp;nbsp; If you are using a timeout of about 300 and it&#039;s still failing then it&#039;s a TCP/IP problem. &amp;gt; &amp;gt; The question is whether&amp;nbsp;there is any way,&amp;nbsp;using Pegasus,&amp;nbsp;the user can &amp;gt; identify the rogue, other than by using a third party application (or &amp;gt; Selective mail download)&amp;nbsp;and and a bit of tedious trial and error. And &amp;gt; is this query unique? Am I the only user who has incoming email stuck &amp;gt; in mid-download, from time to time? Pretty much unique, however failures to to packet fragmentation where the download fails is quite common.&amp;nbsp; The POP3/SMTP transmissions may fail if the MTU packet size is so large that a packet is fragmented.&amp;nbsp; In many cases the receiving system router blocks the receiving servers &quot;packets fragmented&quot; response to the sending system using &quot;MTU Discovery&quot;.&amp;nbsp; These oversize packets are not accepted and so are resent.&amp;nbsp; This results in a timeout, generally at the end of the message transmission but it can be anywhere in the process.&amp;nbsp; You need to reduce the MTU size. Windows defaults to a 1500 MTU and many routers and DSL connections need 1492.&amp;nbsp; 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.&amp;nbsp; http://www.speedguide.net/downloads.php&amp;nbsp; This little utility will allow you to test your MTU for maximum size without fragmentation against specific servers.&amp;nbsp; If will also make it easy to adjust the MTU. &amp;nbsp; And finally, does this computer, by chance, happen to have an NVidia NForce 4 chipset on the motherboard?&amp;nbsp; 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 &quot;checksum offload&quot; made all the problems of sending SMTP mail via WinPMail disappear.

Can I stick my oar in here as we've been trying to resolve this problem for Johnny and getting nowhere.

It's not MTU or similar. The problem exists even if the Pegasus workstation is on the same LAN as the server. It's not time-out either. The session dies off, no amount of waiting for it to come back helps.

The server is Microsoft Exchange Server 2003 (SBS2003 version) with SP2, being accessed in this case via POP3. (MS's standard POP3 server module, no special add-ins.)  

The problem seems to be a specific mail item in the queue. The "manual" resolution is to use OutlookWebAccess to open up the mailbox, and move the offending item to a subfolder, or delete it, then PMail is able to fetch the other items in the queue entirely normally.

We do not think the "rogue" email is corrupt. The problem recurrs whenever that sender sends a similar missive. They tend to send mail with complex HTML content - but so far as I can work out *what* is contained within the message body shoujld just be regarded as "payload" by the POP process so it really shouldn't matter, even if the resulting email is one which Pmail can't display properly, etc. it should still download it.

I am investigating to see if it's a known issue with ES2003(POP).

I believe the *server* has a Nvidia chipset, I'll investigate changing this setting on the server and see if that makes any difference!! <later> It's a Nvidia board with an Nvidia Gig nic but there isn't a parameter called "checksum offload".



 


 

&lt;p&gt;Can I stick my oar in here as we&#039;ve been trying to resolve this problem for Johnny and getting nowhere. &lt;/p&gt;&lt;p&gt;It&#039;s not MTU or similar. The problem exists even if the Pegasus workstation is on the same LAN as the server. It&#039;s not time-out either. The session dies off, no amount of waiting for it to come back helps. &lt;/p&gt;&lt;p&gt;The server is Microsoft Exchange Server 2003 (SBS2003 version) with SP2, being accessed in this case via POP3. (MS&#039;s standard POP3 server module, no special add-ins.) &amp;nbsp;&lt;/p&gt;&lt;p&gt;The problem seems to be a specific mail item in the queue. The &quot;manual&quot; resolution is to use OutlookWebAccess to open up the mailbox, and move the offending item to a subfolder, or delete it, then PMail is able to fetch the other items in the queue entirely normally. &lt;/p&gt;&lt;p&gt;We do not think the &quot;rogue&quot; email is corrupt. The problem recurrs whenever that sender sends a similar missive. They tend to send mail with complex HTML content - but so far as I can work out *what* is contained within the message body shoujld just be regarded as &quot;payload&quot; by the POP process so it really shouldn&#039;t matter, even if the resulting email is one which Pmail can&#039;t display properly, etc. it should still download it. &lt;/p&gt;&lt;p&gt;I am investigating to see if it&#039;s a known issue with ES2003(POP). &lt;/p&gt;&lt;p&gt;I believe the *server* has a Nvidia chipset, I&#039;ll investigate changing this setting on the server and see if that makes any difference!! &amp;lt;later&amp;gt; It&#039;s a Nvidia board with an Nvidia Gig nic but there isn&#039;t a parameter called &quot;checksum offload&quot;. &lt;/p&gt;&lt;p&gt; &amp;nbsp;&lt;/p&gt;&lt;p&gt; &amp;nbsp;&lt;/p&gt;
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft