I've been a Pmail user for years. I don't change settings. HTML content has always been an issue and slow to link to Firefox but I've lived with it and often open it then save as HTML to read it.

Now Ebay and PayPal HTML message format seems to have killed PMAIL in the last 2 days. Pmail downloads from my mail server but freezes and lockouts every time I try to open it from the inbox . I could put up with it if I could read text in the message body. I can open and read the text header, but not the main body message. I can't even save the message as an html extension directly from my inbox because it won't open without crashing. I don't know if it's possible to disable the HTML renderer to see if the message will open as text?

I don't want to keep causing pmail crashes because in the past I know it might cause a mailbox corruption and time consuming effort parsing it and deleting a corrupt message entry.

Is anybody else getting pmail crashes with Ebay and PayPal messages?

Thanks

I think I managed to turn off the renderer and links to my browser eventually: Options/message reader/ manual right click remote-linked graphics, removed image helper application viewers (BMP,JPG etc), deleted the web browser command line and unchecked Find browser automatically.

The pmail visual experience is now pretty dumb with square box placeholders, but at least html messages open as text and can be saved to desktop as HTM and read in my browser. What I find strange is if I use this manual process, Firefox opens and renders the message rapidly, whereas when pmail tries to do it, there's a long pause of inactivity before FF opens and shows the message?

I would have liked pmail to smoothly open Firefox and render the message, but when it has worked it's always been clunky pausing for a while before the browser screen appears. The internal renderers sometimes worked for me me, but not always. There always seems to be an option checked (Usually BearHTM).

