The Anonymous Publishing CL module is part of the Anonymous Publishing project.

It lets users publish content without first registering an account at the site, provided they supply a vaild email-address and click on an activation link sent them in a verification email (some call this the “craigslist model”).

Configuration

To access the Anonymous Publishing CL administration form, you need to be granted the right to administer anonymous publishing.

After installing and activating the module navigate to: Configuration » People » Anonymous publishing CL.

There are seven tabs:

1. Main settings: All the main options for this module.
2. Message templates: Customize verificaton email sent out.
3. Moderation: Moderate anonymously published content.
4. Verified: Block (and unblock) verified email-addresses.
5. Unverified: Ban unverified users' IP addresses.
6. Spambots: Ban reported spambots' IP addresses.
7. Privacy: Privacy enhancing settings.

Main settings

You first need to select the content type (or types) that you will allow anonymous users to post. You may also enable anonymous publishing for comments.

If you want to allow users that are not logged in to create content, you must also give permission for the anonymous user to create content. This is done by navigating to Configuration » People » Permissions.

The rest of the settings on the settings page will only have an effect on the type or types (including comments) selected here.

Here is a brief description of the options:

• Allow self-activation.
  If you check this option, content from anonymous publishers that has not been previously validated will be automatically published when the anonymous publisher verifies the email. If you leave this un-checked, content from un-validated anonymous publishers will be flagged as verified when the user verify the email-address, but it will not be published until approved by a administrator. The setting has no effect if the email-address is already validated. (See description of the “Moderation” panel below for details about how activation works.)
• Skip comment approval.
  This is greyed out, as this setting is managed by the Drupal core comment module. Go to Configuration » People » Permissions to set it. The core “Skip comment approval” setting retains it standard meaning and its status is only included in this panel for information purposes (previous setting). Note that if you allow self-activation, but don't also check “Skip comment approval”, self-activated comments will not be published when the user activates. They will just be flagged as verified and not be published until they are approved by a moderator. To avoid confusion, make sure this setting is in-sync with the setting Allow self-activation.
• Send email to the administrator when anonymous content is created.
  Checking this will automatically send an email to the administrator email address whenever anonymous content is created. You may use this to make sure the administrator becomes aware of possible problems (such as spam), or to speed up the moderation process (if you do not allow self-activation).
• Use IP-address for blocking.
  By default, the “blocking” box only applies to the email used for authentication. The module records the IP-address used to authenticate, but this normally only used for flood control purposes. When this option is set, the module will also block the corresponding IP-address. Note that setting this option may result in false positives (as one IP-address may be shared between several users over time), so use this option with caution.
• Allow registered emails to be used for anonymous posts.
  By default, if a user has already registered and created a regular account on the website, that email can no longer be used for anonymous posts. If you want to allow regular users to be able to publish as the anonymous user role, enable the Anonymous publishing PET sub-module. However, you may override this behaviour by setting this option. This security implications, as somebody familiar with your users will be able to guess the email-address of a registered user and use this to post harmful content which the regular user may be blamed for. It is recommended to turn of stickyness for self-activation if you enable this option.

The setting for verification persistency determines whether users need to re-verify after they've verified (or have been verified) once. The settings are:

1. Make verification persistent.
   If this option is set, a verified email-address will be trusted, relieving the user from the task of re-verifiying on return visists to the site (see “Verified” below).
2. Verification persists as long as the same IP is used.
   If this option is set, a verified email-address will be trusted if the IP-address used to post matches the previous IP-address used used along with the same email-address.
3. Require verification for each posting.
   If you set this option, users will have to re-verify their email-address again every time they post. This is the most secure setting, but also bit more of a burden on the user.

The setting for the attribution or byline (“To whom should anonymous postings be attributed”) can only be used if the retention period (set on the Privacy tab) is set to “Indefinitely”. When accessible, it lets you choose between the following three options:

1. Use the default alias for anonymous users.
   This means that all anonymous postings will share the same byline.
2. Use an generated persistent alias (format “userN”).
   This means that anonymous postings will associated with the same email-address will share the same byline. The byline will be automatically generated and cannot be personalized.
3. Allow the anonymous publisher to set the byline.
   This works like the previous option, but since the alias is selected by the user, it may be personalized.

If you select option 1 (use some default alias) after having one of the options for a persistent alias active for some time, the aliases will no longer appear. They will, however reappear if you select option 2 or 3.

