General question: double opt-in (against spamming)

What are difficulties implementing a double opt-in subscription to a given application (e.g. newsletter)?

Many times users asked for this feature (for poMMo, EasyNewsletter and others). But never there was a solution (or I miss some information). Is it so difficult to implement this? I think it could be a nice addition to many applications:
- newsletter subscriptions
- forum registration
- blog commenting (against spamming)
- contact forms (also against spamming)

Especially for commenting blogs imho it could be an efficient method against spamming. For double opt-in there must be a valid email address available. I think that a spam application don’t have this and therefore can’t handle the opt in. What do you think about?

It’s not difficult; the KoopsMailinglistX port of Koops Mailinglist does this.

You could use one of the existing fields to adapt the procedure to a stock MODx to store a randomly generated value to include in the URL in the confirmation email. The document the URL requests would contain a snippet to grab that GET value, compare it to what’s in the database, and if it’s good, unblock the account (which is originally created blocked for some long time) and delete the value from the database.

Thanks for reply. Will look at KoopsMailinglistX for a client requiring the double opt-in for the newsletter subscription.

But generally: what do you think about a double opt-in for comments in blogs? Many bloggers complain about comment spam and try to build spam-proof comment forms. And it seems there is no way to avoid spamming with all methods provided (hidden fields, time control, sessions, forced preview, captchas, captcha-like questions, ...). Could double opt-in be a solution?

Ok, it’s a double burden to confirm every post in blogs. My question is (to all members here): would you do/accept this?

And do you think this could be a possible way or not? Or can spammers confirm an opt-in via email confirmation? In this case there must be an available email address to receive the request and this email must not be tracked back to a human owner (the spammer).

As far as comments go, I suspect you would lose at least half of the commenters if they had to go through anything like this. Unless you mean for registration when only registered users can comment?

As far as newsletter subscription goes, I’ve switched to the perl script DADA mail. Very powerful. The configuration is a bit complex, but once you work through it it’s well worth the trouble. It’s very easy to embed in a module, or simply add a link to the cgi-bin/dada script in the manager. It can embed FCK editor or use a url. I set up a MODx document to use; all the client has to do is edit that document. The DADA form has the documen’t URL already in the field, so once they are happy with the page the document creates they just log in to their newsletter in DADA and send. I’m pretty sure it wouldn’t be difficult to automate this to use the latest news document instead.

First it was also my doubt that this could be too complicated for comment posters because of the divided ways (the web site form and the email client). A registration is also an additional load but it’s on the same site.

I was searching for a solution to use Quip with a double opt-in model. It's not only that you "bother" users when demanding a double opt-in registration but here in Germany it is necessary otherwise you can get a liability notice if this is the right word for it, in different situations you'd speak of a cease and desist. Don't ask me why the situation is like this but we have to use a double opt-in feature. And Quip does not seem to support a way of doing this on the first sight. Any ideas would be appreciated.

You don't say what version of MODX you're using. In Revolution, the Register and ConfirmRegister snippets come with the Login package and do double-opt-in registration very nicely.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODX info for everyone: http://bobsguides.com/modx.html

Thx again Bob, I will have a look at these snippets but as I read their description I don't know if I can easily implement them with QUIP. Your online guides were a profund help getting our evolution site well ported to revolution. Thx for this.

I have to apologize for not mentioning the version of our installation. For me, more being into humanities and being more the writing kind of guy, I always do implicit answers not like you "techies". As I mentioned "Quip" before, it was clear I was referring to Revolution, hence Quip cannot be used with Evolution.

Thanks for the kinds words. No apology necessary -- that's just my sig.

That said, I'm always struck by how many times the answer to a question depends not only on whether the user is on Evo or Revo, but which exact version they are running. Each release has its own quirks, problems, and adverse interactions with extras.

BTW, The Register and Confirm Register snippets don't care what else you're using (e.g. Quip) and vice versa. They register users (i.e., create a user account with login credentials), period. Quip, OTOH, just checks to see if the user is logged in and, once you set it up, Quip should be able to send not-logged-in users to the page with the Register form, or better yet, to a page with a Login form and a link to the register page.


---------------------------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
MODX info for everyone: http://bobsguides.com/modx.html