Extended lists don't even allow a * or any regular expression.
Support is correct in that it can't be done witht he extended list. It's a complicated reason, but the list merges into the URL database and the database itself doesn't have wildcarding.
Why do you want the extended list over the more flexible wildcard lists?
He's got very large lists.
Reporting is another reason.
At the moment you don't have a choice other than to create another rule and wildcard list for anything where you need more complex regex. Sorry sir.
And there's Chris, that knows our environment very well. ;-) To Chris' point we have very large lists, and in our Ops teams logic (that manage this list) they have determined they need to block items that are already categorized as malicious by trustedsource. But an example of why we would like to have the regex capability is domain[1-22].com, would be 1 line per entry and regexing that would reduce to 1 line total. The other reason, there is, unfortunately, a limitation on the extended list size. If it gets close to 50K records it no longer sames and throughs Java heep errors resulting in use having to create two lists now, and I'm sure we will (in the near future) have to create another list. So our attempt is to regex alot of this to reduce the list size and teach this team how to implement regex entries.
I know we can use the wildcard lists, but the problem with that is, we would need to create a new rule for each different user-defined category that this external group manages and they would have to update each list. And honestly, (Chris knows our issues with this) we don't want to confuse them anymore than we already have.
At this level, you should contract with McAfee to generate a category, just for you! I won't ask why you have a 50K list
PS: Could you not cut a big part of this using an internal DNS Blackhole?