I'm not even sure that I'm following this correctly.  It seems that it is a hack/future feature in which a subscriber has to enter their PIN in order to unsubscribe.  If this is true, I truly hope that it will be an option, not a standard feature. 

Here's why:  With my large list I get a few unsubs after every blast.   Of these unsubs, some of them don't use the very obvious link in the blast, but instead reply and ask me to unsub them. It gets annoying after a while.  If a PIN was required for them to unsub, practically all of them would just reply to unsub rather than doing it themselves.  They wouldn't remember their PIN or bother looking for it.

Many of my users are barely computer literate.  I cannot make any part of their experience with my business confusing or difficult for them.

John Collins

Justin J wrote:

Alan, 

I think a great idea would be for you investigate the feature yourself on a forked copy of Dada Mail by using github. It's quite easy to fork off Dada Mail, make your changes and then ask for a pull. I'm currently working on other parts of Dada Mail, so I can't really focus to much of myself on this part, but I'd be interested in what you find. 

For such a feature in such a sensitive part of Dada Mail - a part that would really need to work without bugs, it would be nice if you could include tests with your new feature, to make sure it's working correctly. 

I think if I could put some constraints on your feature, this would be my wishlist: 

	* Don't use the current pin system, since, as I've stated, I don't want it to be exposed in the mailing list messages - or really at all, since the mechanics of the confirmation URLs have, and will change, over time. I think it is exposed as a artifact from versions previous. 

	* I think you should really consider some of my comments about the idea, the security and usability parts of everything. I'm really delighted someone with so much experience is interested in working with Dada Mail, but perhaps you are also going to have to not fight with what I'm just trying to point out as good ideas and not so good ideas. 

	* TAP tests with the new feature

Also, please - this kind of stuff: 

  

> In closing, I would like to thank the other subscribers who thought it would be amusing to attempt to unsubscribe me from the list.  If anything, these childish and passive aggressive attempts to deter me have only resulted in strengthening my resolve to participate.  I look forward to chatting with you all as other traffic hits the list.  Cheers.
    

No one needs. 

-- 
Justin J.

Dada Mail -  Write Once: Distribute Everywhere Software 
url: http://dadamailproject.com

The Dada Mail Demo: 
http://demo.dadamailproject.com

On Apr 3, 2010, at 3:38 AM, Alan Hysinger wrote:

> 
> 
> On Apr 2, 2010, at 3:11 PM, Justin J wrote:
> 
    

>> 
>> On Apr 2, 2010, at 3:45 PM, Alan Hysinger wrote:
      

>>> If a pin is compromised, it's only the one pin.  I have observed it is different for each mailing, even for the same email address, so it seems the algorithm generating the pins has some defense against being cracked.
        

>> 
>> As the implementor of it, I'd say it's laughably insecure. I'm pretty worried about it, myself. I would like to completely replace it with just a random number, that's saved somewhere and generated when a sub/unsub request is made, instead of a 2-way hash that's created using the email address. 
      

> 
> I agree storing a number would be more secure.  Even with, as you suggest, an easily crackable algorithm, the expense of the attack goes up to the point where we are talking about botnet herders and not just pissed off competitors.
> 
    

>> 
>> But, if that happens, having the pin available in, say, the mailing list message wouldn't be something that could be done. So in the future, the pin won't be available anyways. 
      

> 
> If you say so.  As far as my experience has been, I can make anything in code I want to.
> 
    

>> 
>> I don't know if your ideas would be best - to make enabling it so obscure (changing a global config variable, which goes against what's set in the list control panel - but only sometimes
      

> 
> that is one perspective on it, and a very myopic one if you ask me.  i see it as adding a valuable feature while maintaining some level of defense against basic unsubscribe attacks.  perhaps a different path of implementation is more desirable, and if so, i am all ears.  i've been coding for a very long time, and i have learned not to be attached to the way I think something needs to be done.
> 
    

>> and then rolling your own unsubscribe link,
      

> 
> is that not what the template processing macros are for?
> 
    

>> using another undocumented feature
      

> 
> undocumented?  i found it in the documentation
> 
    

>> - which I've stated is a bug)  as not something that a regular user would want to do
      

