Community Discussions and Support
8: Socket read timeout.

Dear Mr. Stephenson,

Reading your message I found the way to solve problem with sending e-mails from Pegasus.

I had troble using Pegasus from november 2006.

"After installing latest version of Pegasus mail v 4.41 I can not send
e-mails via SMTP server of my Cable ISP. If I use other e-mail
software I can send e-mail via same SMTP server. With other ISP SMTP
servers sending of e-mails working fine."

I used today http://www.speedguide.net/files/TCPOptimizer.exe and start option
in program to find maximum MTU and used this value, I also checked No for MTU discovery.

I can use Pegasus mail for sending messages even if I use connection of my cable provider and all
programs also work fine now.

Kind regards,
Milan



Dear Mr. Stephenson, Reading your message I found the way to solve problem with sending e-mails from Pegasus. I had troble using Pegasus from november 2006. "After installing latest version of Pegasus mail v 4.41 I can not send e-mails via SMTP server of my Cable ISP. If I use other e-mail software I can send e-mail via same SMTP server. With other ISP SMTP servers sending of e-mails working fine." I used today http://www.speedguide.net/files/TCPOptimizer.exe and start option in program to find maximum MTU and used this value, I also checked No for MTU discovery. I can use Pegasus mail for sending messages even if I use connection of my cable provider and all programs also work fine now. Kind regards, Milan

I am running v 4.21c (yes I know I should upgrade) but this problem is intermitent and would like to find a solution. When I am sending outbound email, sometimes it fails with a

"Network or Protocol Error"

stating that 'SMTP Network error connection timeout (no response from host)'

My ISP claims they have had no problems.  Eventually it will send successfully. Here is the data from the popup error message from pmail:

>> 0061 220 comcast.net - Maillennium ESMTP/MULTIBOX alnrmhc12 #103
<< 0022 EHLO name-name (removed real name)

>> 0017 250-comcast.net
>> 0010 250-7BIT
>> 0014 250-8BITMIME
>> 0031 250-AUTH CRAM-MD5 LOGIN PLAIN
>> 0009 250-DSN
>> 0010 250-HELP
>> 0010 250-NOOP
>> 0016 250-PIPELINING
>> 0019 250-SIZE 15728640
>> 0014 250-STARTTLS
>> 0020 250-VERS V05.21c++
>> 0012 250 XMVP 2
<< 0040 MAIL FROM:<me@isp.net> SIZE=512   (removed real address)
>> 0008 250 Ok
<< 0029 RCPT TO:<user@isp.com>                  (removed real address)
>> 0008 250 Ok
<< 0006 DATA
>> 0050 354 Enter mail, end with "." on a line by itself
8: Socket read timeout.

&lt;P&gt;I am running v 4.21c (yes I know I should upgrade) but this problem is intermitent and would like to find a solution. When I am sending outbound email, sometimes it fails with a&lt;/P&gt; &lt;P&gt;&quot;Network or Protocol Error&quot; &lt;/P&gt; &lt;P&gt;stating that &#039;SMTP Network error connection timeout (no response from host)&#039;&lt;/P&gt; &lt;P&gt;My ISP claims they have had no problems.&amp;nbsp; Eventually it will send successfully. Here is the data from the popup error message from pmail:&lt;/P&gt; &lt;P&gt;&amp;gt;&amp;gt; 0061 220 comcast.net - Maillennium ESMTP/MULTIBOX alnrmhc12 #103 &amp;lt;&amp;lt; 0022 EHLO name-name (removed real name)&lt;/P&gt; &lt;P&gt;&amp;gt;&amp;gt; 0017 250-comcast.net &amp;gt;&amp;gt; 0010 250-7BIT &amp;gt;&amp;gt; 0014 250-8BITMIME &amp;gt;&amp;gt; 0031 250-AUTH CRAM-MD5 LOGIN PLAIN &amp;gt;&amp;gt; 0009 250-DSN &amp;gt;&amp;gt; 0010 250-HELP &amp;gt;&amp;gt; 0010 250-NOOP &amp;gt;&amp;gt; 0016 250-PIPELINING &amp;gt;&amp;gt; 0019 250-SIZE 15728640 &amp;gt;&amp;gt; 0014 250-STARTTLS &amp;gt;&amp;gt; 0020 250-VERS V05.21c++ &amp;gt;&amp;gt; 0012 250 XMVP 2 &amp;lt;&amp;lt; 0040 MAIL FROM:&amp;lt;&lt;A href=&quot;mailto:me@isp.net&quot; mce_href=&quot;mailto:me@isp.net&quot;&gt;me@isp.net&lt;/A&gt;&amp;gt; SIZE=512&amp;nbsp;&amp;nbsp; (removed real address) &amp;gt;&amp;gt; 0008 250 Ok &amp;lt;&amp;lt; 0029 RCPT TO:&amp;lt;&lt;A href=&quot;mailto:user@isp.com&quot; mce_href=&quot;mailto:user@aol.com&quot;&gt;user@isp.com&lt;/A&gt;&amp;gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (removed real address) &amp;gt;&amp;gt; 0008 250 Ok &amp;lt;&amp;lt; 0006 DATA &amp;gt;&amp;gt; 0050 354 Enter mail, end with &quot;.&quot; on a line by itself 8: Socket read timeout.&lt;/P&gt;

