Dada Mail, 2 10 10 rc1 has been released:

tar gz:

http://prdownloads
sourceforge
net/mojomail/dada-2_10_10_rc1
tar
gz?download

zip:

http://prdownloads
sourceforge
net/mojomail/dada-2_10_10_rc1
zip?download

This version has still been nothing but bug fixes - we've topped 50
bug fixes since starting this version

Many of them have to do with security concerns and the session
keeping mechanism If you can give these dev version a show, I'd
really appreciate it

What follows is the changelog for this version, notes and known issues,

Cheers,

Justin

Bug Fixes:

2 10 10 rc1 (refer to the 2 10 10 beta 1 changes as well)

Bug Fixes (pending) * 1531985 2 10 9 - sub form on list page could be more usable when A list is cloed -

    If so, the subscription form only has the "Unsubscribe" radio
    button, but it's unchecked, meaning, if you try to unsubscribe to
    the list, w/o checking this button, you'll fail
 That's stupid - it
    should probably be checked by default


    http://sourceforge
net/tracker/index
php?func=detail&aid=1531985&group_id=13002&atid=113002

* 1532861 2
10
9 - Typo in, "Resend Unsubscription Confirmation"button
    This button is showed if you limit the number of sub/unsub
    confirmations that you send out


    http://sourceforge
net/tracker/index
php?func=detail&aid=1532861&group_id=13002&atid=113002

* 1532864 2
10
9 - No feedback if list doesn't exist when sub/unsub'in
    If you sub/unsubscribe to a list from an outside form, and that form
    is not created correctly, for example: the list shortname is entered
    wrong (or not there at all), no error is reported - you're just
    shown the default screen
 There should at least be an error on that
    screen stating, "hey chump, here's the deal"

    http://sourceforge
net/tracker/index
php?func=detail&aid=1532864&group_id=13002&atid=113002

* 1533593 2
10
9 - Errors are triggered in "Confirmation" step when


    the subscription confirmation (double-opt-in) is disabled
 This
    leads sometimes to some unlikely events, like wanting to redirect if
    a subscription fails, but having this redirect not happen, since the
    error gets trapped during *confirmation*, which should be skipped


    http://sourceforge
net/tracker/index
php?func=detail&aid=1533593&group_id=13002&atid=113002

* 1533640 2
10
9 - SASL test does not support, "Server replied: '235'"
    Complete OK status:

    Server replied: '235 ok, go ahead (#2
0
0)'

    Looks like it comes from a server running Mac OS X/postfix




    http://sourceforge
net/tracker/index
php?func=detail&aid=1533640&group_id=13002&atid=113002

* 1533647 2
10
9 - Settings/Archives backup, "Dir not empty" error
    Looks like this:

    [Wed Aug 2 23:12:32 2006] mail
cgi: couldn't remove
    /home/user/
dada_files/
backups/j/settings/1154581249 Directory not
    empty at /DADA/App/GenericDBFile/Backup
pm line 176


    For some reason, when it tries to remove all the separate files,
    some get left behind?

    Solution seems to be to feed unlink a list of files to remove,
    instead of calling unlink again and again


    Probably more efficient, too


    http://sourceforge
net/tracker/index
php?func=detail&aid=1533647&group_id=13002&atid=113002

* 1533653 2
10
9 - No safegaurd against sending a msg w/blank Subject
    A simple Javascript check would do wonders in this

    http://sourceforge
net/tracker/index
php?func=detail&aid=1533653&group_id=13002&atid=113002

* 1534824 2
10
9 - Errors triggered in \"unsub \" step when


    Instead of the unsubscription confirmation step - just like in the
    subscription step


* 1534939 2
10
9 - sub or unsubbing request with no email - and

?
    and you get redirected to the list page - with no real description
    of what may have been the problem - this needs to be rectified - at
    the very least, it should say something like, "fill in your email,
    fool!"

    http://sourceforge
net/tracker/index
php?func=detail&aid=1534939&group_id=13002&atid=113002

* 1534947 2
10
9 - http://example/cgi-bin/dada/mail
cgi?f=n causes err
    Simply going to:

    http://example
com/cgi-bin/dada/mail
cgi?f=n

    Causes a Server 500 error



    http://sourceforge
net/tracker/index
php?func=detail&aid=1534947&group_id=13002&atid=113002

* 1535132 2
10
9 - admin screens easy to hide, but also easy to guess
    It's easy to guess what the main administration login screen is -
    'cause it's always the same -

    http://example
com/cgi-bin/dada/mail
cgi/admin

    If this could be changed, you can ensure that only the right people
    knew where the main administraton login screen is


    http://sourceforge
net/tracker/index
php?func=detail&aid=1535132&group_id=13002&atid=113002

* 1535133 2
10
9 - Admin Login Available Anywhere
    Meaning, you don't *have* to use the login form - as long as you
    know the variables that have to be passed to Dada Mail, you can log
    in anywhere -

    which also means, you can attempt to automate logging in,

    as in a robot trying various logins


    http://sourceforge
