The majority of changes in this release deals with stability and documentation.
The Clickthrough Tracker works again and the URL's are now (mostly) just string of numbers, instead of attempting to save the enitre URL you're redirecting to. This is a pretty good thing.
Email Message Templates can now support HTML::Template::Expr syntax
Partial List Sending Options are now supported by Beatitude.
Beatitude now bears a resemblence to the rest of Dada Mail's list sending screens, instead of looking completely different.
The, -odq
sendmail flags are set by default. If mail sending isn't working, try taking these flags off, it may be an incompatibility.
I'm in sort of a tough spot, since these flags don't always work, but having them on makes life easier for the mail server.
I think I'm siding on the mail server in this case.
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_9.tar.gz
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_9.zip
Things are broken - this is an alpha release - don't use for production work, please.
Some things we know are completely busted:
The clickthrough tracker won't work - the redirect tags are never parsed. These will return soon enough.
I'm not sure if the Update Subscription extension works. It doesn't know about multiple fields and using it will most likely erase any information saved in these fields. The Multiple Subscribe Extension should work just swimmingly, though.
Most, if not all of the error messages that were in the DADA::App::Error module have been moved out of the module and into the, dada/DADA/Template/templates
directory. Each error message has its own template file. Most, if not all of the error message file names start with, "error_".
Email Templates now use HTML::Template (yes, for plain text emails too) for the backend, instead of random and dispersed simple regexes that have been in use for 8 or so years. Depending on the email being sent out, list settings and subscriber information is automatically passed to HTML::Template to be used when output
ing.
Currently, only the HTML::Template way of doings things is supported, but adding HTML::Template::Expr is a possibility.
Care has been given to allow a graceful backwards compatibility with older email templates and most older email templates will work without problem. One exception is the, "List Invitation" email template - this template should be reverted to the default that's shipped with this release.
For more information, see the documentation for, screen
in DADA::Template::Widgets - it's currently the wrapper around HTML::Template for Dada Mail.
The, Send a List Invitation feature is still a part of Dada Mail, but it's functionality has been moved from it's own stand-alone administration screen to a part of the Add Email steps. After verification of new subscribers, you now have the choice of subscribing or inviting the verified addresses.
There's been some confusing amongst... amongst myself in some of the terms used in Dada Mail - one of them is the, "Black List" - is it, "Blacklist", or, "Black List?"
I've decided on, "Black List". Some list settings are named, "black_list_*" and some are named, "blacklist_*"
These currently won't change, but the error paramaters have. They should all be, black_list
The DADA::Template::Widgets screen
subroutine has gone through significant changes - one of the largest is the move from passing paramaters in a hash, to passing paramaters in a hashref. All the old paramaters will work (and there's a slew of new, optional ones, but these paramaters must be passed in a hashref. So:
print DADA:Template::Widgets::screen(-screen => foo.tmpl); # No!
print DADA:Template::Widgets::screen({-screen => foo.tmpl}); # Yes!
The idea behind the tags (like): tags: [plain_list_subscriber_link] was stupid and their use is now dropped. Use list_subscriber_link instead. The only difference is that for HTML email messages, [list_subscriber_link] will not automatically become a clickable link - you'll have to make that yourself.
The email message templates in the list control panel under, "Manage Copy -> Email Templates" can now have their Subjects and in some instances To: and From: phrases editable.
Many of the email message template tags have been modified - most of the modifications are simple and make sense. A small rundown:
Anything that has to do with a list setting, now has, list_setting. appended to it. For example:
Anything that has to do with a subscriber now has subscriber. appended to it. For example:
Documentatoion still needs to be written concerning these changes. Old email templates should work, as they are auto-translated to this new syntax.
If you don't set an error log, one will now be made for you, automatically. The rub on this is errors made during compile time won't be logged.
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_8.tar.gz
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_8.zip
This release sports a very large new feature: Multiple subscriber fields. For an overview of this feature, do see:
dadamailproject.com/support/documentation-dada-2_11-alpha_8/subscriber_fields_in_2_11.pod.html
No, really - it's in there. Check it out. You'll need the SQL backend. For a large list of improvements, do see:
dadamailproject.com/support/documentation-dada-2_11-alpha_8/subscriber_fields_in_2_11.pod.html
Of note, this feature also has the below features that relate to it:
The dada_bridge.pl plugin name has been modified to, Dada Bridge, lest we figure out a more clever name. We're still going through the documentation and changin' stuff
If you were fond of the original Dada Mail, "moderation" sytem, this is basically it again, relabled, "Authorized Senders".
The Authorized Senders is a sublist in Dada Mail. It contains a list of email addresses that are allowed to post a message to a Dada Mail list.
This is most extremely useful for announce-only lists, where you'd like to give posting access to someone other than the list owner.
White List support is back after a little break. The white list is a sublist of Dada Mail list that allows you to specify a list of addresses that are allowed to subscribe. It's basically the opposite of the blacklist.
SQLite is now completely up to par with the other backends. I doubt I'd suggest it as a backend, but it's an option and is used for testing.
This support is very spotty and probably is broken at the moment. Go go alpha code. More information:
Added a silly calculator to tell you how long a sending will probably be. It's in AJAX
"Stuck" Mailouts shouldn't really happen anymore.
The Config variable, $DEBUG_TRACE is now populated with a few module names, example: DADA_Mail_Send. Setting this name to a value of, 1 will print many lines in your error log for things pertaining to the DADA::Mail::Send module.
A word of warning about using the $DEBUG_TRACE stuff - the implementation isn't very complete for any module and what's implemented may not make sense to anyone but me. Be aware: Thar be dragons.
(partial) Support is current there for the DADA::Mail:Send, DADA::Mail::Mailout and DADA::App::Subscriptions modules.
Font sizes have been changed from px to em's.
Removed the following templates:
Added:
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_7.tar.gz
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_7.zip
This is a features-focused release. Most of the relevent bugs that cropped up in the 2.10.15 release of Dada Mail should be patched up in this version of Dada Mail (2.11 Alpha 7) but aren't verified.
Please refer to the 2.10.16 changelog for specifics on bugs fixed. The 2.10.16 release is a bugfix-only release and should be the current distribution used for production websites.
Most all plugins and extensions currently shipping in the 2.11 alpha 7 build of Dada Mail will need to be run with 2.11 alpha 7. No other previous version of Dada Mail will work.
All the plugins/extensions available for Dada Mail (by me) are available in the 2.11 alpha 7 release. Furthermore, any restrictions on list size, or max # of lists has been lifted. This is to help you test the program out and find bugs.
Do note that this is an ALPHA release and is known to not always work correctly. It SHOULD NOT be used on a production server
Also see the New Features docs for 2.11 alpha 6.
The MySQL, Postgres and SQLite tables have been optimized for performance and speed. Most of the changes deal with the data TYPE of the different fields. You may want to study the new schemas and see how they differ to the old schemas that were shipped -
The old schemas should work with this new alpha, so if you don't want to update your SQL tables that deal with Dada Mail, it's not required.
The MySQL schema has indexes added to the schema. These schemas are not verified and need to be tested. Feedback welcome!
If the SQLite backend didn't work (it wasn't actually working for us) try this new alpha version. We're probably keeping SQLite along for SQL backend testing purposes, as it's dead easy to use for such a task.
If you were testing the SQLite backend, note that the entire schema is probably completely different. We're now basing it on the MySQL schema, instead of the Postgres schema.
In the popup menus in the Restore Lists screen, you can now see how many entries are available for each saved backup.
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_6.tar.gz
http://downloads.sourceforge.net/mojomail/dada-2_11_alpha_6.zip
This is a features-focused release. Most of the relevent bugs that cropped up in the 2.10.14 release of Dada Mail should be patched up in this version of Dada Mail (2.11 Alpha 6) but aren't verified.
Please refer to the 2.10.15 changelog for specifics on bugs fixed. The 2.10.15 release is a bugfix-only release.
Most all plugins and extensions currently shipping in the 2.11 alpha 6 build of Dada Mail will need to be run with 2.11 alpha 6. No other previous version of Dada Mail will work.
All the plugins/extensions available for Dada Mail (by me) are available in the 2.11 alpha 6 release. Furthermore, any restrictions on list size, or max # of lists has been lifted. This is to help you test the program out and find bugs.
Do note that this is an ALPHA release and is known to not always work correctly. It SHOULD NOT be used on a production server
Also see the New Features docs for 2.11 alpha 5, if you're usually running 2.10.14.
Some of the plugins/extensions currently supported are:
See also the $PLUGIN_CONFIGS
Config.pm variable.
See the Beatitude Docs, most specifically the,
plugin variables.
The method to do so should be the same for Beatitude (Mail Scheduler), Mystery Girl (Bounce Handler) and dada_bridge.pl
See the $Plugin_Config-{FCKeditor_Support}> var in dada/plugins/scheduled_mailings.pl for more information.
You don't need to use the --run
flag when running scheduled_mailings.pl from the command line.
See the dada_bridge.pl Docs, most specifically the,
plugin variables.
The method to do so should be the same for Beatitude (Mail Scheduler), Mystery Girl (Bounce Handler) and dada_bridge.pl
You'll see lines, such as these in the Dada Mail usage log ($PROGRAM_USAGE_LOG)
[Wed Jun 20 03:55:04 2007] listname 12.34.12.34 Subscription Confirmation Sent for listname.list user@example.com, remote_host:, ip_address:120.0.0.1
[Wed Jun 20 04:05:38 2007] listname 12.34.12.34 Unsubscription Confirmation Sent for listname.list user@example.com, remote_host:, ip_address:120.0.0.1
To let you know what's happening.
See the Mystery Girl Docs, most specifically the,
plugin variables.
The method to do so should be the same for Beatitude (Mail Scheduler), Mystery Girl (Bounce Handler) and dada_bridge.pl
Note! Your old scorecard is probably not going to be of much use anymore;
Helpful to see why they may be bouncing.
We've enabled the use of the MailHide CAPTCHA idea for email addresses in the list archive messages. You also have the option to use no protection at all, or keep the default protection scheme (called, SPAM-me-not)
More information on Mailhide:
http://mailhide.recaptcha.net/
See also the Config.pm variable, $RECAPTHCA_MAILHIDE_PARAMS
The options to protect email addresses in the list's archives is availabl ein the list control panel under, Manage Archives - Archive Options - Advanced
Should work for Session information, list subscribers, settings and archives.
We've added support for the reCAPTCHA project in Dada Mail. Here's more information on it:
In Dada Mail, see the following variables:
To use the reCAPTCHA system, you'll need to set this variable to, "reCAPTCHA"
You'll need to plug in the, public_key and private_key variables.
The following locations hold the various SQL table schemas needed for the SQL backends:
dada/extras/SQL/postgres_schema.sql
dada/extras/SQL/mysql_schema.sql
dada/extras/SQL/sqlite_schema.sql
Originally, we were using Net::POP3, but have now moved to Mail::POP3Client.
Amongst other things, you can now connect to a POP3 server via SSL and also set the type of authentication scheme you want to use.
You'll see the options in the Manage List - Sending Options - SMTP Options, as well as in Mystery Girl and dada_bridge.pl.
Used specifically in the, "Send a Webpage" screen, using this tag in the message itself, will have the tag be replaced with the actual URL you're getting the message source from. For example, in your message, you can write:
<p> <a href="[originating_message_url]"> If you cannot see this message, click here! </a> </p>
DADA::App::POP3Tools Holds all the stuff needed for POP3 connections and replaces the various, independent schemes in dada_bounce_handler.pl, dada_bridge.pl and the DADA::Mail::Send module.
http://downloads.sourceforge.net/mojomail/dada-2_10_14.tar.gz?download
http://downloads.sourceforge.net/mojomail/dada-2_10_14.zip?download
There are no official new features in 2.10.14 of Dada Mail, when compared to 2.10.13. This is a bugfix only release.
These bugs appear in at least the 2.10.13 version of Dada Mail and should be fixed in the 2.10.14 release.
https://sourceforge.net/tracker/index.php?func=detail&aid=1710309&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1712412&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1712400&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1712412&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1713638&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1713641&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1714705&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1714728&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1714725&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1704711&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1701826&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1692100&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693199&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693371&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1699829&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1699838&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1696684&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1695274&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1679568&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693368&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1688094&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1684126&group_id=13002&atid=113002
http://downloads.sourceforge.net/mojomail/dada-2_10_14-beta_1.tar.gz?download
http://downloads.sourceforge.net/mojomail/dada-2_10_14-beta_1.zip?download
https://sourceforge.net/project/showfiles.php?group_id=13002&package_id=102361&release_id=502753
All bugs are known to be fixed, but require testing and verification.
https://sourceforge.net/tracker/index.php?func=detail&aid=1704711&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1701826&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1692100&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693199&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693371&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1699829&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1699838&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1696684&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1695274&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1679568&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1693368&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1688094&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1684126&group_id=13002&atid=113002
This is a features-only release and doesn't contain bug fixes. For a bugfix-only development release, do see 2.10.14 beta 1,
This is a features-only release and doesn't contain bug fixes. For a bugfix release, do see 2.10.14 Stable.
2.11 Alpha 5 is basically based on Dada Mail, version 2.10.13 (again, NOT 2.10.14)
http://downloads.sourceforge.net/mojomail/dada-2_11-alpha_5.tar.gz?download
http://downloads.sourceforge.net/mojomail/dada-2_11-alpha_5.zip?download
See the New Feature in 2.11 Alpha 4 - it's basically the same.
This is a features-only release and doesn't contain bug fixes. For a bugfix-only development release, do see 2.10.14 beta 1,
http://downloads.sourceforge.net/mojomail/dada-2_11-alpha_4.tar.gz?download
http://downloads.sourceforge.net/mojomail/dada-2_11-alpha_4.zip?download
This variable sets how many different mailouts may go out from an installation of Dada Mail at one time. Conservatively, this is set to, 1 by default.
There are a few reasons why you wouldn't want to set this to any higher limit, one being that there's a possibility that there is a limit on how many email messages you are allowed to go out in a specific period of time.
Another reason is that sending out too many messages at once may cause the server your running to be overloaded.
$MAILOUT_STALE_AFTER sets, in seconds, how long a mailout can go with no mailing activity until Dada Mail itself won't automatically restart it. The default, 86400 seconds is one full day.
This variable attempts to safegaurd you against having a dropped mailing that you've, "forgotten" about restart, "mysteriously" and unintentionally.
A mailout may still be restarted if this limit has been surpassed, but it must be done manually, through the list control panel.
This should allow you to keep tags on all your mailings for a list at once, without having to visit each individual screen.
This screen will also reload a mailing, if necessary (just like the individual screens)
You now have the ability to pause a mailing, instead of simple stopping a mailing. A stopped mailing cannot ever be restarted, a paused mailing may be restarted with ease
WIth the Mailout At Once Limit, Dada Mail now supports queueing of awaiting mailouts.
See The writeup here:
for a brief overview on how pausing and queueing work in Dada Mail.
tar.gz distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13.tar.gz?download
zip distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13.zip?download
tar.gz distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13-rc1.tar.gz?download
zip distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13-rc1.zip?download
https://sourceforge.net/tracker/index.php?func=detail&aid=1673762&group_id=13002&atid=113002
tar.gz distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13_beta1.tar.gz?download
zip distro:
http://downloads.sourceforge.net/mojomail/dada-2_10_13_beta1.zip?download
multi_admin_subscribers.cgi is a plugin to allow you to administrate subscriptions/unsubscriptions for multiple lists at one time.
Note: Most likely, this plugin will only be distributed with Pro Dada/The Magicbook in the future, but is released in this beta distribution for testing purposes.
More information:
multi_admin_subscribers.cgi.html
https://sourceforge.net/tracker/index.php?func=detail&aid=1673762&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1657018&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1654672&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1654671&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1654669&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1648447&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1647628&group_id=13002&atid=113002
http://downloads.sourceforge.net/mojomail/dada-2_10_13_alpha1.tar.gz?download
http://downloads.sourceforge.net/mojomail/dada-2_10_13_alpha1.zip?download
See:
http://dadam ailproject.com/support/documentation/FAQ-email_sending.pod.html
Net::SMTP_auth allows us to choose which exact SASL authentication method to use, Net::SMTP would just try to make a best guess.
Note that we are shipping with a module called, Net::SMTP_auth_SSL that allows the same functionality over an SSL/TSL connection. This is not a CPAN module, but a tweak of Net::SMTP_auth to use SSL connections.
Marked at Experimental.
By default, the CAPTCH stuff uses a True Type font called, "StayPutt.tff" that's included with Dada Mail. This should make much better CAPTCHA images than the default GD fonts
The process of uploading a file and processing a file has now been split. This may help with large lists amd timeout problems.
It's no longer necessary to have to set the crontab to run dada_bridge.pl as a command line script, you can simply now set a URL for the crontab to visit. This also means you do not have to tweak the environment that dada_bridge.pl runs in, to run correctly as a cronjob.
See:
dada_bridge.pl.html#setting_the_cronjob_the__easy_way
See:
ajax_include_subscribe.cgi.html
The Dada Mail test suite is available to use in the regular distribution. It can be run using the, prove
command or the included web-based Dada Mail extension. More information:
https://sourceforge.net/tracker/index.php?func=detail&aid=1626608&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1634573&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1639133&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1627577&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1638183&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1638187&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1639138&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1641124&group_id=13002&atid=113002
The SMTP SASL Authentication tester was removed in 2.10.11 and was based on the Mail::Bulkmail module, which was also removed in 2.10.11.
It has now been put back in, based on the new (for us) Net::SMTP module.
Note!: Passwords are shown, albeit in an encoded version, in its results. DO NOT POST the SMTP conversation in this test in any public space.
Workaround for ver. 2.10.11 and 2.10.11b:
Find this line in the dada/DADA/Mail/MailOut.pm file:
my ( $junk, $list, $listtype, $id ) = split( '-', $file );
and change it to:
my ( $junk, $list, $listtype, $id ) = split( '-', $file, 4);
http://sourceforge.net/tracker/index.php?func=detail&aid=1609792&group_id=13002&atid=113002
Sending a list invitation doesn't send the invitation to a list of hopeful subscribers, it sends it TO your subscribers.
Workaround for ver. 2.10.11 and 2.10.11b:
Find this line in the dada/DADA/Mail/MailOut.pm file:
my $list_type = $args->{-list_tpe} ? $args->{-list_tpe} : 'list';
and change it to:
my $list_type = $args->{-list_type} ? $args->{-list_type} : 'list';
http://sourceforge.net/tracker/index.php?func=detail&aid=1612943&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1610543&group_id=13002&atid=113002
You're using the SQL backend (either MySQL or Postgres) for your list's settings backend and you attempt to save a password setting - it may fail.
http://sourceforge.net/tracker/index.php?func=detail&aid=1606467&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1611114&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1607259&group_id=13002&atid=113002
Workaround for ver. 2.10.11 and 2.10.11b:
Add this key/value pair somewhere in the Config.pm's %LIST_SETUP_DEFAULTS hash:
find_spam_assassin_score_by => 'looking_for_embedded_headers',
http://sourceforge.net/tracker/index.php?func=detail&aid=1606468&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1611105&group_id=13002&atid=113002
The Config.pm vars aren't being imported by default, so they need (and currently aren't) called directly, ala:
$VER
should be:
$DADA::Config::VER
You'll know you're hitting this error if you receive error message for this plugin that look like this:
Global symbol "$GOOD_JOB_MESSAGE" requires explicit package name at scheduled_mailings.pl line 404. Global symbol "%MIME_TYPES" requires explicit package name at scheduled_mailings.pl line 1487. Global symbol "$FILE_CHMOD" requires explicit package name at scheduled_mailings.pl line 1652. Execution of scheduled_mailings.pl aborted due to compilation errors.
Workaround for ver. 2.10.11 and 2.10.11b:
If you have a version of scheduled_mailings.pl from ver 2.10.11 or 2.10.11b find this line in scheduled_mailings.pl:
use DADA::Config qw(!:DEFAULT);
and change it to:
use DADA::Config;
http://sourceforge.net/tracker/index.php?func=detail&aid=1613740&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1608203&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1608202&group_id=13002&atid=113002
A few small, yet quite annoying bugs were found in the 2.10.11 distribution - 2.10.11 has just a few notable bug fixes:
(Note: That this only affects people who are using the SQL backend for list settings.
http://sourceforge.net/tracker/index.php?func=detail&aid=1606467&group_id=13002&atid=113002
This bug affects only those who are using dada_bridge.pl for discussion lists with moderation.
http://sourceforge.net/tracker/index.php?func=detail&aid=1607259&group_id=13002&atid=113002
This bug affects only those who are trying to use the dada_bridge.pl plugin
http://sourceforge.net/tracker/index.php?func=detail&aid=1606468&group_id=13002&atid=113002
Do see the changes for the 2.11 alpha series - all changes made in 2.11 alpha will also be for 2.10.11.
Mailing List Messages can now be monitored via the list control panel in great detail.
Note: The addition of this feature has also come with the removal of other features that this feature intends to replace (and do so, in a much better way). If you are looking for these features, note that they have been removed:
The Mail::Bulkmail SMTP engine hasn't been updated by the author in more than three years, so we're not too sure if there will ever be updates and/bug fixes in the futre for it. Its addition to Dada Mail came at a great expense of added complexity
Do note that SMTP Sending is still, 100% supported, just that Dada Mail has moved to using the Net::SMTP SMTP engine. Along with a simpler interface, secure, encrypted SMTP connections are now supported, as well as various new authentication schemes.
Batch completed messages via email has been removed - but are still logged and are logged in much greater verbosity. The web-based monitoring tool does do a better job in telling you exactly where a mailing is, so should be used instead.
This feature was basically the answer to what you do if a mailing was dropped. It wasn't very fun to use and since mailings now are auto-reloaded automatically, it's presence is no longer needed.
You will notice that you can only set batches between 1 and 60 addresses, and then time between 1 and 60 seconds. Although this seems constrictive, this should allow you to set message sending between 60 messages an hour and 216,000 messages an hour, which should work for almost all circumstances.
More information on this feature can be found at the following places:
Technical Details:
NOTES.pod.html#autopickup_of_mail_sendings
Nerdy Perl API Overview:
Mailing List Sending FAQ (goes over how to use this feature):
FAQ-mailing_list_sending.pod.html
auto_pickup.pl extension docs (extension that makes use of this feature):
Use the auto-pickup feature. Will work MUCH better
We've now completely moved to Net::SMTP
Batches could theoretically fail mid-batch, but the auto-pickup feature would reload the mailing at the correct email address. This does cause the batch # to be incorrect. To simplify everything, this feature has been dropped.
Logging in the Dada Mail usage log still happens and the logging is much more verbose, but batches are not numbered.
This only work with the Mail::Bulkmail backend, which has also been dropped.
Mystery Girl now takes advantage of the Mail-DeliveryStatus-BounceParser CPAN module, in conjunction with its own bounce parser routines (not replaced, in other words)
More information on Mail-DeliveryStatus-BounceParser:
There are MANY changes between this version and the 2.10 series. Please see:
http://dadamailproject.com/features/2_11_dev/index.html for details of the new features.
See the, "NOTES" for various things concerning this specific version of Dada Mail.
Being a alpha release, there are known bugs and some unknown bugs. If you do use this version, makes sure to understand that it will be a rocky way.
This is a simple check, that should be dealt with.
Something as simple as:
<script>alert('foo')</script>
When submitted in either the, "add" or, "remove" email subscribers will show the Javascript alert box.
http://sourceforge.net/tracker/index.php?func=detail&aid=1540234&group_id=13002&atid=113002
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.
The fix has been to employ an, "auth_id" hash that's saved in Dada Mail's list files. Dada Mail will make this hash, when it shows any type of login form. If this auth_id is missing or incorrect, Dada Mail will not allow logging in of a list.
See also the, $DISABLE_LIST_LOGINS Config.pm variable.
Config.pm.html#_disable_outside_logins
Currently, this feature is disabled by default.
http://sourceforge.net/tracker/index.php?func=detail&aid=1535133&group_id=13002&atid=113002
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
The fix has been to allow you to change the query string - in this case, admin to basically whatever you want, given some constraints. See the documentation for the $ADMIN_FLAVOR_NAME and, $SIGN_IN_FLAVOR_NAME Config.pm variables:
The, "You're already subscribed!" error that is received if you try to subscribe to a list, that you're already subscribed to, could be seen as a way to find out private information about someone, if an individual enters an email address that actually, isn't theres. The chance that someone would do this seems slim, but it is a hole that should be plugged.
Currently, the fix is to allow you to just email them the, "you are already subscribed" message, instead of showing this information in the web browser. The program will act just as if no problem with a subscription request has happened - this includes any errors it may return, in any sort of format.
This fix is currently disabled, but can be enabled in the Manage List -> Mailing List Options screen.
will act like the root password!
This is a problem, because it could be unbeknowest to the list password haver, that they have credentials that could unluck more stuff than they should have!
The fix is to have the list password, when set to the same as the root password, act as if it's the list password only. More information, List and Dada Mail Root Passwords -
Tied closely to the above bug - List Passwords can be set - by default *to* the root password. Since you need the root pass to create a new list, it's alright to say, "hey, you just set the list pass to the root pass - don't do that!"
Also see:
NOTES.pod.html#list_and_dada_mail_root_passwords
http://sourceforge.net/tracker/index.php?func=detail&aid=1530149&group_id=13002&atid=113002
In the, "Manage Appearance -> Edit Template" screen. This makes it hard to debug template problems that use an outside URL.
http://sourceforge.net/tracker/index.php?func=detail&aid=1540194&group_id=13002&atid=113002
Any archived message that has a blank subject line will have its navigation broken, since the link is made up soley of the Subject line. Currently the solution is to put the default subject line in its place (The default defaults to, (no subject)
http://sourceforge.net/tracker/index.php?func=detail&aid=1539846&group_id=13002&atid=113002
None of the Timestamp options actually do work. (fixed of course)
http://sourceforge.net/tracker/index.php?func=detail&aid=1539669&group_id=13002&atid=113002
The breakcrumbs for the archive search results doesn't have, well, "Archives" in the train of breadcrumbs. This is add, since an individual archived messages will. This should be fixed!
http://sourceforge.net/tracker/index.php?func=detail&aid=1530146&group_id=13002&atid=113002
An unhelpful screen of blank stuff.
Should there are least be a note that says, "There are no archived messages"
Instead of nothin'? (usability issue, really)
http://sourceforge.net/tracker/index.php?func=detail&aid=1529531&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1528324&group_id=13002&atid=113002
Basically a usability issue, if you only have one list, and that list isn't hidden, you'll still see the, "other..." link to log into that mysterious second, hidden list.
Now, the "Other..." link will only show *if* there's another list to log into.
http://sourceforge.net/tracker/index.php?func=detail&aid=1539659&group_id=13002&atid=113002
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, KNOWN ISSUES, under, CGI::Session Problems
http://sourceforge.net/tracker/index.php?func=detail&aid=1531088&group_id=13002&atid=113002
Which means, when you try to log back in again, you'll be greated with the, "You're still logged in, bucko!" error and the session information gets stale and hangs around for what seems, forever.
http://sourceforge.net/tracker/index.php?func=detail&aid=1530173&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1530156&group_id=13002&atid=113002
...this may be important if the new style, well, Just Doesn't Work Right.
Never use this feature unless you understand the security implications, which are described in detail:
You explicitly turn off the screen in the, "Customize Feature Set" screen. Somewhat related to this bug:
1527704 2.10.9 - Customize Feature Set - Function Unclear (huh?!)'
http://sourceforge.net/tracker/index.php?func=detail&aid=1527704&group_id=13002&atid=113002
This is because the, "-Function" isn't set in the $ADMIN_MENU variable in the Config.pm file.
http://sourceforge.net/tracker/index.php?func=detail&aid=1529990&group_id=13002&atid=113002
Similar error to, 1530173 2.10.9 - changing a list password fails to log out user..
http://sourceforge.net/tracker/index.php?func=detail&aid=1527007&group_id=13002&atid=113002
Which means, they stick around for what seems like forever. Logins that fail should have the session information removed, as it's useless, if the information is incorrect, outdated, etc.
There's also a minor security issue here, as the sessions do have a copy of the password, encrypted of course, but still, these file should not stick around.
When I use mysql to save the sessions, every time I enter the wrong password to the list administration, it inserts multiple records to the dada_sessions table. With every time I input a wrong password it seems to increase the number of records that inserts into the table. This cause the logging page to get slower and slower every time.
http://sourceforge.net/tracker/index.php?func=detail&aid=1525557&group_id=13002&atid=113002
... is there, but the feature went away, many moons ago.
http://sourceforge.net/tracker/index.php?func=detail&aid=1539402&group_id=13002&atid=113002
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
and you get redirected to the list page - with no real description of what may have been the problem
The fix in place is to show a simple message on what needs to be done. The message itself is located in the list_page_screen.tmpl file.
http://sourceforge.net/tracker/index.php?func=detail&aid=1534939&group_id=13002&atid=113002
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"
See the NOTES section about this under, List Subscription Errors - When Are The Catched?:
NOTES.pod.html#list_subscription_errors__when_are_the_catched
Similar to the above bug.
http://sourceforge.net/tracker/index.php?func=detail&aid=1533593&group_id=13002&atid=113002
A simple Javascript check woul do wonders in this situation...
http://sourceforge.net/tracker/index.php?func=detail&aid=1533653&group_id=13002&atid=113002
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
A list is closed -
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
... in an outside config file, since it's sort of mysterious how they're added to the list settings file - indeed they are in the DADA::MailingList::Settings module, sort of magically.
They should be explicitly set in the $DEFAULT_LIST_SETTINGS Config.pm variable, just like all the rest of the default settings - perhaps the text itself could be saved in an outside variable, as it's done now, so you if you were tweaking these before, it should work a similar way.
(basically is the workaround)
http://sourceforge.net/tracker/index.php?func=detail&aid=1530017&group_id=13002&atid=113002
... are present.
Or should I say, is in order, but is order of the listshortname (which is useless), instead of the List Name - which is the human readable thingies, and this program is written for humans.
http://sourceforge.net/tracker/index.php?func=detail&aid=1528753&group_id=13002&atid=113002
The "Customize Feature Set" menu item is rather confusing.
When I click on that option, there are unchecked options, for example:
Manage List|Delete this list Manage Subscribers|Options Customize Feature Set
Being unchecked I would assume that means they would not be operational or displayed? Howver, they are both displayed and operational.
http://sourceforge.net/tracker/index.php?func=detail&aid=1527704&group_id=13002&atid=113002
And this is dumb - since the first form will be *broken* and will lead to genereal confusion if someone stumbles upon this.
http://sourceforge.net/tracker/index.php?func=detail&aid=1526615&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1526579&group_id=13002&atid=113002
... per unit of time. That's stupid. Should be at least...well... 1?
http://sourceforge.net/tracker/index.php?func=detail&aid=1526251&group_id=13002&atid=113002
Because it has a named target, instead of something like, "_black"
When $GLOBAL_BLACK_LIST is set to one, and you're using one of the SQL's (which is required for the Global Black List function)
http://sourceforge.net/tracker/index.php?func=detail&aid=1525708&group_id=13002&atid=113002
When you send messages via the the list control panel.
This should really be rectified in the, Send a List Message, Send a List Message -> Advanced and the Send a Webpage, at the very very least.
http://sourceforge.net/tracker/index.php?func=detail&aid=1525671&group_id=13002&atid=113002
you submit the form.
This is because something needs to be in the body of the message, and if both the text and HTML version of the message are blank, you get an error.
http://sourceforge.net/tracker/index.php?func=detail&aid=1523618&group_id=13002&atid=113002
... before actually unsubscribing the email address?
The, "number of subscribers" notice in the email is off by exactly the number of addresses the bounce handler has supposively unsubscribed.
http://sourceforge.net/tracker/index.php?func=detail&aid=1523529&group_id=13002&atid=113002
nd company (%LIST_SETUP_INCLUDE, %LIST_SETUP_OVERRIDES) doesn't work, since the passwords are saved in the actually list-specific settings in an encrypted form.
Attempting to override this, either in the Config.pm or in an outside config file (.dada_config), will lead to unexpected results.
This is neither documented, or discourgaged, or whatever.
I propose the behavior be that placing a password in any of these locations automagically encrypts the password transparently, so the program Does What You Tell It, and a warning is placed stating the dangers of placing such a password in there.
That shoud do it.
(Proposal accepted by the propose...ie)
http://sourceforge.net/tracker/index.php?func=detail&aid=1521008&group_id=13002&atid=113002
...but it still shows the heading, "available lists"
and the signup form to subscribe to a list - which doesn't work.
This should all just be hidden - no?
http://sourceforge.net/tracker/index.php?func=detail&aid=1520969&group_id=13002&atid=113002
Which is worthless. If all the lists are hidden, there should be a text box to enter in a list short name, instead of having to select, "other..."
Kind of small and niggling, but it's there.
Pro Dada is running correctly, but is not configured properly - if you haven't configured the program, please do so now.
Click here for more information.
This happens if you don't set the, "$PROGRAM_URL" or, "$S_PROGRAM_URL", but try to access Dada Mail.
If this information is lacking, it tries to use
CGI.pm's url()
method. Sometimes this fails.
You *may* be able to also use the environmental variable,
$ENV{SCRIPT_URI}
and then, if that's blank, use the CGI->url()
method.
http://sourceforge.net/tracker/index.php?func=detail&aid=1520960&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1520961&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1520957&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1520956&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1520954&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1511088&group_id=13002&atid=113002
See the Magicbook for version 2.10.9 for an updated version of this script.
http://sourceforge.net/tracker/index.php?func=detail&aid=1539645&group_id=13002&atid=113002
subscribe()
etc, not follow
This currently is only an issue if you're using the Flash XML sub/unsub stuff.
http://sourceforge.net/tracker/index.php?func=detail&aid=1535188&group_id=13002&atid=113002
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
There's a line by itself with a space, that makes the next line show as code;
http://sourceforge.net/tracker/index.php?func=detail&aid=1528774&group_id=13002&atid=113002
doesn't exist. All instances of it in documentation should be changed to:
dada_settings_dbtosql.pl.html
http://sourceforge.net/tracker/index.php?func=detail&aid=1527084&group_id=13002&atid=113002
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
(Note: there was an introduction of a white list feature in the alpha versions of 2.10.9 - this has since been removed from 2.10.9 stable.)
Note: yet again! There was integration of some sorts of SpamAssassin into the dada_bridge.pl plugin in the alpha versions. This also has been removed for 2.10.9 stable
Does basically what it says - when checked, your discussion list will work similar to how most traditional discussion lists work. Unchecking this option will make your discussion list work like how Dada Mail discussion lists have worked before.
This option currently is only available if you use either the sendmail command, or the Net::SMTP SMTP engine - this leaves out the Mail::Bulkmail SMTP engine, which I haven't yet figured out how to hack to make it work well with this option.
Sessions are what let's Dada Mail know who's logged into what list. This information was saved in plaintext files, one file per session. There's now an option to save this information in a MySQL, Postrgres of Berkeley DB databased.
See the, $SESSION_DB Config.pm variable; valid values are:
There's a new choice on how to send email - more specifically there's now two ways to send messages via SMTP - the old way is using Mail::Bulkmail - sometimes this method is problematic, so you have a second choice: Net::SMTP. Net::SMTP also supports CRAM-MD5 SASL authentication and even SSL/TSL connections.
More information on how to use this and the differences between the two versions is located in the General FAQ:
faq.pod.html#what_s_the_differences_between_the_two_smtp_engines
We've moved Mystery Girl over to a, "points-based" system. The bounce handler already knew the difference between hard and soft bounces, now it takes that into account when judging when an email address should be removed from a list.
Each type of bounce has a score associated with it and there's a threshold that needs to be hit to have an email address get unsubscribed. Basically, multiple bounces will unsubscribe an email address, instead of just one, "hard" bounce.
More information on this feature is located in the Mystery Girl docs:
http://sourceforge.net/tracker/index.php?func=detail&aid=1495336&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1488538&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1489960&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1483212&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1480009&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1479583&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1476643&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1476639&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1499257&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1516061&group_id=13002&atid=113002
You can now specify an address other than the list owner that test messages are sent to (oft-requested feature!)
A check is in place to stop you from logging into a list, if you're already logged into a different list - the scenario being, you go *back* to your previously logged in admin control panel, make some changes and then realize, as the page refreshed, that you made these changes to the seond list.
http://sourceforge.net/tracker/index.php?func=detail&aid=1468216&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1467932&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1467123&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1467007&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1463806&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1463098&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1462786&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1462630&group_id=13002&atid=113002
* 1455896 2.10.7 - Server Error 500 error in SMTP options page
http://sourceforge.net/tracker/index.php?func=detail&aid=1455896&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1472653&group_id=13002&atid=113002
Available for MySQL and Postgres
Pretty easy to set up, create the table located in dada/extras/SQL/dada_settings.sql - which is:
CREATE TABLE dada_settings ( list text, setting text, value text );
and set the, $SETTINGS_DB_TYPE to MySQL, or Postgres
DB FIle to *SQL migration isn't too hard, see the script, dada_settings_dbtosql.pl in the dada/extras/scripts directory,
Whose instructions are:
Name dada_settings_dbtosql.pl Description Cute name, huh?
Basically, this small script takes the information of a Dada Mail list settings in the DB File and ports it to the MySQL format.
Fairly simple and straightforward.
How to use this script * Backup Everything SQL tables, list files (all of them)
* Create the List Settings SQL table The SQL statement to run should be saved in a file called *dada_settings.sql* which is located in the *dada/extras/SQL* directory of the distribution
* Set $SETTINGS_DB_TYPE to the correct SQL type (MySQL, Postgres) Directions are located in the Config.pm about this, search for, *$SETTINGS_DB_TYPE*
* Fill in %SQL_PARAMS in the Config.pm file Again, directions should be supplied in the Config.pm file.
After the above (do not skip a step) are done, make sure Dada Mail is still running by visiting it in your webbrowser. The program should run as if no lists existed - not to worry! We shall fix that soon enough.
Upload this script into the same directory that you have the *mail.cgi* script in, and run it, either from your web browser, or via the command line.
That should be it.
ps. backup everything.
Archive editor functionality added to the main mail.cgi script - meaning, you don't have to install this plugin separately.
=item * Option to add Subscription form in rss/atom feed entries. (enabled by default)
Located in Manage Archives -> Archive Options
http://sourceforge.net/tracker/index.php?func=detail&aid=1449089&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1446975&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1444644&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1444643&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1439442&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1439436&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1438836&group_id=13002&atid=113002
=item * 1438834 2.10.6 - Invitation Subscribers Never Removed w/SQL backend?
https://sourceforge.net/tracker/index.php?func=detail&aid=1438834&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1437842&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1433140&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1433135&group_id=13002&atid=113002
https://sourceforge.net/tracker/index.php?func=detail&aid=1433133&group_id=13002&atid=113002
Screen caching saves many of the HTML screens Dada Mail displays, so they don't have to be rendered twice! This could mean a serious speed up to the Dada Mail UI. More information:
faq.pod.html#is_there_a_way_to_speed_up_screen_rendering__how_to_use_the_screen_cache_
You can now use the URL Redirects for the confirmation process while also passing a query string to the URL you're redirecting to! This query string holds things like, if the action was successful, the email address used and any errors encountered. Handy!
When enabled, only one confirmation message can be sent out at one time per subscriber, without the subscriber manually requesting (basically, clicking a button) a new subsciption confirmation to be sent. This helps cut down on unneeded message sending and abuse of the subscription confirmation system.
Bugs Fixed:
HTMLArea has been replaced with FCKeditor. HTML WYSIWYG editing is now available for:
RSS feeds are now 2.0, up from .91; Atom feeds are now 1.0, up from .03.
There's a new archive editor in plugin form, called archive_editor.cgi For more information, see:
$ADMIN_MENU - Added entries for extensions (currently commented out)
sub/unsubscription notices is now *on* by default.
New Config.pm variable: %LIST_SETUP_INCLUDE -
Appends %LIST_SETUP_DEFAULTS - useful in outside config files
Manage Copy -> Email Messages - Made changes so you can hit the big read button to revert all your email messages to the default.
The SQL tables for the archives have changed - there is now a different one for MySQL and Postgres. More details in, "NOTES"
added a dada_subscribers_plaintext2sql.pl script in dada/extras/scripts
Changes from 2.10 Beta 2 and 2.10 rc1
The only changes have been bug fixes and code cleanup to beta 2. Changes from 2.10 Beta 1 and 2.10 Beta 2 Main Changes:
Send a List Message and Send a Webpage
Send a List Message and Send a Webpage screens now have a new widget to allow you to, Archive but DO NOT Send a message. This is a stop gap for the missing feature of adding/editing an archive. Messages can also be backdated, so this should provide a way to add in old messages.
Send a Webpage
The Send a Webpage screen now also has an option to just write an HTML document, instead of having to point a URL of where a document may live. The web-based WYSIWYG editor is hooked up to this as well.
Admin: View Archive
The Archive Index screen has been templated out, finally. It's been slightly redesigned - using a table instead of a ordered list to show all the archives available. There's also a new function to, "purge all archive messages". If you have the DB File backend, this will actually delete the archive's db file, which may help if the archive file is completely corrupted.
The individual archive screens now has a link to the publically available version of the archive message and a note saying that the admin view may be different than the view you're seeing there.
There's also a small new feature to allow you to see the source of the message itself (works only with the SQL backend)
Ongoing CSS/Layout Changes
- default CSS file has been simplified and reorganized into meaningful categories, making things easier to find and change
- improved XHTML compliance
- improved structural markup (many things out of table-based layouts for greater CSS-based design control)
- added structural groupings to the templates, following in the footsteps of the CSS Zen Garden <http://csszengarden.com>, for greatly enhanced CSS customization and control. (All new id's and classes are listed in the default CSS file.) Changes from 2.10 Alpha 1 and 2.10 Beta 1
General code cleanup - getting ready for a solid release! New Features
New Discussion List Option:
Send message posters a copy of the message they've sent the discussion list. Bug Fixes for Dada Mail 2.10 Alpha 1
For an up-to-date list, please see the BugTraq New Features Sending Options
Time between batches can now be less than a second. Archiving
Viewing Attachments supported.
Inline Images support.
Security - Archived messages are pruned of javascript exploits before being viewed.
Discussion messages will show a link to the message being replied to.
The Iframe that holds the HTML version of the archived message can now be turned on/off by a per-list setting.
Previous/Next Links corrected.
Styled quoted text (for plaintext messages)
Email addresses in archives are encoded to stop email harvestors. dada_bridge.pl
CC, Bcc Infinite Loop Bug Solved.
Initial moderation supported -
Moderators in Dada Mail: a sublist of email addresses that can also send to an announce-only or discussion list without having to be on the subscription list itself. dada_bounce_handler.pl
unsubscribed message sent to list owner and former subscriber Message Sending
"I'm sure" and "Open in a New Window" checkbox options now available in the, "Send a Webpage" and "Send a List Invitation" screens. List Messages
[list_confirm* tags are, "Correct" HTML Templates
Furious combed through for syntactic correctness and neatness. Should be almost 100% XHTML compliant. Deprecated Items Removed
The %STYLE hash in Config.pm has been completely removed.
checklist()
javascript function removed.
The SASL Authentication wasn't working? For some reason, the username was given twice - it's now given once. Very odd.
I also do a bit of a hack job to counteract SMTP servers that aren't following the spec and completely scoobying Dada Mail
The SASL Test in Manage List -> Sending Options SMTP Options should, in some instances, actually tell you if the logging in was successful, instead of just telling you what happened. (I know - ooohh! and stuff.)
I've changed how certain CPAN modules are being bundled in Dada Mail. If you were having trouble with the following modules: MIME/Base64.pm, MIME::QuotedPrint.pm, Data::Digest, Digest::Base, Data::Dumper - please read, "CPAN Perl modules/conflicts" in the "known issues".
http://sourceforge.net/tracker/index.php?func=detail&aid=1201741&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1201094&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=1200210&group_id=13002&atid=113002
Fix for the optimize_mime_parser subroutine, will stop all those tmp files from accumulating;
Changed the help links URL, and the version to release candidate status.
Added the $HELP_LINKS_URL and applied it.
Removed the "default content type" thing, cause it didn't work that well, and everyone was confused. So it was stupid.
Speling Errors:
s/doesn't exists!/doesn't exist!/g; s/sytems/systems/g; s/boilderplate/boilerplate/g;
Fix for uploaded files not attaching properly when filenames have spaces in them.
Added Path Info shortcuts to the redirect stuff;
Changed the restart mailing at x to NOT work when you have the messages being sent by the cron job - (no current way to save that info in the mail scheduler - doh!)
Docs Added. Lots of Docs added.
You may find that you get tmp files that accumulate in the same directory that you have the mail.cgi in. These files are harmless, but very annoying.
Here's how to fix that.
MIME Parsing Optimized
There are now three ways you can optimize MIME Parsing if you should want to.
The three ways are:
faster
less memory
no tmp files
The default is, 'no tmp files'
See the entry for, $MIME_OPTIMIZE in the Config.pm file.
I also explicitly set the $PROGRAM_USAGE_LOG to write by default.
:: Bug fixes
Removed the double, '//' in the Template path;
Fast List Switcher is now invisible if you only have one list;
Reworded the zap sigs in the advanced archive options to sort of sorround the entire new concept;
The SASL test should now be inline, instead of spawning it's own, no formatted screen.
The missing Date::Format and friends CPAN modules should be included in the Dada Mail perllib by default; Fixed problems dealing with errors regarding the removed, "setup_list" subroutine;
Fixed some sloppy coding regarding all the Path Info stuff;Deleting a list should work again;
Creating a back link should work again;
Typo in dada_bridge.pl regarding the infinite loop test has been fixed.
Dada Mail 2.8.16 alpha is now Dada Mail 2.9 beta 1.
This means:
No more new features. Please, no more.
From now on, only bug fixes/completing features:
From Server 500 errors
to the smallest, "use of uninitialized..." warnings
Picky layout annoyances fixed.
Usuability highlighted.
Things should work, or they will be pulled out.
Basically, anything that would stop the program from shipping.
I foresee many many problems with the archiving viewing of Dada Mail - 500 errors, the whole bit - read on for more changes.
Just to make light on this change log, this is what's *new* in the latest beta, not all the features of Dada Mail. Haha... um hmm...
:: Test Suite Revised.
I added a Email Formatting test -
This *should* allow us to test multipart/alternative message creation, with attachments a little easier, since we'll all be using mostly the same information and the same attachments. I tested to my liking using Hotmail, Yahoo, Gmail and Apple's Mail.app. I attached screenshots.
http://dadamailproject.com/images/testing/testsuite_apple_mail.gif
http://dadamailproject.com/images/testing/testsuite_gmail.gif
http://dadamailproject.com/images/testing/testsuite_hotmail.gif
http://dadamailproject.com/images/testing/testsuite_yahoo.gif
If the test suite message does not work as it does above, I need to know what the mail reader is. Please, for the sake of simplicity, do not apply the list template to outgoing messages. I'll hardwire this in... later...
:: New Features
:: Rewrote the while, "Send an archived message"
Should work now and should be very slick. I'm very happy with it.
:: Fast List Switching!
If you have more than one list, log into one using your Dada Mail Root Password. On the left hand menu, you should have a little pulldown menu to allow you to select another list to switch to. Hitting, "switch" will bring you to the list control panel of the list you selected, seeing the screen you were on at the previous list. It's cool. It'll save you time. It'll help out.
:: Archives
OK, this is going to be long - there's been much work:
First off, there's been support added to save the raw text of an email message that's been sent. In the past, messages were saved in some weird, bastardized version. If, (and only if!) you're using the SQL backend (which I *highly* recommend!) for the archives, Dada will save the raw message for you. Speaking of which, the SQL table schema has changed. It now looks like this:
CREATE TABLE dada_archives ( list varchar(32), archive_id varchar(32), subject text, message text, format text, raw_msg text );
Consult your previously created table and make the appropriate changes - basically, add the new column - pretty painless. If anyone knows how to make this table better (read: faster), please get in touch - I'm not the master of SQL.
I tried doing this with the db_file backend, but, basically, the db_file would get corrupted in mysterious ways. I hit my head on that one for a really long time. I can't figure out if it's the base64 encoded attachments that screw with something, or if it's just the size of the message. Archive Backups are created just fine. Odd.
I also realized that putting this in would break backwards copatibility. So, there you go. Upgrade to the SQL backend, if you can. There's a import script called, "dada_archive_dbtosql.pl" in dada/extras/scripts. Read the instructions. Let me know if it still works *grin*
.: Archive "Blurbs"
I made it easy to show part of an archived message in lots of places in Dada Mail. For example, the default screen will now show a snippet of the last archived message, and a link to view the rest. It's handy.
The list page shows the last ten (by default) archives and a snippet from them. It's just a lot more interesting than a boring list. In a glance, I can get a little better of an idea on what the list is all about.
.: Viewing Archives.
Ok, so there's support added to save the raw email message, I also added a whole heap of support to view this raw message - which means, convert the raw message into something like HTML. Very nontrivial and as cool as my implementation is, it does not support:
*Attachments
Fetching images that are needed in a HTML message that are attached to the message itself
Saying that, Archives should now:
Handsomly show Plain Text Messages - converted to HTML for viewing in a web browser.
Easily show complex - and I mean, Web Page complexity scale complex HTML messsages and sing at the same time. No easy task. The way I solve that problem was to embed an iframe into the archive page, and have the extremely complex HTML message reside in that, instead of trying to embed an HTML message in an HTML message. This doesn't work. If there's stylesheets in the embedded HTML message, it'll be contracted into the host page - things break all over the place. Different web-based mail readers solve this problem differently - a good read -
http://www.alistapart.com/articles/cssemail/
And they all suck. I don't want to use an iframe - but it seemed like the best way to control layout. The body of the message is embedded in the archive page itself - not just in the contents of the iframe - so hopefully that'll be good for search engines.
The iframe idea is also somewhat slow, since two different versions of the email message have to be parsed out. It's also nigh impossible to control the size of the iframe without using some Javascript trickery. Don't know if I want to go that route - maybe?
I need some opinions on that.
Archives should also show multipart/alternative messages easily too, instead of just puking the contents for you to try to read. Sorry about that...
I also added some logic to the archives, so that they parse out the mailing list message templates out of the email message for display. It just looks really weird to get instructions to unsubscribe from an email list you're reading in an archive.
To take full advantage of this, reload your email message templates. This is easily done by logging into your list control panel, navigating to:
Manage Copy -> Email Messages
Clearing all your Email Message Templates and hitting the green button. When the page refreshes, you should have the default templates. Hopefully.
This WILL not retroactively work for already archived messages - sorry;
Here's some changes done:
Mailing List Message Template - PlainText
I goofed. There's a pretty standard signature break symbol thingy, that looks like this:
--
It's officially known as,
newline dash dash space newline
It was in prior versions of Dada Mail,
newline dash dash newline
So that's been fixed.
So that's the signature mark, the place where you message ends, and the signature begins is usually where your unsubscription information starts.
But, in Dada Mail, by default, there's also the little blurb on the top that says that unsub instructions are located at the bottom! What to do about that?
I decided to make something called the, "opening" mark. Yes I know. I'm quite the visionary. Here's the format:
newline underscore underscore space newline
OR: __
Ah ha! Sneaky sneaky!
So, Dada Mail, at least, will look for this line and think that anything before it is a part of the mailing list template, and not really your message. Of course, if you don't use it, everything should be fine. Honestly.
Mailing List Message Template - HTML
So what about the HTML? Sorry, but:
--
looked stupid in HTML, so I made the:
<!--opening--> <!--/opening-->
"opening" comment pair (anything inside is a part of the message template, and not the message) and the:
<!--signature--> <!--/signature-->
"signature" comment pair. Again, completely local to Dada Mail. Use them, reap the benifits; ignore them, life as it was;
From my tests with Spamassassin, these comments aren't flagged as bad things. Which is good!
Again, something you don't need to worry about, but it's there.
.: Email Message Formatter
I've done extensive work on the email formatter for Dada Mail - DADA::App::FormatMessages.
This is new as of a few alphas ago, but it's totally new in Dada Mail Land. Basically, you feed a message you want to send with Dada Mail and it takes care of annoyances, like adding the list template to your message, makes sure that everything that needs to be there, is there, creates the sub/unsub links - things like that. Should produces less code everywhere else.
For example, it now will create a multipart/alternative message for you, if you give it only an HTML message - it'll also wrap the mailing list template around *both* of them correctly. It's really slick. It does more. And it's nothing you have to worry about;
.: Batches Enhancement
Added support for receiving a email batch notification every x batches, instead of every single batch;
Sounds like a silly little feature, but what if you wanted to set batches at... 1 email every 1 second. Without this feature, you'd be deluged with batch notifications. Now you can set batches to be 1 email every 1 second, and get a batch notification every 500 batches. *whew*. Was about 4 new lines of code for both the smtp and sendmail routines. Well worth it.
.: Templates
Take a gander at: /dada/DADA/Template/templates
There's a whole slew of template files... 71 files? 360k of (mostly) HTML? Dada Mail is templated to the max. Have fun playing with them all.
Speaking of which, I went through about... all of the HTML templates and made sure they were pretty strict in formatting, which means they should pass through your local xHTML validator without too much trouble. They're not perfect - they never will be - honestly, but it's darn close.
.: css changes
The default css in the list template is now inline, rather than external:
Pros:
Faster this way one less program call,
Won't be marked as spam by AOL,
Cons:
Stupid.
Sometimes it's smart to be stupid.
.: Breadcrumb Navigation Aids
In many of the list/archive screens of Dada Mail, I've added breadcumb links to help with navigating everything. These screens should be easy and useful to use. Hopefully, that helped!
.: Subscriber Help Screen
I added a link to the default HTML screen confirmation message, it links to a page that looks like this:
http://justinsimoni.com/cgi-bin/dada/mail.cgi/subscriber_help/announce/
Which gives basic support on how to add the list owner to an address book/ whitelist. Why? It's a defensive measure. You want your messages to be delivered. Usually, when you add an address to your addressbook, it really really really makes these changes a whole lot better on very strict systems.
Don't like it? Take off the link.
Oh! and view the source of that screen, all the email addresses mention should be skewed so not to be picked up by spambots! The code is based off of:
http://dadamailproject.com/perl/spam_me_not.pl
Which is in itself a rewrite of a rewrite of this thing:
Thank them.
Anyways, I really really need help in this screen - I need directions to add as many major mail readers as possible, including some big holes like:
Outlook Outlook Express
Please please get back to me with clear, consice directions - I don't have access to these programs, so I'm going blind.
.: Syndication
I added support for Atom feeds.
Atom:
Why did I do this? Basically, I realized: What are the archives? Why, they're a collection of messages, with good, pertinent information, sorted by date. What's a weblog - why, it's very similar! Why not make the archives as similar to a weblog as possible? People are familiar with that interface - let's emulate it, add value to the content you already have! Huzzah! What a great idea!
So, we've got rss *and* atom feeds, we've got ping'ing capabilities, we've got search-engine friendly URL's - we've got some great resources added to your site, everytime you send a list message - it's almost as if the email message is the icing! I'm just really excited about all this...
Here's a real example of the atom feed created by Dada Mail:
http://justinsimoni.com/cgi-bin/dada/mail.cgi/archive_atom/announce/
Neat.
:: Formatting Email Messages
Problem: Mail Filters flag messages created by Dada Mail
And it's not just Dada Mail, but, more than ever, Mail messages need to be made sure they're created very well - which means, very cleanly and strictly. If you have an HTML message, it has to be a full HTML document, not just text formatted using HTML. Weird, I know.
Also, you need to make the HTML message be a part of a multipart/alternative message - which means, there HAS, and I mean, HAS to be a plain text version of your HTML message, For example:
http://spamassassin.apache.org/tests_3_0_x.html
MIME_HTML_ONLY, Message only has text/html MIME parts, scores 1.204 local. That's. Huge.
Luckily, Dada Mail will now look for both of these things, and "correct" them automatically. Another thing you don't have to deal with. Take more time writting a killer email message.
Other things that should be mostly sorted out are;
TO and From always have a, "Real Name" ( From: does not include a real name NO_REAL_NAME 0.124 0.178 0.336 0.007)
Things like that.
.: Path Info, Instead of Query Strings
Many, many many of the Query Strings in Dada Mail - and not only in email messages, use a path info, instead of a query string. Here's a real example:
Query String Version:
http://justinsimoni.com/cgi-bin/dada/mail.cgi?flavor=archive;list=announce;id=20040604025003
Path Info Version:
http://justinsimoni.com/cgi-bin/dada/mail.cgi/archive/announce/20040604025003/
Both of these URLs go to the same screen.
The Path Info version is more compact
The Path Info version is more clear
The Path Info version is way more search-engine-friendly
The Path Info masquerades like it's a directory structure
Another example:
Query String Version:
http://example.com/cgi-bin/dada/mail.cgi?f=n&l=announce&e=justin%40example.com&p=8911234
http://example.com/cgi-bin/dada/mail.cgi/n/announce/justin/example.com/8911234/
Slightly shorter. Nicely shorter.
The email address is also now embedded within the URL, instead of being blatantly encoded in - notice the, %40 in the query string version. %'s in URL's are a big no-no for some services, like AOL. Hopefully, that problem is fixed now;
:: Deprecated
the DADA::App::Guts::open_database subroutine has been completely removed. This will most likely break many plugins/extensions that aren't currently bundled.
dada_send.pl is still removed. Yeah, dada_send.pl
Removed the "HTML_and_text" - Plaintext version is created from HTML in the "Send a List Message" basic screen. This is done automatically for you.
:: Removed - For Now
I had to take the "Resend Archived Message" and, "Edit Archived Message" from the program. I need to rethink how these work...
If you need to do any editing, do so *before* upgrading to this beta. Edit is going to be hard to implement, because a MIME editor is non trivial - like, how exactly do you edit a MIME message created by the "Send a Webpage" screen? Answer: You don't. :)
The resend an archive would be simpler, but you wouldn't get a preview of your message, or be able, (again) to edit the message slightly. Hmm...
I removed support for the, "attached images are part of the HTML message", "feature" - did it ever really work? I rewrote the rest of the sub send_email screen that I left alone - what a mess that was. I simplified the message creation to the bare minumum and added the Email formatting test.
If it passes for most all people, we'll talk about this feature again - it wouldn't be really too hard, but I'm thinking it's useful for about 1 person - and that ain't me...
The following issues were looked at and worked on. A few other issues may have been fixed, but not noted here.
Manage Subscribers / Add brings up an empty screen
Manage subscribers / View / View Options tells you always you have no one subscribed to your list.
Manage Subscribers - Options gives an error about a wrong template, it askes for subscription_options.tmpl iso subscription_options_screen.tmpl
If I go to an archive from a list page I get a syntax error in the bottom part of the page where the subscribe/unsubscribe is supposed to be..
syntax error in <TMPL_*> tag at list_subscribe_form.tmpl : 7. at DADA/perllib/HTML/Template.pm line 2288.
When the discussionlist (dada_bridge) options screen is on , in the right hand upper corner the 'Logged in as root' is not showing, on all other screens it is.
By the way, how do I change this red color, I can't find it in the CSS... ( should be #root_login_msg id )
In the Archived Message : Edit screen, I still think one button should be called 'Clear Changes' and one 'Save Changes'.
Another 'Edit Archived Message' button just doesn't make sense....to me that is...
Also the edit window on this screen is very narrow compared to the screen with the current message below it. (less than half on my screen)
Also on the Customize email messages screen, the memo boxes are very narrow, now we got the space...let's use it !
The new email tag [list_confirm_(un)subscribe_link] is not mentioned in the tag table.
The administration link shows again, due to previous problems (can't recall what exactly) and on your advice we set it at 2:
I also did some work on the CSS, the left menu should look a bit better - I'm still working on some of the admin buttons that appear on the lower left side - a lot of massaging of the sourcecode needs to be done, but that can be done later - write first, optimize later.
I also added a Test Suite to help with squashing bugs; at the moment, there's only a layout test to see what the Stylesheet is doing.
Before I get into this, I want to state that the mail.cgi script has been almost entirely rewritten and the program has seen more work done to it in the last 3 weeks than it has in the last 6 months. This will be a major major release.
:: HTML Template Optimizations.
Optimizations for *most* of the templated out screens. Here's what's going on:
Dada Mail is using something called HTML::Template"
http://search.cpan.org/~samtregar/HTML-Template-2.7/Template.pm
to do the templating tasks for the HTML screens. It does a really really good job. Kudos to the HTML::Template team. Some, not all, the templates use a add on to HTML::Template called HTML::Template::Expr:
http://search.cpan.org/~samtregar/HTML-Template-Expr-0.04/Expr.pm
- it allows you to evaluate statements, and lots of other goodies. The problem is that using it has a speed penalty.
By default, Dada Mail was using HTML::Template::Expr for all of it's HTML templating needs - it should now only use HTML::Template::Expr when absolutely necessary.
:: Email Formatting
Formatting of Email Messages has been completely overhauled. I've been working on a module called, DADA::App::FormatMessages that will, hopefully, handle all the needed formatting of email messages in a centralized space - instead of how it's been working now, where each messge was formatted separately, which is sort of the dumb way of doing things.
Here's some things that this new little wizbang thing handles:
.: MIME messages - as complex as you want -
This means, you can have a multipart/alternative message - a message with both a PlainText and HTML version and have the correct formatting applied to both versions.
.: List Templates Applied Correctly
OK - not to confuse, but there are Email Templates Dada Mail uses - for example, the Mailing List Template, which usually has the unsubscription instructions placed at the bottom; there is also the List Template - which is what's used for HTML screens - what you see in your browser.
Support has been added to apply the List Template over the Mailing List Template correctly. Doesn't sound like a big deal, but here's a scenario:
You Send a Webpage - getting the message information from a URL. The info you get is a complete HTML document. DADA::App::FormatMessages will parse in the Mailing List Template in the *body* of the complete HTML document, instead of wrapping around the entire HTML document like a dumb script would. Pretty slick.
Ok, now say you want to apply the List Template to this Mailing List Message. Here's a problem - both your document and the List Template are full HTML files!
DADA::App::FormatMessages is smart enough to pick out the content of the Mailing List Message and apply it to the List Template, instead of wrapping an HTML document in an HTML document.
:: Template Changes.
By default, List Templates use the Default List Template - meaning, what you see on the default screen of Dada Mail (http://example.com/cgi-bin/dada/mail.cgi)
This option can be changed in Manage Appearance -> Edit Template in the List Control Panel. It can also be changed *back* to using the default, and can also be overrided to only use the default in Config.pm's %LIST_SETUP_OVERRIDES. It's a good thing.
You'll also notice in the Edit Template screen you now have the option to, "Apply the list template to HTML email messages". This means, *all* HTML messages sent by Dada Mail for this list. Pretty slick.
.: Templates: XHTML 1.0 Transitional
I was getting a lot of flack from people around the Intarweb about Dada Mail's reliance on templates that are taking advantage of table-based hacks, circa 1999. It made me feel bad, since people scoffed in their ivory towers, saying,
"Yeah, the guy can sling some dirty Perl code, but he doesn't know the first thing about xHTML/CSS" and this is certainly not true. I've been making xHTML/CSS sites before it was even stylish to do so! *before* Mozilla 1.0!. But Dada Mail didn't get any of that goodness, because it's a really complex program with hundreds of files, and HTML strewn about the place and, and and let's see YOU make such a program, Mr. I coded my weblog in xHTML/CSS based on someone elses template! But in reality, egg was on me, since the HTML shouldn't have been strewn about the place. But who knew Dada Mail was going to be about 10 times the size it was since the 2.0 release? Not I!
The template used for Dada Mail version 2.8.15 is basically the same template that was in version 1.0. The interesting thing is that template was using pretty advanced techniques to get that cool, black hairline border at the time (Queue in, "Back in my day!" jokes...) .
But, things sure do change. So, I refreshed Dada's Templates to use xHTML, with a nice CSS-based layout, got rid of the brown, gave it some red and made the entire layout a little more spacious. Since there's much less code, the interface should come down the pipe a little faster.
.: Need feedback on the following:
* Formatting correctly Does anything look completely wrong? * Usability? Is the new template easier to work with? If not, what needs changing?
Screenshots, HTML/css examples very much appreciated.
If you're wondering how the CSS gets applied to the template, going to a URL like this:
http://example.com/cgi-bin/dada/mail.cgi/css
Will bring you back the CSS needed for the templates. Slick, huh? This should help me not have to embed the CSS in the template files themselves and be able to share most of the CSS between the list and admin templates. This also means you can:
Change *just* the CSS in a format you're comfortable with
Change *just* the xHTML
.: Default List (user) Template and Default Admin Templates are now out of the DADA::Template::HTML module
You can now find both the List Template and Admin Template in the dada/DADA/Template/templates directory, under:
default_list_template.tmpl
and
default_admin_template.tmpl
respectively.
You can find the default css under:
default_css.css
If you'd like to play with that.
There's a file called, "default_js.js" - don't use.
:: More screens templating out.
I've completely lost count of what screens of the mail.cgi are templated out, but it's now, "most". A quick check on that directory tells me it's: 292k in size. Which is a lot.
So, to answer the question, "Why is the HTML in Dada Mail embedded in the code?" The answer is, "It's mostly not."
To answer the question, "I'd like to translate Dada into another language - how do I do that?" The answer is, "Translate the template files, you're 90% there".
To see how much of a size saver it is to template out the files, let's compare past versions of the mail.cgi file:
2.8.15: 280k 2.8.16 alpha 1: 248k 2.8.16 alpha 2: 240k --------------------- 2.8.16 alpha 3: 184k
So, almost 100k slimmer than 2.8.15 - and with all these new whizbang features. I think we're on the right track.
:: New email tags.
The [list_subscribe_link] tag and friends would produce different URLs depending on the context they were used in. For example. If you knew offhand what the email address you were sending from was, this tag would have the full URL to subscribe to the list, including the pin.
This is confusing and really a bad idea, when, for example, you're running a discussion list, where reply's of a message will hold someone's copy of this subscribe/unsubscribe link and send it to other people. These other people have to only click the link to sub/unsub YOU. Which is bad.
So: Here's the change:
[list_subscribe_link], [list_unsubscribe_link] and friends will only have enough information to send a confirmation for subscription/unsubscription. There's a new set of tags called:
[list_confirm_subscribe_link], [list_confirm_unsubscribe_link] (and friends)
Which holds the pin number to sub/unsub you off a list.
The default email messages, located in the Config.pm have been reflected to work with this new system - you may have to manually change your email templates if you're upgrading from an older version. Use the default ones as a guide.
:: RSS Changes.
Ok, this is exciting:
Dada Mail now supports XML/RPC! Basically, when you send out a message that gets archived, Dada Mail will ping sites that support this service to come and check out your changes. This is usually for weblogs and the ilk, but Dada Mail's archives are very similar to entries in a weblog. Why not have services, like Technorati spider Dada Mail created archives, like they do web log archives? Why not indeed! Now, they should be able to, no problem.
Kind of neat.
This option can be turned on under, Archive Options -> Advanced under, "Ping/Notify Site Update Services". The list that's shown can be changed in the Config.pm array, @PING_URLS. When this is turned on, you may notice a slight delay in getting the, "your list message is underway!" screen when sending a list message. This is when Dada Mail is pinging.
If you see this option greyed out, it means you need to install the XMLRPC::Lite CPAN module - it's something I can't bundle in Dada Mail.
:: VERP Support!
VERP stands for, Variable Envelope Return Paths. Here's more information:
http://cr.yp.to/proto/verp.txt
Dada Mail supports encoding VERP, Mystery Girl supports decoding VERP.
This should help in two instances:
It should help Mystery Girl parse bounces, since the email address that was sent to is encoded in the headers it receives. Neat.
This should also help people who are having trouble with AOL not giving them the address that a complaint originated from. This address will now be encoded in the To: header of whoever receives the complaint. Hopefully. If not, it will be encoded in the Return-Path of the headers you receive with the complaint. Neat.
:: New way to send messages (Sort of)
There's a problem sometimes with Webservers killing the sending process of Dada Mail. It's really stinky, because you don't even get a error log report about this, it just sort of, "happens" This is usually not very welcome.
To workaround that, there's a new option in Sending Options -> Advanced entitled, "Schedule List Mailings to be sent by a separate process."
Checking this option will, instead of sending the message right away, save the message as a schedule - the same kind use by Beatitude - marked to be sent *right away*
Near the checkbox to turn this option on, you'll see the, "NOTE:" that states, "Make sure to set the cronjob correctly, or your mailing list messages will never be sent!"
Here's the instructions on how to do that:
If you have Beatitude running, and it's working really well, there's the cronjob set for that, you don't have to do anything else. You're done.
If not, you have to set a cron job that looks something like this:
0,10,20,30,40,50 * * * * /usr/bin/perl /home/myaccount/www/cgi-bin/dada/mail.cgi --run >/dev/null 2>&1
Notice it's the mail.cgi script itself you'll be running.
Most likely, you'll also have to change the mail.cgi's use lib()
statement just like you would for Beatitude:
scheduled_mailings.pl.html#configuration.
Given the above setup, mailing list message will be sent after about a ten minute pause, but the web server won't really have any role in it. As long as your unlimit()
is, "unlimited", I don't see a reason that the sending process would ever get killed.
Note! That scheduled mailings created via Dada Mail will remove themselves once they're done sending. This is normal.
I was going to make a whole, complicated system to queue up messages, and send at appropriate times, but I realized I already had a whole complicated system that sort of does what I need in DADA::MailingList::Schedules
Note! that this option doesn't at all make Beatitude obsolete - you can't edit this schedule, once you've made it, nor, can you view it, set the time - yadda yadda. It's sort of a specific schedule, for a specific task.
:: Send a List Message Screen Changes
There's a new option entitled, "Plain Text - HTML Version will be created"
This will, quite simply, create an HTML Version from a plain text version and send both as a multipart/alternative mailing. Not very exciting, except, since you can now set HTML messages to apply the list template - you can set up Dada Mail for someone who has little or no experience creating HTML, and have them sending out really professional looking messages just by typing in some plain text. Neat. A good fallback for people having trouble installing HTMLArea.
:: Mystery Girl Changes
See, "VERP" above
:: Beatitude Changes
Like most of mail.cgi, Beatitude now formats it's messages using DADA::App::FormatMessages. This took a few hundreds lines out of Beatitude, which is what we were looking for.
I also added a new flag called, "--check_deletions" that should help in checking if messages that are supposed to be deleted, actually were. Add it to your command line and Beatitude will wait 5 seconds, open up a new POP connection and check and see if the messages that were supposed to be deleted were. If they weren't, it'll try once again.
HTMLArea Integration
HTMLArea, a browser-based HTML editor comes with Dada Mail now! Here's how to get it working:
* Upload the htmlarea directory into your public html directory. * Note this location. * Set the Config variable, $HTMLAREA_URL to the URL of where the htmlarea directory is. That's it.
You'll see the HTMLArea inline editor by going to the ``Send a List Message'' screen in the list control panel and clicking, ``Advanced''.
Send a Webpage now applies the Mailing List Template
A long standing bug, we hope that this is now fixed. Please kick the tires and let us know if anything falls off.
Changelog
(I know this is rough, it'll get slicker as the development cycle ramps up)
:: Bug Fixes
Restore List Functionality:
I fixed a race condition where the program was trying to fix a corrupted db file while using the corrupted db file. Naturally, this didn't work. Traced it and squashed it.
s/psuedo/pseudo/g
:: New Features:
State is kept using the CGI::Session module:
http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session.pm
If the prereqs exist. Currently, this means, CGI::Session/Data::Dumper loads up correctly and Perl 5.6.1 If these prereqs aren't there, Dada will use the former system, which isn't half bad.
If you have a plugin that is giving you errors when using this alpha, you may have to tweak them like so:
:: OLD CODE:
use CGI; my $q = new CGI;
my %login = $q->cookie(-name => $LOGIN_COOKIE_NAME); my $admin_list = $login{admin_list} || undef; my $admin_password = $login{admin_password} || undef;
my $root_login = check_list_security(-Admin_List => $admin_list, -Admin_Password => $admin_password, -IP_Address => $ENV{REMOTE_ADDR}, -Function => 'log_viewer');
::NEW CODE:
use CGI; my $q = new CGI;
my ($admin_list, $root_login) = check_list_security(-cgi_obj => $q, -Function => 'log_viewer');
Which is nice, little less code, little more transparency.
All Session/State code has been moved from dada/DADA/App/Guts.pm to dada/DADA/Session.pm, an OO module.
Cookie/Session now expires after 1day.
:: Developer Docs
I've added the list of needed CPAN modules for Dada Mail and my personal ToDo list into the dada/extras/developers directory, just in case you were wondering what I do.
:: GUI
The following screens have been templated out of the main, mail.cgi script:
Delete List Delete List Successful List Options
mail.cgi is now a whole lot slimmer:
2.8.15: 280k 2.8.16 alpha 1: 248k 2.8.15 alpha 2: 240k
All in all, the diff -u file for mail.cgi itself is about 3800 lines long :)
:: Bug Fixes
(as far as I know, these bugs are fixed, if they're not, let me know)
[ 1070637 ] 2.8.15 - dada_bridge.pl contains estranious set lib paths [ 1076411 ] 2.8.15 - archive search producing error [ 1075515 ] 2.8.15 - Help Link URLs are incomplete [ 1095349 ] 2.8.15 - Misc Typos [ 1124419 ] 2.8.15 - Button Styles needs to be removed from the Config [ 1072837 ] 2.8.15 - dada_bounce_handler.pl - line 2140 [ 1087666 ] S_PROGRAM_URL skipped when logging in [ 1070269 ] 2.8.15 - congrats screen encrypted password warning msg [ 1070242 ] 2.8.15 - template directory not found [ 1077969 ] 2.8.15 - Solaris and Exclusive locks [ 1077154 ] 2.8.15 - SQL archives trying to delete archive backups
* programming 500'ing if you send a blank message - fixed.
* Send a Webpage not applying list template - fixed. (archives are most likely still funky)
* s/existance/existence/g
:: New Features
SASL Login Check added in Sending Options -> SMTP Options, (somewhat rough - need feedback)
HTMLArea integration for inline HTML editing - see the Config.pm docs.
Batch and Finished Mailing emails now have:
ETA (in batch completed emails) - not a very good estimate, though. Total time a mailing took copy of mailing list message as an attachment, instead of inline (with code showing)
Gmail/gmail.com added to list stats.
Config.pm variable - $ALTERNATIVE_HTML_TEMPLATE_PATH
MIME::Tools a part of distro - no need to install separately. (need to make a note of this in the docs if it works out)
:: dada_bridge.pl
Reply-To is explicitly set to the sender of a message to a group list if the Reply-To is not set to the list address.
Messages are deleted off the POP server in a separate loop - may relieve problem of messages not being removed properly.
Added flags, --test pop3 --help --verbose to script (see the dada_bridge.pl docs for more information)
pop3 passwords are now encrypted in the list settings using the cipher key - you will have to reset your pop3 passwords for dada_bridge.pl
:: GUI
The following screens have been templated out of the main, mail.cgi script:
Send a List Message Send a List Message (advanced) Send a Webpage View List Sending Options -> SMTP Options Manage Script (About Dada Mail) the Create a New List form (not an easy Admin Javascript
Some of these screens may not be functioning properly because of the migration to the outside templates - need feedback.
mail.cgi is now a whole lot slimmer:
2.8.15: 280k 2.8.16 alpha 1: 248k
Buttons:
button styles that were in the Config.pm, undef, "Artsy Buttons" are now deprecated (need to make note of that in the Config.pm itself!). They have been replaced by the following CSS classes:
$STYLE{default_submit} -> input.plain
$STYLE{green_submit} -> input.processing
$STYLE{red_submit} -> input.cautionary
$STYLE{yellow_submit} -> input.alertive
:: dada_send.pl
Removed completely.
Using 2.8.12b, when viewing the archive web page of a plain text message sent with a URL in it that is surrounded by "<" and ">" characters, the URL is improperly encoded into HTML.
This bug is still unresolved and will be added to, "known issues"
Going to something like: http://example.com/cgi-bin/dada/mail.cgi?flavor=archive_rss&list=example_list *should* give you back a list of archive subjects, with links to their content. It doesn't. Needs to be fixed.
This bug has been fixed.
If you check:
[] Send all e-mails with only the address in the 'To' and 'From' message headers
in Sending Options -> advanced
and attempt to send a list message via sendmail (not SMTP) your mailing will fail. Usually, *one* email will send out, and nothing else.
This bug has been fixed.
(dada_backup.pl issue)
There's two instances of,
my $blksize.
This bug has been fixed. Version of dada_backup.pl will be 1.2
The "If submission for subscription confirmation failed, redirect to this URL:" redirect does not seem to work.
This bug seems to be fixed, but needs more testing.
I have set dada mail up on SSL, so the list control panel operates on https pages. However, when I update the limited number of subscribers under Manage Subscribers - Options I am redirected to http (after clicking 'save subscription options')
This bug should be fixed.
This double opt-in confirmation email was sent to protect the privacy of the owner of this email address. Double opt-in confirmation garuntees that only the owner of an email address can subscribe themselves to this mailing list. garuntees should be spelt guarantees
This bug should be fixed.
If you send a message using Beatitude and have the message picked up form a file or URL, AND have a custom header in the message, it will sometimes not be picked up - most likely the, "Apply the PlainText Email template to this message" option will be checked.
This bug should be fixed.
If any of these issues aren't completely resolved, let us know by ammending the bug report for the particular bug in question.
Pin generation and verification does not take into consideration how email case is handled. For example, if $EMAIL_CASE is set to, lc_all (which it is, by default), ME@EXAMPLE.com should be seen as the same address as: me@example.com. Note the"case"
A confirmation to unsubscribe usingME@EXAMPLE.com will most likely unsubscribe the email address, but the "thanks for subscribing, you're now unsubscribed" email message will /then/ have a subscription url with the upper case version of the email, and the verification will fail.
This bug should be fixed.
This bug should be fixed.
The wordage on the first, "installation successful" screen should be more clearer on how to actually encrypt the Dada Root Password.
This bug should be fixed.
DADA Mail fails to send the Habeas Headers, or rather fails to list the Habeas Headers as a contiguous list in the email headers.
This bug appears only when sending in SMTP mode.
This bug should be fixed.
If a charset in the Content-type header is present, Dada Mail will still tack on another charset value, thus magling the Content-type header. Usually, a charset would only be present if the header was set in a program other than the main mail.cgi script, like dada_send.pl
This bug should be fixed.
This bug should be fixed.
This bug should be fixed.
"Your list mailing will be sent to all your list subscribers, starting at" then doesn't have anything after it.
This bug should be fixed.
When sending a mailing list message, every occurence of 'PIN" will get replaced with the pin number. This only happens in SMTP sending.
This bug should be fixed.
In dada_backup.pl, the extension attempts to wrongly delete the backup directory holding active and setting backups. This is wrong.
(if you have the Magicbook and want to try the fixed version, please contact me)
This bug appears to be fixed, but needs more testing.
When sending an email using the "Send a Web Page" option it no longer includes the unsubscription information at the bottom of the message.
This bug is still unresolved.
The Pop-before-SMTP tester, basically doesn't work correctly. Typing in gobble-dee-gook will come out with a successful status.
This bug seems to be resolved, but needs more testing.
Fixed.
Fixed.
Fixed.
Fixed.
Without any tinkering, Habeas Header support has been put in. Habeas headers can be turned on by going to Sending Options - Advanced
http://sourceforge.net/tracker/index.php?func=detail&aid=860022&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=859713&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=859709&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=859703&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=859213&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=859204&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=857255&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=857240&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=853716&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=853713&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=852953&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=850258&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=849205&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=832466&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=830641&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=830160&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=820557&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=818374&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=818353&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=812866&group_id=13002&atid=113002
http://sourceforge.net/tracker/index.php?func=detail&aid=812865&group_id=13002&atid=113002
The Program has been renamed, "Dada Mail". The following test has also been changed in the program:
For More Information, please see Upgrading Dada Mail from Mojo Mail 2.8.9 and below
You can set the maximum number of allowed subscribers of a list, using the new Subscription Options admin screen. This screen by default is only available when someone log onto a list using the Mojo Root Password. It can also be set in LIST_SETUP_DEFAULTS as use_subscription_quota (use it at all) and subscription_quota (the actual quota) You can set the maximum number of lists allowed to be created by tweaking the $LIST_QUOTA Config.pm variable.
1.56 -> 1.60
IP Addresses are logged in the usage logs, as well as in subscription/unsubscription notices. This is helpful, for instance, if you are dealing with a subscription dispute and need some information on what computer the subscription took place. Most of the common functions dealing with subscription/unsubscription handling can have an URL redirect to any other page you'd like, Making Mojo Mail able to be semi transparent to a tightly designed website. The first index of archived messages can now be had as an RSS feed. The address would be: http://yourmojosite.com/cgi-bin/mojo/mojo.cgi?flavor=archive_rss&list=yourlist This is sort of experimental. If it proves popular, I'll build up this feature.
There's a new Config variable called, $SMTP_CONVERSATION_LOG, which, when set to the absolute path to a file, will keep a log of the converstation between Mojo Mail and the SMTP server. For more information, see: http://search.cpan.org/author/JIMT/Mail-Bulkmail-3.09/Bulkmail/Server.pm The variable will be passed to the CONVERSATION method. Among other things, it states: Be warned: This file is going to get huge. Massively huge. You should only turn this on for debugging purposes and never in a production environment. It will log the first 50 characters of a message sent to the server, and the full server response. I would follow that warning. The problem with SMTP and batching is that the current mechanism (as of 2.8.8) for batching in Mojo Mail destroys the advantage of using SMTP, mainly that only one connection is created per mass mailing. Worse still is that a POP-before-SMTP authentication was done for each message. This problem has been fixed. Using batching with SMTP is now safe and advantageous to do. POP-before-SMTP authentication will take place before any connections to the SMTP server. Batch mailing notices and logging will still function as well. Mojo Mail now has preliminary SASL authentication support. You can set your
SASL login info in Sending Options -> SMTP Settings. You can set the Message Encoding of both HTML and PlainText messages. The default is 8bit. This menu replaces the $PLAIN_TEXT_ENCODING config variable, but allows you to set it on a list-per-list basis, and also allows you to tweak the HTML encoding. fixed. When in the advanced Send a List Message screen, messages were still being archived, even if you've unchecked, "Archive Message". This has been fixed. Email addresses with a .info domain couldn't be deleted via the admin control panel. This has been fixed. The Email Unknown Bounce Type message and subject were being switched, so you'd get the message as the subject, and vice-versa. This has been fixed. .co.uk domains should be seen by Mojo Mail now to be counted in the list stats. Batch mailings sometimes do not get logged in some instances. If the mailing process is killed before the mailing is finished, no logs of batches sent out successfully will be written. This has been fixed by actually closing the logfile everytime a log has been written. MOJO::Logging::Usage now checks to see if the logfile is open and opens it if it isn't. The %COOKIE_PARAMS Config.pm variable will hold paramaters passed to the cookies mojo sets. It's a good place to start if you need to tweak the cookie. I'm removing all lines that have the Additional space has been added to the end of the subscription list screen. fixed. Mojo Mail doesn't mind if there is an error in an outside config file. I find this somewhat of a security problem, since you may be running mojo mail with incorrect settings. This has been fixed and mojo mail will not work if there is an error in an outside config file.
SMTP mailings now explicitly send the Domain of the mailing email to the server when saying HELO. Some people were getting this error: You shouldn't anymore. The SMTP error log wasn't being written into unless whatever file was set in $SMTP_ERROR_LOG_FILE already existed. That seemed a little silly. This is no longer the case. It should create this file for you, if it's not present. You may receive an error if the file isn't there. It also wasn't very clear that you need at least version 5.6 for SMTP mailing to
work now. Warnings are now put in the error log and in the Sending Options screen to politely tell you. Fixed a bad link in the Send A list Message - Advanced...>, the link, labeled, "Basic...", wasn't going anywhere interesting. The Errors-To textfield doesn't explicitly get printed out to tweak, unless you've asked that this header by printed in list messages. This itself is off by default, since this particular header is deprecated. Similarily, the Return-Path textfield doesn't explicitly get printed out to tweak, unless you've asked that this header by printed in list messages. But, you could never have this textfield printed before, so it's a little added feature. But! this as well is turned off, since I've never been able to set the Return-Path header myself, except when using Qmail. The From and Reply-To text fields are now properly escaped. They weren't before and an improperly escaped From addy could mess up deliveries. I was enjoying a brisk read of rfc2369 ( http://www.faqs.org/rfcs/rfc2369.html ) and noticed there really isn't a suggestion to have a List-Software header. Hmm. Bug [ 741691 ] Mojo and spam filters also noted that the lack of an X-Mailer header, coupled with an X-Priority header bangs on .6 points on SpamAssassin's (http://spamassassin.org ) penalty point system. 5 points per email, and the message is tagged as SPAM. So, there is no more List-Software header, but! there is a new X-Mailer header, that will basically hold the same information the List-Software header was. I also tweaked the remaining List- headers to conform with the RFC's suggestions; basically to add brackets around the url's. I'm also ditching the Organization header, since it's fairly useless. Some people were reporting that the "Send a List Message" screen would hang after they submitted the form. This has been fixed by reopening STDIN and STDOUT to a null device, as suggested: There's a new Config variable, $LOGIN_WIDGET. Setting this variable to, 'popup_menu', will change the login form to allow you to select a list you want to log into. This is the default header and isn't very interesting... but! you can set $LOGIN_WIDGET to, "text_box" and instead of a popup menu, you'll just get a plain text box that you'll need to explicitly type in the list short name to. It's a small security step, if you're worried. Some people were reporting that when they confirmed the subscriptions of many email addresses via the admin control panel, they would received weird characters and basic gooble-de-gook. This has been fixed. The problem was that Mojo Mail was trying to upload a file that didn't exist, and you were given a line by line review of a directory, not a file, (since that was nonexistant) MOJO::App::Guts::available_lists knows about the schedules db. Commas in list names were mucking up emails sent, because the From: header wasn't being escaped for commas properly. This should be fixed. Minor CSS tweaks. The Mystery Girl bounce handler has been updated - bug fixes mostly. Bug Fix: [ 750715 ] wrong confirm link when + in e-mail address I added a little message that states, "you need cookies enabled" in the ?f=admin screen, so when people have trouble logging, they can at least self debug the most likely problem.
There was some problems with the clickthrough tracker, clickthroughs would redirect to the
Mojo Mail support page by accident! This has been resolved. Exim support added to the Bounce Handler
They should now convert them to <BR> tags. ( Hat tip: Rod Stephens ) I also decided that conversion of Text to HTML would be something people may want to tweak for their own use, so you can change what options do get passed in the Config.pm hash, %HTMLFROMTEXT_OPTIONS, like so: I also realized that this module hasn't been updated in 3 years, and there's a different, but similar module called, HTML::Text2HTML that I may look into more,
since it has many more options to nerd through. There's now an option to supress the sending of the "Your subscription is successful email", the List Setup key is send_sub_success_email. This should also keep the symmetry between subscription/unsubscriptions options. I also cleaned up the Mailing List Options screen as it was getting unruly with sub, unsub and other options all mixed together. You can now specify showing the oldest and newest archive entries without having to know the actual id number, instead of, say: You can now set a default url that Mojo Mail will redirect to, using the $DEFAULT_SCREEN variable. To tie some things together, say I have a list called, "diary", which I write every week. I could have the default screen of Mojo Mail show the last entry that I sent out in my diary list by setting the the $DEFAULT_SCREEN to: That's pretty sick I think. You can still access the default... default screen by specifying 'default' as the flavor that you type in the address bar: The text in the $FOOTER variable actually gets used for the first time in a year! The $FOOTER text will be added to the subscription confirmation emails only. If you don't like this, consider using the "pro" version, where this information isn't added.
The MOJO::MailingList::Subscribers::baseSQL::print_out_list() method was printing a newline without a defined filehandle. I doubt this affected anything, but it has been fixed. The "Get HTML Code" form didn't "Set" anything in some instances, since there was a minor bug in the javascript. This has been fixed. There was some debug code that has been taken out of the MOJO::MailingList::Subscribers::baseSQL::print_out_list() method and the view_list subroutine in mojo.cgi. The Errors-To mail header isn't printed in any email messages by default. This header has been deprecated for quite some time now. You can still enable this header in Sending Options -> Advanced screen, it's list settings key is print_errors_to_header The Sender mail header is now supported by MOJO::Mail::Send You now have the option of setting the Mail::Bulkmail has been upgraded from 3.05 to 3.09. It's changelog is located here: http://search.cpan.org/src/JIMT/Mail-Bulkmail-3.09/Changes There are a few problems with the "Send a Web Page" feature. First, archived messages of sent webpages aren't very readable, since they're really the MIME encoded body of the email itself. The second issue is that the Mailing List Message template isn't being set correctly, so the unsubscribe footer that's in that template by default isn't being shown. In 2.8.5, the url is fetched twice, once for the actual email, the second time for archving. The second time, the information from the url isn't MIME encoded. Also, for mailing list messages using the "Send a Web Page" feature, the Mailing List Message template won't be used, since it was breaking the format of the MIME encoded email itself. This may be the culprit on why some people would only see the sourcecode itself in their mail reader when sending a webpage. At this moment, it is advised that you should put the sub/unsub links, etc in the webpage itself. Sort of a bandaid, but better than what was happening in the 2.8 series since.
Errors occuring when trying to preview a template, creating a new archived message and when viewing your list in a new
window are fixed. Ugh. The Black List screen wasn't showing correctly if you're backend is one of the SQLs. This was because of an error in the SQL statement itself. This has been fixed. "Mailing Sent" messages can be sent, even when batching ins't enabled. This will work for SMTP mailings as well.
Some pesky CGI subroutines were still not converted to CGI method calls. This affected the "Add Subscribers" control panel, and the "Create a new List" control panel.
Security Fix - There was an issue when setting the "REFERER_CHECK to '1' in 2.8 and 2.8.1. Doing so would actually circumvent mojo's security when logging into a list control panel. Bad news. This has been fixed, although setting it
seems to break logging into Mojo Mail using a Mozilla-based browser. Please note. I've done some more work on cookies being set correctly. Another, slightly related problem is with HTML forms in Mojo Mail, which seemed to NOT get auto-escaped, as the CGI.pm docs said they would be. I thought this was some sort of odd condition with setting the charset, but it isn't. The way I fixed the form values not being auto-escaping is by changing every subroutine call to CGI.pm subroutines to method calls. For some odd reason, I think mixing the two styles is a bad idea. I "fixed" the cookie problems by setting a throwaway cookie before the cookie I really want set. For some reason, CGI.pm wasn't writing the cookie value correctly. mojo_send.pl has be recommitted because insanity in the community. The version provided in this distro should also work for version 2.8 and 2.8.1. I found that if you have a list name that has a double qote (") in the name itself, mail using this address may not always be sent, since the To: header wouldn't be formatted correctly. I've fixed this problem, and if you had problems with receiving subscription notices, password emails, etc, a funky email address may be why.
mojo_send.pl was taken out of the distribution. A note was put in its place
to kindly tell people the.. obvious. Bug Fixes Editing Email Messages via the list control panel sometimes causes an Internal Server Error.
This should be fixed. Some users have been complaining that it is impossible to actually log into the list
control panel. After the password information is entered into Mojo, the user is now
refreshed into the list control panel, instead of being redirected. This was suggested by
an anonymous user. Thanks anonymous user, (whoever... you, are). There was a formatting error in the "Advanced Sent a List Message" page. Apparently,
version 2.91 of CGI.pm doesn't autoescape double quotes. The %SQL_PARAMS hash in MOJO::Config looks like this: The addition of the needed 'subscriber_table' key, and a little help on how to set
the 'db_type' value. Debug code dealing with [redirect] tags has been taken off. Content-type header tags were, in some instances, NOT printed. This has been fixed. You don't have to explicitly set the $S_MOJO_URL if you use an outside config file now. setting $LIST_IN_ORDER to "1" should do as advertised with Plain Text Lists. It's
still HIGHLY (bolded, underlined) recommended that you not set $LIST_IN_ORDER to "1"
if you're using a Plain Text list.
$LOGIN_COOKIE_NAME holds the name of the cookie for Mojo Mail. This can be changed
to stop mucking up other web apps that use cookies. (set to 'mojologin' by default)
I added: To the %LIST_SETUP_DEFAULTS config hash. Why? Well, hard_remove deals with how subscribers are unsubscribed in the SQL backends, it means, delte the row. A "soft" remove just sets the list_status to "0". In 2.7.2, all removes were soft, and this is wrong. The worst thing about this is that every new subscription is checked to see if there is already a row for this subscriber. This can take a lot of time and really ruined much of the pepiness of the SQL backends. This can be set in 2.7.2 for a huge speed gain. This lead to another bug, where I've added a few more CPAN modules, because, what the hey. I'm going to ship with HTML::Template, just because this is what's going to be there for the future of Mojo, and I might as well know I have it handy, if I ever make an extension or plugin that uses it. Did a bit more work on the View List Screen. It's now possible to set how many
subscribers you see per screen (default is 100) bug fix $LIST_IN_ORDER should actually have some sort of affect for the SQL backends, hurra! I'm thinking of making a generic SQL module that both MySQL and
Postgres base themselves upon. That would stop a lot of the same code in each module. I think the only discrepency right now is the different way MySQL and Postgress automatically make unique ids.
I'm beefing up the "Send this archive to a friend" feature. although not used
that much, it ain't that good to be used. Once finished, a multipart/alternative email will be created using the archived message, a plain text version will be made if the original is HTML, and vice versa. I'm going to be playing with the HTML::FromText CPAN module, which should make a HTML version from a plain text
source fairly well. If it works out well, I'll do the same for archived plaintext messages, when they're viewed via a browser, and have this an option (plain text to HTML) in the basic, "Send a List Message" screen and who knows what else. I think Plaintext to HTML could be used in a million places. Much work has been done to the "Send this archive to a friend" link. To start, it's no longer a link to a awfully rendered popup window. The form is in the page itself. Secondly, email addresses are actually checked for validity before sending. I know, like, why weren't the before? Thirdly, instead of just stripping out the HTML tags and sending a plain text message, a plain text message is created and both HTML and plain text versions are created and sent via a multipart/alternative message. A HTML version of the message will be created if the archived message is in plain text. A referer check is also done before sending, something that was lacking in the original implementation. This should be seen as a major security hole. If you are using a version of Mojo Mail that is 2.7.2 or below, please do not use the "send this archived message" link feature. It is off by default. new feature: The send an archive message can now be edited and customized via the control panel, under "Manage Copy->Email Messages". Along the same line, There is now a "Resend an archived message" button when you browse the list's archives via the admin control panel. Pushing this button will take you to the Advanced "Send a List Message" screen with the appropriate fields already filled in. Because the entire message is NOT saved in the archive, things like attachements won't be automatically added. bug fix: When using a SQL backend and SMTP sending, tmp subscription list files, created when you send a mass email, are never deleted. This should be fixed. bug fix: When using an SQL backend, invitation entries were never removed, and subscribed addresses would receive the invitation again and again. This has been fixed. new feature: List Invitation message bodies and the subject are now saved for future invitation messages. bug fix: When using SMTP sending and asking for a new list password to be sent to the list owner, Mojo will still send the request email using whatever path to sendmail is set via $MAILPROG. This is because the list settings, which the SMTP info is included, is never passed to the I'm currently rewriting the "View your Subscribers" screens, as they're really not that helpful in.. viewing your list if you have more than say, 100 subscribers. The reason being, the list is in a scrolling list widget and... that's it. You can't select anything in that list and do anything with it. So, I'm currently creating an interface with just a list of the subscribers. If you click an address, you'll get a screen where you can either remove the address or edit that address. Should be much more handier. I've finished working in the "View Subscribers" screen for the time being. I've integrated much of what was on the old "View Subscribers" page, except the domain stats. It's much more useful, to say this least, and adds much legroom for multiple fields. new feature: Subscription/unsubscription notices now tell you how many subscribers are actually on your list in each mailing. Handy.
Did some house cleaning. All modules fetched from CPAN are now in a directory called "perllib",
which you can move somewhere at your descretion installed manually at your discretion via the CPAN shell or whatnot. Worked on which MIME Type is figured out when you attach a file in the Sending Options->Advanced screen. People were asking q's about it with unexpected results and I figured it was pretty stupid to keep adding to the %MIME_TYPES hash everytime you have some sort of odd file to send. So, I did some research on MIME::Types and MIME::Type, realized that they were already included with Mojo Mail - for MIME::Lite! that actually finds MIME::Types for attachments automatically... but! Mojo Mail is shipped by default to not do these checks. Yeah, talk about retarded. So, now Mojo will see if the correct version of MIMEL::Types is available, if not, it'll try to do the MIME Type association by itself. If nothing turns out, the task is passed to MIME::Lite. The Send a Webpage screen has been supercharged. Instead of just putting a base href tag on the top of the page, you can now actually embed the images, and link external CSS files, or just change all the relative URLS to absolute(which doesn't work yet). With that, you can also specify a username/password to access "protected" directories, which makes sense I guess. You can now set a default charset for the majority of HTML screens, using the $HTML_CHARSET Config.pm varible. This is a nice, small step towards better internationalization. SMALL, small step. I had some drowsy thinking last night that the Guts.pm package has to go.
The name is cute yes, but the insides are just awful. So I have dubbed: MOJO::MailingList::Settings Which, at the moment, has 2 public methods, In doing this, I've created a bug, since setup_list, actually /was/ for setting up lists, but... it also used to save settings. This will be dealt easily, once there's a object or something that will allow you to create a list, since now you can only access lists that are created. MOJO::MailingList::Settings won't let you try to access an undefined list - which is a good thing. Mail::Bulkmail is now at version 3.02, it was 3.00 3 days ago. I may wait a little while for that module to mature before I put it in Mojo Mail. I've rearranged the library structure some more: I hope it makes sense why I actually did this. In MojoMaiLand, A Mailing List has subscribers, an archive and settings... so why isn't this reflected in the code structure? There's also a baby module, called MailingList.pm, which in the near future, you'll be able to use to do anything that has to do with a list. In theory, you'll soon say: Instead of the Usually OO'd, module calls now. The problem is, no OO module in Mojo Mail has a "has a" relationship. Nothing really has a "is a" relationship either. I could see different kinds of logs have a isa relationship soon. MOJO::MailingList does have a I'd like to also make a MOJO::Mail::CreateMessage module, perhaps inheriting MIME::Lite methods directly. I'm slowing bolting Mail::Bulkmail onto Mojo Mail. There seems to be some bugs still lurking in that module, but including this module will be a great benifit I hope :) Mail::Bulkmail has been upgraded to 3.0.4 because of a bug I called in.. and again to 3.0.5.
Black lists should be working for everyone again. Bulk Mailing Precedences can now, um, NOT be set. The can also be successfully default in %LIST_SETUP_DEFAULTS The From: header in all messages sent are now escaped when the have double quotes in them. A bug has been sent to the maintainer of Mail::Tools about this. The newest version of Mail::Address has been put into Mojo Mail. A simple check has been placed on the Advanced Mail Settings "add the -f flag" setting. If the effective uid isn't the same as the reail uid, an warning is presented.
Lists in the popup menus and on the default page are now in alphabetical order (an amazing world we live in today) - this is a sorta bug - fixed. calling Guts::open_database with a list name that doesn't exist creates a blank db with nothing in it. I couldn't believe there wasn't a check to see if the db being called actually exists. It does now. many instanced where "use of uninitialized errors" warnings where plugged Amazingly enough, I'm having good luck running Mojo Mail with the '-T' flag, I don't really know why! :)
email, pin, list and flavor params given to Mojo Mail are filter to prevent XSS. Messages were getting archived even when archiving was turned off - fixed. When creating a new list and an error was encountered when filling out the form, the user was redirected to the default page - fixed. there was a bug in the add_to_email list function in MOJO::MailingList::Subscribers::PostgreSQL that would come up if you tried to subscribe to a list. This has been fixed. This bug would only affect people using PostGres as their backend. POP3 passwords are now Cipher encrypted in the list settings database. YOU WILL NEED TO RECONFIGURE THE POP3 PASSWORD IF YOU USE POP-BEFORE-SMTP AUTHENTICATION. The program setup check has been fixed, it should now come up if the program wasn't setup correctly. Furthermmore, more information about the setup can be viewed, with hints on what, if anything, is wrong. ( $MOJO_URL?f=setup_info ) Funnily enough, if you didn't setup the $MOJO_RUL variable correctly, you won't be able to see any of the setup info. Cipher keys can be reset for all lists. ($MOJO_URL?f=reset_cipher_keys) For security and functional reasons, this line: in mojo.cgi has been commented out. DNS lookups would return a Software Error, even when the DNS lookup succeeded. It is still suggested that if you have problems configuring the script that you uncomment this line FOR TESTING PURPOSES and then, comment it again.
small formatting bug fixed in "need_to_login" error screen password changes are now confirmed when a new password has to be sent out to the list owner. passwords saved in the browser's cookie are now encrypted much stronger using CipherSaber encryption The Return-Path Header Can now be set on a list basis.
Lots of things. Too many to remember.
There's a new module, called MOJO::Template::Widgets for making widgets. All it has now
is a subroutine called Test messages were being archived in some instances. no more! The SMTP option sometimes couldn't be set. No more! Some HTML Sybtax errors have been fixed.
Some email messages were being sent blank. No more! There's a new variable in the Config.pm file called: $DEFAULT_ADMIN_SCREEN set to: $MOJO_URL.'?flavor=send_email'; perhaps you can figure out what it does.
Tweaked the MOJO::Guts::check_setup() sub to warn if people try to
use MOJO on NT, the check is disabled for NT folk. There was a report that if the root password is left blank or is
commented out in the Config.pm file, you can log into ANY list using a
blank password. The documentation specifically says that if the root password
is left blank, this password is disabled. This should now be the case. The outside config file-getter, MOJO::Config::_config_import was making use of the
getpwuid Perl function, which isn't supported in a WinNT environment. There is
now a check to see if the script is infact in a WinNT environment and only uses this
function if it isn't.
I removed the submit button on the "Add Subscribers" screen.
it's back. I'm the absent-minded professor.
Added a file upload form to Tweaked how Config.pm imports an outside config file. the [subscriber_email] should work now. print_out_list List::* wasn't allowing you to pass the filehandles for any of the
SQL's added a new method in MOJO::MailingList::Subscribers in MIME::Lite, set both $PARANOID and $QUIET to '1' in hopes that errors it's throwing will stop, even though they shouldn't be throwin' the errors. fingers crossed. exists does work correctly on some of the DB File formats. took one instance of 'exists' out
and changed it to defined, which should be alright $SMTP_ADDRESS is really just a default setting, each list can issue it's own
SMTP server to use, changed the code to reflect this idea. This was a little
whacky in Mail.pm where it would look at the $SMTP_ADDRESS variable instead of
$self->{list_info}->{smtp_server} which does get set to $SMTP_ADDRESS by default. turned off the
Added a filter in MOJO::Mail::Send::clean_headers to change CC headers into Cc headers tweaked mojo_send.pl to look at the Cc header instead of CC 'mail_group_message_to_poster' and 'add_reply_to' checkboxes should 'stick' or 'unstick' now in mojo.cgi::mojo_send_options() The Config.pm file now checks a an absolute path instead of a file handle to see if there's a
outside config file. you are using an outside config file, aren't you? Added documentation for the multiple_subscribe mini script The Config.pm.pdf link should be fixed in the docs added the following mime thingies to the Config.pm file:
typo in $NOT_ALLOWED_TO_POST_MESSAGE corrected cookies are set with a path of '/' since some servers where actually setting the wrong path line 129 in mojo_send.pl was missing 'new' Guts::check_for_double_email should obey whatever $Config::EMAIL_CASE is set to.
fixed a bug in mojo_send.pl in the 425: To => $From_address, changed to: 425: To => $From_address->address, a few other places like this were changed as well. added a Mojofied FormMail script to the distro. fixed a bug in mojo_stats.pl pertaining to the
Added a sample FLA subscription form as an example on how to use Mojo Mail using
Flash. Added a test to see if Mojo is set up correctly when Mail::BulkMail mergeing was clobbered... fixed. MIME_HUSH is actually implemented! (wow!) There is PDF version of the Config.pm docs... Just because I have a Mac and
I can. Stylesheet applied to docs More docs written Southpark == funny tonight in mojo_send.pl, fixed $To_address->address to read @To_addresses at: 327: $mh-> in Mail.pm, the List-Headers should work correctly again. lists were getting escaped twice when making subscription/unsubscription links
- this has been fixed black lists were only working for the first black listing, this only seems
to have problems with PlainText.pm, this has been fixed. new list passwords were NOT being created when a list owner asks for a new one, something got
clobbered, this is fixed. the list's shortname was used in a whole bunch of places where the list_name should have been used. This has been fixed. the functions, I don't know why I created this, but the Admin Control Panel is now, (get this) plugin-able You can now, with just a bit of moxy, roll your own Admin Control Panel Screen to do
just, about, anything. There are two examples in mojo/scripting_examples/admin_plugins/ One is useless,
but gives you a good overview on how this all works, the other one allows you to all your list settings
This is fantastic, cause now more specific features can be created, without bogging down the
piggy mojo.cgi script. This is a good thing. I wonder if anyone will make any... I'm using sort of a 'make me a distro' script to automate the process of making ... a distro. working good. perhaps I'll make an installation one too! The distro shouldn't have those annoying '.DS_Store' files, thanks to the new
make_distro thing I made The Config.pm is now set up to read from a outside config file, so people don't have to redo the Config.pm file everytime they want to upgrade. yes. you are welcome. it's set to read the config file at $ENV{DOCUMENT_ROOT}/mojo_config if you need to change that, change it in the Config.pm file, I suggest your home directory and then .mojo_config I have to do some research on how you find a home directory via a CGI script. Any help == welcome this file can have any $variables, @arrays or %hashes that are in the Config.pm file except things that are between BEGIN {} brackets. Those cannot be changed after runtime, sorry. the config file can be as simple as: added the '$TMP' variable to the Config.pm file for temporary file... stuff. The Config.pm comments have been converted into pod so I don't have to write two different versions of the same things There's a new variable in the Config.pm file, called $PLAIN_TEXT_ENCODING which has been set to 8bit by default. added the '%LIST_SETUP_OVERRIDES' hash to the Config.pm to override any set list pref. added the 'mail_group_message_to_poster' setting um, you should be able to set add_sendmail_f_flag via "Sending Options : Advanced..." for real now cleanup of mojo_send.pl a bit mojo_send.pl should now recognize if you send to a list using the CC: header List::MySQL now has Unix Line Endings MIME::Type.pm and MIME::Types.pm have been added to the distro in mojo.cgi, in the in Mail.pm the do_not_send_to method should work added the 'add_sendmail_f_flag' pref to allow you to add the -f flag to the
$MAIL_SETTINGS variable in sendmail sending MOJO::Mail::Send::clean_headers takes off extra newlines from the ends of mail headers pray that fixes that mojo_send.pl send problem More cleanups, All Config variables are in UPPERCASE all modules now are in MixedCase, CONFIG.pm is now Config.pm new methods in MAIL.pm these take the place of similar-named headers, which really didn't make much
sense anyways $mh-> MAIL.pm usage of: has been replaced with: same with: new function in MAIL.pm: _make_list_headers this function creates the following headers: which means, you don't have to set these anywhere else. This really cleans up some
messes in mojo.cgi new function in MAIL.pm: _make_general_headers which (at the moment) makes default headers for: and also makes sure they're escaped as in accordance to some hard to read RFC, i'm sure I'm beginning to put defaults for list stuff in the CONFIG.pm file (what a concept)
instead of just peppered everywhere, looks like this right now: this can really clean up the MIME::Lite has been upgraded to 2.117 Mail::Address has been upgraded to 1.43 Mail::Bulkmail is still at 2.05 on CPAN, the version of Mail::Bulkmail in the mojo distro
has 2 bug fixes that aren't available in the CPAN version (crazy, eh?) There is now a MySQL module in the distro. The PostGreSQL schema works for this module In mojo_send.pl, you can now turn on and off the Reply-To header, weee added documentation for the bounce handler took off all Return-Path headers in mojo.cgi and mojo_send.pl cause
they're useless (i think) all Error-To: headers are set to the admin_email in mojo_send.pl, the 'To: is the same as the From:' check is now case insensitive, as is the test to
see if a message is being sent out by either the admin or list owner in mojo_send.pl now used the new for group mailings, mojo_send.pl does not leave a trail of Re: Re: Re:'s (and there was much rejoicing) it also looks for AW: I added instructions for sendmail in the mojo_send.pl pod $file_chmod works now as advertised! (and there was much rejoicing) the List Information screen now shows the list's short name, which is WHAT YOU WANT TO USE FOR mojo_send.pl new function in MAIL.pm, Hopefully, this will take some more heft out of the main new sub, sub Some of the Net Modules will be bundled in the download the MAIL object can now have stuff passed to it, like this: my $mh = MOJO::Mail::Send-> new function in MAIL.pm, I'm trying to slim down the a new function, called _email_batch_notification has been created to move the
email batch notification stuff out of the ditto with ditto with ditto with #lines of still too too many lines... added a new variable to CONFIG.pm, '$mime_hush' to try and quiet down MIME::Lite, calls the MIME::Lite-> plain text messages with no attachments are now sent as 'quoted-printable' instead of binary(?) CONFIG.pm tweaks, $LOG{mailings} is now defaulted to 0, $list_in_order is defaulted to 0 new function, two new functions in Guts.pm, updates for this period have not been recorded, but they are many. yes, i'm lazy.
Mailing your lost password works again! yes yes yes, I have no no no idea what was going on. also, having the passwords saved as rot13 encrypted didn't go over when you wanted to allow the root password to log into lists,
but this is now fixed. Thanks everyone who yelled at me. I started making a the list subscribe url a bit smaller, without totally
changing the way I do things, I just truncate what the variables are called,
and see if those are passed, or their longer cousins: Long Version: Short Version: http://dev.skazat.com/cgi-bin/mojo/mojo.cgi?f=u&l=big_list&e=justin@example.com&p=1234 seems to make a noticable difference, although my example is still over 70
characters long, This is a cutoff point, at least for terminals. I added a lock file for unsubscriptions to the list. A lock file will
stop anyone trying to unsubscribe from a list while someone else is doing
the same thing a bit before. People are having lists wiped out, and I think
there is a race condition in the Create a lock file that will stop anyone from doing what's in between
opening this file, and closing this file. open the list
open a temp list copy over all addresses in the list into the temp list,
unless we don't want them anymore close both lists ####################### open the temp list,
open the list copy what's in the temp list to the real list. close the lock file. If this subroutine is busy, the script will sleep one second, for ten times
while waiting for the lock to clear. it gives up after that, and returns 'too busy' -
I also added another user_error error that prints that the server is too busy. The unsubscribe feature for the admin side was broken. easy fix, forgot to tell
it what list to do the axes in. I'm also changing the fiule structure a bit to be more unix-centric, all files will be in the
mojo directory, like the mojo_extras directory. Tweaked the POD docs in all the modules. wee. I also added the '$mime_paranoid' variable to the CONFIG.pm file to be used
with the $MIME::Lite::PARANOID variable in MIME::Lite. From the docs of MIME::Lite: That means you don't need the MIME::Base64/MIME::QuotedPrint modules no mo. I also added the $NPH variable to CONFIG.pm, specifically for Windows servers.
It seems that cookies aren't set or sent back correctly to M$ IIS without no parse
headers turned on. This is done by setting $NPH to one. The only place I'm using this
is in the well,
if you hadn't noticed, there are a *few* examples of mojo helper scripts, check check it also, added a new 'list invite' feature. Also, changes made to modules are logged in the modules that are changed, in POD format. I've been working on the port of mojo to NT, I want to keep only one version of the script if possible. I changed all code that's similar to this: to this: I also added the nph' flag for the redirect when the cooie is being passed to the script, like this: This seemed to make M$ IIS happier. fixed a problem with the archives, the back link on the archive indexes
was fumbled in some circmstances, in Archive.pm, what used to read which will give you what you want. and I feel cool. spelling errors, little things, getting ready to release mojo mail 2.4.7 stable totally redid how Mojo Mail deletes emails. we'll see of it works :) general code cleanup, Change/Tweak log, for Mojo Mail, 2.4.6 beta fixed a few instances wher i was checking the value of something, and if
it wasn't true, would give it a default value. The prolem was, I tried to
do this testing for 0 as a valid value and my way went capoot. something like: The abovecode would always say 'something else" egg on my face. this fixed a funky bug on the main page people were having (hopefully it fixed it) I also changed how attachments worked in the control panel,
There are two ways they can be done, and I'm keeping it that way, since ones
bound to not work for some people, and vice versa. I also added some CONFIG.pm things
to customize file attachments: $default_mime_type = 'text/plain'; rewrote the ENTIRE um, its got more functionality that's for sure. Its actually fuckin awesome.
it now has two modes, 'Basic' and 'advanced', Basic is pretty much the same as what its been, advanced is a whole nother cookie. In advanced, you're allowed to reset the 'From', 'Reply-To' and 'Errors-To' to your
fancy, you can also set the precedence and priority. I also added attachment support
for as many attachments as you think your little MTA can handle. And finally I addd the feature of creating a seperate version of your mailing in
Text and/or HTML. You can also say if you want this message to be archived or
not from the send a list message form. That's alot of stuff. With that, i also snuck in support for X-Priority header in MOJO::Mail::Send.pm
and also added a select box to Sending Options -> Advanced for a Default
Priority. In group options, I made it a decision to add the [group name] to the beginning of
the header, since someone is bound to ask me how to turn that off. I've also been playing around with the idea of usgin CGI.pm to make my checkboxes
in the control panel It's a whole lot cleaner that what I've been doing, if its less code, I don't know, but
it looks cool, and that's what counts :) I have never used the EXP ? true : or_this thingy before,
I'd like to report that it works! :) I added a new function in Guts.pm, called kinda makes a string of plain text readable in a browser, cute name eh? There was also a bug in the MAIL::Bulkmail module, concerning the date, the fix is: "Go to line 714, this is it: Change it to this: You're just changing the "$hour - $ghour" to
"$diffhour" and that's it. Bug repaired, and even
done correctly this time." I changed that in the version I bundle, and am anxiously awaiting the arrival of the new
Mail::Bulkmail :) I added some documentation on tweaking the mojo.cgi script itself,
check it out. fixed a small bug in a screen like this:
http://dadamailproject.com/cgi-bin/mojo/mojo.cgi?flavor=subscribe&list=mojo_mailers where the flavor is set to 'subscribe', there is a list that is real, but there
is no email address or pin. The source just ddin't have two hidden HTML field tags: <input type=hidden name=flavor value=subscribe>
<input type=hidden name=list value=$list> fixed a bug dealing with the archives, some people were having trouble deleting
archived messages, all I had to do was reset the $| variable where the delete
function was called... really weird. fixed a bug in mojo_send.pl when you try to send email to a list that
doesn't exist. I noticed that it would email the person trying to send to that
list saying 'hey, its not there' and then do it again, and again and... the problem was that after it sent the error, it would write a warning using
the fix was just to put in mojo_send.pl
2.8.10 beta 2
New Features
Updated CPAN Perl Modules
2.8.10 beta 1
2.8.9
alarm()
call in them, since it's useless; Mojo Mail isn't run interactively.2.8.8
MBS010 - can't greet server w/o domain
http://www.perldoc.com/perl5.8.0/pod/func/fork.html
2.8.7
2.8.6
%HTMLFROMTEXT_OPTIONS = (
urls => 1,
email => 1,
paras => 1,
bold => 1,
underline => 1,
lines => 1
) unless keys %HTMLFROMTEXT_OPTIONS;
http://ms.com/cgi-bin/mojo/mojo.cgi?f=archive&l=justin&id=1234
You can say:
http://ms.com/cgi-bin/mojo/mojo.cgi?f=archive&l=justin&id=newest
or,
http://ms.com/cgi-bin/mojo/mojo.cgi?f=archive&l=justin&id=oldest
=item * $DEFAULT_SCREEN
$DEFAULT_SCREEN = 'http://mysite.com/cgi-bin/mojo/mojo.cgi?f=archive&l=archive&id=newest';
http://ms.com/cgi-bin/mojo/mojo.cgi?f=default
2.8.5
Sender()
method in Mail::Bulkmail. This will set the Sender: and Return-Path header in email messages to the admin_email address. From the Mail::Bulkmail docs:
Stores the Sender address of this mailing. Must be a valid
email address, unless Trusting is set. Really really should
be a valid email address anyway.
Sender is mainly used when speaking SMTP to the server,
specifically in the RCPT TO command. The spec defines
"Sender" as "he who send the message" (paraphrasing), which
may not actually be who the message is from. 2.00 used the
From address as the Sender.
You should specify this, but if you don't then the From value
is assumed to be the sender.
$bulk->Sender('jim@jimandkoka.com');
print $bulk->Sender;
If this value is not set, then Mail::Bulkmail will place a
Sender header equal to the From value.
Note that the ultimate receiving SMTP server is expected to
place a Return-Path header in the message. This Return-Path
value will be set to the value of the sender of the message,
either ->Sender or ->From. This, in turn, will be the address
that bounce backs go to. You should not set a Return-Path
header yourself, because bad things will result.
(hat tip: Finn Smith)
2.8.4
2.8.3
2.8.2
2.8.1
%SQL_PARAMS = (
database => '',
dbserver => '',
port => '',
dbtype => '', # 'mysql' for 'MySQL', 'Pg' for 'PostgreSQL'
user => '',
pass => '',
subscriber_table => 'mojo_subscribers',
) unless keys %SQL_PARAMS;
2.8 BETA 1
2.7.3 alpha3
hard_remove => 1,
new_id()
was being called in the SQL backends. Before 2.7 I believe, unique ids were created by hand for each of the subscription entries. This is a bad because two rows will eventually get the same id, if they're subscribed at the same time. The fix for this is to let the database itself do this step. The problem with that approach is that MySQL and Postgres do it differently; MySQL uses "auto increment".. thingy, while Postgres uses the "serial" field type. This little muckup has been fixed.2.7.3 alpha2
new()
constructor. This has been fixed.2.7.3 alpha
get()
and save()
. This replaces MOJO::Guts::open_database() and MOJO::Guts::setup_list() which are so awfully named, it's a wonder I haven't done this before.
Moved: To:
--------------------------------------------------
MOJO::Archive MOJO::List::Archives
MOJO::Error MOJO::App::Error
MOJO::Guts MOJO::App::Guts
MOJO::HTML MOJO::Template::HTML
MOJO::Licenses MOJO::App::Licenses
MOJO::List MOJO::MailList::Subscribers
MOJO::Log MOJO::Logging::Usage
MOJO::Log::ClickThrough MOJO::Logging::ClickThrough
MOJO::Mail MOJO::Mail::Send
MOJO::Password MOJO::Security::Password
MOJO::Widgets MOJO::Template::Widgets
MOJO::Widgets::AdminMenu MOJO::Template::Widgets::AdminMenu
my $ml = MOJO::MailingList->new($name);
my $settings = $ml->settings;
my $archive = $ml->archive;
# etc
Create()
function... it's not a method and you cannot have a MOJO::MailingList method yet, since I'm still trying to grapple on how you can have a MOJO::MailingList object without naming what the list is.2.7.2
2.7.1 beta3
2.7.1 beta2
use CGI::Carp "fatalsToBrowser";
2.7.1 beta1
2.7
2.6.8
list_popup_menu()
That'll give you a select box for all the
lists. This is used throughout the site and previously, ever instance had slightly different
code. No more!2.6.7
2.6.6
2.6.5
2.6.4
add()
so you don't have to cut and paste in everythingwrite_plaintext_list()
write_plaintext_list()
will write your subscriber list in a plain text format and return the filename. What's the point? It makes sense if you're using on of the List::*SQL's as the subscriber database. mojo::send_list_to_admin was just using the subscription list name and sending that, well, that isn't around when you're using a SQL backend.check_setup()
list directory test for WinNT folk. Beware! I don't
know why the stat()
file tests aren't working, I guess they're not implemented as
well on WinNT systems ?2.6.3
'.doc' => 'application/msword',
'.xls' => 'application/x-msexcel',
'.ppt' => 'application/x-mspowerpoint',
'.mp3' => 'application/octet-stream',
'.mov' => ' video/quicktime',
2.6.2
my $mh = MOJO::Mail::Send->new(\%list_info);
Version 2.6.1
send_back_email()
sub:list_option_form()
that's now
called via an OO interface.Version 2.6
default()
is called in
mojo.cgi, should stop lots of people from getting a Server Error when they try
to make a list in a dir that doesn't exist.do_not_send_to([@To_addresses])
;user_error()
and check_list_security()
have been moved into Guts.pm, along with my roommates who 'forget' to pay the @home bill
$MOJO_ROOT_PASSWORD = 'pa$$word';
$FILES = '/home/account/mojo_lists';
$MAILPROG = '/usr/sbin/sendmail';
$MOJO_URL ='http://mysite.com/cgi-bin/mojo/mojo.cgi';
list_invite()
function, $mh->mass_send is spelled correctly.
list_type
bulk_test
bulk_start_email
bulk_start_num
do_not_send_to
do_not_send_to(['justin@example.com'])
;
$fields{send_via_smtp}
$self->{list_info}->{send_via_smtp}
$self->{list_info} is set in the new() method:
my $mh = MOJO::Mail::Send->new(\%list_info);
Strip-Headers (strip_message_headers)
List_Sleep (bulk_sleep_amount)
Bulk_Amount (mass_send_amount)
List_Batch (enable_bulk_batching)
Batch_Notification (get_batch_notification)
Finished_Notification (get_finished_notification)
Organization
List
List-URL
List-Owner
List-Unsubscribe
List-Subscribe
List-Archive (show_archives)
From
Errors-To
use_pop_before_smtp => 1,
smtp_server => $smtp_address,
add_reply_to => 1,
precedence => 'list',
charset => 'English (en) iso-8859-1',
content_type => 'text/plain',
priority => 3,
archive_show_month => 1,
archive_show_day => 1,
archive_show_year => 1,
archive_index_count => 10,
open_database()
function in Guts.pmsend_announce_email()
and send_group_email()
subscribe_link()
and unsubscribe_link()
functions from Guts.pmmass_send_bulk_smtp()
mass_send()
subroutine_pop_before_smtp()
and with that, POP-before-SMTP Authentication support.
This should help people use an SMTP connection, instead of, *sigh* sendmailnew(\%list_info)
;_strip_fields()
mass_send()
function,mass_send()
function (amazingly enough)_email_finished_notification()
_mail_error_no_start_email()
_mail_error_no_start_num()
mass_send()
before: 460
#lines of mass_send()
after: 354quiet()
method if set to 1message_id()
in Guts.pm returns an id based on the date.subscribe_link()
and unsubscribe_link()
that return a url to sub and unsub.Version 2.5
remove_from_list()
subroutine. The routine
now goes something like this:
=item B<4/4/01>
If true, we won't attempt to use MIME::Base64/MIME::QuotedPrint,
even if they're available. Default is false.
login()
function in the mojo.cgi script, that looks a bit like this:
print $input->redirect( -uri => $location,
-COOKIE => $cookie,
-nph => $NPH,
);
print "Location:$mojo_url?flavor=change_info&done=1\n\n";
print $input -> redirect(-uri=>"$mojo_url?flavor=change_info&done=1");
print $input->redirect( -uri => $location,
-COOKIE => $cookie,
-nph => 1,
);
$back = ($stopped_at - ($iterate*2));
is now changed to:
# let see if we're at some weird halfway between point
my $mod_check = $stopped_at % $iterate;
my $fixer;
my $full_stop = $stopped_at;
if($mod_check > 0){
# substract it from the iterate
$fixer = $iterate - $mod_check;
$full_stop += $fixer;
}
$back = ($full_stop - ($iterate*2));
my $foo = 0;
my $bar = $foo || "something else";
print $bar;
######################################################################
# .: File Attachments :.
# To add an attachment to a list message in Mojo Mail form the control panel,
# we have to upload it via the web browser. There's two ways we can do this,
# one is to save the information in the $FILES directory and then open it up,
# attach it, and then delete it, the other involves some magical qualities of
# CGI.pm and MIME::Lite, probably coupled with your server's /temp file, if
# you can use it.
# setting $attachment_tempfile to '1' uploads, saves, attaches and then deletes
# the file, setting it to '0' does it magicaly. I suggest 1, unles you want to
# play around with it.
$attachment_tempfile = 1;
######################################################################
# These are the MIME types Mojo Mail understands, the file ending is on
# the left, what MIME type it maps to is on the right. feel free to add your own.
%mime_types = (
'.gif' => 'images/gif',
'.jpg' => 'image/jpg',
'.png' => 'image/png',
'.jpeg' => 'image/jpeg',
'.pdf' => 'application/pdf',
'.pdf' => 'application/psd',
'.html' => 'text/html',
'.txt' => 'text/plain',
);
######################################################################
# In case nothing up there matches what someone is trying to upload, there's
# a default MIME type, for a last ditch guess. Some mail readers are
#sophisicated enough to figure out what an attachment is without its MIME
# type, but don't count on it.
send_email()
; mojo.cgi function, in hopes of making
it clearer, increase it functionality and lessen its footprint.webify_plain_text()
-
sub webify_plain_text{
my $string = shift;
$string =~ s/>/\>/g;
$string =~ s/</\</g;
$string =~ s/\n\n/<\/p><p>/gi;
$string =~ s/\n/<br>/gi;
$string = urlify($string);
return $string;
}
($diffhour = sprintf("%03d", $hour - $ghour)) =~
s/^0/\+/;
($diffhour = sprintf("%03d", $diffhour)) =~ s/^0/\+/;
warn()
and then die. when the program dies, the mail gets put back into the que to
sent again, where it will die...exit()
instead of die.
228 $mh -> send(%mailing);
229 #and we go!
230 warn("Mojo Mail $ver ERROR \- Attempt to
send a list message to an unknown list
($email_list) by means of mojo_send.pl");
231 exit;