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 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@dadamailproject com

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

--

Post: mailto:dadadev@dadamailproject com

Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/u/dadadev/originalgeek/mac 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=

--

Post: mailto:dadadev@dadamailproject com

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=

--

Post: mailto:dadadev@dadamailproject com

Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/u/dadadev/originalgeek/mac 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=