I'm not sure if this is the same problem but it seems that this explanation from Nick may shed some lights in. The text below is from PM-WIN@LISTSERV.UA.EDU archives.

[quote]Several "gurus" have looked at this several times.

The problem is obvious.

_Arguably_ RFC-correct multi-part messages with more than (from memory)
two levels of nesting and constructed in one of two (or more) legally
possible ways (that is where the arguments will start!  8-) ) are NOT
seen by PMail to have "closed" the "last level" of one of the MIME
level structures, when in fact, it has.  My _guess_ is that PMail then
scans through the rest of the digest looking for what it considers the
"missing" MIME part closure header.  It seems that the  parser is dead-
set that the next "MIME part header thing" it should see is this
"missing" part and thus it _ignores_ all the other MIME component part
start and end headers that exist from the point the PMail parser
errors, thus does not "see" any messages in the digest _after_ the
message in which this parsing error occurs.  As the digest summary
message -- the one that looks something like:

   There are 13 messages totaling 1058 lines in this issue.

   Topics of the day:

     1. smtp relay host
     ...
     6. PMAIL Digest - 4 Jan 2012 to 5 Jan 2012 (#2012-6)

-- is always the first message in the digest and (so far) always
produced in a format that cannot trigger this bug (it is a single-part,
text/plain-only Content-Type message) you can always see the correct
listing and count of the messages that the BAMA digester put into the
digest, but then may only see from 1-N (where N is the number from the
"There are 13 messages ..." sentence in the example above) messages
listed.  If you drop into "raw view" while reading the digest _and_ in
the message list viewer, you can see that all messages promised from
the digest summary are present, but as just described, PMail will not
actually list any of them (nor provide you any other way of seeing
them, other than "raw view") after the first message in the digest that
has this "imagined" MIME non-conformance issue.

In the last 4 or 5 years (maybe longer -- anyone keeping count?) this
has been noticed, replicated, analysed, and described on this list
multiple times, but never addressed in any updates.

It may well NOT be an easy fix, as the MIME component parser is
probably fairly crucial to a _lot_ of PMail internals and changing it
now may produce a whole lot of hurt (if nothing else, the beta testers
will presumably have to re-do a huge amount of message conformance
testing).



Regards,

Nick FitzGerald
[/quote]

Hope it helps. [:)]

I am a longtime user of PMAIL going back to DOS days. I love the ability to read MIME Digests, and I love the way PMAIL handles them. However, one particular list I subscribe to regularly fails to display all the messages in the digest.

Double-clicking the digest in my inbox will oipen a window containing the title information about the digest, and a list of SOME of the messages, always including the earliest message in the digest and a variable number more. I can read all those displayed in PMAIL, but no more. For example, a recent issue of the AMDIS list showed the header plus 2 more messages. Double-clicking the header message will show me the actual summary contained in the digest, thusly:

 I can only see the remaining contents in "Raw view" which of course contains a ton of html and other code.

 The only unifying feature in these digests I see is that all contain attachments or messages encoded in "base64." Is there some known bug parsing base64 in 32-bit Pmail? Is there a known workaround?

 I'm using WinPMail version: Version 4.63 (Win32), Dec 22 2011, build ID 325 on Windows 7sp1 32-bit, fully patched.

 Any ideas much appreciated.

David English