Hi Viktor Thanks for your claification and pointing to the right RFC.
On 06.12.17 21:08, Viktor Dukhovni wrote: > Mostly, because correctly encoded content is basically valid: > > https://tools.ietf.org/html/rfc2047#section-5 > > in the free-form "phrase" part of the From header. The mailsploit attack is not only going to the "free-form phrase", it's also affecting the from-address. Doing the test with the Thunderbird payload [1] yields in the from-header: From: "=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=0A=00?=" <=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=0A=00?=@mailsploit.com> If compare that line to the cited RFC (2047, section 5, paragraph 3), I think this is in multiple ways against the recommendation: on page 7: - "An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'." - "An 'encoded-word' MUST NOT appear within a 'quoted-string'." - [...] "'encoded-text' MUST NOT be continued from one 'encoded-word' to another" - "Only printable and white space character data should be encoded using this scheme." on page 6, under (1): - "However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'" I did some testing with my exim with the patterns suggested on mailsploit.com: Exim does throw an error, when the whole from address is encoded with one method like base64 but not when the address is encoded in a mix of base64 and quoted-printable. The From:-header line from above passes without any complaint. If I understand the RFC 2047 correctly, neither the "free-form phrase" nor the from-address is compliant. Regards, Adrian. [1] https://www.mailsploit.com/index#demo -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
