Multipart Message Formatting

Steeley

posted Aug 7 '22 at 8:42 am

[READ MY LAST POST IN THIS THREAD - this was "a loose nut on my keyboard", and not a Pegasus or IER problem. ~Steeley]

In 4.80 (and perhaps earlier versions) with IR 2.6.5.18 (also applies to IR 2.6.5.17 and perhaps earlier), it looks like there may be an issue with the multipart formatting which can cause sent emails to be discarded by the receiving email server.

With Sending Mail - > "Generate multipart/alternative versions of richtext messages" (in the Tools / General Settings menu), the pertinent formatting is as follows...

Priority: normal
X-mailer: Pegasus Mail for Windows (4.80.1028 )
Content-type: Multipart/Alternative;
boundary="Alt-Boundary-4747.1126761890"
X-PMFLAGS: 570950016 0 1 P5768L0U.CNM

--Alt-Boundary-4747.1126761890
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

This is an email with Multipart enabled <-----(message text)

--Alt-Boundary-4747.1126761890
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head>
<title></title>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<meta http-equiv="Content-Style-Type" content="text/css"/>
</head>
<body>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "><font face="Arial" size="2"><span dir="ltr" style="font-size:10.0pt; ">This is an email with Multipart enabled </span></font></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
</body>
</html>

--Alt-Boundary-4747.1126761890--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

With multipart deselected, this is the resulting format:

X-mailer: Pegasus Mail for Windows (4.80.1028 )
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-PMFLAGS: 34079360 0 1 P6A14D28.CNM

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head>
<title></title>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<meta http-equiv="Content-Style-Type" content="text/css"/>
</head>
<body>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "><font face="Arial" size="2"><span dir="ltr" style="font-size:10.0pt; ">This email sent with multipart generation delelected</span></font></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
<div align="left" style="min-height: 11pt; "></div>
</body>
</html>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

There is only html, no "text" at all. This has caused some mail parsers to reject the email as "empty"

Can this be confirmed as RFC compliant? Or at least, as intended?

[READ MY LAST POST IN THIS THREAD - this was "a loose nut on my keyboard", and not a Pegasus or IER problem. ~Steeley] In 4.80 (and perhaps earlier versions) with IR 2.6.5.18 (also applies to IR 2.6.5.17 and perhaps earlier), it looks like there may be an issue with the multipart formatting which can cause sent emails to be discarded by the receiving email server. With Sending Mail - > "Generate multipart/alternative versions of richtext messages" (in the Tools / General Settings menu), the pertinent formatting is as follows... Priority: normal X-mailer: Pegasus Mail for Windows (4.80.1028 ) Content-type: Multipart/Alternative; boundary="Alt-Boundary-4747.1126761890" X-PMFLAGS: 570950016 0 1 P5768L0U.CNM --Alt-Boundary-4747.1126761890 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body **This is an email with Multipart enabled** _<-----(message text)_ --Alt-Boundary-4747.1126761890 Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> <title></title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <meta http-equiv="Content-Style-Type" content="text/css"/> </head> <body> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "><font face="Arial" size="2"><span dir="ltr" style="font-size:10.0pt; ">**This is an email with Multipart enabled** </span></font></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> </body> </html> --Alt-Boundary-4747.1126761890-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With multipart deselected, this is the resulting format: X-mailer: Pegasus Mail for Windows (4.80.1028 ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-PMFLAGS: 34079360 0 1 P6A14D28.CNM <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> <title></title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <meta http-equiv="Content-Style-Type" content="text/css"/> </head> <body> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "><font face="Arial" size="2"><span dir="ltr" style="font-size:10.0pt; ">**This email sent with multipart generation delelected**</span></font></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> <div align="left" style="min-height: 11pt; "></div> </body> </html> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There is only html, no "text" at all. This has caused some mail parsers to reject the email as "empty" Can this be confirmed as RFC compliant? Or at least, as intended?

edited Aug 8 '22 at 4:02 am

Steeley

posted Aug 7 '22 at 9:00 am

Actually - The above was using IR 2.6.5.18, where an earlier message sent with IR2.6.5.17 produced the following multipart deselected with rich text..

X-mailer: Pegasus Mail for Windows (4.80.1028 )
Content-type: Multipart/Related; boundary="Message-Boundary-12625"
X-PMFLAGS: 570949760 0 1 P68TF1SD.CNM

