I think I have a sense, why David doesn't want it. I think he would have to completly rewrite the way mails are displayed.

For imagination have a look at that (it's the second example) starting with content-type in main header:

• multipart/alternative
  
  • text/plain
  • multipart/mixed
    
    • text/html
    • application/pdf
    • text/html

Funny [:S]

   Olaf

P.S. I'll mark this thread solved - even if there is no solution, but I have an explanation.

We have a discussion at the german mailinglist on Pegasus and nobody has a solution. Someone got a mail from an appleuser:

X-Mailer: Apple Mail (2.752.3)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/mixed; boundary=Apple-Mail-43-169523306

--Apple-Mail-43-169523306
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

(--> First part of mailtext, which is displayed within Pegasus)

--Apple-Mail-43-169523306
Content-Type: multipart/appledouble; boundary=Apple-Mail-44-169523306
Content-Disposition: attachment

--Apple-Mail-44-169523306
Content-Transfer-Encoding: base64
Content-Type: application/applefile; name=ESSENTIALS new.doc
Content-Disposition: attachment; filename="ESSENTIALS new.doc"

(--> Special part of attached file with information for filesystem of MacOS, irrelevant on Windows)

--Apple-Mail-44-169523306
Content-Transfer-Encoding: quoted-printable
Content-Id: <62D307C1-1138-44B2-B542-58176FB7FE43@w90-27.abo.wanadoo.fr>
Content-Type: application/octet-stream;  x-mac-type=52544620;  x-unix-mode=0755;  x-mac-creator=4D535744;  name=ESSENTIALS new.doc
Content-Disposition: attachment; filename="ESSENTIALS new.doc"

(--> Data of attached file, in that case obviously text/rtf or application/rtf but not declared like that, is saveable by Pegasus)

--Apple-Mail-44-169523306--

--Apple-Mail-43-169523306
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed

(--> Second part of text, but not displayed by Pegasus)

--Apple-Mail-43-169523306--

Someone knowing about that problem sayed, that minimum on  iPad or iPhone the user may drag and drop any attachment anywhere in the mailtext and Applemail obviously inserts his multipart/appledouble exactly at that point into the mail. So in raw view the text of the mail is splitted into two parts. Problem is, that if Pegasususer doesn't look exactly at the attachments, he may not recognize the second part of mailtext. Questions:

• Is this behaviour of Applemail in conformity to RFC?
• Is there a workaround in Pegasus or with a plugin?

The user tested and found, that the webfrontend of email-provider web.de is capable to handle this and join the two textparts during display, but is there a solution for Pegasus? I will have to ask the user, if there is a CSID anywhere in the first textpart ... otherwise the CSID at  datapart of attachment doesn't make any sense ... and as I know doesn't make it at all as long as the first part isn't text/html.

bye   Olaf

[quote user="FJR"]Is this behaviour of Applemail in conformity to RFC?[/quote]

See RFC 2183 for details about the Content-disposition header, specifically the inline type which doesn't appear in the headers you quote (which Pegasus Mail doesn't handle the recommended (it's a should, not a must) way, though). BTW: What or where is "multipart/appledouble"? Workaround is to check your attachments, of course.

Hallo Michael,

• RFC 1740
• Wikipedia
• Microsoft

multipart/appledouble consists of two parts: header (with finder information and resource fork, type application/applefile) and data (any mimetype for attachments). The information in the header part is only relevant for filesystem with MacOS, so may be ignored by all other OS.

Is David planing to insert handling in PM5?

bye   Olaf

[quote user="FJR"]Hallo Michael,multipart/appledouble: Have a look above ... there is a boundary with that content type in. Information on that: [/quote]

First of all: Sorry, I really overlooked it. But the issue you're describing isn't related to this header (or the whole section denoted by it), since this header only applies to the attachment files, and as you say the Windows version of it can properly be saved as file. So with regard to the text parts my first reply is still correct and Pegasus Mail is handling them correctly. IOW: Nothing to add here. Oh, and if you don't believe me: Remove the multipart/appledouble section and you'll still get only the first text section displayed.

I believe in what you say.

I understand  that even if second text-part is declared inline Pegasus wouldn't display it. Is that right?

I have another example here very similar - no multipart/apple-double but application/pdf in between -  where content-disposition is declared inline in second textpart (and PDF, but that's irrelevant, because I guess nobody would expect Pegasus to display the PDF in his viewer).

bye    Olaf

[quote user="FJR"]I believe in what you say.[/quote]

You better don't ... [;)]

[quote user="FJR"]I understand  that even if second text-part is declared inline Pegasus wouldn't display it. Is that right?[/quote]

Yes, Pegasus Mail doesn't implement the RFC's recommendation (only David Harris can tell his reasons).