Re: [exim] Mime + filename matching

> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Phil Pennock
> Sent: Friday, February 08, 2008 4:17 PM
> To: Craig Jackson
> Cc: exim-users@???
> Subject: Re: [exim] Mime + filename matching
>
> On 2008-02-08 at 15:52 -0600, Craig Jackson wrote:
> > Case did occur to me, so that's why I used ${lc:$mime_filename}
> > Wouldn't that take care of case?
>
> I missed that. Sorry.
>
> So in that case, I suspect that your message was too small -- you're
> only checking messages over a certain size; note that each "condition"
> rule needs to be satisfied.
>
> If you want to set acl_m7 when _either_ the size is over a
> certain limit
> _or_ when there's an extension matching that list, then either use two
> separate warn rules or combine the two conditions into one condirion,
> with or{{}{}}; given the complexity, I'd recommend splitting into two
> separate warns.
>
> -Phil
>
Okay, I'm really showing my mime ignorance here, but it only happens
when the attachment shows up within the body of the email as if it were
inline rather than as an attachment (using Thunderbird). I hope that
makes sense. The size of the emails are well over the limit in every
case. I've tried duplicating this by sending the exact same attachment
but the acl catches it. It's got to be a mime issue. Here's the header
from an email containing the same image sent from a yahoo! (god help
them) account to me that was caught by the same acl:

Header:
Content-Type: multipart/mixed; boundary="0-2028537276-1202418523=:13119"

Mime boundary:
--0-2028537276-1202418523=:13119
Content-Type: multipart/alternative;
boundary="0-1661705436-1202418523=:13119"

--0-1661705436-1202418523=:13119
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
it now.
--0-1661705436-1202418523=:13119
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

lag<span style="font-weight: bold;">aeraergaer<img
src="http://us.i1.yimg.com/us.yimg.com/i/mesg/tsmileys2/02.gif"><br>aera
eraeraer<img
src="http://us.i1.yimg.com/us.yimg.com/i/mesg/tsmileys2/11.gif"><br>aera
ergaaergaergaerg<br></span><p>&#32;
      <hr size=1>Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile. <a
href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ah
u06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a>
--0-1661705436-1202418523=:13119--
--0-2028537276-1202418523=:13119
Content-Type: image/bmp; name="test.bmp"
Content-Transfer-Encoding: base64
Content-Description: 1704005798-test.bmp
Content-Disposition: inline; filename="test.bmp"

This is different from the headers I posted earlier, and I think the
explanation is somehwhere in there.