[quote user="Comedians"]Happens with just a plain straight forward plain text emails and more complex html.[/quote]

Can you forward such a message to idw.doc[at]t-online.de?

[quote user="Steffan"]

Seems to me like you hit Shift+Ctrl+7. Anyway, go to Folders | Grouped views, and click 'None'.

Cheers!

[/quote]

you are right steffan i might have accidently pressed the shift key with ctrl+ F7

any ways thankyou verymuch everything is back to normal after pressing "Shift + Ctrl + 0"

Thanks once again for your guidance

[quote user="gromit"]I can't see the message body. It appears encoded or encrypted.[/quote]

What kind of encoding? Can you post a sample? What does the raw view show?

Hi

Thanks for the suggestion. But (there's always a but) i'd already had a look at mbx2eml and even assuming it works OK, and it looks like it should, I still have the problem that, if I'm reading it right all the subdirectories have to be dealt with seperately. We have (at worst case) a 4 level directory structure in our local email folder and having to deal with layers individualy is a bit of a monster. I'd hoped that because pegasus can deal with mbx files there would be a way to migrate the whole structure (I can't be the only one who does a lot of emailing and need to have a filling system), but looks like I'm out of luck. Thanks agian for the suggestion.

Thanks, Thomas.

I've used DosBox in the past to run old games like Commander Keen and Duke Nukem ;) so I'll install it. 

There is no function like this, but just use Google translation from http://www.google.ca/language_tools?hl=en

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