[quote user="Euler GERMAN"]I maybe wrong as I never used AOL but as noted by Olaf 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).

I received an email from Verizon which contained a GIF file image of a UPS Shipping Label.

On AOL's WebMail Server ( who now runs Verizon.Net email services )  the GIF is a quality image and I printed it.

However in P-Mail that wasn't the case.  If I view the GIF attachment within P-Mail I get "Read Aborted" error with the dialogue labeled "Gif2Bmp".

When I save the GIF and view it it is very low quality with black banding artifacts.

When I use AOL's View Message Source and extract RAW email and save to .EML format the EML file is 52KB and views properly in both T-Bird and Windows Live Mail.

When I am in the attachment section of P-Mail it shows the GIF to be 5.9KB.  When I extract the GIF from the AOL WebMail server or from the EML file I created from there, the GIF 29KB.

When I view the RAW format in P-Mail and Copy the RAW data and create an EML file, the EML file is only 22KB.

P-Mail is corrupting the email and truncating the GIF.

When I look at the RAW email in Notepad++ I see the section...

Content-Type: application/octet-stream; name=1Z5X18F29094633828.gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=1Z5X18F29094633828.gif

However in the two different EML files what comes after is portrayed quite differently which may account for the GIF corruption.

[quote user="David H. Lipman"]

P-Mail is corrupting the email and truncating the GIF.

[/quote]

I doubt it very much, but YMMV. And unfortunately, the information you provided is not sufficient to determine a cause of the problem nor propose a solution. Could you share the troublesome message? It would be nice to know which renderer (and its version) used too.

Unfortunately, I can't share the email itself, publicly, as it contains a UPS Shipping label and thus it contains PII.

However I loaded the two variants of the email and captured representative ScreenShots of the embedded Base64 structure.

Here is the view when it is extracted from P-Mail

Here it is when it was extracted from AOL WebMail

In case one presumes it is a one-off problem and that it isn't reproducible, well it is.   When email is POP'd out of the InBox on AOL, AOL moves it to the Trash Folder of the AOL WebMail server.  All is good there.  The GIF is OK and ~29KB

When I view it it in P-Mail the GIF is again corrupted and showing it's only ~5.9KB.

So I go back and move the email out of the AOL WebMail server Trash folder back into the AOL WebMail server InBox and POP it off the server using P-Mail.   Every time, same result.

So I go back and once again move the email out of the AOL WebMail server Trash folder back into the AOL WebMail server InBox and I then Disabled Verizon POP in P-Mail,  I then loaded MS Outlook and then chose  Send/Receive.  Sure enough,  I get a quality GIF and the MD5 CheckSum  is the same from MS Outlook POP'd off the server as the GIF extracted from the RAW format, used to create an EML file, from the message on the AOL WebMail server.  Only when P-Mail POP'd the email off the server does the GIF get corrupted and only within P-Mail.  Thus I come to the conclusion P-Mail is corrupting the email.

Hmm, what caught my attention was that the Base64 encoded attachment is spread over nine lines (Pmail) and on a single only (AOL). I'm not sure if the latter is RFC compliant, though we know Microsoft, AOL et al don't care much about RFC. AFAIK Pegasus Mail does and maybe it may have lead it to error. Not a conclusion, just a hunch.

I pinched this text snip from RFC2045:

(Soft Line Breaks) The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long.  If longer lines are to be encoded with the Quoted-Printable encoding, "soft" line breaks must be used.  An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text.

All in all, it's still difficult to infer what caused the problem on Pegasus Mail. Maybe Martin Ireland or Michael in der Wiesche can shed lights on this.

From the conversion error GIF2BMP  you got in Pegasus Mail, I would suspect that you were using Pegasus Mail internal message displayer, in Text mode, not either Bearhtml or IERenderer Html renderers.  You should check the message headers for a Content-Type-Multipart line indicating that a Multipart message has been created, which would likely contain both a plain text message and a Rich-Text/Html version of the message body.

Before we look into this further you should try to click the View menu item to see if rendering in rich/html is better.  If that doesn't work, we will need to see an example message. Please send a copy to me at irelam17@telus.net.  Do not post it to this community site. We will not share it to anyone else.

Martin 

That caught my attention as well.

I used the Compare Plug-In in Notepad++ and loaded both EML file variants.

Of course, the first notable difference would be what P-Mail inserts into the header;  X-PMFLAGS [ X-PMFLAGS: 570966016 0 1 PA19AP5U.CNM   ]

That's obvious so I'll leave it out ( It'll also guarantee their checksum won't be the same as well ).  There were two other notables.

On the Left Pane, the RAW format from the AOL server.  On the Right Pane, the RAW format from P-Mail

--------------------------------------------------------------------

#1 - This one appears to be that P-Mail has removed the period "." delimiter within the URL

#2

[quote user="irelam"]Please send a copy to me at irelam17@telus.net.  Do not post it to this community site. We will not share it to anyone else.[/quote]

Email sent.  Obrigado.

Hi David,

the mail is a "little bit" malformed - as usual with AOL:

[quote]Here it is when it was extracted from AOL WebMail[/quote]

1. No line of a mail has to be longer than about 1024 characters - never!!!
   
2. AOL declared to attach a file encoded base64. This means, that there is no line longer than 64 characters (under some circumstances 68 characters).
   

I can't see what exactly happens, but Pegasus tries it's best. It seems Pegasus wraps the lines to the allowed 1024 characters. That's the reason why you see more lines in Pegasus than in "original". May be there's going something wrong on wrapping or the poor quality is due to even after wrapping the file still isn't base64 encoded.

