Question Regarding RFC822 mime parts

Tom,

A question about how the MIME ACL is called in the context of attached
messages. (Patch revision 21)

When sending a message with an RFC 822 attachment, as the MIME headers
describe below.
> --------------050000040007040808060807
> Content-Type: message/rfc822;
>	name="[***SPAM***][Score:12.1] larynges"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>	filename="[***SPAM***][Score:12.1] larynges"


I've found that the MIME ACL is called twice for this MIME part. Once
as:

>>> Found content-type: MIME header, value is 'message/rfc822'
>>> Found name= MIME parameter in content-type: header, value is
'[***SPAM***][Score:12.1] larynges'
>>> Found content-transfer-encoding: MIME header, value is '7bit'
>>> Found content-disposition: MIME header, value is 'inline'
>>> Found filename= MIME parameter in content-disposition: header, value
is '[***SPAM***][Score:12.1] larynges'
>>> using ACL "acl_check_mime"


And the second time as:

>>> RFC822 attachment detected: running MIME ACL for
'/usr/local/exim/spool/scan/1BVYjQ-0006bU-St/__rfc822_00000'
>>> Found content-type: MIME header, value is 'multipart/alternative'
>>> Found boundary= MIME parameter in content-type: header, value is
'--9249391545251218552'
>>> using ACL "acl_check_mime"


I was wondering whether this was intentional or not. The reason it came
up is that the first time it's called it has $mime_filename set to the
"subject" of the RFC822 attachment, which I wasn't expecting.

I've worked around it with the following, so that an ACL of mine doesn't
run on it on the first pass:
  condition = ${if
!match{$mime_content_type}{\N^message\/rfc822$\N}{1}{0}}

Cheers,
Matt.