Add message filtering support

[jgknight]

Description of the Feature

This feature would provide server operators a way to filter/drop chatroom messages, IMs, and other user-generated content (profile HTML, buddy comments, etc.) based on a list of disallowed filters, for example matching a message against a list of regular expressions.

It appears that AOL performed some amount of filtering on the server-side for malicious HTML tags. https://adium.im/help/pgs/Accounts-AIM.html

AIM servers filter strings containing <img and <script, which are tags in the Hypertext Markup Language (HTML) AIM uses to encode messages (so as to support fonts, colors, etc.). [...] However, it appears that the AIM server drops messages containing even escaped HTML (but only those two tags—other tags work fine). AIM will also drop any message containing a link to a file: address. These addresses are intended to refer to files on the sender's or your computer. (The file need not actually exist on one end or the other. A perfectly valid file: link can refer to a path that does not exist on anyone's machine, such as this one.)

• The mgmt API could allow adding and removing message filter regular expressions
• Each incoming chat message, instant message, profile update, etc would then be matched against this list of filters
  • If a message matches one of the regular expressions, it is dropped.

Use Case

• Implementing some filtering would allow RAS to more closely match the behavior of the original servers where they did some amount of malicious HTML filtering
• Server operators could use this to filter out spam or other offensive messages based on their community policies
• This could also provide a way to filter out known exploits or boot/crash codes that target specific AIM clients, if that becomes an issue

Potential Challenges

• Regex can become complex and cause performance problems
• Filters can be easily bypassed or overblock
• It's unknown if these filtered messages generated an error back to the sending client or if it was silently dropped. We'd need to investigate.

Additional Information

There is an open request, #23 , that's also related to server-side parsing/processing of messages. It may make sense to evaluate both of these requests at the same time to see if there is some common framework or interface we can design to allow a plugin-style system for message processing.