--Message-Boundary-12625
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Mail message body

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

--Message-Boundary-12625--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Is this controlled/affected by IR? Pegasus is the same 4.80 version in all examples.

Actually - The above was using IR 2.6.5.18, where an earlier message sent with IR2.6.5.17 produced the following multipart deselected with rich text.. X-mailer: Pegasus Mail for Windows (4.80.1028 ) Content-type: Multipart/Related; boundary="Message-Boundary-12625" X-PMFLAGS: 570949760 0 1 P68TF1SD.CNM --Message-Boundary-12625 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns=3D"http://www.w3.org/1999/xhtml" xml:lang=3D"en" lang=3D"en">= <head> <title></title> <meta http-equiv=3D"content-type" content=3D"text/html;charset=3Dutf-8"/> <meta http-equiv=3D"Content-Style-Type" content=3D"text/css"/> </head> <body> {snip} </body> </html> --Message-Boundary-12625-- =-=-=-=-=-=-=-=-=-=-=-=-=-=- Is this controlled/affected by IR? Pegasus is the same 4.80 version in all examples.

edited Aug 7 '22 at 10:58 pm

Brian Fluet

posted Aug 7 '22 at 8:25 pm

In Tools > Options > Outgoing mail > Messages and replies, do you have the "Rich (formatted) text" set to "On"? I don't know whether this would override the generation of a plain text part but it is the only other option I can think of that might be involved. I have it set to "Off" and have confirmed that RTF messages I send contain both the HTML and the Plain text parts.

Win10 21H2 Home
PMail 4.80
IER 2.6.5.18

In Tools > Options > Outgoing mail > Messages and replies, do you have the "Rich (formatted) text" set to "On"? I don't know whether this would override the generation of a plain text part but it is the only other option I can think of that might be involved. I have it set to "Off" and have confirmed that RTF messages I send contain both the HTML and the Plain text parts. Win10 21H2 Home PMail 4.80 IER 2.6.5.18

Steeley

posted Aug 7 '22 at 10:05 pm

Yes, I do have Rich Text set to ON. And not having plain text somewhere in it doesn't seem to confound any receiving email servers (I doubt there's many left any more that don't know how to handle html, apparently none that I use anyway.) But that's just a curiosity question.

However, the big issue is that the previous IERenderer version IER2.6.5.17 malformed the email when multipart was disabled. The latest IERenderer version IR2.6.5.18 (released last week) corrected that...

IER2.6.5.17 (multipart deselected)
X-mailer: Pegasus Mail for Windows (4.80.1028 )
Content-type: Multipart/Related; boundary="Message-Boundary-12625"
X-PMFLAGS: 570949760 0 1 P68TF1SD.CNM

--Message-Boundary-12625
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Mail message body

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

IER2.6.5.18 (multipart deselected)
X-mailer: Pegasus Mail for Windows (4.80.1028 )
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-PMFLAGS: 34079360 0 1 P6A14D28.CNM

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

The release notes don't mention that correction.. (hey, why should Michael confess if he hasn't been charged with anything? smile )

https://www.pmpgp.de/renderer/History.htm

I guess I'm just saying "I see what you did there, Mike.." smile

..and at least this will hopefully document the issue for anyone stumbling over it in earlier IER versions..

For the record, I originally came to point out the problem with .17 and noted .18 was released and so installed that and then proceeded to post the results. And after I posted it, I spotted that the multipart formatting disappeared entirely - my original question was the lack of plain text in a message boundary. Since this was my first post using the new forum format I was unfamiliar with how to update the original post.. so I posted a followup reply - still confusing that way, but not as bad.

