Content Altered - Causing display issues

[iammattmartin]

We've seen that content via Postal appears to be altered in such a way that when Gmail receive it, the content is completely different.

I have sent the message from our mailer system directly to Gmail and the content is perfect but only that which goes via Postal gets completely altered.

Could anyone think of why this would happen?

[catphish]

Could this be related to #106? Otherwise, are you able to explain how the content has been altered?

[iammattmartin]

I don't believe so but I am doing some further testing and comparing side by side one via postal and the same message not. Wanted to just see if anyone else had seen the same thing.

[catphish]

Thanks. If you can identify exactly how it was changed, I'm sure we can track it down.

[iammattmartin]

It appears to be just the way that Gmail displays via the web view. If you view your Gmail mails via IMAP the content appears the same.

However, the content type changes.

Direct from server:
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="utf-8"

Via postal:

MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

When I download the original message of that going via postal to that not, the content is the same but when I "view original" in Gmail's interface, the lines are wrapped and suspect it is the quoted-printable parsing the content as text instead of HTML.

[iammattmartin]

Further to that. It may be related to #106 but in a different way.

We were sending a HTML only message without a text counterpart.

When we sent with a text counterpart, the HTML part was shown correctly with a different content-type output.

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_ee079b92370ca00e8276bdc0b6cc7d33"

--b1_ee079b92370ca00e8276bdc0b6cc7d33
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

test plain text.

--b1_ee079b92370ca00e8276bdc0b6cc7d33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

[adamcooke]

We'll look into this. To work around it, you should be able to disable tracking and the message shouldn't be touched at all.

[yogesum]

HTML only email with tracking enabled has display issue. Anyone one working on it?
If not, could you specify the problematic code.

[willpower232]

If this issue is related to the content type of message parts, have a look at #376

[yogesum]

I pulled changes and tested for email without text part. still same issue.

[erikassuncao]

I confirm the problem. It's still exists. Does anyone know how to fix it?

[pjv]

to get graphic about this (what I think is the same issue)...

with tracking:

without tracking:

i need both tracking and non-borked html emails. if anyone can tell me where to start digging into the postal source, i'll try to fix this and post a PR.

[iammattmartin]

If you're only sending a HTML version, that might be related. Does that happen when sending a text version as well as HTML?

[catphish]

This looks specifically with the content-encoding of the HTML part, or perhaps the content-encoding of the message as a whole.

[pjv]

Just on HTML emails and only those from a particular source. HTML emails passing through the same postal server with the same settings that originate from a discourse forum are not altered with tracking enabled. The messed up email shown above originates from a WooCommerce online store.

The discourse forum emails have both plain text and html parts and are multipart / alternative encoded. The messed up WooCommerce email has no plain text part.

[pjv]

@catphish can you tell me where to look in postal's source for whatever content-transfer-encoding mangling it does when it pushes a tracking pixel into a message?

[iammattmartin]

The discourse forum emails have both plain text and html parts and are multipart / alternative encoded. The messed up WooCommerce email has no plain text part.

So the ones that are being messed up are those with only HTML content and no text part. If so, that's what we found and adding a text part was the only "workaround" currently.

[pjv]

@iammattmartin thanks for that pointer. I installed a plugin on the WooCommerce site that just adds a plain text part to all outgoing emails and it's "fixed". i'm glad it's working now, but this is a total kludge.

I looked at lib/postal/message_parser.rb where the tracking pixel is getting inserted into the email. It kinda sorta made sense and i'm pretty sure that the issue is somewhere in either the function / method generate or the function / method parse_parts but I'm not a ruby dev so the code looks foreign to my pythonic / PHP eyes and I'm totally unfamiliar with whatever mailing library is in use here.

could it be as simple as the fact that in parse_parts it's setting the content_transfer_encoding for each part to nil?

[nhadsall]

Is there a fix for this in the works? One of my sites is affected too. Thanks!

[iammattmartin]

The work around remains adding a text part.

[nhadsall]

Thanks @iammattmartin. The issue is that we wanted to roll this out to several of our clients who all use WP sites. We would have to intercept all mail calls to add a text only part to the emails. And if something went wrong, then things would get messed up. I think a more reliable fix would be just making sure Postal can handle emails without the text part. Of have an option for Postal to generate it.

@willpower232 any thoughts?

[pjv]

@nhadsall it definitely would be better to have this fixed in Postal.

In the mean time, this WP plugin which adds a plain text part to any WP emails that don't have one, is working across all the sites I manage which all send email through Postal: https://wordpress.org/plugins/lh-multipart-email/

[nhadsall]

Thanks @pjv. I found that one too. It worked on one site, but not another. We realized the issue was the plugin that was intercepting wp_mail() and sending with to the Postal server. I assume it was the priority used by the various hooks in each plugin.

[pjv]

@nhadsall which plugin are they using to send mail to postal? I've standardized on this one: https://wordpress.org/plugins/wp-mail-smtp/

[uhlhosting]

Since 2017, no idea why this was even closed back then, when was clearly not solved until today.