Re: [exim] Content scan -- Mime check -- progress?

Herb Martin wrote:

> <<40.3 Scanning MIME parts
> The acl_smtp_mime global option defines an ACL that is
> called once for each MIME part of a message, including
> multipart types, in the sequence of their position in
> the message.>>
>
> So a message with 3 parts will call this acl handler 3
> times.

Depends on what you call a part. Remember the enclosing multipart "part"
counts too. So a message with three real parts will cause the MIME ACL
to be called 4 times :)

> If an DENY occurs in any part, processing ends and neither
> the next mime parts nor the data part will ever be called.

Yes.

> Is the same true for an explicit accept? (I believe so.)

No, accept skips to the next part.

> An implicit DENY exists at the end of this ACL if no other
> action is specified explicitly -- this is possibly invoked
> on EACH part so one must accept (or something?) within
> each pass, but that would mean that no other passes would
> occur?????

You must explicitly accept each part. You can put a single accept at the
end of the ACL so you easily accept what isn't denied.

> How does one somehow 'defer' until the last part, and then
> determine that it is in fact the "last" part, but do this
> without "accepting" too early, waiting to the end to invoke
> an appropriate Accept (nothng bad seen) or Deny (nothing
> good seen <grin>)

See above, "accept" does not end the MIME processing :)

> Entering multipart recursion, boundary
> '----=_NextPart_000_0005_14761476.72507250'
> ====================================================
> Hit EOF ...
> using ACL "acl_check_data"

Hmm it does not find the boundary to start the next part. You example
message posted earlier looks good ...

I'm afraid you'll have to look into this yourself due to the issue being
with cygwin. Check out mime.c, there's a place where the code looks for
the next boundary string, that's where the problem is.

Sorry,

/tom