Yes, I do have Rich Text set to ON. And not having plain text somewhere in it doesn't seem to confound any receiving email servers (I doubt there's many left any more that don't know how to handle html, apparently none that I use anyway.) But that's just a curiosity question. However, the big issue is that the previous IERenderer version IER2.6.5.17 malformed the email when multipart was disabled. The latest IERenderer version IR2.6.5.18 (released last week) corrected that... _IER2.6.5.17_ (multipart deselected) X-mailer: Pegasus Mail for Windows (4.80.1028 ) **Content-type: Multipart/Related; boundary="Message-Boundary-12625"** X-PMFLAGS: 570949760 0 1 P68TF1SD.CNM --Message-Boundary-12625 Content-type: text/html; charset=ISO-8859-1 **Content-transfer-encoding: Quoted-printable** Content-description: Mail message body <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> _IER2.6.5.18_ (multipart deselected) X-mailer: Pegasus Mail for Windows (4.80.1028 ) **Content-type: text/html; charset=US-ASCII** **Content-transfer-encoding: 7BIT** Content-description: Mail message body X-PMFLAGS: 34079360 0 1 P6A14D28.CNM <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -------------------------- The release notes don't mention that correction.. (hey, why should Michael confess if he hasn't been charged with anything? :D ) https://www.pmpgp.de/renderer/History.htm I guess I'm just saying "I see what you did there, Mike.." 8) ..and at least this will hopefully document the issue for anyone stumbling over it in earlier IER versions.. _For the record, I originally came to point out the problem with .17 and noted .18 was released and so installed that and then proceeded to post the results. And after I posted it, I spotted that the multipart formatting disappeared entirely - my original question was the lack of plain text in a message boundary. Since this was my first post using the new forum format I was unfamiliar with how to update the original post.. so I posted a followup reply - still confusing that way, but not as bad._

edited Aug 7 '22 at 11:02 pm

Brian Fluet

posted Aug 7 '22 at 10:28 pm

We don't need Michael to disclose everything he does. I am intrigued though since I didn't see any complaints about it while 2.6.5.17 was out there. I'm going to try to remember to revert IER and test when I have time, just for the fun of it.

Steeley

posted Aug 7 '22 at 10:44 pm

I was involved in debugging some other email handling issues (that software's parser wouldn't handle anything with multipart formatting enabled) when, after we got that taken care of, it then stumbled over Pegasus' multipart disabled emails. So now I'm worn out and, since everything is working now and multipart disabled now looks sane, my curiosity of how far back that multipart disabled issue goes is about zip-point-zero.

I'm not sure how many people actually configure for multipart disabled - I did it in the course of troubleshooting the other software - so maybe it wasn't reported because nobody was using a multipart disabled configuration. (.17 only released June 30th.)

And I'll confess Michael may not have even known of it and it got fixed while doing something else.

Now, if you load up .17 and the problem doesn't reappear, I guess I'll just have to stop drinkin... smile

I was involved in debugging some other email handling issues (that software's parser wouldn't handle anything with multipart formatting enabled) when, after we got that taken care of, it then stumbled over Pegasus' multipart disabled emails. So now I'm worn out and, since everything is working now and multipart disabled now looks sane, my curiosity of how far back that multipart disabled issue goes is about zip-point-zero. I'm not sure how many people actually configure for multipart disabled - I did it in the course of troubleshooting the other software - so maybe it wasn't reported because nobody was using a multipart disabled configuration. (.17 only released June 30th.) And I'll confess Michael may not have even known of it and it got fixed while doing something else. Now, if you load up .17 and the problem doesn't reappear, I guess I'll just have to stop drinkin... |(

edited Aug 7 '22 at 10:54 pm

Michael

posted Aug 7 '22 at 11:48 pm

And I'll confess Michael may not have even known of it and it got fixed while doing something else.

I'm not dealing with any headers at all unless you're using my PMPGP extension. If the headers have been changed it's something in the encoding that may have triggered it such as patching Tidy for breaking proper URL encodings (but this would only occur extremely rarely), but I'm certainly not creating, deleting or modifiying any message headers at all with IER. This is completely done by David Harris' own code.

[quote="pid:54282, uid:3346"]And I'll confess Michael may not have even known of it and it got fixed while doing something else.[/quote] I'm not dealing with any headers at all unless you're using my PMPGP extension. If the headers have been changed it's something in the encoding that may have triggered it such as patching Tidy for breaking proper URL encodings (but this would only occur extremely rarely), but I'm certainly not creating, deleting or modifiying any message headers at all with IER. This is completely done by David Harris' own code.

			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

Steeley

posted Aug 8 '22 at 2:37 am

Hi Michael,

Well, I'm running straight Pegasus (4.80) with IER, and that's all. No extensions or plug-ins (unless Dave considers Win 10 an extension. smile )

I'll wait and see if Brian turns up anything untoward, and if not, then I'll reload .17 and see if I can reproduce it.

