This FAQ is targeted on helping solve errors frequently found with Dada Mail. Please make sure you've read both the installation and The Config.pm tour. Many things are explained in those pages.
That's not much to go on, Why isn't it working? If you don't have a clue, find out as much about the server its software that you can and read on, brave soul!
Check to see that you:
If you still have trouble, check the error logs.
Once I fill out all the information and click the submit button, the program returns a 500 error message. What's going on?
Most likley, Dada Mail does not have enough permissions to write files into the directory you supplied in the $FILES variable - (If you're using the advanced setup, we're also talking about the $ARCHIVES, $BACKUPS, $TEMPLATES, $TMP and $LOGS directories.)
This usually occurs if the UNIX user that created the directory differs from the UNIX user that Dada Mail is running as. For example, sometimes cgi scripts, like Dada Mail are run as, ``nobody'', or, ``apache'', for security reasons. If this is the case, you're going to have to change the permissions of the directories mentioned to: 777.
Note that this gives everyone who has access to these directories read/write permission, so be careful when applying this chmod. If you're uncomfortable doing this, see if you cannot run Dada Mail using a wrapper script. A wrapper script allows you to run a cgi script using a different UNIX user - usually whichever one is associated with your usual login username. A common wrapper script is one called, CGIWrap.
Find out the following before proceeding:
If so, adjust your batch settings accordingly
unlimited
If you want to get a finer grain on what's happening, run the ulimit command with the, -a flag:
me@there me> ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 524288 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 7322 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 65536 cpu time (seconds, -t) unlimited max user processes (-u) 3661 virtual memory (kbytes, -v) 589824
What we're mostly interested is the, cpu time which is, ``unlimited''. Great!
If you cannot find a limit to your sending capabilities and your resource limits aren't the problem, here are things to check:
If you're using the sendmail command, you may look into the various flags you can set in the Config.pm variable, $MAIL_SETTINGS that will force messages to queue up, instead of attempting to be send right away. NOTE: that using a queueing flag will cause a pause before sending that is very noticeable (could be, 15, 30 minutes)
In that case, in the list control panel, go to: Sending Options - Advanced and check, Schedule List Mailings to be sent by a separate process.
Then, setup the mail.cgi to run via a cron job. Here's an example:
0,10,20,30,40,50 * * * * /usr/bin/perl /home/myaccount/www/cgi-bin/dada/mail.cgi --run >/dev/null 2>&1
The command line options are very similar to what's available using Beatitude, the schedule mailings plugin; For more information on how to set up this cron, check out the documentation for Beatitude:
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
NOTE: You do NOT need to install Beatitude to have this feature working correctly - the options are just similar to that of Beatitude, including the cron job setup. If you have Beatitude working already, you do not have to set up this additional cron job. Beatitude is still needed to actually create scheduled mailings with any sort of flexibility.
NOTE AS WELL - This is somewhat of an experimental feature. Let us know how it works for you!
If none of this is working, and you're in a pinch and it's 3:00 am and you need to get this mailing out now, Dada Mail has an option to send a list messsage from a particular part of your list.
Log into your list control panel and when you get to the, ``Send a List Message'' screen, click, ``advanced''.
At the bottom of the form, you should see the option to send your message from a particular part of your list.
To figure out where your list might have stopped at, consult the batch completed messages. If you didn't setup batchings, consult the usage log, which by default should be called, usage.txt and saved at the same location as all your other list files.
If the usage log isn't there, consult the Config.pm file variable, $PROGRAM_USAGE_LOG to see where it was set.
If the usage log wasn't set up, consult Dada Mail's error log.
If you don't know where Dada Mail's error log is, consult the Config.pm variable, PROGRAM_ERROR_LOG
If there is no error log, before the next time you send a list message out, set up the error and usage logs; as well as setup up batching to something realistic.
This is a very difficult question to answer. Here's some things to consider:
Here's some places to check:
http://www.spamcop.net/bl.shtml
I belive SpamCop's blacklist is one that expires over time and if you reply to the abuse emails, you can come to a conclusion that may get you off quicker.
The only way to get off an individual block list is to have the individual take you off.
Lyris provides a free content check at:
http://lyris.com/contentchecker/
It's somewhat barebones, and you'll receive some marketing information from the company once you're done, but it uses a similar backend to what I test Dada Mail with, which, if you're interested, is a fine program called, SpamAssassin:
I'm personally very happy with Spam Assassin's development and thank my lucky stars each time it blocks the billions of SPAM I personally receive a day. Mail filtering software like SpamAssassin is not going to go away any time soon and the best thing to do is work in conjunction with it, rather than to try to find holes in which to get past it.
To end this discussion, here are some things I'm pretty sure of:
Saying all this, keep in mind that you have a social responsibility when running your mailing list - do not abuse the right your subscribers have granted you with their email addresses. Respect is a two-way street.
Dada Mail seems to be not working correctly. Viewing the error logs that I have setup - as per suggestion, give me back some odd cryptic messages about lockfiles not being removed, what do I do? Is it safe to manually remove these lockfiles?
If Dada Mail seems to be completely stuck, displaying only part of a screen, generally unusable, it is safe to delete the lock files - yes. Lock files should only be in use for seconds at the most, and then be automatically removed. If they're not, you can safely delete them yourself.
Lockfiles that aren't removed and still have their filehandle open may because of a larger problem you shouldn't ignore - either there's a bug in Dada Mail, or your server is being bombarded with requests - more than Dada Mail can handle.
I've found this to be true when Dada Mail is trying to load complex archive messages. If this is the case for you as well, you may want to play around with the, $MIME_OPTIMIZE Config.pm variable.
Background:
Data::Dumper is probably already installed on your account.
Simply remove the copy that comes with Dada Mail by navigating to the dada/DADA/perllib directory and removing or moving the, Data directory.
I'm getting an error with the following (or similar) gobble-dee-gook:
Guts.pm: [Thu Jul 17 22:43:11 2003] Guts.pm: / < # opening angle bracket [Thu Jul 17 22:43:11 2003] Guts.pm: [Thu Jul 17 22:43:11 2003] Guts.pm: [Thu Jul 17 22:43:11 2003] Guts.pm: [Thu Jul 17 22:43:11 2003] Guts.pm: (?: # Non-backreffing grouping paren [Thu Jul 17 22:43:11 2003] Guts.pm: [Thu Jul 17 22:43:11 2003] Guts.pm: [^>'"] * # 0 or more thi/: regexp *+ operand could be empty at /DADA/App/Guts.pm line 1217. BEGIN failed--compilation aborted at mail.cgi line 87.
This error happens if you're server is running a version of Perl that's below version 5.005. Dada Mail requires at least version 5.005 of Perl and it's suggested that you use at least Perl 5.6. Dada Mail is developed and tested on a machine running Perl Version 5.8.
Among major hosts that have a version of Perl that's below 5.005 is Earthlink. Dada Mail will not run correctly on an Earthlink account. It's suggested that if you do have an account on Earthlink and want to run Dada Mail that you thoughtfully express your wantings of an up-to-date version of Perl available on their servers. Or, move your account to a hosting company that responds to their customers wants and needs.
To give you a brief history of Perl, Perl version 5.005 was released on 7/22/98. I don't think it's too much to ask that Dada Mail will only run on with a version of Perl that's five years old or less.
I'm getting a Software Error that says:
can't open /usr/home/path/to/your/dada_lists to read: No such file or directory at /DADA/GUTS.pm
Did you change the first 4 variables in the Config.pm file? What's happening is that its looking for a directory on the server that doesn't exists.
I'm getting a sofware error that says:
can't open /usr/home/myaccout/lists to read: Permission denied at /DADA/GUTS.pm
The directory that you specified in the Config.pm as the place to put your lists (the $FILES variable) exists, but isn't something Dada Mail can read and possibly write into. You'll need to change the permissions of this directoy. Usually, people on a regular hosting account will have to chmod the $FILES directory to 777.
Just to reiterate, this is a directory not a file. All sorts of files are going to be written inside this directory, so be ready.,
I get the 'Congratulations' startup screen, but when I enter my root password and click the button, I either see a 404 page, or nothing happens
Did you set the $PROGRAM_URL variable in the Config.pm file? This variable is defaulted to this:
$PROGRAM_URL ='http://yoursite.com/cgi-bin/dada/mail.cgi';
Which, unless your domain is yoursite.com, is wrong. Change it to the URL that you have to access the mail.cgi script from.
In your server configuration, can information be passed to the script using the POST method? If not, you're in trouble, cause Dada Mail needs that. 99.99% of the time, you'll be able to use the POST method to send information to a script, but sometimes, for security reasons, you won't be able to. This can be set in your servers configuration file, like httpd.conf.
mail.cgi: Broken pipe at DADA/MAIL.pm
or I see this Software Error in my browser:
Error: can't pipe to mail program using settings: |/usr/bin/sendmail -t
This means that the $MAILPROG variable in the Config.pm file is incorrect. If you have shell access to your server, type in this:
which sendmail
to find out where the sendmail program is on your server, or ask your system administrator.
If you're on a WinNT server, you're most likely not going to be using Sendmail this way, you should be sending all your mail using an SMTP server. Check out the Windows readme file for more information on how to set up your copy of Dada Mail for Windows.
Everything is working fine, but when I open up my error log (or even sprinkled on the mail script in my web browser) I see annoying things like this:
Use of uninitialized value at /home/mysits/web/cgi-bin/dada/mail.cgi line 7064.
They are honestly annoying, I don't know what they mean, and frankly, I don't care, what is happening?!
Not to worry, these aren't really errors, they're 'warnings' It's saying that something isn't being done correctly and that this might be a problem. A few things to do, all these things are located at the top of the mail.cgi file (NOT the Config.pm file)
The first line of mail.cgi should look similar to this:
#!/usr/bin/perl -w
change that line, to this:
#!/usr/bin/perl
The '-w' is a flag, that says, tell me about warnings, (Use of uninitialized blah blah blah), we don't want that.
Around line 40 in mail.cgi, you'll see this:
use CGI::Carp "fatalsToBrowser";
Comment this line out or delete it. That tells Dada Mail to tell you these little things in your web browser.
Mailings work fine, until I try to send out a list message, then I get this error:
Can't locate MIME/Lite.pm in @INC (@INC contains: ...
Make sure you uploaded the MIME directory that's within the DADA directory. The MIME directory has a script called Lite.pm which is used to make list messages. While you're at it, make sure you uploaded the MAIL directory that's within the DADA directory as well. Dada Mail should be uploaded in the same structure as you received it.
I get an error like this:
Software error:
Can't locate MIME/Base64.pm in @INC (@INC contains: [...]
but everything is working fine, what's up?
If we only knew. This looks like a bug in Mime::Lite - a part of Dada Mail that we really like (Ok, LOVE) , but wasn't developed by us, so we can't think why it's broken. Basically, don't worry about the message, it's more of a warning than anything, if a slightly annoying warning. There are directions in mail.cgi itself to get rid of 'em.
A little backgound on how Dada Mail stores its list settings and archives:
Dada Mail stores list settings and archives in what are called ``DB Files''; they're simpler than an SQL database, but have their advantages from completely flat file databases. There are a few different DB File formats, and Dada Mail can use many different kinds. Different DB File formats have different limitations. One of these limitations is the amound of information they can store in each key/value pair. If you go over this limit, you're going to receive something like:
ndbm store returned -1, errno 28
Most likely, you'll experience this when sending out a list message. This is triggered from Dada Mail trying to archive a message into a DB FIle format that has a limitation on the amount of data it can hold. The message goes over this limit. The easiest fix is to turn off archiving.
If you want to, you can play around with how Dada Mail picks what DB FIle to use. In the Config.pm file, find this line:
BEGIN { @AnyDBM_File::ISA = qw(DB_File GDBM_File NDBM_File ODBM_File SDBM_File) }
DB_File, GDBM_File, NDBM_File, ODBM_File and SDBM_File are all different DB File Formats. DB_File is the best and they get poorer from there. If Dada Mail isn't using DB_File, it usually means it's not available. If you have root access on your server, you can always install it, it's free. Before doing that, please note that previous lists setup with a different DB File format will not work if you're uswithcing the DB File package. Dada Mail can only use one of these packages at a time. It's possible that all these DB File formats have import/export tools that you may want to investigate. If you don't know what file format you're using, try using the file command.
Was your hosting account moved to another server, or has the server you were on upgrade it's operating/server software/version of Perl? Those can muck things right up.
Software error: couldn't tie for reading: Permission denied
First off, Dada Mail was never designed to be moved from one server to another, but this problem can be fixed by resetting the permissions on all the files Dada Mail reads to do it's work. Everything you put in whatever directory you set in the $FILES variable needs to be Readable and Writeable to Dada Mail. When you created a list, The files are created by Dada Mail and Dada Mail gave itself enough permissions to read and write it's own files. You reset these permissions to something completely different when you downloaded these files and uploaded them again. Try chmod'ing all the files to 777. This isn't the best thing to do, but it's likely that the files are owned by something other than Dada Mail.
This usually happens if your site has recently moved or, the server itself has been upgraded in part or in total. With the server upgrade, a different type of DB File type may have become supported.
Dada Mail can use a few different types of DB File formats to save its list settings, schedules and archives. These are saved wherever you set the $FILES variable to, and begin with mj-. A quick way to see which kind of DB File you're using is to issue the ``file'' command via the command line:
bash-2.05$ file mj-listshortname mj-listshortname: Berkeley DB (Hash, version 5, native byte-order)
In this case, the list settings file, mj-listshortname is using the Berkeley DB file format. If this is the case for you, you may need to upgrade the db file itself.
Upgrading Berkeley DB Files is easy (make backups first!), just use the db_upgrade utility:
bash-2.05$ db_upgrade mj-listshortname
Now, when you run the file() command again, you should see a change:
bash-2.05$ file mj-listshortname mj-listshortname: Berkeley DB (Hash, version 7, native byte-order)
More Information -> http://www.sleepycat.com/docs/utility/db_upgrade.html
If you're list settings aren't in the Berkeley DB file format, you may have to explicitly tell Dada Mail what file format is being used. For example:
bash-2.05a$ file mj-listshortname mj-listshortname: GNU dbm 1.x or ndbm database, little endian
In this case, the list settings file are using the NDBM database file format.
Telling Dada Mail explicitly what file format is being used is done by tweaking the @AnyDBM_File array in the Config.pm file. In this example, to tell Dada Mail to use the NDBM file format, I would change this line:
BEGIN { @AnyDBM_File::ISA = qw(DB_File GDBM_File NDBM_File ODBM_File SDBM_File) }
to:
BEGIN { @AnyDBM_File::ISA = qw(NDBM_File) }
To clarify what is going on, Dada Mail supports a variety of DB File formats. It tries to use the best format available. If your server upgrades its software, this best format may change and you may have to tell Dada Mail to continue to use the format it was using in the beginning.