If you select option 2 (generated alias), it will only affect new anonymous publishers. email-addresses already known by the system will retain its existing alias/byline association.

If you select option 3 (user sets byline), the field to define an byline will appear on the content creation form for anonymous publishers. If the email-address given by the user already has an byline associated with it, the new byline will take presedence over the old for all anonymous postings unless the user leaves the field blank. If the email-address given is unknown and the user leaves the field blank, an alias will be generated for the user.

NOTE: The privacy settings of this sub-module let the administrator purge the information that links email-addresses to anonymously published content from the datebase after some pre-set retenion period or immediately. This will delete all information linking specific content to activation email-addresses. After purging, the it will no longer be possible to use an alias as a byline. Purging is not reversible.

• Guidelines for the byline.
  If you select option 3 (user sets byline) you may provide a short text of guidance in this field. This field is not used by options 1 and 2.

The last four settings are:

1. Administrator's email-address:
   If you opt to send email to the administrator when anonymous content is created, you need to provide a vaild email-address for the administrator.
2. Verification email address field weight:
   To control where on create content form the verification email-address field is placed, you may specify a weight for this field.
3. Number of hours to retain anonymous posts before auto-deletions removes it:
   Spammers often creates contents on sites that allow them to do so, but almost never act on the verification email. This settings can be used to automatically delete anonymous posts if the email has not yet ben verified after the number of hours you set here.
4. Number of anonymous posts allowed from a single user email/ip allowed within an hour:
   For flood control, you may set the number of anonymous posts allowed from a single email-address or ip-address within an hour from 1 to 98. Use 99 for no limit.

Remember to press “Save configuration” when done.

Message templates

In this panel, there are four fields that let the administrator customize the email-message sent to non-authenticated users when they create content. The first field is the subject, the rest of the fields may go in the body. Other settings determine what fields are used.

There is also two templates (subject and body) for the email sent to the administrator.

Moderation

This panel shows all the comtent published anonymously that have been verified by email. It lets the administrator publish or unpublish.

The moderation workflow of anonymous publishing is tied to the option “Allow self-activation”. If you check this option, the user is allowed to selv-activate content by verifing his or her email-address. If you leave this option unchecked, content created by unverified anonymous publishers will not become activated until it is approved by a moderator.

If you do not check the options “Allow selv-activation”, the content will not be published when the anonymous user verifies is or her email. In addition, the moderator must activate the content for it to be published.

Verified

This panels list all the verified emails and their current status.

Also listed is the alias associated with each email. The alias is always generated, but will only be shown publicly if you check “Associate a generated alias with contents published anonymously” under main settings.

Also listed is IP-address associated with each email. The IP-address listed will be used for blocking if you mark the email as blocked and you've checked “Use IP-address for blocking” under main settings.

email-addresses that are blocked from anonymous publishing is shown with a check-mark in the column “blocked”.

To block, set a check-mark in the row of the email-address. To unblock, remove this check-mark. To make changes take effect, press “Execute”.

Note that a checkmark in the “blocked” column will only prevent the user from posting anonymously. No other part of the site's functionality will be affected. Unlike the ban IP action you may take in the “Unverified” and “Spam” panels, the blocking is handled by this module, not by Drupal.

This status of blocked is only meant to be used to block abusive human users from publishing anonymously, not to ban spambots.

Unverified

This panels list all the emails IP-addresses that has been associated with anonymous publishing that has not yet verified by email and how long it has remained unverified.

This panel provides a chortcut to admins that want to delete unpublished spams posts and at the same time ban the IP-address used to post it. Placing a mark in the “Select” column to the left of an posting listed here will select the posting for one og three actions:

1. Delete: Delete the posting but take no further action.
2. Delete+Ban IP: Delete the posting and add the IP-address used to post it to the Drupal's {blocked_ips} table. Banned IP-addresses will not have access to any part of site at all.
3. Approve: Approve the posting. This will mimic the action of the anonyous publisher verifying the posting using the emailed link.

To unban a banned IP address, navigate to: Configuration » People » IP address blocking and press “delete” for the IP-address you want to unblock.

Spambots

The spambots panel shows the IP-address of the “Top 10” spambots targeting the site, along with some simple statistics. You can ban an IP address by placing a check-mark in the “ban IP” column. When you press “Execute”, the IP-address will is moved to the list of IP-addresses blocked by Drupal.

