VBulleting Is Triggering Mod_security Rule And Banning People

I installed mod_security and the 403security rules on my VPS (Centos 4.1, Release version of WHM).

Several vBulletin files, including the ajax quick editor and some vbulletin.org add-ons are triggering this rule and banning members' IPs in CSF:

# Restrict witch content encodings we accept.
#
# TODO Most applications support only two encodings for request bodies
# because that is all browsers know how to produce. If you are using
# automated tools to talk to the application you may be using other
# content types and would want to change the list of supported encodings.
#
# Note though that ModSecurity parses only three content encodings:
# application/x-www-form-urlencoded, multipart/form-data request and
# text/xml. The protection provided for any other type of encoding is
# inferior.
#
# TODO There are many applications that are not using multipart/form-data
# encoding (typically only used for file uploads). This content type
# can be disabled if not used.
#
# NOTE We allow any content type to be specified with GET or HEAD
# because some tools incorrectly supply content type information
# even when the body is not present. There is a rule further in
# the file to prevent GET and HEAD requests to have bodies to we're
# safe in that respect.
#
# NOTE Use of WebDAV requires "text/xml" content type.
#
# NOTE Philippe Bourcier (pbourcier AT citali DOT com) reports
# applications running on the PocketPC and AvantGo platforms use
# non-standard content types:
#
# M-Business iAnywhere application/x-mal-client-data
# UltraLite iAnywhere application/octet-stream
#
SecRule REQUEST_METHOD "!^(?:get|head|propfind|options)$"
"chain, t:lowercase, deny,log,auditlog,status:501,msg:'Request content encoding is not allowed by policy',id:'960010',severity:'4'"
SecRule REQUEST_HEADERS:Content-Type "!(?:^(?:application/x-www-form-urlencoded$|multipart/form-data;)|text/xml)"
I don't know how to decipher this rule to know if just removing it is ok, or if it is serving an important purpose. During a couple hour period it was enabled, that rule only seemed to trigger false alarms.

The above was triggered with calls such as [uri "/forums/ajax.php?do=usersearch"] and [uri "/forums/newreply.php?do=postreply&t=11057"]

What I really don't understand is that I have an .htaccess in place to turn off mod_security for the /forums directory:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
I have also had this rule triggered today when someone tried to access : ...