I've set up the new confirmation system on the Dada Mail that's on the support site:

        http://dadamailproject.com/cgi-bin/dada/mail.cgi

If it moves you, please test it out, by subscribing/unsubscribing from one of the lists. As far as I can tell, everything's working well. I still have a few small things to work out, but I hope to get this all released soon,

--

Justin J: Lead Dadaist.
url:         http://dadamailproject.com
email:    justin@PROTECTED
skype:   leaddadaist

On Feb 11, 2013, at 3:42 PM, Justin J <justin@PROTECTED> wrote:

>
> Hello everyone,
>
> I've started work on a long-overdue re-haul of the confirmation link system in Dada Mail.
>
> Currently, you'll notice that confirmation links have embedded in them the Mailing List the sub/unsub confirmation is for, the email address the confirmation is for, and then the mysterious, "pin" number, which is used to verify that the confirmation is real.
>
> There's a few shortcomings to this system. The big one is that pin number: it's neither random, nor unique - nor does it ever expire. You can basically dredge up an confirmation email from a year ago and try out the confirmation link - it may in fact work.
>
> The pin number itself is created using a not-so-intelligent, "algorithm" that uses two different and hopefully hard-to-guess strings, PLUS the email and list short name in calculating that number. If someone can figure out the two hard-to-guess strings, the email and list are located in the confirmation link itself, and the pin number "algorithm" could be reverse-engineered. Unless early-20-something me was WAY more clever than early-30-something me thinks he was...
>
> I doubt anyone's "cracked" the pin in Dada Mail - so don't read this the wrong way, but it's certainly a weakness in the app, so I'm intending the fix it. I do think it's contributing to the problem that many are reporting, of specific addresses that seem to be unsubscribing and subscribing to a mailing list. I still don't know *what's* executing these requests, but it doesn't help that these confirmation URLs are never-expiring.
>
> So, I've started work on this new system:
>
>       https://github.com/justingit/dada-mail/tree/features-confirmation_tokens
>
> which replaces a "difficult"-to-calculate pin number that's embedded in the confirmation URL, with a really, really... really long number (basically) that corresponds to a row in a database that holds the email address, mailing list and action that the confirmation link is going to be used for. That means, no information about the actual confirmation is embedded in the mailing list, and there's no real way to, "crack" the new pin number (or "token", as I've been calling it), as there's nothing to crack - there's no real significance to the number - it's basically just a random number picked out of a hat.
>
> Since all the important stuff about the confirmation is in the table row itself, once we're done confirming whatever it is we need, we can remove the table row, as it's useless, and bang! - the confirmation link is now null-and-void: so clicking on it twice won't do anything. A timestamp is also applied to the table structure, so we can say: after one day - remove the row. We can even use that token to log things with - so not only can we log the date/time and ip address of a confirmation click, we can even log what confirmation URL gets clicked. I'm trying to figure out if that's useful though…
>
> In the future, this will also solve the problem of how to confirm *other* neat things, besides subscription/unsubscription confirmations, since I don't have to figure out a new scheme on how to whip up a entirely new confirmation link - all the important information is in the table row, and there's room to grow. The confirmation link will just continue to have that token.
>
> So, here's what a confirmation link may look like:
>
>       http://example.com/cgi-bin/test_dada/mail.cgi/t/Kii3jdYoPKtXS9A3xyeYTE8FKP2ICmbxDHEmHyey/
>
> And here's what the corresponding table row looks like:
>
>
> mysql> select * from dada_confirmation_tokens;
> +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+
> | id | timestamp           | token                                                            | data                                                                                                                                     |
> +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+
> |  1 | 2013-02-11 14:57:02 | Kii3jdYoPKtXS9A3xyeYTE8FKP2ICmbxDHEmHyey | $D = {'email' => 'user@exampe','data' => {'flavor' => 'sub_confirm'},'list' => 'example'};;$D |
> +----+---------------------+------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------+
>
> So, essentially it's just a real simple, but effective session system.
>
> So, my initial commits to this idea basically work: there's rough edges and I need to remove the old tests and write new ones AND THEN make a non-SQL version of all this, but that's the rest of today's work, I guess. I'll try to push this out in some sort of beta form, soon, for those who would like to try,
>
> --
>
> Justin J: Lead Dadaist.
> url:         http://dadamailproject.com
> email:    justin@PROTECTED
> skype:   leaddadaist
>
>
>
>
>
>
>
> --
>
> * Post:              mailto:dadadev@PROTECTED
> * Unsubscribe: http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev=




--

* Post:              mailto:dadadev@PROTECTED
* Unsubscribe: http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev

Mailing List Powered by Dada Mail
http://dadamailproject.com/cgi-bin/dada/mail.cgi/what_is_dada_mail/