Justin,
Sorry I've been too busy lately to give the latest releases a good try Been working on a new website using the Joomla CMS I was amazed to find out there wasn't a mailinglist module for it I think there would be a large audience for you there
For someone with your skills it should be relatively easy to get this going
www joomla org
Just a thought ;-)
Greetings, Alfred
-----Oorspronkelijk bericht----- Van: Dada Mail (Justin Simoni) [mailto:dada@skazat com] Verzonden: maandag 7 augustus 2006 3:35 Aan: dadadev@skazat com Onderwerp: [dadadev] Dada Mail 2 10 10 rc1 Released
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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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&gro up_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
-- Justin Simoni
: Dada Mail "Write Once - Distribute Everywhere" Email Communication Software
url: http://mojo skazat com aolim: leaddadaist
Start a new thread, email: dadadev@dadamailproject.com
This is the developer discussion mailing list for Dada Mail.
If you are just looking for support Dada Mail, consult the message boards at:
https://forum.dadamailproject.com
Documentation for Dada Mail:
Specifically, see the Error FAQ:
https://dadamailproject.com/d/FAQ-errors.pod.html
To post to this list, send a message to:
mailto:dadadev@dadamailproject.com
All subscribers of this list may post to the list itself.
Topics that are welcome:
Dada Mail is on Github:
https://github.com/justingit/dada-mail/
If you would like to fork, branch, send over PRs, open up issues, etc.
This Privacy Policy is for this mailing list, and this mailing list only.
Email addresses collection through this mailing list are used explicitly to work within this email discussion list.
We only collect email addresses through our Closed-Loop Opt-In system.
We don't use your email address for any other purpose.
We won't be sharing your email address with any other entity.
Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.
All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.
All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.