Mark,
Can you do something about these mails so that they're compliant with the Internet RFCs please?
The problem is you're sending them with "Content-Type: text/plain" but without specifying a character set, so the default assumes 7-bit us-ascii encoding. See http://www.ietf.org/rfc/rfc2045.txt, 6.1:
... An encoding type of 7BIT requires that the body is already in a 7bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.
Also 6.2 applies:
The proper Content-Transfer-Encoding label must always be used. Labelling unencoded data containing 8bit characters as "7bit" is not allowed, nor is labelling unencoded non-line-oriented data as anything other than "binary" allowed.
Also 5.2:
5.2. Content-Type Defaults
Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
However, you include top-bit-set characters in the message, which violates that, and causes readers to do this kind of thing:
On Tue, Jul 29, 2014 at 12:24:26PM +0100, Build bot for Mark Brown wrote:
3 ../include/linux/regulator/consumer.h:480:12: warning: ???regulator_list_hardware_vsel??? defined but not used [-Wunused-function] 3 ../include/linux/regulator/consumer.h:473:12: warning: ???regulator_get_hardware_vsel_register??? defined but not used [-Wunused-function] 3 ../include/linux/regulator/consumer.h:468:23: warning: ???regulator_get_regmap??? defined but not used [-Wunused-function]
Please either run the build with LANG=C in the environment to produce 7-bit us-ascii, or provide "Content-type: text/plain; charset=utf-8" and "Content-Transfer-Encoding: 8bit" headers to indicate that it contains utf-8 characters and uses the full 8bit character range in the body.
Thanks.