To unban an IP address, follow the same procedure as suggested above.

Privacy

While no email-address or username is made available to outsiders, the email-address and IP-address associated with content is by default retained indefinitely, and can be extracted from the database. If your site is used to publish sensitive material, you may want to limit the period the record that links emails and IP-addresses to specific content is retained.

For a very sensitive site, you may want to set this to “Delete ASAP” to delete at next cron run. But you may also opt to retain for a limited time (from an hour up to 1 month) to give you some time to pick up the email-addresses or IP-addresses of spammers and block them. The purging of email-adresses and IP-addresses is done by cron, so you need to run cron at least as often as half the maximum period set to be sure identifiers are purged within the time limit.

The button “Purge now” bypasses cron and purges the identifiers instantly.

Note: Purging, as described above, only purges identifiers from the tables belonging to this module. It does not touch other places on your site where identifying information can be found, such as the webserver logs. This means that if you want to protect your anonymous publishers against law enforcement doing forensics on your site, the anonymity provided by this module is not sufficient.

Other administration

If you want users that are not logged in to be able to create content, you also need to navigate to Configuration » People » Permissions and check the following for the anonymous user: “View published content”.

Then for each of the content type(s) you want to allow anonymous publishing for, check the following for the Anonymous user: “Create new content”.

To allow the anonymous user to post comments, grant the following permissions:

• “View comments”
• “Post comments”
• “Skip comment approval”

To get rid of the “(Not verified)” string that appears next to the user name of any comment posted by the anonymous user, navigate to Configuration » Appearance » Settings » Global settings and untick the following: “User verification status in comments”.

Trouleshooting

No email

The Anonymous Publishing CL module uses Drupal's DefaultMailSystem to send out verification/activation emails (refer to the API documentation at api.drupal.org for the function “drupal_mail_system” for details). It uses the method “mail” to send the mail, and prints out the message:

“A link and further instructions have been sent to your email-address.”

after after the mail was successfully accepted for by the mail for delivery.

If the mail system rejects the message, it prints out:

“Error mailing activation/verification link.”

If you get the error message, then there is probably something wrong with the configuration of mail on your Drupal site.

Here are some things to check if you do not receive an email after posting as anonymous, despite the fact that you're told that a link and further instructions have been sent to your email-address:

• The first thing you should check is that Drupal can send email at all. You can try using the Contact module (part of core) or you can request a password reset by logging out and clicking the “Request new password” link in the login block.
• Next check that verification/activation emails are not stopped by some spam-filter at the receiver end. The sender of the emails sent by Anonymous Publishing is the site's email-address. You can inspect this at: Configuration » System » Site information. Search your-spam folder for recent emails sent from this address. Also note that there are some mail services (e.g. gmail.com, mail.yahoo.com) that have spam filters that consider the verification/activation emails from this module as spam and silently delete them. For testing, use a mail service where you control what is filtered.
• When testing this, make sure that the email-address given by the anonymous poster is valid, and goes to a mailbox you've access to.
• Make sure that the site's email-address is valid. Look for bounced verification/activation emails in the mailbox belonging to the site's email-address.

Warnings from schema module

If the Schema module is enabled, you may get warnings saying: “no schema type for mysql type date”.

The reason for this warning is that this module uses the date datatype if it is supported by the database, but date is not a Drupal datatype. Since the module is designed to use varchar as a datatype for dates if the database does not support date, this should not be a problem and you should ignore these warnings. You may turn these warnings of by navigating to: Structure » Schema » Settings and ticking “Suppress schema warnings.”.

For more about this, see the comment linked to in the issue thread: “Schema module reporting some Date discrepancies” on Drupal.org.

Spam protection

If you allow anonymous publishing your site will probably be targeted by spammers, both of the human kind, and spambots. There is already some built-in protection against spambots in this module. These built-in features may be suffiscient to keep spam at bay. If you need more protection against spam, there are several spam control projects on Drupal.org that will help you do that.

Known glitches

• The core comment module allows anonymous publishers to pick their own non-persistent byline when they post a comment. This conflicts with the persistent alias used as a byline by this module, so this feature in Drupal is disabled when this module is enabled.
• When a persistent alias is linked to content, the alias will not appear when there is no content directly associated with the display (e.g. on the forum landing page). Instead the system default name for the anonymous user will appear.