| kugel- | |
| Jun 9 2016, 12:42 PM |
| F1681753: Screen Shot 2016-06-09 at 12.45.35 PM.png | |
| Jun 9 2016, 7:46 PM |
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 y.de/D565" rel="noreferrer" target="_blank">http://phab.xxxx-xxxxxx.yyy.de/D565</a>
Sorry that I obfuscated the URL. I only replaced characters with x and y respectively, the URL is otherwise exactly like that.
| rP Phabricator | |||
| D15885 Send HTML email by default | |||
| D16095 | rPc694bd651b49 Make base64 the default SMTP encoding | ||
Can you try this?
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:
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.
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:
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
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: <01000155354ac441-69a45106-259f-4a37-86b7-cdecd57ba118-000000@amazonses.com> Delivered-To: xxx.yyy@a.b.de Received: from mx1.mailbox.org ([80.241.60.212]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by dobby4.heinlein-hosting.de (Dovecot) with LMTP id VdrMEtpkWVdFlwIAJEBNLA for <xxx.yyy@a.b.de>; Thu, 09 Jun 2016 15:12:32 +0200 Received: from gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) by mx1.mailbox.org (Postfix) with ESMTP id EB5C843A6A for <xxx.yyy@a.b.de>; Thu, 9 Jun 2016 15:12:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from mx1.mailbox.org ([80.241.60.212]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.170]) (amavisd-new, port 10024) with ESMTP id UPSWAZ2BxNjZ for <xxx.yyy@a.b.de>; 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 giant.haxx.se (giant.haxx.se [80.67.6.50]) by mx1.mailbox.org (Postfix) with ESMTP for <xxx.yyy@a.b.de>; Thu, 9 Jun 2016 15:12:26 +0200 (CEST) Received: from a8-128.smtp-out.amazonses.com (a8-128.smtp-out.amazonses.com [54.240.8.128]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTP id u59DCPpO032441 for <xxx.yyy@a.b.de>; Thu, 9 Jun 2016 15:12:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1465477940; h=Date:To:From:Reply-to:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Feedback-ID; bh=K4RuiBgMN4yx+xwntr3cB48V06baAfG/IHtPtP0YqJ4=; b=MECVA4oEmVmvjvLzaoVieE2I/dfW2+07igU7Q/8p9FMQbK9XPYnhDM16zhMqqxC6 8g97irvzyRoHDdbst2fi/m405BkGdBESy7YxWnATGLBESohrGqzzRJb0+lF8zP6+H0b 45pQAZntBeDY1lmTZBcGcW+IwsfI653t33y/ME74= Date: Thu, 9 Jun 2016 13:12:20 +0000 To: kugel@rockbox.org From: "epriestley (Evan Priestley)" <noreply@phabricator.com> Reply-to: T11120+39243+18249ee1ed0db3df@phabricator.com Subject: [Maniphest] [Commented On] T11120: HTML mails malformed Message-ID: <01000155354ac441-69a45106-259f-4a37-86b7-cdecd57ba118-000000@email.amazonses.com> 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: <maniphest-task-PHID-TASK-r6wyl7ttoecxv4bwskue@phabricator.com> References: <maniphest-task-PHID-TASK-r6wyl7ttoecxv4bwskue@phabricator.com> Thread-Index: OTg0MzMxNzI1N2Q5ZWQ3ODMyNDQ3NmI1YjEzIFdZazM= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="utf-8" X-SES-Outgoing: 2016.06.09-54.240.8.128 Feedback-ID: 1.us-east-1.pGOpYxVIMAH0SQCvAG4joaSeOLUocwRUW94fFoAvTwo=:AmazonSES <table><tr><td style="">epriestley added a comment. </td></tr></table><br /><div><div><p>Here is a string of 2048 unbroken "M" characters:</p> <p>MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM! MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM! MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://secure.phabricator.com/T11120" rel="noreferrer">https://secure.phabricator.com/T11120</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://secure.phabricator.com/settings/panel/emailpreferences/" rel="noreferrer">https://secure.phabricator.com/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>epriestley<br /><strong>Cc: </strong>epriestley, kugel-, naddlk, vinzent<br /></div>
Received: from giant.haxx
Well there's the problem. Your mail server is a giant hack. :)
The client was thunderbird and the webclient (based Open-Xchange). I received it on my personal mail account, outside the company.
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".
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.
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.
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.
