Error FAQ
- The Dada Mail Error FAQ
- In-Browser Error Messages
- Strange, Hard to Debug Errors
- Error Messages Because of Incorrect File Permissions
- Error Message: 403 Forbidden
- Program Error Messages - Yikes! App/Server Problem!
- Reporting Errors
- Advanced Error Logging and Reporting
- Difficult to Trace Errors
- Tracing CPAN modules with %CPAN_DEBUG_SETTINGS
- $DEBUG_TRACE - Making Dada Mail's Own Modules More Verbose
- Finding the error log when errors happen when installing Dada Mail
- General Problems
- Perl Version
- Mass Mailing Messages Are Not Delivered or Are Delivered to Junk/Spam Folder
- Problems Logging In
- Links in Dada Mail don't work/just go to the default screen
- Duplicate Email Addresses in Your Mailing List
- Template Problems
- Diagnosing Error Messages
- cannot do statement (at add_subscriber)! Duplicate entry '0' for key 1
- execute failed: Specified key was too long; max key length is 767 bytes
- Died at /usr/lib/perl5/5.8.8/base.pm line 85
- Dada Mail works great! Until I try to create a new list...
- lock files?
- CPAN Perl modules/conflicts
- Data::Dumper object version 2.102 does not match $Data::Dumper::VERSION 2.121 at....
- Guts.pm: / < # opening angle bracket
- can't open /usr/home/path/to/your/dada_lists to read
- can't open /usr/home/myaccout/lists to read: Permission denied
- is only avaliable with the XS version
- I get the 'Congratulations' startup screen, but ...
- No mail is being sent and I get this error in my logs:
- Can't locate JSON.pm, charts/graphs that never load
- Can't locate MIME/Base64.pm
- I moved my lists from one server to another and reinstalled Dada Mail. Now when I try access my lists, I get this error:
- couldn't tie /home/path/to/your/dada_files/mj-listshortname for reading: File exists at [...]
- How do I restore my lists?
- password is blank! - Error.
- Hosting Company-Specific Problems
- Frontpage Extensions-enabled accounts
- Send a Webpage Problems
- Can't locate object method "redirects" via package "HTTP::Headers"
- Can't call method "verify_data" on an undefined value at...
- Assets w/URLS w/Query Strings break
The Dada Mail Error FAQ
In-Browser Error Messages
In-Browser Error Messages are error messages that you may receive in your browser window when interacting with Dada Mail.
For security purposes, Dada Mail is not set up to show verbose error messages within your browser window. You will need to consult your Server/Dada Mail error log to see the specific problem.
In-browser error messages can also be vague or sometimes downright misleading (an error 404 File Not Found when clearly that's not the case!) - don't interpret in-browser error messages alone!
If you do get an in-browser error message, please find the lines in the error log that correspond to your problem. Lines in the error log are usually time stamped, facilitating your search.
Strange, Hard to Debug Errors
One suggestion, if errors start to crop up strangely when the app has been running well for a while, is to simply check if the problem isn't because of a disk quota problem: you have run out of disk space, and the app can't create new files, append to existing files. Checking this early in your attempt to debug the problem may save you many hours of headaches.
Error Messages Because of Incorrect File Permissions
Dada Mail's, mail.cgi
script, as well as all of its plugins and extensions that you are utilizing will need to have their file permissions changed so that they may be executed, when you visit them in your web browser. This usually means changing the file permissions to, 755.
The directories that the mail.cgi
script lives in (dada), as well as Dada Mail's plugins/extensions (dada/plugins,dada/extensions>) should also be set to 755.
You may receive one of the following messages in your browser window if the permissions are not set correctly:
[an error occurred while processing this directive]
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, you@example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Generally, when you receive the above errors, it is not a problem with Dada Mail itself, but rather simply incorrect file permissions.
If file permissions do seem correct, there may be another underlying problem, such as incorrect file ownership, incorrect web server setup, etc. In that case, you will want to look in the server's error log.
Error Message: 403 Forbidden
Forbidden
You don't have permission to access /cgi-bin/dada/mail.cgi on this server.
Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.
This in-browser message can happen for a variety of reasons. Again - in-browser messages can be misleading and vague, which makes debugging them hard.
For example, you may receive this error because of additional server configuration using .htaccess
files. The directives in .htaccess
files may be set for, and utilized by other web apps you have installed on your hosting account, so simply removing them is not a good idea.
An easy way to diagnose that this is a the problem is to rename your base .htaccess
file to move it out of the way, and then run Dada Mail. If Dada Mail runs, without the, 403 Forbidden error - there's something in your .htaccess
file that's stopping Dada Mail from running correctly.
By far, the worst offender of long, verbose and sloppy .htaccess
file directives is Wordpress. If you're running Wordpress and Dada Mail, prepare to troubleshoot .htaccess
directive problems.
mod_rewrite
The mod_rewrite
Apache Module, if configured incorrectly, can stop Dada Mail from working. Dada Mail does not require you to use this directive. You will want to disable mod_rewrite
for Dada Mail.
One way to do this is to create a new .htaccess
file in your, dada directory, with this directive:
RewriteEngine Off
to disable mod_rewrite
for Dada Mail.
mod_security
If the mod_security
Apache module is enabled for your hosting is enabled, it may get in the way of normal, safe operations of Dada Mail.
One solution would be to disable mod_security
in whole or in part for Dada Mail by creating an .htaccess
file with the correct directive to disable mod_security
. Depending on the version of mod_security
you're using, that directive will be different. An example would be:
<IfModule mod_security.c>
SecFilterInheritance Off
</IfModule>
Again - the correct directive for your version of mod_security
could be different.
Program Error Messages - Yikes! App/Server Problem!
If Dada Mail has a problem completing a task, it will show its own error message, similar to what's below:
Yikes! App/Server Problem!
We apologize, but the server encountered a problem when attempting to complete its task.
More information about this error may be available in the program's own error log.
Contact the Server Admin
Time of error: (Time Stamp)
For security reasons, Dada Mail will not show the complete error in the browser window. To find out what the actually error is, you will need to consult Dada Mail's own error log
Viewing Dada Mail's Error Log
If you've set up Dada Mail using the included Dada Mail Installer, Dada Mail's error log is located within your .dada_files
directory, at the following path:
.dada_files/.logs/errors.txt
If you are having trouble finding your error log, or did not use the Dada Mail Installer, you can find exactly where the error log is set in within your dada/DADA/Config.pm file, under the variable, $PROGRAM_ERROR_LOG
. The line looks similar to this:
$PROGRAM_ERROR_LOG = "/home/youraccount/.dada_files/.logs/errors.txt";
If the error you're receiving doesn't stop you from logging into your List Control Panel, you may also use the Log Viewer plugin to view the error log as well. This plugin is also installed by default when you install Dada Mail using its built in Installer.
You'll find a link for the Log Viewer plugin on the admin menu, under: Plugins/Extensions - Log Viewer. Once on the Log Viewer screen, Find the popup menu labeled, View Log: and change it to, Error Log. The Log Viewer should refresh and show the last few lines of your Dada Mail error log.
Reporting Errors
Please come prepared with the following information, or as much as you can gather, or think is relevant:
Version of Dada Mail
Please always give the version of Dada Mail you're using
Error log snippets
Error log lines are time stamped. Please do not post your ENTIRE error log, but rather simply lines that are time stamped around the time you're having problems or suspect problems are occuring.
What, if anything you did to cause the problem
If there's a couple of steps needed to create the problem, it's helpful to describe those steps to the community, so that we all can try to recreate the problem, ourselves.
Advanced Error Logging and Reporting
The following advice is for advanced users of Dada Mail:
Difficult to Trace Errors
If Dada Mail is acting improperly, you can change how verbose Dada Mail reports warning and errors.
Tracing CPAN modules with %CPAN_DEBUG_SETTINGS
Dada Mail uses Perl modules from various sources - mostly CPAN. Each of these modules is written by a different person/persons and usually have their own way of setting debug/tracing levels.
In Dada Mail, the CPAN modules that have a debugging/tracing scheme are listed in the, %CPAN_DEBUG_SETTINGS Config.pm variable. More information:
https://dadamailproject.com/support/documentation-11_22_0/global_variables.pod.html#_cpan_debug_settings
Enabling debugging settings in these modules may help debug issues such as:
SQL Database Connections
Templating System
"Send a Webpage" function
POP3 and SMTP server connections
$DEBUG_TRACE - Making Dada Mail's Own Modules More Verbose
Some of the various modules that make up Dada Mail also have their own debug tracing modes.
The following modules have debug tracing:
DADA_App_DBIHandle
DADA::App::DBIHandle
Handles the connection between the SQL server and Dada Mail. See also the, DBI key/value in
%CPAN_DEBUG_SETTINGS
DADA_App_Subscriptions
DADA::App::Subscriptions
For various things dealing with the subscription list.
DADA_Mail_MailOut
DADA::Mail::MailOut
Monitors Mass Mailings
DADA_Mail_Send
DADA::Mail::Send
Send email messages, including mass mailings.
Finding the error log when errors happen when installing Dada Mail
The included installer for Dada Mail keeps its own error log. You may find it in the same directory that the installer lives in (dada/installer), in a file named, installer_errors.txt
General Problems
Perl Version
Sometimes, the default system Perl is an old version - v5.8, or even v5.6!
This will not work with Dada Mail as it currently requires at least v5.10.1. There is a chance that a more up-to-date version of Perl is available at a different location.
If you're hosted on a cPanel-based hosting account, a more up-to-date version of Perl may be available at:
/usr/local/cpanel/3rdparty/bin/perl
To use this version, you will need to slightly adjust Dada Mail to use this version of Perl. When installing, after you've run the, uncompress_dada.cgi
script (or prepped manually), you will need to change the following files:
dada/mail.cgi
dada/installer/install.cgi
dada/installer/templates/mail.cgi.tmpl
Open them up in a text editor, and find the first line:
#!/usr/bin/perl
and change it to,
#!/usr/local/cpanel/3rdparty/bin/perl
Save your changes, then run the installer.
As of v11.19.0 of Dada Mail, the installer will detect if this specific alternative version is available, and allow you to perform the steps above on your behalf. Then, it will reload the installer and you can continue with the installation process.
If you're running at least v5.10.1 of Dada Mail (a very, very old version of Perl), you may still want to run the alternative version of Perl. See if there's any issues with connection to your SQL backend. You can use that as an indicator of the freshness and health of the default Perl ecosystem. If the required driver isn't available under the default Perl, try using the alternative Perl interpreter location.
Mass Mailing Messages Are Not Delivered or Are Delivered to Junk/Spam Folder
Hosting-Account Hourly Email Sending Limit
Many shared hosting accounts have hourly email sending quotas, that will need to send below.
See the FAQ on Mass Mail Sending: https://dadamailproject.com/d/FAQ-mailing_list_sending.pod.html
The majority of mass mailing delivery problems are from sending over your hosting account's hourly email limit.
Message Content
Dada Mail goes to pretty good lengths in an attempt to make sure the formatting of the messages sent with it are well structured. It is up to you to make sure the messages that you write are also well structured:
No Sloppy HTML coding
If you're sending HTML, make sure that the HTML code itself is not sloppy. The more HTML tags you have in relation to actual text you have, the more suspicious a HTML message will look.
Be careful of certain phrases
Many of the mail filtering software used looks for keywords that will trigger your message to be flagged. A list of all of them is in constant flux and is too large to list here. The easiest thing to do is to test your message out.
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.
Other reasources dealing with the content of your message, primarily:
Some Tips for Legitimate Senders to Avoid False Positives
http://wiki.apache.org/spamassassin/AvoidingFpsForSenders?highlight=%28CategoryFaq%29
HTML Emails - Taming the Beast
CSS and Email, Kissing in a Tree
Frugal Marketing: That's not Spam, That's My Newsletter!
SpamCon Foundation: Best practices for marketers
Bulk e-mail HOWTO:
Mail Server Black Listed
Email Black Lists are lists of sites, servers and individual addresses that are flagged as being abusive to the shared and open system of the web. There are many ways to become black listed and services that will blacklist you. Different services use different methods - it's an anarchic mess that works sometimes.
Resources to check:
SpamCop.net
SpamCop receives individual reports of spam from its users and keeps a database of abusive activity based on the IP address the mail originates from. If you have setup an abuse email address for you domain (usually, abuse@example.com, where example.com is your domain name), you should receive a copy of the complaint. If not, you can check your status at:
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.
mx toolbox Blacklist Check
http://www.mxtoolbox.com/blacklists.aspx
Searches through many, many email blacklists at one time.
Individual's Block List
Black List's can also be individual, which isn't something you're going to be able to control. There's two main reasons that someone would block your message - they genuinely don't want to receive mail from you, or it's a mistake.
The only way to get off an individual block list is to have the individual take you off.
Problems Logging In
Sometimes, people find that it's impossible to log into Dada Mail's list control panel.
Some things to double-check:
Make SURE you're using the right password
Sounds simple, but you never know
Browser? Cookies?
Make sure your browser, firewall and connection to Dada Mail is allowing cookies to be sent, received and stored.
Dada Mail relies on session information saved in browser cookies.
Links in Dada Mail don't work/just go to the default screen
If you're having problems with links in Dada Mail being seemingly broken - for example, going to:
http://example.com/cgi-bin/dada/mail.cgi/admin
Doesn't bring you to the admin script, but instead simply goes to the default screen, you may have a problem with a separate web app or server configuration impacting Dada Mail.
This could be solved by turning off mod_rewrite
for the directory Dada Mail resides in:
Create an .htaccess
file in your, dada
directory and placing this directive inside it:
RewriteEngine off
Duplicate Email Addresses in Your Mailing List
If there are duplicate email addresses in your mailing list, please open up a bug report.
http://github.com/justingit/dada-mail/issues
At least in the Dada Mail program, duplicates should never be present.
If you are edited the plain text list files (if you're using the default back end), or if you're using the SQL dada_subscribers SQL backend directly, then all bets are off, in terms of duplicates. You CAN, easily add duplicates to a mailing list by working with the backends directly. We suggest not doing this, but rather, using the provided Perl API.
Template Problems
Changes made to $USER_TEMPLATE or $ADMIN_TEMPLATE variables make no difference to layout/design
If you're trying to change the layout/design of Dada Mail, but any changes you make do no seem to take hold, see if Screen Caching isn't enabled - it should be enabled by default. Your changes will not be visible, until after you have flushed out the cache.
See the doc on the Screen Cache feature for more information:
https://dadamailproject.com/support/documentation-11_22_0/features-screen_cache.pod.html
Diagnosing Error Messages
cannot do statement (at add_subscriber)! Duplicate entry '0' for key 1
I've seen this error, when the Dada Mail SQL database isn't imported correctly. My advice is to export your list from within Dada Mail's List Control Panel (Your Subscribers -> View, Open List in New Window) Drop the dada_subscribers table, recreate the table and subscribe the subscribers back into your database via Dada Mail's list control panel (Your Subscribers -> Add)
execute failed: Specified key was too long; max key length is 767 bytes
This happen, if you attempt to use Dada Mail with a version of MySQL that is below version 5.7. There are a few workarounds, the easiest seems to be to alter the database itself, by issuing the following SQL:
ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;
More information:
Died at /usr/lib/perl5/5.8.8/base.pm line 85
Upon visiting Dada Mail in your web browser, you get this fairly unhelpful message:
Died at /usr/lib/perl5/5.8.8/base.pm line 85.
BEGIN failed--compilation aborted at /DADA/MailingList/Subscribers.pm line 11.
Compilation failed in require at mail.cgi line 172.
BEGIN failed--compilation aborted at mail.cgi line 172.
Most likely what's happening is this:
The server you're running Dada Mail on doesn't have a DB file type available. Solution? Use the SQL backends.
If this happens after a server upgrade and a Dada Mail installation that was working, suddenly doesn't, yell at your webhost for taking away support for a DB file backend. I'd say something like:
Dear Web Host,
I was using your fine service, until one day I realized
you had taken away support for the Berkeley DB database ( or similar) library
Yours,
-- Your Name
If they do, your Dada Mail may magically work. If they don't, restore your lists (instructions are in this FAQ). If *that* doesn't work, you may have to switch to the SQL backend anyways and manually recreate your lists. Thems the breaks, I guess.
Dada Mail works great! Until I try to create a new list...
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.
lock files?
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.
CPAN Perl modules/conflicts
Introduction:
Dada Mail relies on specific Perl CPAN libraries that have a compiled version and a pure perl version. Usually, the compiled version is there as an option to enhance the speed of execution of the routines of the library itself. It's a good thing.
Problem:
You cannot bundle the compiled version of these libraries within Dada Mail, because they need to be compiled specifically for the OS that Dada Mail will run on, and that list is very large.
Solution?
At the moment, Dada Mail comes with a Pure Perl version of every CPAN Perl library module that it requires. Here is the list:
MIME::Base64
MIME::QuotedPrint
Data::Dumper
Digest
Digest::MD5
JSON
So, if you do not have these modules installed - it's OK, Dada Mail comes with the pure perl version of them.
Problem With This Solution:
The catch 22 to this is: if you HAVE these modules installed - and it's a really good chance you have at least one in the group installed, Dada Mail may produce an error saying basically, "I've got a newer/different/better version already! - whatcha doin'?!"
Solution to the Problem of the First Solution:
To counteract this, the above modules will be included in Dada Mail, but will not be active. This is done by appending, -remove_to_install to the file name/directory of these perl library modules. To make them active, rename the module to not include, -remove_to_install.
Examples:
- Base64.pm-remove_to_install -> Base64.pm
- Data-remove_to_install -> Data
-
(Note: Data is directory)
These files/directories are located in the: dada/DADA/perllib directory of the Dada Mail distribution.
If you can, install the compiled versions of these modules manually. If you can't/don't know how, rename the files as directed above. It's better to use the compiled version if you can. How to install these modules is a little over the pale of this particular document.
Data::Dumper object version 2.102 does not match $Data::Dumper::VERSION 2.121 at....
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.
Guts.pm: / < # opening angle bracket
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.
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.
can't open /usr/home/path/to/your/dada_lists to read
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.
can't open /usr/home/myaccout/lists to read: Permission denied
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.,
is only avaliable with the XS version
This problems comes to the surface when attempting to use the default CAPTCHA backend, as well as attempting to use the SMTP over SSL
This is a problem with the copies of Scalar::Util
and, List::Util
CPAN modules that come with Dada Mail.
See if you have the following directories:
dada/DADA/perllib/Scalar
dada/DADA/perllib/List
If so, renamed them:
dada/DADA/perllib/Scalar-bak
dada/DADA/perllib/List-bak
and see if this problem clears up.
I get the 'Congratulations' startup screen, but ...
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.
No mail is being sent and I get this error in my logs:
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.
Can't locate JSON.pm, charts/graphs that never load
Dada Mail uses the Google Visualization API to create its charts and graphs. This API needs its data given to it in the JSON format and Dada Mail uses the JSON CPAN module to create the data. If you do not have this module currently installed, you will need to install it, yourself.
See, Installing CPAN Perl Modules: https://dadamailproject.com/d/FAQ-installing_CPAN_Perl_modules.pod.html
If that's not an option, Dada Mail also ships with a disabled copy of JSON.
In the dada/DADA/perllib directory
, find the directory named,
JSON-move_contents_to_install
and the file named,
JSON.pm-remove_to_install
Move the files that are in,
JSON-move_contents_to_install
into
JSON
and rename,
JSON.pm-remove_to_install
to,
JSON.pm
Can't locate MIME/Base64.pm
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.
I moved my lists from one server to another and reinstalled Dada Mail. Now when I try access my lists, I get this error:
Software error: couldn't tie for reading: Permission denied
See the error faq about restoring your lists.
couldn't tie /home/path/to/your/dada_files/mj-listshortname for reading: File exists at [...]
See the error faq about restoring your lists.
How do I restore my lists?
Background
By default, Dada Mail saves its list settings and archives (there's also an option to saved archived messages in an SQL table) in a binary type file called a Database File, or DB file for short. Sometimes these files can become binary-incompatible with the environment you're running Dada Mail under. This can happen if:
Your hosting account was moved to a different server
You moved your hosting account to a different server
The server software was upgraded
Visit the following URL:
http://example.com/cgi-bin/dada/mail.cgi?flavor=restore_lists
You'll have to enter your Dada Mail Root Password and then you'll enter a screen that will allow you to restore your list settings/archives.
If you're using a version of Dada Mail under 2.10.6 and you're still receive an error after restoring your list settings/archives, take note of the file that's throwing the error and manually back it up and remove it. Usually, this file either did not get restored properly, or, was an archive file that had no archives saved in it. A bug in the program prior to 2.10.6 would have the latter stuck, even with the restoration feature.
Restoring list settings/archives is accomplished because Dada Mail keeps a plain text, platform agnostic version of your list settings/archives. This feature was put in Dada Mail, version 2.8.12. If you have a version of Dada Mail below this, this backup will not have been created. Upgrading Dada Mail will not create backups of a corrupted list to then restore from. List Setting/Archive restoration only worked with well after 2.9. If you have a installation of Dada Mail that needs to have lists restored that dates prior to 2.9, it's advised to upgrade to the latest version (make a backup, of course) of Dada Mail before attempting to restore your lists.
Read below for ways to restore a list if you're running a version below 2.9.
password is blank! - Error.
I receive an error that says,
List password for listshortname is blank! It is advised that you make sure your list settings file is not corrupted, or reset you list password. at /DADA/App/Session.pm line 123.
List passwords shouldn't become blank on their own, so if your password isn't set, other settings may have been lost because of whatever had happened too. It *may* be a good idea to start a new list if this is the case.
But! The easiest thing to solve this particular problem is to reset your password. In your web browser go to a URL like this:
http://example.com/cgi-bin/dada/mail.cgi?flavor=email_password&list=listshortname
Where, http://example.com/cgi-bin/dada/mail.cgi is the URL to your Dada Mail and, listshortname is the listshortname that's giving you trouble.
Hosting Company-Specific Problems
Frontpage Extensions-enabled accounts
Frontpage and Frontpage Extensions do not play well with Dada Mail.
If you receive errors that include file path with, _vti_cnf
For example:
[Tue Jul 11 13:19:34 2006] mail.cgi: Semicolon seems to be missing at
DADA/perllib/Mail/Field/_vti_cnf/AddrList.pm line 4.
You've been hit with the mighty, Frontpage-Extensions-Corrupted-My-Dada-Mail problem.
The, _vti_cnf directories have something to do with Frontpage - apparently, they hold some sort of configuration information for the program itself.
Here's one thing you'll have to do - you may not like it, but this is the best way to solve the problem:
You'll need to reinstall Dada Mail (I'm not kidding), or go through ALL the directories that make up Dada Mail, and take out every directory called, _vti_cnf (it's like a virus, I know!)
You'll then have to reinstall Dada Mail, but you have to make sure you do one very important step:
Instead of installing both the, mail.cgi file and DADA (uppercase) directory in the, dada (lowercase) directory in your cgi-bin, you're going to have to place the DADA directory in a place that's somewhere other than under your public html directory, and also update the, use lib statements in the mail.cgi file - and any other script that uses the libraries that make up the DADA directory. Here's what you're looking for:
use lib qw(
./
./DADA
./DADA/perllib
);
If you placed your, DADA directory at:
/home/youraccount/perllib_dada/DADA
You'd change the use lib statement to:
use lib qw(
/home/youraccount/perllib_dada
/home/youraccount/perllib_dada/DADA
/home/youraccount/perllib_dada/DADA/perllib
);
An annoyance for sure, but not the end of the world.
Here is the other option:
You can make a wrapper script that first goes through all the directories of Dada Mail for the _vti_cnf directories and removes them and their contents and then runs Dada Mail normally.
This has many disadvantages and can be dangerous - I'll explain the script and how to use it, and then list why this isn't the best idea.
First off, rename your, mail.cgi script to something like, real_mail.cgi. Create a new file called, mail.cgi and have this as its contents:
#!/usr/bin/perl
use strict;
use File::Find;
my %findings = ();
sub find_vti_cnf {
if($File::Find::dir =~ m/_vti_cnf$/){
$findings{$File::Find::dir} = 1;
}
}
find(\&find_vti_cnf, './');
my $file;
for my $dir(keys %findings){
if(opendir(VTI, $dir)){
my @file_deep_six_list;
while(defined($file = readdir VTI) ) {
next if $file =~ /^\.\.?$/;
chmod(0777, "$dir/$file");
push(@file_deep_six_list, "$dir/$file");
}
closedir(VTI)
or warn "couldn't close: " . $dir;
my $final_count = unlink(@file_deep_six_list)
or warn "could not remove any backup files! $!";
warn "couldn't remove $dir $!"
unless rmdir($dir);
}
}
do('real_mail.cgi');
Upload this script where the other mail.cgi used to be, chmod 755 it to make it executable and you should be in good shape.
Now, saying this - make sure you understand how this script work before ever using it:
This script goes through every single directory, looking for directories named, _vti_cnf. It'll then delete the contents of that directory and then, the directory itself.
You should feel very nervous about running a program that delete massive amounts of files/directories. Don't use this script unless you fully understand that fact, since the possibility - however small, is there that this script could delete a file you didn't want removed.
Send a Webpage Problems
Can't locate object method "redirects" via package "HTTP::Headers"
This problem usually deals with out of date versions of CPAN modules that are shipped with Dada Mail itself.
The easiest fix may for you to just do an upgrade of Dada Mail.
If you can not/do not want to upgrade, you can also try to download the newest version of Dada Mail and just replace the directory:
dada/DADA/perllib
with the copy of that directory that came from the downloaded distribution. Make sure to make a backup of the original, perllib
directory, first!
Can't call method "verify_data" on an undefined value at...
Error message will look something like this:
Can't call method "verify_data" on an undefined value at DADA/perllib/MIME/Lite.pm line 1992, <DATA> line 27.
Can't fetch http://example.com.org/page.html
(Can't locate object method "_is_html" via package "HTTP::Headers") at /DADA/App/MassSend.pm line 707.
In the,
dada/DADA/perllib
directory of your installed Dada Mail, renamed the, HTTP
directory to something like, HTTP-bak
and this error should clear up.
Assets w/URLS w/Query Strings break
If you're trying to send a webpage with an image, javascript library or stylesheet with a query string ala:
<script src="http://example.com/script.js?ver=1234" ></script>
The, "Send a Webpage" function of Dada Mail most likely won't understand what to do with this and most likely will ignore and remove the script, image or stylesheet.