Mail subject displayed as empty when encoded

[dregad]

I noticed that the mail subject is sometimes not displayed in the MailHog GUI, as shown in screenshot below:

Looking at the headers, the problem appears to occur only when Subject: is encoded, there is no problem with plain ASCII text. From the above screen:

• Subject: Test project 1 - 0020355 -> displays OK
• Subject: =?us-ascii?Q?[Project:_Test_project_1,_Bug#:_0020355]:_webp_?= =?us-ascii?Q?test?= -> shown empty instead of the expected output [Project: Test project 1, Bug#: 0020355]: webp test

I'm running MailHog from the docker image.

[dregad]

Looks like the javascript library used to decode the subject string is not capable of handling us-ascii encoding.

There is no convert function for USASCII defined in INPUT_CONVERTERS var, so convertBytesToUnicodeCodePoints() function just returns an empty array.

[dregad]

The PHP application I'm using relies on PHPMailer library to send email using PHP's internal mail() function. In this configuration, PHPMailer encodes the mail subject per RFC2047 quoted encoding, folding it to avoid header corruption when the lines are longer than 63 chars. This is what is causing the 2 US-ASCII-encoded string in my earlier example.

Considering that US-ASCII is a subset of UTF-8, a simple solution would be to add a new entry to INPUT_CONVERTERS list, so USASCII is processed by the UTF8 converter function, like so

--- strutil.js	2020-04-13 09:05:08.489987520 +0200
+++ strutil.js.fix	2020-04-13 09:04:47.138836304 +0200
@@ -708,7 +708,8 @@
   'ISO88591':  convertIso88591BytesToUnicodeCodePoints,
   'SHIFTJIS':  convertSjisBytesToUnicodeCodePoints,
   'EUCJP':     convertEucJpBytesToUnicodeCodePoints,
-  'UTF8':      convertUtf8BytesToUnicodeCodePoints
+  'UTF8':      convertUtf8BytesToUnicodeCodePoints,
+  'USASCII':   convertUtf8BytesToUnicodeCodePoints
 }
 
 function convertUnicodeCodePointsToBytes(unicode_codes, encoding) {

What do you think ?

[halmai]

This issue is very annoying.

Even if it is not decoding it properly, at least the raw subject should be written, as a temporal solution.

[khag7]

I can confirm I'm experiencing the same issue. And adding 'USASCII': convertUtf8BytesToUnicodeCodePoints as described above does work without any issue.

[fabswt]

I'm still getting empty subject-lines in MailHog. I'm using the latest version (installed in April 2022, though tried reinstalling just now to be safe, same results.) Consider these two subject lines:

$subject = "Hello, world - this is an email test, let's see"; // ok at 47 chars
$subject = "Hello, world - this is an email test, let's see!"; // blank at 48 chars

They result, respectively, in (from the source tab):

Subject: Hello, world - this is an email test, let's see
Subject: =?us-ascii?Q?Hello,_world_-_this_is_an_email_test,_let's_see?= =?us-ascii?Q?!?=

And then in the dashboard:

---

EDIT: FYI, I get this in production when opening the email source in Gmail and Hotmail (exact same value for both):

Subject: Hello, world - this is an email test, let's see!

So it's different from the source in MailHog. I guess because of how the receiving email servers work, but I don't know for certain. (For sending, using PHPMailer 6.6.0 for both dev and prod.)

[troseman]

seeing this too, maybe open new issue?

[JasonTheAdams]

Just noticed the same thing as @fabswt. If I truncate my subject to 47 characters it shows up correctly. If it's 48 characters or more then it doesn't show up and has the encoding included. It took a frustrating amount of time to figure that out.

Looks like this is fixed on master, but there hasn't been a release since December 2020... not a good sign.

[dregad]

@tyndyll @gedge I appreciate that this is an open-source project and that you guys are probably busy with more pressing matters, but still it would be great if you could take the time to cut a new 1.0.2 release including this fix (and whatever else has already been committed to master).

Thanks in advance for your support

[tyndyll]

Thanks for understanding, things have been manic but starting to stabilise. My plan is to get back to this towards the end of this month. Im aiming for a new release Aug 1st

[dregad]

@tyndyll any update on the new release ? 🙏

[tyndyll]

WIP - merging some of the submitted PR's and then getting to this fix. Still aiming for the next few days

[JasonTheAdams]

For what it's worth, I figured out a workaround for this. Applying the following headers did the trick:

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

Setting text/plain should also work, but for my case I want html. The issue is that MailHog is assuming, without those headers, that the encoding is ASCII, so UTF-8 characters break the subject. Explicitly telling it the encoding resolves the issue.

[bartkleinreesink]

@JasonTheAdams Unfortunately that didn't work for me.

[dregad]

WIP - merging some of the submitted PR's and then getting to this fix. Still aiming for the next few days

The "next few days" are now long gone, still hoping for a release with this fix 🙏

[theenoahmason]

Having this issue in WordPress while using Local by Flywheel's included Mailhog implementation, using emails sent via WordPress' default wp_mail() functionality.

A character limit is causing encoding, starting with: =?us-ascii?Q? which then does not appear in Mailhog. I believe the encoding is okay, but Mailhog shows a blank subject line. Inspecting the headers reveals the encoded subject.

[dregad]

Friendly happy new year bump 😃

[EdithAllison]

Same issue here on LocalWP which comes bundled with Mailhog. Reported to LocalWP https://community.localwp.com/t/mailhog-does-not-show-subject-lines/36250. If you are a LocalWP user, please vote and/or add comments and suggestions how to improve, eg replace Mailhog with Mailpit.

[dregad]

After nearly 3 years, I finally gave up hope and switched to https://github.com/axllent/mailpit...

[rtpHarry]

Oof I spent over an hour trying to figure out why the blog name was breaking the subject line, before it finally occurred to me it wasn't the setting, it was just the length. I found this in minutes then.

[obromios]

Thank you to all the contributors to mailcatcher and then mailhog. I do appreciate how it can become difficult to maintain these creations. But, I have changed to mailpit, which continues the fine tradition and is a drop in replacement.