These are the somewhat raw change logs - they are very prolix. You may want to check out the New Features and friends if you want only a casual idea on what has changed.
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.)
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://mojo.skazat.com/images/testing/testsuite_apple_mail.gif
http://mojo.skazat.com/images/testing/testsuite_gmail.gif
http://mojo.skazat.com/images/testing/testsuite_hotmail.gif
http://mojo.skazat.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://mojo.skazat.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 .rootloginmsg class )
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:
http://mojo.skazat.com/support/documentation/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.
This bug is still unresolved and will be added to, ``known issues''
This bug has been fixed.
[] 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.
There's two instances of,
my $blksize.
This bug has been fixed. Version of dada_backup.pl will be 1.2
This bug seems to be fixed, but needs more testing.
This bug should be fixed.
This bug should be fixed.
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.
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.
This bug appears only when sending in SMTP mode.
This bug should be fixed.
This bug should be fixed.
This bug should be fixed.
This bug should be fixed.
(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.
This bug is still unresolved.
This bug seems to be resolved, but needs more testing.
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
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.
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. 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.
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. 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.
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
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.
http://www.perldoc.com/perl5.8.0/pod/func/fork.html
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)
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
%HTMLFROMTEXT_OPTIONS = ( urls => 1, email => 1, paras => 1, bold => 1, underline => 1, lines => 1 ) unless keys %HTMLFROMTEXT_OPTIONS;
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.
You can now specify showing the oldest and newest archive entries without having to know the actual id number, instead of, say:
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
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:
$DEFAULT_SCREEN = 'http://mysite.com/cgi-bin/mojo/mojo.cgi?f=archive&l=archive&id=newest';
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:
http://ms.com/cgi-bin/mojo/mojo.cgi?f=default
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 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)
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
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.
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:
%SQL_PARAMS = ( database => '', dbserver => '', port => '', dbtype => '', # 'mysql' for 'MySQL', 'Pg' for 'PostgreSQL' user => '', pass => '', subscriber_table => 'mojo_subscribers', ) unless keys %SQL_PARAMS;
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.
hard_remove => 1,
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 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.
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.
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.
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 new() constructor. This has been fixed.
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.
new feature: Subscription/unsubscription notices now tell you how many subscribers are actually on your list in each mailing. Handy.
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.
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.
MOJO::MailingList::Settings
Which, at the moment, has 2 public methods, 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.
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.
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
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:
my $ml = MOJO::MailingList->new($name);
my $settings = $ml->settings;
my $archive = $ml->archive;
# etc
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 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.
I'd like to also make a MOJO::Mail::CreateMessage module, perhaps inheriting MIME::Lite methods directly.
Black lists should be working for everyone again.
Bulk Mailing Precendences 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:
use CGI::Carp "fatalsToBrowser";
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 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!
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.
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.
add() so you don't have to cut and paste in everything
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
write_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.
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
turned off the 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 ?
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:
'.doc' => 'application/msword',
'.xls' => 'application/x-msexcel',
'.ppt' => 'application/x-mspowerpoint',
'.mp3' => 'application/octet-stream',
'.mov' => ' video/quicktime',
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'
my $mh = MOJO::Mail::Send->new(\%list_info);
Guts::check_for_double_email should obey whatever $Config::EMAIL_CASE is set to.
send_back_email() sub:
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 list_option_form() that's now
called via an OO interface.
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.
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
327: $mh->do_not_send_to([@To_addresses]);
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, user_error() and check_list_security() have been moved into Guts.pm, along with my roommates who 'forget' to pay the @home bill
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...
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:
$MOJO_ROOT_PASSWORD = 'pa$$word';
$FILES = '/home/account/mojo_lists';
$MAILPROG = '/usr/sbin/sendmail';
$MOJO_URL ='http://mysite.com/cgi-bin/mojo/mojo.cgi';
added the '$TMP' variable to the Config.pm file for temporary file... stuff.
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
cleanup of mojo_send.pl a bit
mojo_send.pl should now recognize if you send to a list using the CC: header
MIME::Type.pm and MIME::Types.pm have been added to the distro
list_invite() function, $mh->bulk_send is spelled correctly.
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
All Config variables are in UPPERCASE
all modules now are in MixedCase, CONFIG.pm is now Config.pm
list_type
bulk_test
bulk_start_email
bulk_start_num
do_not_send_to
these take the place of similar-named headers, which really didn't make much sense anyways
$mh->do_not_send_to(['justin@skazat.com']);
usage of:
$fields{send_via_smtp}
has been replaced with:
$self->{list_info}->{send_via_smtp}
$self->{list_info} is set in the new() method:
my $mh = MOJO::Mail::Send->new(\%list_info);
same with:
Strip-Headers (strip_message_headers)
List_Sleep (bulk_sleep_amount)
Bulk_Amount (bulk_send_amount)
List_Batch (enable_bulk_batching)
Batch_Notification (get_batch_notification)
Finished_Notification (get_finished_notification)
new function in MAIL.pm:
_make_list_headers
this function creates the following headers:
Organization
List
List-URL
List-Owner
List-Unsubscribe
List-Subscribe
List-Archive (show_archives)
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:
From Errors-To
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:
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,
this can really clean up the open_database() function in Guts.pm
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?)
In mojo_send.pl, you can now turn on and off the Reply-To header, weee
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
send_announce_email() and send_group_email()
mojo_send.pl now used the new subscribe_link() and unsubscribe_link() functions from Guts.pm
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
the List Information screen now shows the list's short name, which is WHAT YOU WANT TO USE FOR mojo_send.pl
bulk_send_bulk_smtp()
Hopefully, this will take some more heft out of the main bulk_send() subroutine
new sub, sub _pop_before_smtp() and with that, POP-before-SMTP Authentication support.
This should help people use an SMTP connection, instead of, *sigh* sendmail
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(\%list_info);
_strip_fields()
bulk_send() function,
a new function, called _email_batch_notification has been created to move the
email batch notification stuff out of the bulk_send() function (amazingly enough)
ditto with _email_finished_notification()
ditto with _mail_error_no_start_email()
ditto with _mail_error_no_start_num()
#lines of bulk_send() before: 460
#lines of bulk_send() after: 354
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->quiet() method if set to 1
plain text messages with no attachments are now sent as 'quoted-printable' instead of binary(?)
new function, message_id() in Guts.pm returns an id based on the date.
two new functions in Guts.pm,
subscribe_link() and unsubscribe_link() that return a url to sub and unsub.
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.
Long Version:
Short Version:
http://dev.skazat.com/cgi-bin/mojo/mojo.cgi?f=u&l=big_list&e=justin@skazat.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.
remove_from_list() subroutine. The routine
now goes something like this:
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.
=item B<4/4/01>
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.
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:
If true, we won't attempt to use MIME::Base64/MIME::QuotedPrint, even if they're available. Default is false.
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 login() function in the mojo.cgi script, that looks a bit like this:
print $input->redirect( -uri => $location,
-COOKIE => $cookie,
-nph => $NPH,
);
also, added a new 'list invite' feature.
Also, changes made to modules are logged in the modules that are changed, in POD format.
I changed all code that's similar to this:
print "Location:$mojo_url?flavor=change_info&done=1\n\n";
to this:
print $input -> redirect(-uri=>"$mojo_url?flavor=change_info&done=1");
I also added the nph' flag for the redirect when the cooie is being passed to the script, like this:
print $input->redirect( -uri => $location,
-COOKIE => $cookie,
-nph => 1,
);
This seemed to make M$ IIS happier.
in Archive.pm, what used to read
$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));
which will give you what you want. and I feel cool.
Change/Tweak log, for Mojo Mail, 2.4.6 beta
my $foo = 0;
my $bar = $foo || "something else";
print $bar;
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:
###################################################################### # .: 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.
$default_mime_type = 'text/plain';
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 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;
}
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:
($diffhour = sprintf("%03d", $hour - $ghour)) =~
s/^0/\+/;
Change it to this:
($diffhour = sprintf("%03d", $diffhour)) =~ s/^0/\+/;
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 :)
fixed a small bug in a screen like this: http://mojo.skazat.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
warn() and then die. when the program dies, the mail gets put back into the que to
sent again, where it will die...
the fix was just to put exit() instead of die.
in mojo_send.pl
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;