> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Phil Pennock
> Sent: Saturday, February 09, 2008 5:49 PM
> To: exim-users@???
> Subject: Re: [exim] Mime + filename matching
>
> On 2008-02-09 at 09:20 -0600, Craig Jackson wrote:
> > Second, the problem with this mime acl: I understand something more
> > since I went back and reread the spec.txt. The
> mime_filename is derived
> > from the content_type or content_disposition headers - but
> no other. Not
> > all MUAs set the filename in these headers. In the above case,
> > mime_filename was set in the content_id header, thus Exim set
> > mime_filename to the empty string. So why didn't Exim set the second
> > part of OR condition (that is the content_type check) to
> true and thus
> > the entire condition to true. I used exim -d+acl+expand -bh
> IPADDRESS to
> > see all this. The answer must be that I made a mistake in there
> > somewhere. So am rechecking and will get back to you.
> Thanks for your
> > patience.
>
> *sigh* Apparently, yesterday was not my day for reading
> comprehension.
> Somehow I missed that the second example was one which was
> caught by the
> filters and was provided as contrast to the first one. Sorry.
>
> Right, Content-ID is not supposed to be used for specifying a filename
> for saving a message or any such thing -- it's strictly for
> identifying
> the sub-parts of a message so that things like HTML mail can refer to
> those images for inline display.
>
> See: RFC 2392 Content-ID and Message-ID Uniform Resource Locators
>
> That RFC contains examples, etc; note that the fact that the value of
> the header looks like a filename is an implementation detail of the
> sender. If any software is sending this mail with the
> expectation that
> those images be saved, it's broken. I suspect that you're just seeing
> large background images in spam and discovering a hard limitation of
> $mime_filename for spam-detection.
>
> The content_type check is failing because when I said that it
> would work
> accidentally I was wrong; yesterday really was an off day for me.
> You're requiring that the content-type _start_ 'bmp' or the
> like, using
> an anchored regexp. A content-type is formed type/subtype so
> since you
> don't allow for the image/ or application/ part, you'll never match
> there.
>
> -Phil
>
> PS: I read private email via my machine in Europe. Exim was developed
> by a British developer and the primary maintainers are all in the
> UK; ghettoisation will bite you hard.
>
No need to apologize. In all of my years of posting what most list
monitors would consider low level silly mixed up confusing questions
I've never had someone post responses as patiently as you do. Thanks.
You've been extremely helpful.
BTW, the MUA that mangled the mime boundary headers in the email in
question is: X-Mailer: Groupwise 6.5
Also I've corrected the mime_content_type condition to check from ^ to
$. And I've changed it to test more like what one might expect based on
both content-type header rfc AND what broken MUAs might just do on their
own. If you have a better way of doing this, say, as in checking some
other header, please let me know.
Thanks again.
Craig