Low-level network failures like this are really nothing to do with Pegasus Mail - they indicate something happening at a level below the application. In this particular case, Pegasus Mail is telling you that it tried to read data from the socket but the operating system returned an error to it indicating that too much time had elapsed. There are too many possible causes for this to list here, but network cables, router issues, ADSL connection issues to your ISP and ISP configuration issues are all possibilities.

The first thing you need to try is increasing the timeout setting in Pegasus Mail's "Sending (SMTP)" dialog. Set it to something like 90 seconds and see if the problem persists. If it does, then you need to start looking for the physical source of the network problem.

Cheers!

-- David --

&lt;p&gt;Low-level network failures like this are really nothing to do with Pegasus Mail - they indicate something happening at a level below the application. In this particular case, Pegasus Mail is telling you that it tried to read data from the socket but the operating system returned an error to it indicating that too much time had elapsed. There are too many possible causes for this to list here, but network cables, router issues, ADSL connection issues to your ISP and ISP configuration issues are all possibilities. The first thing you need to try is increasing the timeout setting in Pegasus Mail&#039;s &quot;Sending (SMTP)&quot; dialog. Set it to something like 90 seconds and see if the problem persists. If it does, then you need to start looking for the physical source of the network problem. Cheers! -- David -- &lt;/p&gt;

[quote user="David Harris"]

Low-level network failures like this are really nothing to do with Pegasus Mail - they indicate something happening at a level below the application. In this particular case, Pegasus Mail is telling you that it tried to read data from the socket but the operating system returned an error to it indicating that too much time had elapsed. There are too many possible causes for this to list here, but network cables, router issues, ADSL connection issues to your ISP and ISP configuration issues are all possibilities.

The first thing you need to try is increasing the timeout setting in Pegasus Mail's "Sending (SMTP)" dialog. Set it to something like 90 seconds and see if the problem persists. If it does, then you need to start looking for the physical source of the network problem.

Cheers!

-- David --

[/quote]

 

Then why does it only happen with Pmail Dave?  I am having the same problem and it is isolated to Pmail using the same SMTP server.  It happens occasionally with just one recipient but it happens quite often with several recipients or when sending to a dlist.  Increasing the the time setting to 90 seconds doesn't help as the timeout always occurs within 15 seconds or so.  Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.  No problems at all with other email clients.  If this is NOT occuring at the application layer then it must also cause timeouts with other applications.  No?  ie: the session layer?

