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?