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
