On 11 Dec 2004 at 22:12, Steffen Heil wrote about
"AW: AW: [exim] Urgend unpacking proiblem":
|...
| > Do you have a acl_smtp_mime ACL as well as acl_smtp_data? If so, maybe
| > the unpacking is being triggered in there. If not, run a test with "exim
| > -d-all+acl -bh" to get a clue.
|
| Great idea, I didn't think for that.
| Yes, I have acl_smtp_mime as well as acl_smtp_data.
There's your answer.
| I always believed acl_smtp_mime would only be triggered by exiscan upon
| demime condition.
ACLs are always run if you define them. If you have a line like
acl_smtp_mime = some_acl_name
then some_acl_name will be run at the appropriate time, period.
Also, while normally acl_smtp_mime will not decode MIME parts to disk
unless directed to via "decode", but:
- For RFC822 attachments (these are messages attached to
messages, with a content-type of 'message/rfc822'),
the ACL is called again in the same manner as
for the "primary" message, only that the $mime_is_rfc822
expansion variable is set (see below). These messages
are always decoded to disk before being checked, but
the files are unlinked once the check is done.
Note the last sentence. I believe the problem message consists of
very deeply nested RFC822 attachments, so each message part will be
decoded to disk.
| Sine demime is not called, I believed acl_smtp_mime not being triggered.
According to the spec, "demime" is being maintained only for
backwards compatibility. It is actually superceded by the MIME ACL,
which is more powerfull.
| Is there a way to prevent that?
I can't think of any way to suppress invocation of the MIME ACL based
on message recpients. I think your only option is to not define a
MIME ACL, and use demime in the DATA ACL instead.
- Fred