> 
> well, this is fairly self-referential.  i consider myself a "regular" user and i want to do it.
> 
    

>> - it just seems like a bad design.
      

> 
> It's ok if you want to be critical of an approach to something.  How could this feature be implemented in a way that is palatable to you?  It is a common feature in other mass-mailing programs, one sorely missing from Dada.
> 
    

>> I can see the feature to be useful, I just don't think it's a good idea to use the current infrastructure that Dada Mail has to make it happen. As far as the current system is set up - I actually kind of am happy with it's current state, but making it do any more somersaults gives me nightmares.
      

> 
> I'm all for clean implementation of a feature, and I really don't see why a UI option can't be communicated in clear words that are understandable even to the lamest of layman (the "Experimental! Send multiple mails per connection" comes to mind here) how an option works and what the caveats are.  Perhaps there is some other way to implement a single-click unsubscribe, why not discuss it?  You will only benefit monetarily from my volunteer efforts.  It is obvious that you object to the implementation approach I suggested, do you object to the feature outright?  And if so, I would really like to know why.
> 
> In closing, I would like to thank the other subscribers who thought it would be amusing to attempt to unsubscribe me from the list.  If anything, these childish and passive aggressive attempts to deter me have only resulted in strengthening my resolve to participate.  I look forward to chatting with you all as other traffic hits the list.  Cheers.
> 
> The Unsubscribe confirmation emails are now being filtered straight to the bit bucket thanks to OS X Mail, by the way, so have all the fun you want.
> 
    

>> 
>> 
>> -- 
>> Justin J.
>> 
>> Dada Mail -  Write Once: Distribute Everywhere Software 
>> url: http://dadamailproject.com
>> 
>> The Dada Mail Demo: 
>> http://demo.dadamailproject.com
>> 
>> On Apr 2, 2010, at 3:45 PM, Alan Hysinger wrote:
>> 
      

>>> 
>>> Well I really hope you don't take that out, it's a very useful feature to me and my non-trivial number of subscribers.
>>> 
>>> That said, in response to your arguments I would say:
>>> 
>>> If a pin is compromised, it's only the one pin.  I have observed it is different for each mailing, even for the same email address, so it seems the algorithm generating the pins has some defense against being cracked.
>>> 
>>> If you are concerned about users understanding my proposed option, then it seems it makes more sense to keep it in Config.pm, well below the first four lines.  That way it is relegated to the realm of advanced users who understand what they are doing.  Sufficient comments in the code can document the ramifications of enabling that option.
>>> 
>>> Finally, given the direction to use Config.pm instead of the UI, to keep it clean for other users, the modification becomes changing this line:
>>> 
        

