Malformed bug update emails causing spam false-positives

[philipp_subx@…]

I'm getting emails that unfortunately don't follow the RFC requirements for well-formed messages, and hence cause false positives in Spamassassin, et al.

Luckily, these are minor issues and are easily fixed:

Subject: Re: [Openchrome-users]
	=?utf-8?q?=5BopenChrome=5D_=2334=3A_random_dia?=
	=?utf-8?q?gonal_lines_appearing?=

What's wrong with this? Two things:

• messages must be encoded in the smallest character set they will fit into. i.e. us-ascii (for 0x00-0x7f), then iso-8859-1, and lastly utf-8 for all else (i.e. non-Western European text).

• putting the same encoding into a message twice is redundant. The encoding is persistent across continued lines… and ending the encoding (with ?=) just before a line-break that's continued is superfluous.

These should be trivial issues to fix.

Oh, one other thing:

--===============1257072393==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

IzM0OiByYW5kb20gZGlhZ29uYWwgbGluZXMgYXBwZWFyaW5nDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpSZXBvcnRlcjogIFJvbWFuIEtoaW1vdiAgfCAgICAgICAgT3duZXI6ICBzb21lYm9keQ0KICAg
IFR5cGU6ICBkZWZlY3QgICAgICAgIHwgICAgICAgU3RhdHVzOiAgbmV3ICAgICANClByaW9yaXR5
OiAgbWFqb3IgICAgICAgICB8ICAgIENvbXBvbmVudDogIHhkcml2ZXIgDQogVmVyc2lvbjogICAg
ICAgICAgICAgICAgfCAgIFJlc29sdXRpb246ICAgICAgICAgIA0KS2V5d29yZHM6ICAgICAgICAg
ICAgICAgIHwgIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tbWVudCAoYnkgUm9tYW4gS2hpbW92
KToNCg0KIENvbmZpcm1lZC4gWWVzLCB0aGF0IGlzIHJlYWxseSB0aGUgcGF0dGVybi4gVGhhbmtz
Lg0KDQogQW5kIHNvcnJ5IG9uY2UgYWdhaW4gZm9yIG1lc3N5IHJlcG9ydCB3aXRoIGxvZyB1bmF0
dGFjaGVkIGFuZCBzY3JlZW5zaG90cw0KIGJlaW5nIGVtYmVkZGVkIGluIHBhZ2UsIEkgZGlkbid0
IHJlYWxpemUgYXQgZmlyc3QgdGltZSB0aGF0IHRoaXMgdGhpbmcNCiB1c2VzIFdpa2kgZm9ybWF0
dGluZyB0aGF0IG11Y2guDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly93d3cub3BlbmNocm9t
ZS5vcmcvdHJhYy90aWNrZXQvMzQ+DQpvcGVuQ2hyb21lIDxodHRwOi8vd3d3Lm9wZW5jaHJvbWUu
b3JnLz4NClRoZSBvcGVuQ2hyb21lIHByb2plY3Q=

--===============1257072393==

Only spammers use base64 encoding on simple text (as a way of trying to defeat simple scanning of messages for keywords). There shouldn't be anything in this content that can't be correctly represented via quoted-printable encoding instead.

[Emmanuel Blot]

Can you give some pointers to the "RFC requirements for well-formed messages" you're refering to ?
I did not find (yet?) the RFCs that specify that "messages must be encoded in the smallest character set they will fit into", so any reference would help.

About encoding specification redundancy: although the encoding format is actually redundant, the syntax is fully valid, and I don't think it is worth optimizing this piece - AFAIK, those headers are generated w/ the help of the Python email module, and there is no way to tweak this behaviour.

In both cases, the notification emails are still valid (until proved otherwise) i.e. not "malformed" but sub-optimal which are known to cause some spam filters to generate false positives.

Base64 MIME issue: this problem has already been addressed in #1754: encoding type can be chosen by the administrator.

For future reference, related RFCs are:

• ​RFC2822: Interet Message Format (supersedes RFC822)
• ​RFC2045: Format of Internet Message Bodies
• ​RFC2047: Message Header Extension for Non-ASCII text
• ​RFC2049: MIME Conformance Criteria and Examples

[Emmanuel Blot]

Closing this ticket as no feedback has been received, and the aforementionned "RFC requirements for well-formed messages" are yet to be referenced.

Other issues have already been fixed.

Feel free to re-open this ticket if you have new pieces of info.