Okay, more data. Had the problem again this morning and did a little research. This time it occurred before I had downloaded any email. Found a reference suggesting adding IN: in front of the address to force this to be recognized as an internet (SMTP?) address. Tried that.

This got rid of the error message complaining about an SMTP/MHS ambiguity and replaced it with the following error message:

"No Internet Mail queue exists on this system. Internet mail messages cannot be sent."

Then I downloaded last night's accumulation of email and tried sending (to the Queue Manager) the outgoing message again. It went with no complaints.

Retrieved the message from the Queue Manager and removed the IN: from the address. Sent it back to the Queue Manager again. Again, no complaints.

Finally, sent the message, no complaints.

Odd....

Hi Thomas

Many thanks for the quick reply, it's very much appreciated. I've printed out your reply to take along with me. Hopefully all will go smoothly and reading your reply and with what I already know of Pegasus Mail the time frame should be quiet short (they always seem to want something when I have a heavy workload with my main job!).

Again my thanks to you

Regards

Ron

Steffan,

    I think their Mapi coding is faulty. I will contact Picasa to let them know of the problem. Their forum has many articles on email problems if you don't use their web solution (needs uploading of photos to their web site).

Martin

Hello again, Thomas ...

Well, I decided to go ahead and rename the two *.CNM files. And that did the trick, as, after I re-opened Pegasus, no rogue messages appeared. I was able to download new messages without difficulty, and several new *.CNM files were created.

I imagine that the two *.CNM files were corrupt or damaged somehow.

Thanks for your help ...

Regards

Kenneth Spencer

Hi Thomas,

Bizarre: when I started putting the .cnm files back, Pegasus ran again.

The problem turned out to be a 0 length .cnm file.

Many thanks for the excellent advice.

Cheers, Paul

Thanks,

Guys,

You both helpped tremendously.

Seems to be working now.

It just took me a while to find your responses...I thought I set up email alerts.

But, I finally got some time & logged back into the forum, found my original question, & there you were.

Thanks again!

[quote user="bstiefel"]yes running mercury on windows platform fully integrated with Novell[/quote]

Yes, I saw your other thread after I posted that :)

What about my other questions?

[quote user="Thomas R. Stephenson"]

The message is a sub-folder, BTW.  I just tried it with a message in the New Mail folder and it works.  Is this behaviour to be expected?

 Yes, when a message is in a folder there is no way to remove part of a message without the danger of clobbering the whole *.PMM data file.  You have to move them to the new mail folder, delete the attachment, confirm the deletion and return it to the original folder.

[/quote]

 Thanks, Thomas.  Much appreciated.

Richard Herbert

Thanks to you both.  That did indeed work!

I think I managed to fix things by rerunning pconfig.exe and moving the files from D:\Pegasus Mail Folders to D:\Program Data\Pegasus

Mail Folders.

PaulF

[quote user="hungerdunger"] I still don't understand why that setting was only affecting Ebay emails, and only for the last few weeks, but the important thing is that they are working again. [/quote]

Sometimes the solution is pretty easy: Maybe it's simply  the sheer length of the URL ...?

The refresh new mail folder option is set to 300 secs. I've never quite understood what that means, though - I take it that's not the same as Check POP3 host for new mail?

 The lengthy timeout to clear mail on host is a new behavior, over the past couple weeks. Again, I'm nowhere near the 750 message limit...

Thanks for that. However, I don't think the problem is in Winsock (even if I of course don't know what is happening internally in PMail) since the POP3 lookup seems to be working just fine. I have fiddled around a bit with Process Manager, found out how to add thread id to the output, and so on, and I have created two screendumps of what is happening, one in the Win7 computer, and one in the old XP computer; I give only the URLs here as they are fairly big -- http://bozze.hopto.org/pmail.png and http://bozze.hopto.org/pmail_xp.png.

As can be seen from these, the program makes three connections to the socket, which is expected since I have set up 3 boxes to be checked every 61 seconds, or something like that; and all events reports success. The difference is that the thread that is loading winrnr.dll (and a lot of other dlls on WIn7) does not exit in the Win7 example (thread id 13284), but does so in XP (thread id 27264).

I will make some more experiments with mailboxes, anit-virus, etc, but all suggestions are welcome... I am also a bit confused about the wording "my threaded TCP/IP code", as it seems that all TCP/IP calls are made in the main thread. Is something in my setup wrong?

Got it. Thanks Paul.

Terry

> This won't work for new mail, only for everything else. For changing the new mail folder you may need to use PCONFIG.EXE which only runs on
> 32-bit Windows versions AFAIK.

Install a copy of DOSBox, this works for 64 bit windows and Linux to run 16 bit DOS  programs.

Check to see if any of the new message files in your mailbox folder are 0 (zero) length.  If so delete them and try again.  Zero length new mail files can cause the problem you are describing.  

Thanks! Disk wiped and restoring stuff now.  PMail seems to have survived with data intact.

Right, up through the end of Pegasus Mail V3.x at least, and possibly into the earliest V4.x versions (I'm not quite sure), whenever the user invoked a "selective mail download" -- which I still do, all the time, first checking the message count using the ancient MultiPOP extension -- the *.TOP file, with a hex file name and containing the mail headers, would be written, temporarily, to the user's mail directory (okay, "folder", I'm old school . . . ) on the client machine.   If the user had a lot of mail "up there", on the host mail server, the TOP file size could be substantial, 100Kb, even, at least under versions of Windows prior to XP. 

That file should have been and was deleted upon completion of the mail download, unless there was something else going on, such as a client-side lockup or crash, or, sometimes, a winsock timeout. 

Under the most-recent 4.x versions, I don't see that file in the mail directory anymore, so I presume that it's being written somewhere else, probably to a *.tmp directory somewhere.  Under Win 3.1, when hard drives were small, one needed to monitor such orphaned files.  But as other posters suggested, it really doesn't matter much anymore, except to the observantly curious among us.  

Thanks a lot for the answers.

I prefer IMAP as sometimes I use a

browser to access my mailbox not from home. So if there is technically

impossible to have one new mail folder for POP3 and IMAP, let it be, it

will not deter me from Pegasus.

You can setup both POP3 and leave the mail on the server.  If you only download unread mail and not delete mail once downloaded then you can still See the mail in the browser.

But again the question: Is

there any chance to set up the filter FULLY automatically without

clicking to the gmail folder to execute the filtering?

No.  The filter can only be and open or close filter and so it does not see mail added to the mailbox after opening.

And if I add

another IMAP account to Pegasus, will it create a separate gmail folder

tree?

Yes, I currently have connected10 added mailboxes and IMAP4 accounts, each has their own tree in the folder listing.

Great, thanks.