On Fri, 22 Apr 2005 12:25:00 +0100 Tony Finch <dot@???> wrote:
> On Fri, 22 Apr 2005, Phil Chambers wrote:
> >
> > I understood that the \A would anchor the test to the start of the attachment,
> > unlike ^ which anchors to the start of a line. Unfortunately, the test succeeds if
> > it finds TV[opqr] at the start of any line in the attachment.
> >
> > Can anyone give me a test which will only search the start of the attachment?
>
> Try writing a regex to match the raw binary and use mime_regex instead.
>
>
> The "regex" condition takes one or more regular expressions as arguments and |
> matches them against the full message (when called in the DATA ACL) or a raw |
> MIME part (when called in the MIME ACL). The "regex" condition matches |
> linewise, with a maximum line length of 32K characters. That means you cannot |
> have multiline matches with the "regex" condition. |
> |
> The "mime_regex" condition can be called only in the MIME ACL. It matches up |
> to 32K of decoded content (the whole content at once, not linewise). If the |
> part has not been decoded with the "decode" modifier earlier in the ACL, it is |
> decoded automatically when "mime_regex" is executed (using default path and |
> filename values). If the decoded data is larger than 32K, only the first 32K |
> characters are checked. |
>
>
> Tony.
I was wanting to avoid decoding the BASE64 as a waste of CPU. The message is to be
virus-scanned so it seems very wasteful for exim to decode and then have the virus
scanner decode too!
It would not be an issue if one could use "malware" in a MIME ACL. This is, decode
the attachment submit the decoded part to the virus engine and also apply your own
mime_regex's as well. Just a single decode on each attachment. One could also opt
to only scan BASE64 attachments, so text-only messages would not impose any load.
Phil.
---------------------------------------
Phil Chambers (postmaster@???)
University of Exeter
