Personally I'd turn them all off for starters and checkout the effect.  If you cannot detect any change in function and if you no longer get the timeouts then you have solved your problem in one action.

I could use some help with this problem: I recently rebuilt my pc with bigger hard drives, then reinstalled XP and Pegasus.  I got the mail box issue sorted out (see separate thread), but now when I try to send email with attachments, the program times out.  I can send emails without attachments with no problem.

I have confirmed with Verizon, my FIOS provider, that I am not hitting their attachment size limit (I've tried with attachments from 800k to 5.4meg). 

The little info thingy in the lower left of the Pegasus screen (that says sending mail etc.) stalls at the 1% mark of what looks to be the attachment.  This happens whether I send the attachments as separate emails or as part of the body.

The error message I get isn't particularly useful--at least to me.  But here it is just in case:

---
Delivery has failed on the enclosed message for the following
reasons reported either by the mail delivery system on the mail
relay host or by the local TCP/IP transport module:

   *** TCP/IP error while processing job ***
   A network error has occurred while WinPMail attempted to send
   your message. This error could be caused by many conditions,
   including the following:
     * The remote host may have gone down.
     * Your network may have been broken or gone down.
     * You may have a configuration problem in your WINSOCK.DLL.
     * If running on a SLIP line, you may have experienced a
       timeout (increase the value in WinPMail's Network Config.
       Dialog), or the phone line may have gone down or suffered
       from excessive line noise.
   WinPMail will requeue your message and try again later.
   ---

Your original mail message follows:
--------------------------------------------------------

X-PM-Identity: <Default>
From: "XXX'd out for obvious reasons"
To: XX'd out for obvious reasons
Date: Sun, 02 Dec 2007 09:39:53 -0500
MIME-Version: 1.0
Content-type: Multipart/Mixed; boundary=Message-Boundary-10658
Subject: 5 recent photos
Reply-to: xx'd out see above
Message-ID: <xx'd out (but numbers)@xx'd out>
Priority: normal
X-mailer: Pegasus Mail for Windows (4.41)


--Message-Boundary-10658
Content-type: Multipart/Alternative; boundary="Alt-Boundary-1181.9366453"

--Alt-Boundary-1181.9366453
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Mail message body

Then the data....

----

I've changed the timeout option in Internet Mail Options/Sending (SMTP) to 180, but that still doesn't solve the problem.

Before I reinstalled Pegasus, I never had this problem.

I would appreciate any suggestions you guys could offer!
 

> I could use some help with this problem: I recently rebuilt my pc
> with bigger hard drives, then reinstalled XP and Pegasus.  I got the
> mail box issue sorted out (see separate thread), but now when I try
> to send email with attachments, the program times out.  I can send
> emails without attachments with no problem.
>
> I have confirmed with Verizon, my FIOS provider, that I am not
> hitting their attachment size limit (I've tried with attachments
> from 800k to 5.4meg).
>
> The little info thingy in the lower left of the Pegasus screen (that
> says sending mail etc.) stalls at the 1% mark of what looks to be
> the attachment.  This happens whether I send the attachments as
> separate emails or as part of the body.

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.

That said, this really looks like a classic 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.

Hi Thomas!  I spent most of today researching this problem and I actually found an answer like this from you before.  :)  You've been trying to help folks for a long time!

I have solved the problem and edited this message significantly as a result.

To help future folks who research the issue, I want to add some comments and the troubleshooting steps I took.

In my router log the attachments were causing this message: "First packet in connection is not a SYN packet: TCP" 

And I was getting a message from Pegasus occasionally: "Socket read error 2745", but mostly the message I was getting was truncating at something about a line ending with "." (sorry I don't have the exact wording anymore).

Also I do have an Nforce motherboard.

So.  After trying some settings in Pegasus which did nothing, I:

1) changed the "checksum offload" setting--but the error still happened.  It did get the "SMTP Sending Message 1 of 1..." to change from 1% to 5%, though. 

2) I tried the -Z 1024 command line but it froze Pegasus when it hit the attachment.

3) I couldn't find MTU settings anywhere in the registry, so I downloaded drtcp from http://www.dslreports.com/drtcp  (sorry can't figure out how to do this as a clicky) and changed BOTH my MTU to 1492 and the Path MTU Discovery to "NO".

4) I rebooted and tried to send the attachment--it worked!

I'm not sure if I safely can go back and change that "checksum offload" setting back to what it was, and I'm not going to try.  It's possible that just changing the path mtu discovery setting alone would solve the problem.  But my system seems to work now so I'm not going to tempt fate.

Thanks again Thomas!

Hi all,

Before i dig into all kind of programs, i think this could also be a problem inside pegasus. I used Eudora, send 1.2 Mb, succes. I used web based mail, the same succes. I try again to use your wonderful program Pegasus, and i have to become a super expert to solve stupid things like this. Any normal other program can send an Pegasus, how wonderfull this is and how cheap this is, it can´t cope the way others do. I use my own mercury server, where eudora uses the same mailserver, pegasus time´s out and eudora not. Isn´t that strange?

Maybe i sound a bit harse but this is not the first expert problem i get with pegasus.

I think it should work good ´out-of-the-box´

Sorry....

Pegasus Mail uses the non-blocking windows sockets.  Many other programs (Eudora, Outlook, Thunderbird) use the slower blocking sockets.  You can tell WinPMail to use the blocking sockets with the -Z 1024 commandline option.

That said, in many cases this is a problem with the very busy POP3/SMTP server being a bit slow and the SMTP setup using a 30 second timeout.  If the server does not respond fast enough then the session fails with a timeout.  I generally use nothing less then 120 seconds in either the POP3 or SMTP setup even when talking to a server on the same LAN.

