Loading

Error FAQ

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.

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 can 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";

You may read the error log file directly by downloading it, etc.

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 View plugin on the left hand menu, under: Plugins - 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 save the support community the need to ask you and come prepared with the following information, or as much as you can gather/is relevant:

Please use the Dada Mail Support Boards, Discussion List and/or Issues Tracker to report errors and receive help through the Dada Mail community. Frequently asked-about problems are listed below, hopefully with advice and solutions.

If you do post a question about an error to the Dada Mail support boards or dadadev mailing list, the first thing you're usually going to be asked is error log snippets, as well as the Version of Dada Mail you are running.

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:

http://dadamailproject.com/support/documentation-7_4_1/global_variables.pod.html#_cpan_debug_settings

Enabling debugging settings in these modules may help debug issues such as:

$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:

General Problems

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: FAQ-mailing_list_sending.pod.html

The majority of mass mailing delivery problems is 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:

Other reasources dealing with the content of your message, primarily:

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:

Problems Logging In

Sometimes, people find that it's impossible to log into Dada Mail's list control panel.

Some things to double-check:

If those problems don't help matters, sometimes it helps to set Dada Mail to use a different session type.

The session type is set in the config variable, $SESSION_DB_TYPE. It can be set to, SQL (you'll need to setup the SQL backend for this to work), DB, PlainText - and, if all else fails, Classic.

All these session types work the same way, but Classic is the least secure - we don't recommend using it, but if it helps you get out of a pinch, then it can help you get out of a pinch.

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:

http://dadamailproject.com/support/documentation-7_4_1/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)

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:

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.

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.

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, How to install CPAN modules: http://dadamailproject.com/d/FAQ-general.pod.html#how_do_you_install__cpan_perl_modules

Dada Mail also ships with a disabled copy of JSON. In the dada/DADA/perllib directory, find the directory named,

JSON-remove_to_install

and the file named,

JSON.pm-remove_to_install

and rename them:

JSON

and,

JSON.pm

respectively.

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.

Software error: ndbm store returned -1, errno 28

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.

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:

Visit the following URL:

http://example.com/cgi-bin/dada/mail.cgi?f=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?f=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.

Beatitude (scheduled_mailings.pl)

Byte order is not compatible

The error will look similar to this,

        [Sat Sep 1 02:19:42 2012] scheduled_mailings.pl: Byte order is not compatible at /usr/local/lib/perl5/5.8.8/x86_64-linux/Storable.pm line 417, at ../DADA/perllib/MLDBM/Serializer/Storable.pm line 27

Try restoring your Schedules, by using going to the Restore Mailing Lists screen in Dada Mail - ie:

http://example.com/cgi-bin/dada/mail.cgi?f=restore_lists

You will only need to restore your mailing list Schedules.

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.

Dada Mail Project

Download

Installation

Support