A PayPal message crash was reported yesterday by someone running Pegasus Mail under Wine on a Linux OS. This means that the default HTML renderer, IERenderer, was not being used since it can't run in that environment. You mentioned "BearHTM" (I'm sure you meant BearHTML) which makes be wonder if you are not using IERenderer either. I would at least test while running the current version of IERenderer (v2.7.3..

Was your PayPal message a notice confirming an order? I ask because I received one of those yesterday and it did not cause a crash when rendered with IERenderer or BearHTML. I load remote graphics manually and doing so did not cause a crash either. If same type of message, I'm curious why yours crashes and mine doesn't.

FWIW, the only action listed here that would affect the display of the message in Pegasus Mail is setting remote-linked graphics to manual loading.
Image helper application viewers only applies to attachments.
Web browser command line and Find browser automatically only apply to opening a message in a browser (eg: right-click > Open message in web browser)

I had a crash with the PayPal message on my linux machine using wine.
Pegasus does create a file in user temp directory where it extracts the encoded message to a file.
Original email PH7TGSJM.CNM.bad (renamed)
13917 Apr 2 04:39 SW6L9YHL.TMP (HTML FILE extracted)
That File opens in browser fine.

wc -lL SW6L9YHL.TMP
1356 16498 SW6L9YHL.TMP
Lines Longest Line

cat SW6L9YHL.TMP | grep metadata
-</span> <span data-metadata="<!--(figmeta)eyJmaWxlS2V

That is beginning of 16498 character line. figmeta???
AI says it is junk that shouldn't have been included in the email, and I found completely deleted line opens the same as far as I can see.
I earlier had issues with some ebay messages that had long lines that were linked to rover.ebay.com that were tracking links? Just deleted those as well.

Don't know if there would be a way to just eliminate these super long lines after the encoded lines are extracted, but before they are passed to whatever crashes because of them. Seems IERenderer has a way of doing that. Don't know if it just ignores the line or converts it.

Hope that helps.

No, it doesn't need to ignore or convert it because it can handle line lengths of almost infinite size (as long as below 2 GB or max. RAM size) as long as Pegasus Mail passes them over to IER without truncating them. Only the latter is causing trouble for IER, but it can even fix it when returning the contents for passing them back to Pegasus Mail to forward or reply - which have their own issues but usually not crashing.

I just got a sample message providing a decoded (from transfer encoding) line length of more than 80,000 characters which does not crash IER or Pegasus Mail on any further processing as long as it is properly transfer-encoded to at most 1,000 characters. Pegasus Mail's buffer size has recently been enlarged to 16 KB per line so could even deal with more than what the respective RFC requests (1,000 bytes including line breaks).

Interesting. Had heard something about the buffer being increased in size, and perhaps that is why I haven't seen any crashes till this one that exceeds the 16K size. Perhaps increasing it to 32K or 64K or 96K would solve the issue?

I could write a simple script that could do 1 of a few things.

1. Just open the latest *.TMP file in the temp directory with firefox, since it can handle the long line.
2. Could have a script that just eliminate the long line from same temp file, and open if with firefox. But since it wouldn't effect the original CNM file would still cause same crash.
3. could write a script that could elimanate the long line, and then re base64 encode it, and then replace the base64 code in the original name.

Don't now if there is a method that a filter or something could modify the TMP file before it gets passed to the process that crashes.

I have another program I've been dealing with that read 72 web pages for campus directory structure of University of Guam. Total size is about 15M.
One strange thing, is it has some lines that are up to 26000 characters for a single line?
Turns out data I need is on lines that are 250 characters are less, but have to have it be able to read lines up to the 26000.

Summary of my program that process files.

Time to Download Campus Directory   29.469332 Seconds
Time to Complete Total Process      29.473751 Seconds
Time to Process Data Completely      0.004419 Seconds              244334 lines in web pages
Time for Process 15M Web Part1       0.000716 Seconds (16.21%)       4042 lines
Time for Process 1M      Part2       0.000569 Seconds (12.88%)       3510 lines
Time for Process 256K    Part3       0.002051 Seconds (46.42%)        702 lines
Time for Process reportissue         0.001082 Seconds (24.49%)

Perhaps some knows a way.
Thanks again for the info.

Thanks, I don't want to be the only pmail user posting an issue that's a local problem. I'll see if others in the community have had a similar experience.

All the years I've supported pmail I've understood (for good security reasons) it was developed by David as a text based client. Unfortunately in the new world of smartphones and html, I'm finding more commercial mail is generated as html. I like the idea of pmail remaining a text based client using a supported browser which builds in security and filtering - Provided the browser link can be made quickly to give a smooth mail message browsing experience. At the moment with those links disabled, pmail opening my messages has become as fast as it always was.

I'm also frustrated at facing obsolescence. Although my Win7_64 is stable and I'm using 3rd party security, Mozilla have stopped releasing Firefox updates. I'm not a programmer, but I think since Microsoft stopped support for older Windows, Mozilla aren't able to continue releasing updates with backwards compatibility? This presents a problem with websites particularly financial which block access for browsers and OS failing their update security checks. Although some browser string spoofing can still get around that.

I recently setup an old PC with Linux Ubuntu and a Firefox current supported browser version. I'm also running Ubuntu under Oracle V.M on a Win7_64 desktop. Unfortunately there isn't a Pmail Linux version unless I install it running under Wine. It won't be music to members ears but I installed Mozillas Thunderbird email client which has no issues with htm messages since both email and Firefox are Mozilla apps. Since I've grown up with Pmail, Thunderbird needs some learning time and it's not so intuitive creating and working with folder trees. I also bought a licence for BitRecover Pegasus converter which can create pdf copies of all my old pmail messages in different formats. I haven't tried converting to Thunderbird and importing yet.

Archiving Pmail messages has always been hard and my mailboxes have sometimes got so large I've date sorted old messages into new message folders and created a fresh install with last 2 years or so of messages. Unfortunately this still leaves messages in a format only readable by a Pegasus Mail client which probably won't be compatible with future computers. No good if you want your life in a time capsule!

I'm starting to convert old pmail message archives to text, pdf (even paper!). Pdf has been a stable Adobe supported format for many years and I can't see text file format going obsolete. Getting a pmail crash and folder corruption is a wake up call to protect your messages in a backup system that doesn't rely on a client app. or restoring a disc image.

Just to point out. I believe Pegasus PMM files are basically mbox formatted files for the actual messages. The PMI index files are uniq to Pegasus but the PMM files have the data.

Not sure if the first 128 bytes at front which includes folder name info is mbox standard?

There are some files in the PMAIL\Programs Directory.
169472 Apr 17 2011 MBXMAINT.EXE
180736 Apr 17 2011 MBXMAINT_UI.EXE
577 Sep 1 2008 MBXMAINT_UI.EXE.MANIFEST

Know MR. Harris is working on changes to version 5 to change a lot of things, but no real info I have. Only beta team has some, but Mr. Harris is only one with complete picture.

Will have to see.

As an addition. Have been playing with way to resolve issue with the TMP files with long lines in the user Temp Directory.

With the number of attempts to open message that crashes Pegasus for me.
Currently have 12 TMP Files that have this.
All seem to have the same data but different sizes?

These are copied to another directory for test.
.TMP are the ones created by Pegasus
.TMP.zzz are ones that filter out the long lines.

113917 Apr 3 23:51 4XWX6G65.TMP
97417 Apr 3 23:52 4XWX6G65.TMP.zzz
116543 Apr 3 23:51 58JMIS3I.TMP
76007 Apr 3 23:52 58JMIS3I.TMP.zzz
93264 Apr 3 23:51 7CS0R9AD.TMP
76781 Apr 3 23:52 7CS0R9AD.TMP.zzz
116543 Apr 3 23:51 AB88QVLK.TMP
76007 Apr 3 23:52 AB88QVLK.TMP.zzz
93264 Apr 3 23:51 AWL899XA.TMP
76781 Apr 3 23:52 AWL899XA.TMP.zzz
137950 Apr 3 23:51 EFOEAGIK.TMP
96342 Apr 3 23:52 EFOEAGIK.TMP.zzz
137950 Apr 3 23:51 G8L2SMGE.TMP
96342 Apr 3 23:52 G8L2SMGE.TMP.zzz
113917 Apr 3 23:51 JNEJ8N07.TMP
97417 Apr 3 23:52 JNEJ8N07.TMP.zzz
93264 Apr 3 23:51 KRDLBDT3.TMP
76781 Apr 3 23:52 KRDLBDT3.TMP.zzz
113917 Apr 3 23:51 SW6L9YHL.TMP
97417 Apr 3 23:52 SW6L9YHL.TMP.zzz
113917 Apr 3 23:51 VLTRWLQ9.TMP
97417 Apr 3 23:52 VLTRWLQ9.TMP.zzz
93264 Apr 3 23:51 ZTO2GPH8.TMP
76781 Apr 3 23:52 ZTO2GPH8.TMP.zzz

long lines start with -</span> <span data-metadata="<!--(figmeta)

Simple program to convert .TMP to .TMP.zzz

 #include <cstring>
#include <iostream>
#include <fstream>
#include <string>

int main(int argc, char* argv[]) 
{
    const size_t MAX_LENGTH = 16384; // 16K limit
    char fileout[80];
    if (argc != 2)
    {
        std::cerr << "Usage: " << argv[0] << " <input_file1> <input_file2>" << std::endl;
        return 1;
    }
    strcpy(fileout,argv[1]);
    strcat(fileout,".zzz");
    std::ifstream inputFile(argv[1]);
    std::ofstream outputFile(fileout);

    if (!inputFile.is_open() || !outputFile.is_open()) 
    {
        std::cerr << "Error: Could not open files." << std::endl;
        return 1;
    }

    std::string line;
    // Read the file line by line
    while (std::getline(inputFile, line)) 
    {
        // Only write lines that are within the length limit
        if (line.length() <= MAX_LENGTH) 
        {
            outputFile << line << "\n";
        }
    }

    inputFile.close();
    outputFile.close();

    std::cout << "Processing complete. Short lines saved to output.txt." << std::endl;
    return 0;
}

Could add code to overwrite TMP with TMP.zzz version, but not clear if way to get Pegasus to run it in a filter or other way before crash is caused.
Ran against all TMP files, but all other the TMP and TMP.zzz files are same.

Could just use a script with this to open file in browser

firefox $(ls -1rt /home/msetzerii/.wine/drive_c/users/msetzerii/Temp/*.TMP | tail -n1)