Thanks everyone for your efforts... Problem Solved!

 Awhile back the e-mail provider connected to my problem mailbox decided to drop POP3 and use only IMAP.  I created an IMAP profile, but had so many problems trying to get IMAP to work with this provider that I finally gave up, set all e-mail from this provider to forward to another provider I use that supports POP3, and had Pegasus retrieve my e-mail from the POP3 client.  In reading over all your replies, a reference to IMAP made me realize that the persistent folder problem began about the same time as the IMAP adventure.  I checked, and sure enough I still had an IMAP profile for the original e-mail provider entered for that mailbox in Pegaus.. It turns out that it was the IMAP profile that was opening the "folders" window.  After I eliminated the profile from IMAP in that mailbox on Pegasus, the persistent window disappeared.

Thanks again for all your suggestions... and research on my behalf.  Hope you all have a great holiday season.

[quote user="jficklin"]Could have saved myself some playing around if I had just been a little bit more patient waiting for your reply.[/quote]

There wouldn't have been any sense of accomplishment in that!  [:)]

Click the Folders menu item.  You will see the Create a Folder. It has a drop down choice, and there you will see Unix MBOXs. Import and Export work.

Martin

Be aware that the PMAIL.INI file resides in the new mail directory which does not move.

From the help file topic Preferences and settings > Mailbox location:

Even if you move your home mailbox location, your new mail will continue to arrive in the default new mail directory: Pegasus Mail will also continue to store your PMAIL.INI settings file in that directory. This is important for the continued correct operation of the program and is neither an error nor an oversight. You cannot relocate your new mail folder using this option.

If the goal is to always capture a copy of sent messages a trick I discovered is to create a copyself rule that always copies to a specific folder.  That copy is recorded with the To: prefix.

This does not interfere with the option to select a copyself destination folder (results in an additional copy).

Eshtaol,

Have you confirmed that double clicking on a .pdf file from within a file explorer works to open the file? 

If not, uninstall/reinstall Acrobat Reader DC to reset the system defaults for .pdf and Acrobat files.

If a .pdf attachment will open using the "Open" button but not by double clicking the filename disable the "Turn off attachment preview by default in the attachment view" option located in  Tools > Options > Incoming Mail >Message reader.

If you can open .pdf files with a double click from within a file explorer AND have ruled out the attachment preview setting as the source of the problem then...

• Within Pegasus Mail go to Tools > Options > Incoming Mail > Content viewers
• Delete the entry associated with ".pdf".
• Delete the entry associated with "Acrobat" if one exists.
• Restart Pegasus Mail
  
• Try opening a .pdf attachment

[quote user="Euler GERMAN"]I maybe wrong as I never used AOL but as noted by an email can't have a line bigger than 1024 characters. If it is Base64 encoded no line can exceed 64 characters. Your message has an encoded line which exceed 64-char by far.[/quote]

Well, it's actually 76 plus the two characters of the line break sequence as per RFC 2045 (emphasis by me, so there's absolutely no ambiguity):

   The encoded output stream must be represented in lines of no more than 76 characters each.

The length of the encoded GIF forwarded to me by David is of ridiculously 38,368 bytes length!

The general line length limits are defined in RFC 5322 as follows:

   There are two limits that this specification places on the number of
   characters in a line.  Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

   The 998 character limit is due to limitations in many implementations
   that send, receive, or store IMF messages which simply cannot handle
   more than 998 characters on a line.  Receiving implementations would
   do well to handle an arbitrarily large number of characters in a line
   for robustness sake.  However, there are so many implementations that
   (in compliance with the transport requirements of [RFC5321]) do not
   accept messages containing more than 1000 characters including the CR
   and LF per line, it is important for implementations not to create
   such messages. 

David Harris already extended some of the buffer lengths he uses up to 4096 bytes in the past, but I don't know which ones and whether there are even some of infinite length (lets rather say up to at most 1 GB which would be a rational limit in 32bit environments).

You're most welcome. Glad it worked. [:)]

Ah, that's it. I missed that one in going through the settings. Thank you.

Well at least everything else is now up-to-date as well.

I did it completely differently. I subscribed to a rss-to-email service called Blogtrottr: https://blogtrottr.com

It delivers my RSS-feeds directly in my email inbox. 

Folks,

Looking at today's posts of GRC's Usenet I found a tool some of you may wanna try. The author also provides the full source code of the application. Following below, some of author's notes:

[quote]Wrote the tool quite some time ago for my personal needs, but since it may be useful for other people willing to run checks on SMTP servers and since it's useful for diagnostic purposes, I thought to share it, the zip file is available at this URL

http://www.mvps.org/bitbucket/smtptest.zip

and contains the 32 bits exe and the full "C" sources, the program is a simple commandline tool which may be used to perform some checks toward an SMTP server (or even the "FakeMX"), running the program without any arguments will show the following help

smtptest: simple SMTP server checking tool
Version 4.7 written by ObiWan Feb-2017

usage: smtptest [-option [value]] server_or_domain

