On Fri, Apr 22, 2005 at 12:25:00PM +0100, Tony Finch said:
> 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. |
This is great info. I didn't know that. (I'm not the OP.)
So if I want to be able to scan for "foo" in both plain text and
base64 mime encoded text, would I need to check in BOTH the DATA and
MIME ACL's:
check_data:
deny message = Your message contained foo
regex = foo
check_mime:
deny message = Your message contained foo
mime_regex = foo
And what impact would "demime=*" have in check_data for this situation?
Demime is depreciated in 4.5x, correct?
