Thanks Thomas.  I'll have a more detailed look at this at the weekend. 

I put an old Win98 machine on the network and that worked fine (using the same version of Pegasus Mail).  I'm not sure if it's a TCP/IP or DNS problem with the XP machine, or an underlying problem with the communication between the SMB software (VisionFS - it's old) and XP.

I've tried doing a command prompt copy of the attachment on the server to another folder on the server, and that only takes seconds.  I suppose I need to try copying between the PC and the server to see if that's slower than expected.  I'll maybe try out a network sniffer on the LAN to see if there are any clues in the packet captures. 

We're running Pegaus Mail 4.21c, and have an OpenServer 5.0.5 system.  The Pegasus executables and mail folders are on the Unix server (using an SMB share).  Pegausus picks up mail for the users from /usr/spool/mail, and uses MMDF as the outgoing mail transport.  We've recently upgraded the local PCs from Windows 98 to Windows XP, and the problem began then, although we also upgraded from version 3.12 at the same time. 

When we send a message with a large attachment (say 3MB) Pegasus Mail sits with an egg timer for about three minutes saying, "SMTP: Preparing mail for sending".  After that it then sends the mail, and you see the percentage completed indicator incrementing.

What is Pegasus Mail doing when it showing the 'SMTP: Preparing mail for sending'?  I assume it's building a temporary file before it copies it to the outgoing MMDF mail queue.  The attachment I'm sending is on the server (as are all the Pegasus Mail folders), and I can't see any hard disk activity on the PC while this stage is in progress.  I'm not sure if there's a TCP/IP issue between the PC and the server, or what.  I've set Pegasus Mail to create an Internet Session Log, but I think that only kicks in when it's sending the mail, ie not when it's preparing to send the mail.

 I've only just started to investigate this problem, but I'd appreciate some advice on where to start looking. 

 I believe that when new mail arrives (into the /usr/spool/mail/<user> file then Pegasus takes quite a long time to process the new inbound mail.

 Thanks very much

David

[quote user="nashd"]

We're running Pegaus Mail 4.21c, and have an OpenServer 5.0.5 system.  The Pegasus executables and mail folders are on the Unix server (using an SMB share).  Pegausus picks up mail for the users from /usr/spool/mail, and uses MMDF as the outgoing mail transport.  We've recently upgraded the local PCs from Windows 98 to Windows XP, and the problem began then, although we also upgraded from version 3.12 at the same time. 

When we send a message with a large attachment (say 3MB) Pegasus Mail sits with an egg timer for about three minutes saying, "SMTP: Preparing mail for sending".  After that it then sends the mail, and you see the percentage completed indicator incrementing.

What is Pegasus Mail doing when it showing the 'SMTP: Preparing mail for sending'?  I assume it's building a temporary file before it copies it to the outgoing MMDF mail queue.  The attachment I'm sending is on the server (as are all the Pegasus Mail folders), and I can't see any hard disk activity on the PC while this stage is in progress.  I'm not sure if there's a TCP/IP issue between the PC and the server, or what.  I've set Pegasus Mail to create an Internet Session Log, but I think that only kicks in when it's sending the mail, ie not when it's preparing to send the mail.

 I've only just started to investigate this problem, but I'd appreciate some advice on where to start looking. 

 I believe that when new mail arrives (into the /usr/spool/mail/<user> file then Pegasus takes quite a long time to process the new inbound mail.

 Thanks very much

David

[/quote]

Not all that sure what to tell you but I suspect all of this is caused by delays in seeing/writing to the remote drive.  This looks like your XP systems are having troubles reading/writing to this SMD share.  I cannot tell you how to fix this.

BTW, preparing the message for sending is converting the attachment by doing a Base64 encoding and it is writing a temp file at least at this time.   I believe it is using both the TEMP and HOME mail directory during this process.  The file is going to be a PMX file when the RFC2822 "glue" headers message is written to the home mail directory for sending via the built-in mailer.  If you are sending via a Mercury/32 queue this same file will be written as a 101 file to the Mercury queue.