Re: [exim] Strange attachment scanning results

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Craig Jackson
Dátum:  
Címzett: Exim-users
Tárgy: Re: [exim] Strange attachment scanning results


> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Craig Jackson
> Sent: Monday, December 18, 2006 2:55 PM
> To: Exim-users@???
> Subject: [exim] Strange attachment scanning results
>
> Hi,
>
> I use Exiscan with Exim v. 4.62. I am experiencing very
> strange attachment scan. There is a test as follows in the
> check_mime acl:
>
> warn     condition = ${if or \
>     { { >{$message_size}{1536k}} 
>     { and { \
>     { >{$message_size}{128k}}
>     { eq{${lookup mysql{MYSQL_BIGSENDERS}}}{$sender_address}}} 
>     }}{1}{0}}
>       condition = ${if
> match{${lc:$mime_filename}}{\N^(?>.*)(?<=wma|jpg|jpeg|pps|ppt|
> gif|png|wm
> v|mpg|mp3|mpeg|avi|wav|bmp|mov|asf|asx)\N}{1}{0}}
>       set acl_m7 = 1

>
> This works perfectly except for one sender whose over-sized
> emails never trigger this warn. If I cut and paste the
> sender's email and send it myself, it also does not trigger a
> warn. So I figure the sender's emails have some kind of
> cruddy headers for the attachments. Here are some of the headers:
>
>
> ------_=_NextPart_002_01C722DB.54957A22--
>
> ------_=_NextPart_001_01C722DB.54957A22
> Content-Type: image/gif;
>     name="ATT390607.gif"
> Content-Transfer-Encoding: base64
> Content-ID: <002c01c72201$24f5d1f0$0500a8c0@mainbox>
> Content-Description: ATT390607.gif
> Content-Location: ATT390607.gif

>
> PICTURE...
>
> ------_=_NextPart_001_01C722DB.54957A22
> Content-Type: image/jpeg;
>     name="ATT390608.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <002e01c72201$24f5d1f0$0500a8c0@mainbox>
> Content-Description: ATT390608.jpg
> Content-Location: ATT390608.jpg

>
> PICTURE...
>


Hey, I figured it out by taking a closer look at the boundary and
reading the spec:

 This is perhaps the most important of the MIME variables. It contains a
    proposed filename for an attachment, if one was found in either the
    Content-Type: or Content-Disposition: headers. The filename will be
RFC2047
    decoded, but no additional sanity checks are done. If no filename
was
    found, this variable contains the empty string.


Now I have to add a condition for Content-type checking.