Bye    Olaf

AOL didn't malform the email.  It was sent from Verizon so if one is to state it was malformed then one must state Verizon malformed the email in its creation.

However...  It must be noted that when the RAW email is extracted and placed into a TXT file and renamed to .EML, Mozilla Thunderbird and  Microsoft Live Mail had no problem rendering the email.  When Microsoft Outlook was used to POP the email off the server, Microsoft Outlook also had no problem rendering the email.  In short;  AOL Webmail, T-Bird, Microsoft Live Mail and Microsoft Outlook all had zero issues rendering the email and extract the GIF from the Base64 encoded stream.  The problem of rendering the email is only found in P-Mail. 

It also does not explain why P-Mail had removed the period "." delimiter within the YouTube URL in Line 186 of that email,  That email's secondary bug was very similar to one that I had previously reported where a Newegg invoice font was corrupted because the preceding Period, "." , in the Font size had also removed.

[quote user="David H. Lipman"]

[quote user="irelam"]Please send a copy to me at irelam17@telus.net.  Do not post it to this community site. We will not share it to anyone else.[/quote]

Email sent.  Obrigado.[/quote]

David/Martin,

this message never made it through to me, can any of you please send it to <beta-reports [at] pmail.gen.nz> as well and tell me in a personal email what subject to look for so I can find among all the spam messages on this account? Don't try to send the sample to my personal address, it's very likely to be blocked by external spam filters so I'll never get to see it at all if so.

Michael:

Email sent.  Subject of email;   "Re: PMail corrupted email from Verizon."

Danke

[quote user="David H. Lipman"]…  In short;  AOL Webmail, T-Bird, Microsoft Live Mail and Microsoft Outlook all had zero issues rendering the email and extract the GIF from the Base64 encoded stream.  The problem of rendering the email is only found in P-Mail.[/quote]

There's a (big?) difference between Pegasus Mail and cited e-mail "clients". All of them use full blown browser engines to render messages and that means it can also execute scripts. Another "limitation" of Pegasus Mail is that it plays by the e-mail rules while others either don't respect them or turn a blind eye to them. Note the fact that the bogus message had a single line of code when it should be spread into several lines. This is no problem for a browser. I used to convert my site's HTML code into a single line both to save space and to obfuscate it, what is fine. But when it comes to e-mail there are rules to follow because you don't know which client your addressee/customer is using.

Unfortunately, companies like MS, AOL, and others used these malpractices to force users to adopt their products. This is not much different of that OAuth2 thing that has nothing to do with security but to force users to abandon their applications (like Pmail) in favor of their Web interface meant to spoil/explore you. Martin Ireland and Michael in der Wiesche are doing a superb job overcoming all sorts of oddities these people produce. I don't know how long they'll last, but I will stick with Pegasus Mail anyway. If the seller can't talk to me, it's his problem not mine.

I really hope this malformed thing doesn't become Byzantine.

[quote user="David H. Lipman"]Email sent.  Subject of email;   "Re: PMail corrupted email from Verizon."[/quote]

Thanks David, I'll look into it ASAP.

UPDATE:

I have been keeping the related email in a folder on the AOL WebMail Server.

I have been dealing with the creation of a new email account due to the deteriorating health of Microsoft MVP Derek Knight and the loss of services Derek provided me. 
This new account has IMAP and it dawned on me that I never used P-Mail to use AOL IMAP and that I could try to render this email directly from IMAP.

When I view the referenced email using IMAP the GIF is rendered properly and repeated tests show the problem only occurs when P-Mail POPs the email off the AOL server.

[quote user="David H. Lipman"]When I view the referenced email using IMAP the GIF is rendered properly and repeated tests show the problem only occurs when P-Mail POPs the email off the AOL server.

[/quote]

Wouldn't that be "When AOL POPs out the email from server?" Pegasus Mail does nothing but showing what it gets and your recent experience with the IMAP protocol confirms it. Please have in mind that POP3 and IMAP are just message transferring protocols. They don't change the payload. If something came malformed its server's fault, believe me.

Your problem IIRC was a very long line length what would do fine if rendered in a browser or email client with a browser engine like Outlook or Thunderbird, but Pegasus Mail lays strictly by the rules.

I am no expert on email.  But I can tell when one application acts differently compared to others performing the same action.

It may be a matter of semantics bout it is only when P-Mail POPs the email off the AOL InBox there is a problem.  Other Email clients POP'ing the same email off the InBox don't have a problem.

I do not see it as a "server fault" ( which one would that be anyway ?  Sender ? Receiver ? Intermediaries ? ) if other email clients have no sequale.   I think I stated this prior but it would be a issue of how the email is created and/or rendered, now how the servers pass it it along the path or hosts it.

Presuming  "Pegasus Mail lays strictly by the rules" is belied by there not be a problem using IMAP vs. POP3. 
It would be my presumption that those "rules" would be the same for POP3 as for IMAP. 
I propose that that is not the case, the two protocols are not handling the email equally, and thus this is something to be looked at for P-Mail v5.x.

What I said is that AOL server is most likely providing a message its web interface could read. I maybe wrong as I never used AOL but as noted by Olaf 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.

Now, there are very condescending clients like Outlook and Thunderbird (to mention two) because they were built over the browser they came from (IE and Firefox). They act more like a webmail, including script execution. Pegasus Mail never, ever executes scripts for security reasons, which may be a cause.

As for the different content depending on the protocol I can only advise you to stick to the best fit solution. You can always copy or move messages to your computer using IMAP.

Obrigado.

YW [:)]