On Thu, 26 Jun 2014, Lena@??? wrote:
>> From: Jamie <jamie@???>
>
>> deny message = Blacklisted file extension detected
>> condition = ${if match \
>> {${lc:$mime_filename}} \
>> {\N(\.exe|\.pif|\.bat|\.scr|\.lnk|\.com|\.zip)$\N} \
>> {1}{0}}
>>
>> It has hugely reduced the amount of spam, but they have suddenly worked
>> around it by sending documents with an attachment name of "& # 1057 ;
>> opy_of_document_SER176.zip" (without spaces)
>
> How the full header of the MIME part looks undecoded? Use the
> "view source" function of your MUA, like perhaps Ctrl-U in Thunderbird,
> e in Mutt, Ctrl-F3 in Outlook Express. Base64-encoded filenames
> like this example should be decoded correctly:
It appears the RFC2047 decode in Exim can be tricked, and the spammers
have figured out how to exploit it.
For example, this is a recent MIME part (I added "_")
Content-Type: application/x-zip-compressed;
name="&_#_1057_;opy_of_Document_ID7851.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="&_#_1057_;opy_of_Document_ID7851.zip"
When Exim expands the variable $mime_filename the result
is only "&_#_1057" and nothing else (again _'s added)
