Technical

Not all of our users are comfortable with the idea of Mollom discarding spam without the possibility of manual review (no matter how spammy the message appears to be). To address this issue, versions of the Drupal Mollom module beginning with mollom-6.x-1.15 add a new basic configuration option that causes comments to be retained as unpublished posts in your site's moderation queue, no matter how spammy they may appear to be. Moderators and site administrators can then periodically review the moderation queue if necessary.

Only forms that support a publishing status (like comments or posts) may be retained. This feature is not available for some contributed modules which manage data that does not have a "published" or "unpublished" status. An example of such a module is webform.

The "Mollom test form" is used in Mollom unit testing, and is not necessary on a site that uses Mollom to protect content or comments.

For this entry to appear in your menu, you must have the mollom_test.module enabled in your modules list. Since, there's no reason to have that module enabled (unless you're during unit testing of some kind), simply go to admin/build/modules and uncheck the box by mollom_test.module, which will uninstall that module and prevent that menu entry from appearing for all users..

By using the contact form on Mollom.com, you can submit a trouble ticket for our support team. Please try to provide as much information as you think may be relevant to your particular situation. Note that you can also use this form for information about pricing/sales information, or if you have trouble logging into the Mollom.com website.

For technical support requests, it is very important that you provide us with with:

• the name and version of the CMS platform hosting your Mollom plugin
• the version of your Mollom plugin
• the name of your website, or in some cases, your Mollom public key
• and any debug information that may have appeared in the logs of your CMS about the issue. In particular, in some of the very latest Drupal plugins on the Drupal CMS, there is a "Mollom session ID" that is very helpful to us as we investigate service related issues. (If the Mollom session ID is not shown on your watchdog log in Drupal, try upgrading to the HEAD version of the Drupal 6-1--1 module. Extra logging has been added to this version, and will appear in future releases. In this module, the session ID is printed at the bottom of the watchdog entry starting with "Ham:", "Spam:" or "Unsure:".

Depending on your particular issue, our support technicians may ask additional questions (such as your version of PHP on your server, whether you can make outbound HTTP requests using PHP, etc).

Yes, if you have multiple domain names all pointing to the same site using Mollom to protect against spam, Mollom will work automatically even if only one of those domains has been registered to the site on Mollom.com.

In addition, if your installation has multiple subsites that all share the same user table (like a multisite Drupal installation using Domain Access, for example), then a single Mollom subscription registered to one of the subsites will work properly for all of the subsites (as long as all the subsites are using the Mollom module).

Because Mollom uses user data from a site to inform its spam filtering, each site that has its own user table must have its own set of API keys from Mollom.com.

The Mollom open API uses an HMAC-based authentication scheme to make sure your key stays your key. Evil hackers cannot pluck it off the net and start checking content on your account. Since Mollom takes its enterprise users very seriously and will soon also be providing many volume-limited advanced features, it is essential that Mollom user identities are secured using an industry-grade authentication system. This is done by signing each API call to Mollom with both a private and a public key. We also add an internal reputation system on top of these keys to prevent evil users from degrading the performance of Mollom’s filters.