[quote user=&quot;David Harris&quot;] &lt;P&gt;Low-level network failures like this are really nothing to do with Pegasus Mail - they indicate something happening at a level below the application. In this particular case, Pegasus Mail is telling you that it tried to read data from the socket but the operating system returned an error to it indicating that too much time had elapsed. There are too many possible causes for this to list here, but network cables, router issues, ADSL connection issues to your ISP and ISP configuration issues are all possibilities. The first thing you need to try is increasing the timeout setting in Pegasus Mail&#039;s &quot;Sending (SMTP)&quot; dialog. Set it to something like 90 seconds and see if the problem persists. If it does, then you need to start looking for the physical source of the network problem. Cheers! -- David -- &lt;/P&gt; &lt;P&gt;[/quote]&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;Then why does it only happen with Pmail Dave?&amp;nbsp; I am having the same problem and it is isolated to Pmail using the same SMTP server.&amp;nbsp; It happens occasionally with just one recipient&amp;nbsp;but it happens quite often with several recipients or when sending to a dlist.&amp;nbsp; Increasing the the time setting to 90 seconds doesn&#039;t help as the timeout always occurs within 15 seconds or so.&amp;nbsp; Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.&amp;nbsp; No problems at all with other email clients.&amp;nbsp; If this is NOT occuring at the application layer then it must also cause timeouts with other applications.&amp;nbsp; No?&amp;nbsp; ie: the session layer?&lt;/P&gt;

[quote user="Dirty Harry"] 

Then why does it only happen with Pmail Dave?

[/quote]

Firstly, please don't call me "Dave". I absolutely hate that. My name is "David".

I can't tell you how often I hear "But it only happens with X..." - I'm sure the tech support people at all the network-based companies get the same thing (I know of a number who definitely do). Not all software is written the same way nor uses the underlying facilities of the operating system in the same fashion or even sequence. There are innumerable paths through any piece of computer code, and most of them will generate slightly different side-effects. Often, even simple matters of timing can cause problems... There was one case a few years ago where a guy couldn't connect to a POP3 host using Pegasus Mail but could do so using a Visual Basic script he'd written: the problem turned out in the end to be that the ethernet card in his computer had a latency problem that meant two packets sent in quick succession would cause it to fail; Pegasus Mail was sufficiently faster than the VB script that it would provoke the problem. To prove this to the guy, I had to produce a custom version of Pegasus Mail that had explicit delay statements to force it to slow down. I must have wasted about three solid days trying to track that one down.

This is the curse of my existence doing network technical support, because I *know* it's true, but I can't go around writing custom versions of the program to prove it to everyone who doubts me. I know it's easy to think "One guy can't possibly be right compared with a big corporation", but the fact remains that I have been doing this for a very, very long time and I have vast experience in diagnosing this type of problem. In this particular case, it's 100% clear-cut: Pegasus Mail is quite literally only reporting an error that has occurred at a lower level. Now, it's possible, perhaps even likely, that the lower-level problem might have been *provoked* by something Pegasus Mail has done - perhaps there's a sequence or timing problem of some kind... But the fact remains that it's actually the lower-level code that's failing, and once it has failed, I can't do much more than simply tell you that fact and report the error.

Seventeen years of hearing "But it only happens with X" has taught me that the phrase is usually almost entirely meaningless, but I've just about given up any hope of ever getting other people to understand that.

-- David --

