Since you can search based on "starts with", "ends with", or "contains", no wildcard is needed. When searching the attachment name, any asterisk placed at the start or end of the search will be ignored.

No, they are always case insensitive.

• When searching the "Message body" or "Entire message", only the first 1mb of the message is used.
• Some attachments types are completely excluded from the "attachment" search (but would be accessible in the 'header' search context), including: 'gif', 'jpg', 'jpeg', 'png', 'bmp', 'vcf', 'txt', 'desc'

All searches are applied to both the raw version and the mime decoded version (with the exception of the message body, where only the mime-decoded version is used.)

Yes, but not at the beginning or the end of the rule (whitespace on either end will be trimmed off). Likewise, whitespace at the beginning or end of each line of the message will also be trimmed.

• The regex engine being used is PRCE.
• Regex options enabled:
  • m - Multi line (Allows using ^ and $ to match the start and end of a line instead of the entire text body)
  • i - Case insensitive matching
• No starting or ending delimiters are needed.
• The forward slash (/) will be escaped automatically, so you don't need to escape it.
• No tech support is offered for troubleshooting regex expressions. However, there are third-party websites that offer free, web-based regex testing tools.

No, Approved sender rules always takes precedence over Custom Filter rules.

Custom Filter rules are run in groups, based on the "Action" they perform. If two Custom Filter rules match on the same message, the rules will be applied in the following order (with the first match determining the outcome).

No, Custom Filter rules that are set to "always deliver" will override all other filters when there's a match. That includes messages with viruses, spoofed senders, blocked senders, and other Custom Filter rules that are set to "quarantine". Be sure that the criteria of your "always deliver" Custom Filter rules are not too broad.