>>>>>>> if($lh->check_for_double_email(-Email => $email,-Type  => 'unsub_confirm_list')  == 0){ 
                

>>> 
>>> to
>>> 
        

>>>>>>> if($DADA::Config::REQUIRE_CONFIRMED_PIN_UNSUBSCRIBE == 1 && $lh->check_for_double_email(-Email => $email,-Type  => 'unsub_confirm_list')  == 0){ 
                

>>> 
>>> 
>>> And of course, the appropriate declaration and comments in Config.pm, so it seems that something actually could be done to accommodate this feature request, while respecting your concerns for a clean UI and understanding for your users.
>>> 
>>> On Apr 2, 2010, at 3:36 AM, Justin J wrote:
>>> 
        

>>>> 
>>>> On Apr 2, 2010, at 4:19 AM, Alan Hysinger wrote:
>>>> 
          

>>>>> 
>>>>> I'm sorry I wasn't clear.  I want to maintain the closed-loop opt-out when someone visits the UI on the site, to protect my mailing list from tampering, but if they have their PIN in a link, then I want to trust it and do it in one click.  Unchecking that option allows literally anybody to remove email addresses.
            

>>>> 
>>>> Hmm, not sure if I have anything to offer to get that working. The, "needs to actually make a confirmation request" is a pretty important step, since it stops more abuse - if the pin is cracked, you'll have a similar problem. 
>>>> 
>>>> It also vastly simplifies things, since the current system either def. enforces you need to make the subscriber confirm the unsubscription, or, you def. don't. 
>>>> 
>>>> Allowing the subscriber to sometimes sorta not need to confirm the unsub, starts blurring lines. I think I specifically took this sort of behavior out, to make it simpler to understand. I'm actually surprised the pin can be accessed, when you send a list message out (still). Since it doesn't work - for basically anything, when it comes to mailing list messages, it probably should be taken out. 
>>>> 
>>>> -- 
>>>> Justin J.
>>>> 
>>>> Dada Mail -  Write Once: Distribute Everywhere Software 
>>>> url: http://dadamailproject.com
>>>> 
>>>> The Dada Mail Demo: 
>>>> http://demo.dadamailproject.com
>>>> 
>>>> On Apr 2, 2010, at 4:19 AM, Alan Hysinger wrote:
>>>> 
          

>>>>> 
>>>>> I'm sorry I wasn't clear.  I want to maintain the closed-loop opt-out when someone visits the UI on the site, to protect my mailing list from tampering, but if they have their PIN in a link, then I want to trust it and do it in one click.  Unchecking that option allows literally anybody to remove email addresses.
>>>>> 
>>>>> Alan
>>>>> 
>>>>> On Apr 2, 2010, at 3:02 AM, Justin J wrote:
>>>>> 
            

>>>>>> 
>>>>>> On Apr 2, 2010, at 3:48 AM, Alan Hysinger wrote:
>>>>>> 
              

>>>>>>> Hi, I'm totally new to the list, so if I am in need of a clue, just speak up.  I have no idea of any etiquette out here, and I am a very direct person.
                

>>>>>> 
>>>>>> On topic is nice - the list is moderated by a couple of people, so it's usually not a problem. Anyways: 
>>>>>> 
              

>>>>>>> I wanted to provide my users with a single-click unsubscribe option.
                

>>>>>> 
>>>>>> All you have to do is this: 
>>>>>> 
>>>>>> In your list control panel, go to: 
>>>>>> 
>>>>>> 	Your Mailing List -> Mailing List Options
>>>>>> 
>>>>>> and uncheck the option: 
>>>>>> 
>>>>>>  [ ] Send Unsubscription Confirmation Emails (Closed-Loop Opt-Out)
>>>>>> 
>>>>>> Save and Boom: you're done. 
>>>>>> 
>>>>>> There was a change in Dada Mail, after version 3.0.3: 
>>>>>> 
>>>>>> 	http://dadamailproject.com/support/documentation-4_0_4/changes_4_x.pod.html#subscription_and_unsubscription_links_now_include_an_email_address
>>>>>> 
>>>>>> That puts the email address in the unsub link - this guy: 
>>>>>> 
>>>>>> 	<!-- tmpl_var list_unsubscribe_link -->
>>>>>> 
>>>>>> So, when the user clicks on it, you'll get a one-click unsubscribe, just like you want (and it looks like, your subscribers want). In fact, I think that first option I told you to uncheck should also be unchecked, by default after 4.0.3, as well: 
>>>>>> 
>>>>>> http://dadamailproject.com/support/documentation-4_0_4/changes_4_x.pod.html#send_unsubscription_confirmation_emails__closed_loop_opt_out____disabled_by_default
>>>>>> 
>>>>>> So, actually, what you want, should be the new default. Are you running the newest version of Dada Mail (or, have you upgraded, with lists with old settings?) 
>>>>>> 
>>>>>> If you're running something lower than 4.0.3 and want the same effect w/the unsubscription link (email address present), you can just do this: 
>>>>>> 
>>>>>> 	<!-- tmpl_var list_unsubscribe_link -->/<!-- tmpl_var subscribe.email_name -->/<!-- tmpl_var subscriber.email_domain -->/
>>>>>> 
>>>>>> But don't do this after 4.0.3 - it'll look weird. 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Justin J.
>>>>>> 
>>>>>> Dada Mail -  Write Once: Distribute Everywhere Software 
>>>>>> url: http://dadamailproject.com
>>>>>> 
>>>>>> The Dada Mail Demo: 
>>>>>> http://demo.dadamailproject.com
>>>>>> 
>>>>>> On Apr 2, 2010, at 3:48 AM, Alan Hysinger wrote:
>>>>>> 
              

>>>>>>> 
>>>>>>> Hi, I'm totally new to the list, so if I am in need of a clue, just speak up.  I have no idea of any etiquette out here, and I am a very direct person.
>>>>>>> 
>>>>>>> I wanted to provide my users with a single-click unsubscribe option.  I have received some emails from angry users who don't understand the multi-step unsubscribe process, or worse, the unsubscribe confirmation gets moved to their spam folder.  Additionally, almost all of these people are my customers, who after graciously spending money in my store and opting in, decide they want to opt out.  I really want that to be as easy as possible for them.
>>>>>>> 
>>>>>>> I thought I was going to be able to implement a single-click unsubscribe simply by putting <!-- tmpl_var list_unsubscribe_link --><!-- tmpl_var subscriber.pin --> as the unsubscribe link in the mailing templates.  Unfortunately, it did not work because Dada checks to see if a confirmation was first requested, and issues this error:
>>>>>>> 
>>>>>>> Problems with Unsubscribing!
>>>>>>> 
>>>>>>> The unsubscription confirmation did not complete correctly. This may be because:
>>>>>>> 	• You've attempted to unsubscribe to a list (even when using a valid pin), without first asking for a confirmation.
>>>>>>> I found it easy to circumvent the check for a confirmation by commenting out this code in Subscriptions.pm::unsub_confirm and the unsubscribe request successfully removed the subscriber from the list.
>>>>>>> 
>>>>>>> # My last check - are they currently on the UNsubscription confirmation list?!
>>>>>>> #    if($lh->check_for_double_email(-Email => $email,-Type  => 'unsub_confirm_list')  == 0){ 
>>>>>>> #        $status = 0; 
>>>>>>> #        $errors->{not_on_unsub_confirm_list} = 1; 
>>>>>>> #        warn ' $errors->{not_on_unsub_confirm_list} set to 1'
>>>>>>> #            if $t; 
>>>>>>> #    }
>>>>>>> #    else {
>>>>>>> 	
>>>>>>> 		warn 'removing, ' . $email . ' from unsub_confirm_list'
>>>>>>> 			if $t; 
>>>>>>>   my $rm_status = $lh->remove_subscriber(
>>>>>>> 			{ 
>>>>>>> 	            -email => $email, 
>>>>>>> 	            -type  => 'unsub_confirm_list'
>>>>>>>        }
>>>>>>> 		);    
>>>>>>> 
>>>>>>> #    }
>>>>>>> 
>>>>>>> 
>>>>>>> Anyway, I was thinking it would be a good feature to have this configurable via the administrative UI, or perhaps in Config.pm.  Obviously, I have a selfish motive: I don't want to patch every update to Dada, or worse, forget to patch an update.  If this feature is deemed acceptable, I am willing to put in some time coding some patches.  Not to get too far ahead of myself, but I would need some pointers at what perl files to look at for managing configuration options.  The code is beautifully clean, which enabled me to kludge in my feature in under 5 minutes, but the storage of config settings from the UI didn't jump out at me.  Putting the option in Config.pm would be very simple, however I have some love for Dada and I wouldn't mind putting in the time to "do it up right".
>>>>>>> 
>>>>>>> Kind Regards,
>>>>>>> Alan Hysinger
>>>>>>> Post: 
>>>>>>> mailto:dadadev@PROTECTED
>>>>>>> 
>>>>>>> Unsubscribe:
>>>>>>> http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/justin/dadamailproject.com/
>>>>>>> 
>>>>>>> List Information:
>>>>>>> http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev
>>>>>>> 
>>>>>>> Archive:
>>>>>>> http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev
>>>>>>> 
>>>>>>> Developer Info:
>>>>>>> http://dev.dadamailproject.com
>>>>>>> 
                

-------------------------------------------------
John Collins
Meetings and Mixers
Box 80461
Rancho Santa Margarita, CA 92688
c949 689 7070
john@PROTECTED
http://www.meetingsandmixers.com/

Post:
mailto:dadadev@PROTECTED

Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/kohenkatz/gmail.com/

List Information:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev

Archive:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev

Developer Info:
http://dev.dadamailproject.com