[quote user=&quot;Dirty Harry&quot;]&amp;nbsp;&lt;p&gt;Then why does it only happen with Pmail Dave?&lt;/p&gt;[/quote] Firstly, please don&#039;t call me &quot;Dave&quot;. I absolutely hate that. My name is &quot;David&quot;. I can&#039;t tell you how often I hear &quot;But it only happens with X...&quot; - I&#039;m sure the tech support people at all the network-based companies get the same thing (I know of a number who definitely do). Not all software is written the same way nor uses the underlying facilities of the operating system in the same fashion or even sequence. There are innumerable paths through any piece of computer code, and most of them will generate slightly different side-effects. Often, even simple matters of timing can cause problems... There was one case a few years ago where a guy couldn&#039;t connect to a POP3 host using Pegasus Mail but could do so using a Visual Basic script he&#039;d written: the problem turned out in the end to be that the ethernet card in his computer had a latency problem that meant two packets sent in quick succession would cause it to fail; Pegasus Mail was sufficiently faster than the VB script that it would provoke the problem. To prove this to the guy, I had to produce a custom version of Pegasus Mail that had explicit delay statements to force it to slow down. I must have wasted about three solid days trying to track that one down. This is the curse of my existence doing network technical support, because I *know* it&#039;s true, but I can&#039;t go around writing custom versions of the program to prove it to everyone who doubts me. I know it&#039;s easy to think &quot;One guy can&#039;t possibly be right compared with a big corporation&quot;, but the fact remains that I have been doing this for a very, very long time and I have vast experience in diagnosing this type of problem. In this particular case, it&#039;s 100% clear-cut: Pegasus Mail is quite literally only reporting an error that has occurred at a lower level. Now, it&#039;s possible, perhaps even likely, that the lower-level problem might have been *provoked* by something Pegasus Mail has done - perhaps there&#039;s a sequence or timing problem of some kind... But the fact remains that it&#039;s actually the lower-level code that&#039;s failing, and once it has failed, I can&#039;t do much more than simply tell you that fact and report the error. Seventeen years of hearing &quot;But it only happens with X&quot; has taught me that the phrase is usually almost entirely meaningless, but I&#039;ve just about given up any hope of ever getting other people to understand that. -- David --

[quote user="Dirty Harry"]

I am having the same problem and it is isolated to Pmail using the same SMTP server.  It happens occasionally with just one recipient but it happens quite often with several recipients or when sending to a dlist.  Increasing the the time setting to 90 seconds doesn't help as the timeout always occurs within 15 seconds or so.  Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.

[/quote]

Generate a Pegasus Mail session log showing the error and post it here. The session log shows exactly what is failing and when.

-- David --

[quote user=&quot;Dirty Harry&quot;]&lt;p&gt;I am having the same problem and it is isolated to Pmail using the same SMTP server.&amp;nbsp; It happens occasionally with just one recipient&amp;nbsp;but it happens quite often with several recipients or when sending to a dlist.&amp;nbsp; Increasing the the time setting to 90 seconds doesn&#039;t help as the timeout always occurs within 15 seconds or so.&amp;nbsp; Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.&lt;/p&gt;[/quote] Generate a Pegasus Mail session log showing the error and post it here. The session log shows exactly what is failing and when. -- David --

[quote user="David Harris"][quote user="Dirty Harry"]

I am having the same problem and it is isolated to Pmail using the same SMTP server.  It happens occasionally with just one recipient but it happens quite often with several recipients or when sending to a dlist.  Increasing the the time setting to 90 seconds doesn't help as the timeout always occurs within 15 seconds or so.  Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.

[/quote]

Generate a Pegasus Mail session log showing the error and post it here. The session log shows exactly what is failing and when.

-- David --

[/quote]

 

I completely understand your experience with this and believe me your expertise is not in question here.  It is simply a matter of fact that the timeout occurs only when using Pmail.  Lots of timeouts with pmail vs. no timeouts with anything else really causes a layman such as myself to point fingers.  Turns out I was right too.  It was pmail causing the timeout however it was due to operator error in the setup that instructed Pmail to behave badly.

I ran a session log with the intention of posting it here at your suggestion and right there at the top was reported a timeout setting of 15.  WHAT??  I know I set that to 90.  The default setting was indeed set to 90 but lo and behold there is an optional setting within the pop3 and SMTP setup that was set to 15.  I didn't even know that was there.  Reset it to 60 and all is well.  That setting is not reported in the little popup timeout report either.  That could also be Mr. Mkjar's problem as well.

 Well, thanks for the reply --David--.   I learned something today and that's a good thing.