I looked at every possibility in Mercury, and every timeout setting i found i set to 160 seconds, still doing so it did not work. I had problems before in this manner, and tried it then a few times with pegasus without succes and did the same file via mercury with eudora, with succes. That´s why i said what i said. Trying it a few time through Eudora gave me succes at last.

Maybe i´m thinking wrong, but should this be something for end users to fix? i can´t comprehend the things that come that can go wrong. Again, i might be a bit dark but i really hope things are forced down to a perfect working system. Until then i shall not dig into this problem bacause of other priorities i have besides my family, work, website and gameservers.....

Thanks though Thomas... ( is snapshotting the problem a solution?)

All I can say is that if the system is timing out when sending attachments either the timeout is to low or you have a packet fragmentation problem.  The blocking sockets will help some with packet fragmentation but if you are using the packet discovery where the sending client keeps increasing the packet size until it gets a "packet too large" error and the receiving system/router/etc is blocking the outbound "packet too large" error then you will keep getting timeout until you either turn off the packet discovery function or fix the problem with the errors being blocked.

Dear Thomas,

I really do not know where to begin. You tell clearly where the problem may lie, but i do not know where to start.

If there´s a clue to start and you are willing to tell (don´t curse me please) i´ll be happy to try tomorrow...

Thanks, again.

1. Set thePOP3/SMTP timeout to 300 seconds minimum.

2. Set your maximum packet size to 1400.and/or turn off the packet discovery operation.   This can be done manually via a registry edit but you should also be able to do this with the SG TCP Optimizer found at http://www.speedguide.net/downloads.php

You can then check this out again to see if you still get the timeouts.  

. 

Hi Thomas,

A co-worker showed me the way and your solution was also very much appreciated, however this was the return message...

[*] Connection established to (my ISP ip adres)
>> 0042 220 mail.mysite.nl ESMTP server ready.
<< 0021 EHLO [10.11.10.100]
>> 0056 250-mail.mysite.nl Hello [10.11.10.100]; ESMTPs are:
>> 0010 250-TIME
>> 0012 250-SIZE 0
>> 0025 250-AUTH CRAM-MD5 LOGIN
>> 0016 250-AUTH=LOGIN
>> 0010 250 HELP
<< 0043 MAIL FROM:<me ofcourse@mysite.nl> SIZE=2760165
>> 0048 250 Sender and size (2760165) OK - send RCPTs.
<< 0034 RCPT TO:<a good friend@his email.nl>
>> 0039 250 Recipient OK - send RCPT or DATA.
<< 0006 DATA
>> 0039 354 OK, send data, end with CRLF.CRLF

So as you can see even after a reboot nothing helped.

sigh......

Thanks though......

[quote user="anne"]

Hi Thomas,

A co-worker showed me the way and your solution was also very much appreciated, however this was the return message...

[*] Connection established to (my ISP ip adres)
>> 0042 220 mail.mysite.nl ESMTP server ready.
<< 0021 EHLO [10.11.10.100]
>> 0056 250-mail.mysite.nl Hello [10.11.10.100]; ESMTPs are:
>> 0010 250-TIME
>> 0012 250-SIZE 0
>> 0025 250-AUTH CRAM-MD5 LOGIN
>> 0016 250-AUTH=LOGIN
>> 0010 250 HELP
<< 0043 MAIL FROM:<me ofcourse@mysite.nl> SIZE=2760165
>> 0048 250 Sender and size (2760165) OK - send RCPTs.
<< 0034 RCPT TO:<a good friend@his email.nl>
>> 0039 250 Recipient OK - send RCPT or DATA.
<< 0006 DATA
>> 0039 354 OK, send data, end with CRLF.CRLF

So as you can see even after a reboot nothing helped.

sigh......

Thanks though......

[/quote]

Again this really does look like packet fragmentation.  Did you turn off the packet discovery ?

Dear Thomas,

I'm sorry if i make you cry but i looked in my network card configuration, in the registry, in Pegasus and in Mercury but could not find an option pointing in your direction, the packet discovery option.

Anne

As I said before, this can be done manually via a registry edit but you should also be

able to do this with the SG TCP Optimizer found at

http://www.speedguide.net/downloads.php  This program allows you to manually disable the packet discovery operation.  It's the MTU Discovery on the attached graphic.

I had the MTU set to 1500 and the MTU discovery on. As i turn it off i have to reset, then i can retest the job. Kinda contradictionary, as i first set things from a far lower setting to 1500 and then turn it off..... makes me wanna think....

I'll be back in a while.......

Thomas, never mind this, if i use the optimizer and shut the option to off, i'm asked to reset, I did that, nevertheless the option shows in the registry (EnableMTUDiscovery = 0) and still the mail sending failed. 

I'm not desperate, but a little how do you say when all hope is lost?,......, yeah, quit a bit at this moment. I hope this option is in the next version of Pegasus so improved, that no mail will get lost in nothingness. (-:

I can't go further on this, i'll have to accept that this is what it not should do, like so many things in life.

Thanks again for your help and time

Anne.

Personally, I still suspect that it is the nforce network card "checksum offload" setting-

 
Can you double check and confirm that your setting is like in the attached image (assuming this board allows me to upload the attachment):

Hi,

I do not have that kind of network card, neither do my network card have that specific settings. So i think that there's something else....

Anne

There are all sorts of places that the packet can be fragmented and the best wat to stop it it to turn off the pack discover function.  This will allow you to use a fixed packet size small enough for any packet.  It will be a bit slower, hardly noticeable though.

Strangly though my server's networkcard, Intel 1 gbps does have three settings that might do the trick.

It's about this...

Offload receive TCP Checksum

Offload transmit IP Checksum

Offload Transmit TCP Checksum

They are all on. Maybe setting the latest (Offload Transmit TCP Checksum) set to off will do the trick????