Re: AW: AW: [exim] Urgend unpacking proiblem

Góra strony
Delete this message
Reply to this message
Autor: Fred Viles
Data:  
Dla: exim-users
Temat: Re: AW: AW: [exim] Urgend unpacking proiblem
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