[quote user=&quot;David Harris&quot;][quote user=&quot;Dirty Harry&quot;] &lt;P&gt;I am having the same problem and it is isolated to Pmail using the same SMTP server.&amp;nbsp; It happens occasionally with just one recipient&amp;nbsp;but it happens quite often with several recipients or when sending to a dlist.&amp;nbsp; Increasing the the time setting to 90 seconds doesn&#039;t help as the timeout always occurs within 15 seconds or so.&amp;nbsp; Sometimes it does send the message but it can take as much as 10 or 15 tries to do so.&lt;/P&gt; &lt;P&gt;[/quote] Generate a Pegasus Mail session log showing the error and post it here. The session log shows exactly what is failing and when. -- David -- [/quote]&lt;/P&gt; &lt;P mce_keep=&quot;true&quot;&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;I completely understand your experience with this and believe me your expertise is not in question here.&amp;nbsp; It is simply a matter of fact that the timeout occurs only when using Pmail.&amp;nbsp; Lots of timeouts with pmail vs. no timeouts with anything else really&amp;nbsp;causes a layman such as myself to point fingers.&amp;nbsp; Turns out I was right too.&amp;nbsp; It was pmail causing the timeout however it was due to operator error in the setup that&amp;nbsp;instructed Pmail to behave badly.&lt;/P&gt; &lt;P&gt;I ran a session log with the intention of posting it here at your suggestion and right there at the top was reported a timeout setting of 15.&amp;nbsp; WHAT??&amp;nbsp; I know I set that to 90.&amp;nbsp; The default setting was indeed set to 90 but lo and behold there is an optional setting within the pop3 and SMTP setup that was set to 15.&amp;nbsp; I didn&#039;t even know that was there.&amp;nbsp; Reset it to 60 and all is well.&amp;nbsp; That setting is not reported in the little popup timeout report either.&amp;nbsp; That could also be Mr. Mkjar&#039;s problem as well.&lt;/P&gt; &lt;P&gt;&amp;nbsp;Well, thanks for the reply --David--.&amp;nbsp;&amp;nbsp; I learned something today and&amp;nbsp;that&#039;s a good thing.&lt;/P&gt;

The program allows you to set a default timeout, which can be overridden on a definition-by-definition basis (as you've discovered). I apologize that it didn't even occur to me to suggest that that might be the problem. I think in the back of my mind I was also still mulling over the other report active in this forum where there's an invalid connection error being returned by "connect" for one user, and I allowed that to flavour my thinking on this simpler problem.

I'm curious why your ISP is taking 15 seconds to process a message via SMTP, though - that seems like an awfully long time.

Cheers!

-- David --

&lt;p&gt;The program allows you to set a default timeout, which can be overridden on a definition-by-definition basis (as you&#039;ve discovered). I apologize that it didn&#039;t even occur to me to suggest that that might be the problem. I think in the back of my mind I was also still mulling over the other report active in this forum where there&#039;s an invalid connection error being returned by &quot;connect&quot; for one user, and I allowed that to flavour my thinking on this simpler problem. I&#039;m curious why your ISP is taking 15 seconds to process a message via SMTP, though - that seems like an awfully long time.&lt;/p&gt;&lt;p&gt;Cheers! -- David -- &lt;/p&gt;

[quote user="David Harris"]

I'm curious why your ISP is taking 15 seconds to process a message via SMTP, though - that seems like an awfully long time.

Cheers!

-- David --

[/quote]

It most certainly is albeit there is a simple explanation.  I am forced to use a satellite service for my ISP as I live out here in the boonie Catskills where there is no DSL or cable service.  Connectivity is slow at the beginning of a session but once the connection is made it moves much better than dialup.  This is important to me since I do quite a bit of downloading and uploading of files.  It takes a bit of time to connect to a mail server and that is where the time is burned.  When it rains I am hard down. [8o|]

FYI pmail was evidently right on the fence.  I am still receiving admonishments from all those folks on my Dlist whom I have mail bombed.  I kept trying to resend the message cuz I thought it was not sent ala timeout.  It was bounced back to me as NOT sent and was even held over in the outbox queue.  Well, that was a lie since everyone received the message in fine form..........several times. (ugh)  [:S]

Thanks again for your response.  It's great having the opportunity to talk to "THE MAN" himself!! [:)]

[quote user=&quot;David Harris&quot;] &lt;P&gt;I&#039;m curious why your ISP is taking 15 seconds to process a message via SMTP, though - that seems like an awfully long time.&lt;/P&gt; &lt;P&gt;Cheers! -- David -- &lt;/P&gt; &lt;P&gt;[/quote]&lt;/P&gt; &lt;P&gt;It most certainly is albeit there is a simple explanation.&amp;nbsp; I am forced to use a satellite service for my ISP as I live out here in the boonie Catskills where there is no DSL or cable service.&amp;nbsp; Connectivity is slow at the beginning of a session but once the connection is made it moves much better than dialup.&amp;nbsp; This is important to me since I do quite a bit of downloading and uploading of files.&amp;nbsp; It takes a bit of time&amp;nbsp;to connect to&amp;nbsp;a mail server&amp;nbsp;and that is where the time is&amp;nbsp;burned.&amp;nbsp;&amp;nbsp;When it rains I am hard down. [8o|]&lt;/P&gt; &lt;P&gt;FYI pmail was evidently right on the fence.&amp;nbsp; I am still&amp;nbsp;receiving admonishments from all those folks on my Dlist&amp;nbsp;whom I&amp;nbsp;have mail bombed.&amp;nbsp; I kept trying to resend the message cuz I thought&amp;nbsp;it was&amp;nbsp;not sent ala timeout.&amp;nbsp;&amp;nbsp;It was&amp;nbsp;bounced back to me&amp;nbsp;as NOT sent and was even held over in the outbox queue.&amp;nbsp; Well, that was a lie since everyone received the message in fine form..........several times.&amp;nbsp;(ugh)&amp;nbsp; [:S]&lt;/P&gt; &lt;P&gt;Thanks again for your response.&amp;nbsp; It&#039;s great&amp;nbsp;having&amp;nbsp;the opportunity to talk to &quot;THE MAN&quot; himself!! [:)]&lt;/P&gt;

[quote user="Dirty Harry"]

I am still receiving admonishments from all those folks on my Dlist whom I have mail bombed.  I kept trying to resend the message cuz I thought it was not sent ala timeout.  It was bounced back to me as NOT sent and was even held over in the outbox queue.  Well, that was a lie since everyone received the message in fine form..........several times. (ugh)  [:S]

[/quote]

The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It's not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message:

---------- cut here ------------
   SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly.
---------- cut here ------------

So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing).

It sounds to me as though your ISP's server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a "temporary failure - please retry" response had been received and will subsequently retransmit the message.

I admit that I don't have the entire information package here, so I'm scrambling a bit and may be missing something, but what you're describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I'm pretty confident that my code follows those rules).

