Hi Justin:

If I understand your analysis correctly, these modifications would disable a "one click" list unsubscription process

I think that this might be a mistake

I, for one, always use the list_confirm_unsubscription_link in the bottom of my emails My feeling is that if somebody wants off the list then they should be able to do so without jumping through a lot of hoops It always seems a little bit odd to me when I see unsub mechanisms that require me to enter my email address before I unsub I have dozens of email addresses and I simply can't be bothered to take note of which one was used in this particular message I shouldn't have to do the work

That being said I think the points you make concerning security of list subscriptions is important Ideally the modifications you are talking about would only apply to subscriptions I don't think there is as much of a risk with unsubs

Of course this is just one persons perspective

Thanks for all your hard work

-- // Rob Taylor \ TD Media // http://www tdmedia com

\ 760 438 9393

>

Heya everyone

I've been hard at work, getting Dada Mail ready for the next alpha release

The more things I add, in terms of features - and right now, it's just one big feature: multiple subscriber fields, the more things I find I have to tweak to make the system work (still) This gives good opportunity to tune some of the code and get rid of stuff that's not even needed

Along the way, the new features do call for some decisions on how the program works Right now, Dada Mail has quite a few options on how the current subscription process works For example, you can subscribe with, or without confirmation, with extra checks for blacklisting, CAPTCHAing challenge/responses, confirmation request limits, etc and also have different options on how to report that a subscription works out - URL redirects/showing a result via HTML - and all this works in a portable way in a few methods you can call in any Perl program

It's actually quite a headache to keep straight

One of the glaring problems is that the confirmation authentication isn't as strong as it could be It'd like to work specifically on that problem, but it would impact quite a few things in the program:

Currently, there's the idea of a, "Subscription URL" and a, "Subscription Confirmation URL" The "Subscription Confirmation URL" is the URL with the pin number in it Looks like this:

http://example com/cgi-bin/dada/mail cgi/n/list/user/example com/123456789/

As it stands, the pin number (123456789) is fairly unique per email address and is probably unique in the pairing of this email address with this Dada Mail installation - meaning, trying to confirm an address using this pin with this email on a different Dada Mail won't work

I'm not an expert in security, but the pin number in Dada Mail has some shortcomings First off, it's computed using the email address itself as some of the data The rest you can set, but it's always the same data for the rest of the computation for every email address If I was snarky, I could figure out how to make pins for every address per Dada Mail installation No one has, that I know of, but it's just a matter of time

What would be better is a completely unique and random pin number for each subscription request There's a few things that stop me from implementing that - well, really just one: there's no where to save this pin request temporarily, since the subscription back end does not support multiple fields

Well - in the Very Near Future, Dada Mail will support this It's not such a big deal to get this in now for the SQL backends that also support Multiple Subscriber Fields

The PlainText backend won't Still I'm basically going to give up trying to shoehorn multiple fields-like behavior for the PlainText backend and say, "Hey, if you're using the PlainText Backend, this is how pins are made"

As it stands right now, when someone makes a request for a subscription, their email address, along with any other subscription fields, is saved in the "sub_confirm" sublist and is moved from this sublist to the actual subscription list once the confirmation process is complete

When creating the multiple fields feature, I realized that there's nothing to really stop someone from faking a confirmation I want to suggest that a check is made to see if the subscriber is on this "sub_confirm" sublist, before actually being able to subscribe to a list This would basically guarantee that the subscriber actually went through the subscription process, before getting on It would also provide some sort of protection to the pin authentication stuff

Sounds great to me

There are a few drawbacks that I'm able to swallow, but I wanted you guys/gals opinions on:

• If a subscription and/or unsubscription confirmation is going to need the email address to be on a confirmation list, the "Subscription Confirmation URL" won't be allowed in your mailing list messages In other words, you won't be able to use this tag anymore:

  [list_confirm_unsubscription_link]

only this tag:

[list_unsubscripton_link]

In fact, the only place you'll be able to use this tag is in the List Subscription/Unsubscription Confirmation Message No where else

It also means that every single subscription/unsubscription a person makes will require going through the entire process I know that at least in testing, I just use the same message over and over again to subscribe myself (after, somehow, removing myself)

There are some benefits to this With the multiple subscriber fields especially, it makes sure, upon subscription, the information they first submit in the beginning of the confirmation process will still be around when they finish it

I've said quite a bit Thoughts?

-- Justin Simoni

Dada Mail - Write Once: Distribute Everywhere Software url: http://mojo skazat com

--

Post: dadadev@PROTECTED

Unsubscribe: http://mojo skazat com/cgi-bin/dada/mail cgi/u/dadadev/

List Information: http://mojo skazat com/cgi-bin/dada/mail cgi/list/dadadev

Archive: http://mojo skazat com/cgi-bin/dada/mail cgi/archive/dadadev