Characters being stripped from emails since upgrade from 2.1.2 to 2.3.0 #2816
Comments
|
That is interesting. Would you be able to provide a full (uncorrupted) copy of the raw email? |
|
Hi @catphish, the "original message source" above is the uncorrupted version, with the "delivered message source" being the corrupted output that is ultimately delivered. |
Sorry, I wasn't clear in my email, I meant the full raw email (with headers etc). I know you can't download it without corruption, but if you can get a copy somehow that would be very helpful. |
|
@catphish Sure, give me 10 :) |
|
@catphish Ok so it may not be so simple. I can capture the SMTP transcript between the sending webserver and Postal if that's what you're after. It is however formatted terribly, so I apologize in advance. The headers Postal captures are below - if it's something else you need, let me know and I'll try and get it.
As you mentioned, I can't capture the client headers (i.e from Outlook) and have a non-corrupted email. I can send the email via other means outside of Postal and capture that, though I'm not sure if that'll be of any use to you? Lee |
|
Can you pull the text out of the database manually? You mentioned you could read it there. |
|
I can give you the message source, but it doesn't include the headers, just the body I'm afraid and that's what's posted above.
I'm not sure which table Postal stores the header data in internally, but I imagine it'll just be as per the screenshot in my previous comment. Any logging we can enable? |
This is actually extremely useful. I have a hypothesis. We will look into it and let you know. |
|
Great! If you need anything else, I'll be glad to help :) |
|
We've now identified the problem. When the link tracking system modifies the email, we only save the updated message body, and ignore any changes to the headers.
If you look at the raw .eml file in a text editor, you will see there is no corruption, just clean HTML, but a header saying it's quoted-printable, when it's not. We will be working on a fix ASAP. In the meantime, you have two workarounds available:
Thanks to @adamcooke who did the hard work on reproducing this. |
|
As @catphish said, I've pushed a fix for this and released Assuming it works, this issue probably sets a record for the quickest resolved issue in Postal history so congratulations. I can't guarantee any future issues will be so lucky but you never know 🤞 |
|
Hi @catphish, @adamcooke Okay so that makes sense. We're using a Wordpress plugin on this website to generate the emails - if it's generating garbage headers then I'll file a bug with them too. Unfortunately given the limitations of the plugin I'm unable to change the origin headers without butchering the plugin, which I'd like to avoid (as above, I'll raise a bug report with the plugin author and see if that can be resolved). In the interim I've set Wordpress to just send the plain text version of this particular email so it's not a showstopper right now thankfully. I'm reluctant to disable the open tracking as it's come in handy a bunch of times when customers are complaining about missed deliveries etc, but it's good to know it's an option if this particular issue becomes more widespread in the interim. I'd just like to thank you for your exceptional support with this. I raised the issue an hour ago (at 9pm no less) and you've already identified the issue, given me a workaround and are working on a permafix, which I think is absolutely incredible; even more so for an open source project that I can clearly see is a labour of love. I'd love to give something back as a token of my thanks, though I can't see a donate link or anything of the sort. Thanks for all your help. I've been using Postal for a year now and it's been rock solid! |
|
I assume it may take some time for this to filter down? Lee |
|
Yeh, I might have spoke a bit soon. It seems like the build didn't finish. It's currently building the image so it should be there soon. |
|
No worries - I'll try again in 15 and will let you know if the issue is resolved. Thanks again |
No - the original email is perfectly valid. It's Postal messing up the headers. It's just unusual (but perfectly valid) that the Wordpress plugin generates emails with HTML only. Usually you'd send both HTML and plain text together in the same email (multipart). |
|
So I've got the new version installed, re-tested the email and this is now working flawlessly :) |
|
@pawprintdigital The image has made its way in to the container registry now so you should be good to upgrade now. Edit: I see you've already discovered this on your own. Good to hear it works! |
|
There is one final thing.. After enabling click tracking, the reset link no longer works. Without click tracking, the output link is https://thewhole-shebang.co.uk/my-account/lost-password/?key=XXXXX&id=3 With the click tracking, the resulting link is: https://click.shop.thewhole-shebang.co.uk/nuknvj/XXXXX The broken & breaks the reset flow. It's not a major issue as I can live without the click tracking for the time being, but if you're currently in the god-mode fixing mood... ;) Happy to create a new issue for this if I can't find an existing open issue for it. Lee |
adamcooke
added
the
star-issue
There is an issue for that #907. It's quite an old one which escaped our attention. It'll be fixed in v3 which will be available soon. |
|
Great, thanks. I'll leave this thread alone now as it's all resolved. Lee |
Describe the bug
I have a bizarre issue wherein HTML appears to be getting mangled in seemingly random emails.
Viewing an affected message renders fine in the backend (with no missing characters), however downloading the email from the backend, or viewing the resulting email in Outlook etc. results in broken source code. See below:
The message source is correct in the "raw-xxxx-xx-xx" database table for a given message, so the issue seems to be occurring once it's being parsed either for download or delivery.
It would appear that the first character from any attributes wrapped in quotes is being lost, but I'm at a loss as to why.
The same template is used for numerous emails (the source is a WooCommerce website) and share the same header/footer HTML etc, which in turn isn't affected.
I upgraded to 2.3.0 from I believe 2.1.2 a few days ago, at which point the issue began.
I don't believe the email HTML itself is the problem, however I'll gladly be proven otherwise.
Click tracking is turned off, though open tracking is enabled. Toggling these still produces the issue.
I'm happy to provide any further information/run tests etc to get this nailed.
Original message source
Delivered message source
To Reproduce
I'm able to consistently reproduce the issue with these particular emails (password resets), however other emails appear to be working fine. Please see above.
Expected behaviour
Characters not stripped.
Environment details
The text was updated successfully, but these errors were encountered: