SOLVED Mailer-Daemon and Mail Queue Manager Show Subject and To Encoded in Base64

[linux4me2]

I'm using WHM 60 build 17. I got a delay message from the Mailer-Daemon that has both the subject of the message and the "to" encoded in Base64. I checked the message in Mail Queue Manager, and both display the subject of the message like this:

=?UTF-8?B?TmV3IHByaXZhdGUgbWVzc2FnZSBoYXMgYXJyaXZlZA==?=

There aren't any special characters in the original subject. Decoded from Base64, it simply says, "New private message has arrived".

At first, I thought there was a problem with the bulletin board that attempted to send the message, but I tested it and the emails it sends for a new private message, when received in my email client, display the subject in UTF-8 as they should.

Is this a bug in WHM, by design, or do I have something configured incorrectly? It seems like encoding the subject and "to" of a message makes it more difficult to troubleshoot email issues.

 

[cPanelMichael]

Hello,

Could you search for the message in /var/log/exim_mainlog and see if the same subject shows up there? EX:

exigrep MSGID /var/log/exim_mainlog

It seems possibly related to the issue discussed on the following third-party URL:

Exim4 Fix Wrongly Decoded Mail Subject — Martin Klepsch

Thank you.

 

[linux4me2]

Thanks for the info. That does sound like the source of the problem.

I searched exim_mainlog with the message ID I had, but it showed the subject of the failure message and not the original message's subject. I couldn't find the message ID for the original message, though I searched /var/log/exim_mainlog using the recipient's email address too. The original message has been removed from the queue, so I can't get the message ID there, either. I'll check the next time I get one of these.

 

[cPanelMichael]

Hello,

You can also verify that check_rfc2047_length is set to "False" in your /etc/exim.conf file (It should be set to "False" by default in cPanel):

# grep check_rfc2047_length /etc/exim.conf
check_rfc2047_length = false

Feel free to post the output from /var/log/exim_mainlog for one of these messages the next time one comes through.

Thank you.

 

[linux4me2]

Yes, check_rfc2047_length is set to "false". I'll post when I get another one of these messages. Thanks for the help.

 

[linux4me2]

Here's the output from /var/log/exim_mainlog for one of these messages that just came through:

2016-11-23 22:19:32 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1c9lVU-0003Gp-AQ

2016-11-25 02:32:57 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1c9lVU-0003Gp-AQ

2016-11-25 02:32:57 1cABwH-0003lN-Rr <= <> R=1c9lVU-0003Gp-AQ U=mailnull P=local S=2634 T="Warning: message 1c9lVU-0003Gp-AQ delayed 24 hours" for [email protected]
2016-11-25 02:32:58 1cABwH-0003lN-Rr => firstuser ([email protected]) <[email protected]> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <[email protected]> yN9VATr3N1iPOAAA1I9b2Q Saved"
2016-11-25 02:32:58 1cABwH-0003lN-Rr -> seconduser ([email protected]) <[email protected]> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <[email protected]> yN9VATr3N1iPOAAA1I9b2Q:2 Saved"
2016-11-25 02:32:58 1cABwH-0003lN-Rr Completed

2016-11-25 10:36:02 cwd=/usr/local/cpanel/whostmgr/docroot 3 args: /usr/sbin/exim -Mvh 1c9lVU-0003Gp-AQ

2016-11-25 10:36:02 cwd=/usr/local/cpanel/whostmgr/docroot 3 args: /usr/sbin/exim -Mvb 1c9lVU-0003Gp-AQ

+++ 1c9lVU-0003Gp-AQ has not completed +++
2016-11-23 22:19:32 1c9lVU-0003Gp-AQ <= [email protected] H=host.hostdomain.com [XX.XX.XX.XXX]:60659 P=esmtpsa X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_login:[email protected] S=1422 [email protected] T="New private message has arrived" for [email protected]
2016-11-23 22:19:32 1c9lVU-0003Gp-AQ SMTP connection outbound 1479961172 1c9lVU-0003Gp-AQ thedomain.com [email protected]
2016-11-23 22:19:32 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-23 23:33:46 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 00:33:44 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 02:33:41 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 04:33:37 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 07:33:32 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 11:33:25 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-24 17:33:14 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete
2016-11-25 02:32:57 1c9lVU-0003Gp-AQ == [email protected] R=dkim_lookuphost defer (-1): host lookup did not complete

 

[cPanelMichael]

Hello @linux4me2,

Could you open a support ticket using the link in my signature so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[linux4me2]

I would if I could, but I don't believe I can. My web host is the licensee for cPanel, so I don't think I have the ability to create support tickets. I will get in touch with them and see if they'll open a support ticket for me and post back.

 

[linux4me2]

My web host opened a support ticket for me. The ticket number is 8040999.

 

[cPanelMichael]

To update, it was explained in the support ticket that the "to" and "subject" lines in the bounceback messages are MIME encoded, and handled by the sending client as opposed to the server. This page explains a little more about how MIME encoding works in email headers:

RFC 2047 - MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text

Thank you.

 

[linux4me2]

I don't have access to the full explanation in the support ticket, and this seems like it might be over my pay grade, but I have to ask. Is the sending client the web app that sent the original email, or the server that bounced that message? In either case, at what point does it get encoded in Base64?

 

[cPanelMichael]

Hello,

It's happening on the email client used to send the message, and that's where the encoding happens. You can start at "5. Use of encoded-words in message headers" in the URL referenced on my last response for additional information. For instance:

(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
user-defined ("X-") message or body part header field.

Thank you.

 

[linux4me2]

Thanks for the explanation. As far as I'm concerned, you can mark this one resolved.