-- David --

[quote user=&quot;Dirty Harry&quot;]&lt;p&gt;I am still&amp;nbsp;receiving admonishments from all those folks on my Dlist&amp;nbsp;whom I&amp;nbsp;have mail bombed.&amp;nbsp; I kept trying to resend the message cuz I thought&amp;nbsp;it was&amp;nbsp;not sent ala timeout.&amp;nbsp;&amp;nbsp;It was&amp;nbsp;bounced back to me&amp;nbsp;as NOT sent and was even held over in the outbox queue.&amp;nbsp; Well, that was a lie since everyone received the message in fine form..........several times.&amp;nbsp;(ugh)&amp;nbsp; [:S]&lt;/p&gt;&lt;p&gt;[/quote] The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It&#039;s not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message: ---------- cut here ------------ &amp;nbsp;&amp;nbsp; SMTP clients that experience a connection close, reset, or other &amp;nbsp;&amp;nbsp; communications failure due to circumstances not under their control &amp;nbsp;&amp;nbsp; (in violation of the intent of this specification but sometimes &amp;nbsp;&amp;nbsp; unavoidable) SHOULD, to maintain the robustness of the mail system, &amp;nbsp;&amp;nbsp; treat the mail transaction as if a 451 response had been received and &amp;nbsp;&amp;nbsp; act accordingly. ---------- cut here ------------ So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing). It sounds to me as though your ISP&#039;s server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a &quot;temporary failure - please retry&quot; response had been received and will subsequently retransmit the message. I admit that I don&#039;t have the entire information package here, so I&#039;m scrambling a bit and may be missing something, but what you&#039;re describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I&#039;m pretty confident that my code follows those rules). -- David -- &lt;/p&gt;

