Even within the core service of filtering email there were several extensions and enhancements which could have been offered.
The following items are a selection of the ideas which were rejected during our service lifetime:
Our service concentrated upon the filtering of incoming email, and ignored the sending and filtering of outgoing mail (with the exception of auto-whitelisting).
Filtering bi-directionally wouldn't have been a significant technical challenge. The main reason not to offer such a facility was the wish to avoid having to deal with end user queries with regard to SMTP-Authentication and relay control.
One of the key differentiators of our service was the storage of rejected email in an online quarantine.
Several industries, and groups, are legally obligated to maintain records of prior communications and emails. Extending the quarantine duration on a per-user basis would have been straightforward.
The only additional overhead would have been additional storage capacity at the master node - and the actual cost of that would have been peanuts.
Actual filtering might not have even be necessary for some fields. A service merely offering off-site copies of every incoming and outgoing message for a company might have value, either for compliance or for disaster recovery.
One common problem in mailing lists is that they attract SPAM, and require policing if you're maintaining an online archive.
An obvious enhancement would have been hosting mailing lists for different topics. Rather than filtering all mail on a particular domain just filter email@example.com. This would be a reasonably large change, but not a technically difficult one.