Hi Michael, Well, I'm running straight Pegasus (4.80) with IER, and that's all. No extensions or plug-ins (unless Dave considers Win 10 an extension. :P ) I'll wait and see if Brian turns up anything untoward, and if not, then I'll reload .17 and see if I can reproduce it.

Steeley

posted Aug 8 '22 at 3:56 am

OK, this appears to be MY FAULT....
As I noted above: I was involved in debugging some other email handling issues (that software's parser wouldn't handle anything with multipart formatting enabled) when, after we got that taken care of, it then stumbled over Pegasus' multipart disabled emails.

During the process I was working with two different servers, with two different accounts.. and switching between the two identities in Pegasus.. and after looking at the mail cache, I recovered the email that generated the format I posted under IER 2.6.5.17, that failed to go through.

The reason it failed to go through was not the formatting, but because it was sent from the wrong identity.
And that identity was configured with multipart enabled. And that message had content that indeed triggered Content-transfer-encoding: Quoted-printable in Pegasus.

The other identity was in the test configuration I wanted to test one of the servers with, but switching back and forth between identities and servers, that wasn't the one I used for sending the test message to that server.

Since we were chasing email format parsing issues, I stayed wrapped around that axle.

I hate it when software does what I tell it to do, and not what I want it to do or thought I told it to do..

And actually, drinkin' had nothing to do with it, but will likely be part of my embarrassment-recovery plan starting in moments.

Apologies to all for the arm waving..

OK, this appears to be MY FAULT.... As I noted above: _I was involved in debugging some other email handling issues (that software's parser wouldn't handle anything with multipart formatting enabled) when, after we got that taken care of, it then stumbled over Pegasus' multipart disabled emails._ During the process I was working with two different servers, with two different accounts.. and switching between the two identities in Pegasus.. and after looking at the mail cache, I recovered the email that generated the format I posted under IER 2.6.5.17, that failed to go through. The reason it failed to go through was not the formatting, but because it was sent _from the wrong identity._ And that identity was configured with multipart enabled. And that message had content that indeed triggered_ Content-transfer-encoding: Quoted-printable_ in Pegasus. The other identity was in the test configuration I wanted to test one of the servers with, but switching back and forth between identities and servers, that wasn't the one I used for sending the test message to that server. Since we were chasing email format parsing issues, I stayed wrapped around that axle. I hate it when software does what I tell it to do, and not what I want it to do or thought I told it to do.. And actually, drinkin' had nothing to do with it, but will likely be part of my embarrassment-recovery plan starting in moments. Apologies to all for the arm waving..

Michael

posted Aug 8 '22 at 7:49 am

I'm never surprised to learn about something new I hosed without knowing I even could, so I know how it feels smile , there's always a chance for being a real issue behind something weird, somtimes only time will prove ...

I'm never surprised to learn about something new I hosed without knowing I even could, so I know how it feels ;), there's always a chance for being a real issue behind something weird, somtimes only time will prove ...

			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

Brian Fluet

posted Aug 8 '22 at 1:40 pm

I'm glad you figured out what happened. I tested with IER 2.6.5.17 late last night, reread the discussion, ended up confused, realized I was tired, went to bed. I'm glad I visited here this morning before picking up where I left off last night.

Steeley

posted Aug 8 '22 at 7:31 pm

"confused, realized I was tired, went to bed."

It's contagious, Brian. That's what caused me to start this thread, and you caught it from me..
After two days of debugging OPCs (other people's code, and I'm not a programmer), and wore out, I went to bed, got up in the morning, and decided I should notify the community of a problem I uncovered.
And I did just that...

...only it wasn't Pegasus or IER..

Turned out it was a guy who has been using Pegasus since shortly after it was originally released in 1990 and is starting to realize he's getting too old for this stuff..

"confused, realized I was tired, went to bed." It's contagious, Brian. That's what caused me to start this thread, and you caught it from me.. After two days of debugging OPCs (other people's code, and I'm not a programmer), and wore out, I went to bed, got up in the morning, and decided I should notify the community of a problem I uncovered. And I did just that... ...only it wasn't Pegasus or IER.. Turned out it was a guy who has been using Pegasus since shortly after it was originally released in 1990 and is starting to realize he's getting too old for this stuff..

edited Aug 8 '22 at 7:42 pm

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history