[quote user="David Harris"]
The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It's not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message:

So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing).

It sounds to me as though your ISP's server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a "temporary failure - please retry" response had been received and will subsequently retransmit the message.

I admit that I don't have the entire information package here, so I'm scrambling a bit and may be missing something, but what you're describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I'm pretty confident that my code follows those rules).

-- David --

[/quote]

I'm sure your coding is dead nuts on the money David.  I am ASSuming that by saying Pmail is resending the message that it is simply reloading it in the outbound queue.  Pegasus did NOT resend anything automatically as a matter of network protocol.  The message was resent manually by me when I thought it was being timed out.  Those that complained stated that they received four duplicate messages which is precisely how many times I tried to resend.  At any rate, I have no idea what happened with all this.  Guess I'll leave it to the netware developer gurus to ponder. [;)]

 Thanks once again for your response to this. 

&lt;P&gt;[quote user=&quot;David Harris&quot;] The way SMTP works, the sending client sends all the recipient addresses, then after they have all been processed (accepted or explicitly rejected), it sends the message data. It&#039;s not possible for the message to be sent unless all the recipient addresses have all been processed by the relaying server. Furthernore, the SMTP protocol definition, RFC2821, says that if a client program receives an unexpected connection-related error, it must act as if a 400-series error had occurred - which will cause it to resubmit the message: So, if the relaying SMTP server is getting a failure any time up to the point where its final message is accepted by the client, then it should *not* be sending the message - it should be expecting the client software to resend it (as Pegasus Mail is apparently doing). It sounds to me as though your ISP&#039;s server is accepting the mail for relaying and then not reacting properly to a connection error encountered sometime after the DATA command, sending the message on anyway instead of failing it. This will result in multiple copies of the message going out, because Pegasus Mail will - correctly - act as if a &quot;temporary failure - please retry&quot; response had been received and will subsequently retransmit the message. I admit that I don&#039;t have the entire information package here, so I&#039;m scrambling a bit and may be missing something, but what you&#039;re describing should not be possible in a situation where both sides of the connection are following the rules (and needless to say, I&#039;m pretty confident that my code follows those rules). -- David -- [/quote]&lt;/P&gt; &lt;P&gt;I&#039;m sure your coding is dead nuts on the money David.&amp;nbsp; I am ASSuming that by saying Pmail is resending the message that it is simply reloading it in the outbound queue.&amp;nbsp; Pegasus did NOT resend anything automatically as a matter of network protocol.&amp;nbsp; The message was resent manually by me when I thought&amp;nbsp;it was&amp;nbsp;being timed out.&amp;nbsp; Those that complained stated that they received four duplicate messages which is precisely how many times I tried to resend.&amp;nbsp; At any rate, I have no idea what happened with all this.&amp;nbsp; Guess I&#039;ll leave it to&amp;nbsp;the netware developer gurus to ponder. [;)]&lt;/P&gt; &lt;P&gt;&amp;nbsp;Thanks once again for your response to this.&amp;nbsp;&lt;/P&gt;

When you get a network or connection error, Pegasus Mail will report the error to you (it really has to do this, after all) but if the error is recoverable (i.e, was caused by a network layer error or by the remote server saying "try again later") it will automatically re-queue the job and try again in the next poll cycle.

Looking at this in the light of this thread, I can see how the error report dialog might be misleading for users, in that it may result in them thinking that nothing has been sent and trying again. I probably need to see if I can rework that.

Cheers!

-- David --

When you get a network or connection error, Pegasus Mail will report the error to you (it really has to do this, after all) but if the error is recoverable (i.e, was caused by a network layer error or by the remote server saying &quot;try again later&quot;) it will automatically re-queue the job and try again in the next poll cycle. Looking at this in the light of this thread, I can see how the error report dialog might be misleading for users, in that it may result in them thinking that nothing has been sent and trying again. I probably need to see if I can rework that. Cheers! -- David --

A 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.


A 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.
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 ?
Pending draft ... Click to resume editing
Discard draft