option          option meaning/usage
------------      ------------------------------------------
-p port         SMTP port for connection (default=25)
-h helo         HELO/EHLO string to use (default=DNS-PTR)
-e                use HELO instead of EHLO
-a type         AUTH type 1=PLAIN, 2=LOGIN
-U user         AUTH user name
-P pass         AUTH password
-x                send a HELP command to the server
-f fromaddr    use this address as the "from" (-c/-r)
-c address     check <address> using VRFY/EXPN
-r recipient     try an RCPT TO <recipient>
-M filename   send an email from file contents
-t timeout      connect/response timeout (default=10000)
-n retries       number of retries on error (default=1)
-d delay        delay between retries (default=30000)
-i                  ignore SMTP 5xx codes (keep going)
-T                use TCP only for DNS queries (no UDP)
-I                 use ICMP to check if the host is alive
-m               test all MX for the given domain
-C               enable colors
-o               dump traffic in readable format
-v                enable verbose/debug logging mode
-?               shows this help text
------------     ------------------------------------------

examples: smtptest mx1.hotmail.com
                smtptest -t 30000 -v mx2.hotmail.com
                smtptest -r postmaster@live.com mx3.hotmail.com
                smtptest -xm hotmail.com

notice that while the program may optionally be used to send an email message, I purposely didn't optimize that part so hopefully it won't be abused as a "spam tool", also, the program currently doesn't support SSL, time ago I started fiddling with schannel code, but then I didn't go on and add it to the program, willing to do so, the best approach would probably be adding an "sslsock.c" module exposing the needed functions and then modifying the "smtptest.c" code to add calls to the module to deal with either implicit or explicit SSL modes.[/quote]

Thanks. Cascade and close worked.

 

Thanks for the replies

Brian and Michael,

     I now believe that neither renderer is involved, and place suspicion on TER/HTS running in Pegasus Mail.  I can see no logging activity in Bearhtml when replies are processed. The only test I can think to prove this is to disable both Bearhtml and IERenderer and see if the Reply function still works. The only other test I can think of is to check the content of the original message against the pre-loaded text in the reply. If Bearhtml was involved, then there should be a dramatic reduction in size when the wantCSS=no is enabled, as the SCRIPT and CSS content is completely removed from the Html stream. By dramatic reduction I mean at least 50% in size, not just a line or two.

I will try disabling Bearhtml and not enabling IERenderer,

Martin

[quote user="Brian Fluet"]I have seen this happen with other old apps.  The behavior is as if the print job is sent directly to the printer, ignoring the printer driver preferences.  Does setting the default tray in the printer preferences on a client machine make a difference?[/quote]

The default tray is already set on each client machine, but Pmail is ignoring it.

[quote user="Brian Fluet"]Also, might the problem be specific to printers using a PS driver?  I'm using PCL drivers on all printers due to problems with PS drivers (I don't remember the specifics though).  Tray management on a recently purchased Xerox printer was problematic with both PS & PCL6 drivers.  A PCL5 driver solved the problem.[/quote]

We are using PCL drivers only

[quote user="Brian Fluet"]Finally, I've experienced client PC's that just would not print correctly when the printer was installed as a network printer.  Installing the printer as a local printer to the appropriate TCP/IP port has been the solution. [/quote]

All of our printers are network printer. Installing local printers is not our preffered method since all printer queues should be centrally managed by the server.

But anyway. The problem is only with one of our printers where normal paper is in tray 2 and letter heads in tray 1. I will exchange the trays one with another. Then it doesn't matter when Pmail is always using tray 1, ignoring all default Windows settings.

I have been a little remiss in not keeping the internal properties info for Bearhtml.dll in step with the zip files naming, that I have been creating. I have been creating new versions of Bearhtml on an almost monthly basis, to introduce Html V5 coding requirements, at the same time keeping Html V4 coding alive. As well I am trying to implement CSS V3 fully, and started on CSS V4 as well as the draft version of CSS V5.

Martin

 

Thank you for the explanation Martin.

[quote user="irelam"]fixed announcement but don't see a way to update the main topic page?[/quote]

There's still the previous ZIP archive for download, Martin. If you want to change file and announcement there you need to go to the and select your respective page for editing which would be this one.

The zip file is loaded at http://community.pmail.com/files/folders/languages/default.aspx

Quite strange that posts of twelve years ago arrive as posted today...[*-)]

[quote user="Melissa2011B"]

Just got this from a client. Several clients in the last few months, have expressed not liking the quote back marks:

BTW, if you wouldn't mind, when you reply, please just type your reply as a new

message instead of interleaving your sentences into the text of my prior

message.  They way it is displayed on my screen has a profusion of >>>> and

weird indents that makes it very hard to read.

 

[/quote]

"The client is always right," so I'd suggest you to create an Identity where all your messages would be top-posted, pure HTML, and with your client message below your signature.

 

P.S. Also use For replies to HTML, preserve original's formatting on your Reply options to stick with your client preferences.