Page MenuHomePhabricator

HTML mails malformed
Closed, ResolvedPublic


We've updated our phabricator instance and are now getting HTML mails per default (as expected).

However, some of the mails are malformed:

<a href="http://phab.xxxx-! xxxxxx.yy" rel="noreferrer" target="_blank"></a>

Sorry that I obfuscated the URL. I only replaced characters with x and y respectively, the URL is otherwise exactly like that.

Event Timeline

kugel- created this task.Jun 9 2016, 12:42 PM

Can you try this?

  • Find the mail in bin/mail list-outbound, identifying the internal ID of the mail.
  • Dump the raw HTML with bin/mail show-outbound --id <id> --dump-html.
  • Tell me if the raw HTML is malformed?

If the raw HTML is not malformed, this is a problem with either our handoff to your MTA, your MTA itself, or your client, so we need information about those:

  • Which mail adapter are you using (metamta.mail-adapter)?
  • How do you send mail?
  • Which client do you use to view mail?

Particularly helpful would be to write some comment on this task which reproduces the issue for you, then tell me which client you're using.

(I suspect this is an MTA handoff/MTA issue, though, and that no comment you can make on this install will reproduce the problem.)

bin/mail show-outbound --id <id> --dump-html shows the mail fine.

  • metamta.mail-adapter is set to PhabricatorMailImplementationPHPMailerLiteAdapter.
  • This mail was generated by differential (closed revision). But there are other, similar differential mails that are not affected. Some other ones (updated revisions) are also affected, but again not all of them.
  • The client is IBM Notes (company dictated...). The webmail client (IBM Lotus iNotes) has the same problem. Unfortunately I can't find how to view the raw mail on these.
kugel- added a comment.Jun 9 2016, 1:00 PM

The webmail client allows me to view the raw mail. It's malformed as well.

It seems that, so far, only the "REVISION DETAILS" section is affected, and only the href attribute.

It's possible that adjusting phpmailer.smtp-encoding (say, to binary or base64) might fix this.

If it does, I'm not sure if it's a bug in the Adapter or if 8bit simply can not encode all inputs properly. A reading of RFC1341 suggests this may be the case; if so, we should likely default to binary or base64. But I feel like every time I find information in an RFC it's wrong because it has been obsoleted by five newer RFCs, so who knows.

The trigger for the behavior is likely just "long lines of text", we had an earlier report of something similar occurring inside an inline comment snippet (but it could not be reproduced on this install).

Oddly, in the prior case where mail was mangled for a user on their install but similar mail was not mangled here, the unmangled mail I received was encoded in "8bit", which tends to suggest that this might be an MTA problem rather than an "8bit" problem, per se. But changing the encoding away from "8bit" might be the only real lever we have to fix the MTA.

Here is a string of 2048 unbroken "M" characters:


chad added a project: Mail.Jun 9 2016, 3:29 PM
kugel- added a comment.Jun 9 2016, 7:33 PM

Here's the mail that I received for your comment. You can see that the M stream is broken with "!" in two places. This seems to match the behavior I observed initially, although there was also an extraneous blank.

Return-Path: <>
Received: from ([])
	(using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	by (Dovecot) with LMTP id VdrMEtpkWVdFlwIAJEBNLA
	for <>; Thu, 09 Jun 2016 15:12:32 +0200
Received: from ( [])
	by (Postfix) with ESMTP id EB5C843A6A
	for <>; Thu,  9 Jun 2016 15:12:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([])
	by ( []) (amavisd-new, port 10024)
	with ESMTP id UPSWAZ2BxNjZ for <>;
	Thu,  9 Jun 2016 15:12:27 +0200 (CEST)
X-policyd-weight:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_MX=-3.1 (check from: .amazonses. - helo: .giant.haxx. - helo-domain: .haxx.)  FROM/MX_MATCHES_NOT_HELO(DOMAIN)=1; rate: -3.6
Received: from ( [])
	by (Postfix) with ESMTP
	for <>; Thu,  9 Jun 2016 15:12:26 +0200 (CEST)
Received: from ( [])
	by (8.15.2/8.15.2/Debian-4) with ESMTP id u59DCPpO032441
	for <>; Thu, 9 Jun 2016 15:12:25 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1465477940;
Date: Thu, 9 Jun 2016 13:12:20 +0000
From: "epriestley (Evan Priestley)" <>
Subject: [Maniphest] [Commented On] T11120: HTML mails malformed
Message-ID: <>
X-Priority: 3
X-Phabricator-Sent-This-Message: Yes
X-Mail-Transport-Agent: MetaMTA
X-Auto-Response-Suppress: All
X-Phabricator-Mail-Tags: <maniphest-comment>
Thread-Topic: T11120: HTML mails malformed
X-Herald-Rules: <105>, none
X-Phabricator-Projects: <#bug_report>
X-Phabricator-To: <PHID-USER-ba8aeea1b3fe2853d6bb>
X-Phabricator-Cc: <PHID-USER-ba8aeea1b3fe2853d6bb>
X-Phabricator-Cc: <PHID-USER-w42jhnsmxnzpcglc2baz>
X-Phabricator-Cc: <PHID-USER-z2tgimjrmscmwdn7rypw>
X-Phabricator-Cc: <PHID-USER-p4inixvlyz7at2nl3yul>
Precedence: bulk
In-Reply-To: <>
References: <>
Thread-Index: OTg0MzMxNzI1N2Q5ZWQ3ODMyNDQ3NmI1YjEzIFdZazM=
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="utf-8"
X-SES-Outgoing: 2016.06.09-

<table><tr><td style="">epriestley added a comment.
</td></tr></table><br /><div><div><p>Here is a string of 2048 unbroken &quot;M&quot; characters:</p>

 MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="" rel="noreferrer"></a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="" rel="noreferrer"></a></div></div><br /><div><strong>To: </strong>epriestley<br /><strong>Cc: </strong>epriestley, kugel-, naddlk, vinzent<br /></div>

Interesting. The same mail was delivered to me intact:

chad added a subscriber: chad.EditedJun 9 2016, 7:55 PM

Received: from giant.haxx

Well there's the problem. Your mail server is a giant hack. :)

kugel- added a comment.Jun 9 2016, 7:57 PM

The client was thunderbird and the webclient (based Open-Xchange). I received it on my personal mail account, outside the company.

avivey added a subscriber: avivey.EditedJun 9 2016, 8:04 PM

If your email goes through postfix, it breaks lines after 1000 bytes, rain or shine.
The solution I got from IT was "Set phabricator to encode the mail using base64".

eadler added a subscriber: eadler.Jun 9 2016, 8:08 PM

From RFC 2822 There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
I believe the behavior of splitting the lines using a ! is implementation specific.

eadler added a comment.Jun 9 2016, 8:11 PM

More specifically, I believe phabricator is violating the RFC when it sends overly long lines and that postfix (or whatever is munging the output) is taking a rather silly action as a result.
base64 encoding the output should work around the problem.

Let's just make base64 the default and see what that breaks. ¯\_(ツ)_/¯

kugel- added a comment.Jun 9 2016, 8:19 PM

How can I enable base64 encoding within phabricator?

ConfigAll Settingsphpmailer.smtp-encoding

epriestley closed this task as Resolved.Jul 8 2016, 2:20 PM
epriestley claimed this task.

Presuming this was resolved by D16095 since we haven't seen further reports, or new reports of brokenness.

I will probably remove the option eventually since there seems to be no real reason to set it to anything except base64.