[quote user="Elaine T"]It's not a big problem, but it's a bit of a nuisance. I've searched this forum and found someone with a similar problem from 2007, and I fiddled with the files suggested in that thread as the source of the problem. No change. I uninstalled, wiped my directory, reinstalled... No change.[/quote]
Did you ever check the described in this post? May I ask for crash dumps, again? I may provide you with a debug version of Pegasus Mail once you get the MiniDump extension to work properly.
[quote user="Elaine T"]For anti-virus & malware protection I'm running Avira Security and MalwareBytes. I've looked at their configurations and don't see anything obvious that would be causing the problem[/quote]
I'm running Avira as well and never encountered such an issue, but you can only tell for sure after (temporarily) disabling both these applications, I'm afraid ...
"Take a look at this thread http://community.pmail.com/forums/thread/21403.aspx
You need dosbox or similar to run these apps on 64-bit Windows."
Well... it worked so far as being able to make rescom function, but my variable sigs are still not showing up in the outgoing messages. Yes, the converted file resides in the proper location and the signature has ~! where the variation needs to be.
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.
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.
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!).
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).
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.
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 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 ...?