net/tracker/index
php?func=detail&aid=1535133&group_id=13002&atid=113002

* 1535188 2
10
9 - \"-html_output\" param in subscribe() etc, not follow
    


ed, if there's an error where there's no list, or no email, etc


    http://sourceforge
net/tracker/index
php?func=detail&aid=1535188&group_id=13002&atid=113002

http://sourceforge
net/tracker/index
php?func=detail&aid=1535188&group_i
d=13002&atid=113002

Known Issues: * [ 1533596 ] 2 10 9 - Can't call method "param" on an undefined value These sorts of errors happen sometimes:

    [Wed Aug 2 19:23:06 2006] mail
cgi: Can't call method "param" on an
    undefined value at /DADA/App/Session
pm line 261
 [Wed Aug 2
    19:27:45 2006] mail
cgi: Can't call method "param" on an undefined
    value at /DADA/App/Session
pm line 128


    The reason is unclear for me


    WORKAROUND

    * Install a server-wide version of CGI::Session

    * Set the $SESSION_DB_TYPE to, "Classic" (please see the warning in
    the, "NOTES"

New Config Variables Consult the Config pm documentation on information of these new variables

* $SESSION_DB_TYPE
    Actually, not a new variable, be can now be set to, *Classic*, as
    well as the current choices of: *PlainText*, *Db*, *MySQL*,
    *Postgres*


* $ADMIN_FLAVOR_NAME
* $SIGN_IN_FLAVOR_NAME
* $DISABLE_OUTSIDE_LOGINS
* $YOU_ARE_ALREADY_SUBSCRIBED_MESSAGE
    (actually, most likely introduced in 2
10
10 beta 1)

Notes:

10 10 List Subscription Errors - When Are The Catched? Not to confuse you too much, but Dada Mail has the option to use Double-Opt-In confirmation We strongly suggest you use it
There's an option to not, but you'll be shooting yourself in the foot if
you don't

 Saying all that, When you don't set the double-opt-in and a  

subscriber tries to subscribe, Dada Mail will basically fake the
confirmation of subscription part, except, that it'll still make sure the email is valid, not already subscribed, not blacklisted, etc, at the, subscription step - which is basically the step we're telling it to skip

 This doesn't really sound like that bad of a deal - two sets of  

error checking, but, if you're trying to do something specific at the
error checking, like redirecting to a URL upon an error, you'll find that this, just doesn't work And thus, the bug

 This bug has been fixed in Dada Mail, but will cause a slightly
 different behavior in the program - so:

 If you turn off double-opt-in (which you shouldn't), and want to
 redirect on a subscription error, it will work as advertised
 If  

you're using a version below 2 10 10, the error will be trapped and your preferences will be triggered as if you're on the, subscription confirmation step - which should had been skipped I know
Confusing

List and Dada Mail Root Passwords There's a slight change on how Dada Mail handles how passwords are accepted, when you log into a list

 In the past, if the List Password was the same as the Dada Mail  

Root Password, the user would be granted login as if they were using
the Dada Mail Root Password This causes a problem, since, perhaps it was
purely coincidential the List and Dada Mail Root Password were the same - giving the person who only has the list password right that only
someone who logs into using the Dada Mail Root Password usually has By
default, one of these privileges is the deletion of a list in entirely

 To counteract this bug, you can no longer set a List Password  

that same as the Dada Mail Root Password on list creation

 If the List Password is changed to be the Dada Mail Root  

Password, upon log in of the list again, the password will only work as a
regular List Password If this comes as a surprise to you, simply reset the List Password as something other than the Dada Mail Root Password

SQL backend for sessions We've updated the SQL tables for both MySQL and Postgres - if
you're using either of these backends, please drop your current sessions (usually called, dada_sessions) table and create the appropriate
new table Should clear up a lot of problems

Known Issues:

Known Issues CGI::Session Problems CGI::Session is bundled with Dada Mail - you don't have to
install it separately In rare occurances, it doesn't work correctly You may receive an error like this:

  Wed Aug 2 19:23:06 2006] mail
cgi: Can't call method
  "param" on an undefined value at /DADA/App/Session
pm
  line 261


 I haven't yet figured out what causes this, but there's two  

solutions:

 Remove the files in the, *dada/DADA/perllib/CGI/Session** files and
 directories

 and install CGI::Session and CGI::Session::ExpireSessions  

manually or via CPAN

 More information:

 http://search
cpan
org/~markstos/CGI-Session/lib/CGI/Session
pm

 http://search
cpan
org/~rsavage/CGI-Session-ExpireSessions/lib/ 

CGI/Sessi on/ExpireSessions pm

 or,

 Set the Config
pm variable, $SESSION_DB_TYPE to, "Classic"


 Do Note that only attempt the second solution if you understand  

that the classic method will pass your list name and list password across
the network and save this information (albeit in an encrytped form)
in your brower's cookie jar Not the best situation, but if you're in a
pinch, it may be a life-saver - but try to get one of the other options
working ASAP