On May 20, 2015, at 7:02 PM, OCO Admin oco_admin@ottawachamberorchestra com [Dada Mail Developers] dadadev@PROTECTED wrote: Does the installer script really require 5 10? Perhaps it could be made to work with 5 8 and if /usr/bin/perl is <5 10 look in other paths (like cpanel) for a different version of perl?

Unfortunately, it does, as it also is written using the CGI::Application framework, which is why I bumped up the min Perl version from v5 8 8 to v5 10 v5 10 isn't anything bleeding edge or anything - it was released in 2009 I do believe Perl v5 22 is about to be shipped, shortly Why the system Perl is kept at such an ancient version is simply silliness

The place to put the code to change the shebang line is probably in the uncompress_dada cgi script, which does not have any outside prereqs I'm trying to keep it that way - and keep the script as lightweight as possible To do the whole, "let's figure out other legitimate paths to Perl" correctly would take a sizable amount of code to do correctly I may simply have a list of other paths, a way to see if they exist, a way for the user to pick a different path to perl, and a way to replace the shebang line with the other path That's about ten lines, I think ;)

Do you know why the default curl user agent doesn't work and my installation requires this extra option? Is it related to a specific cpan library version? I thought it was something that would affect all Dadamail users, not just my installation

No, I hope that you did ;)

It's not related to the app at all, since curl is its own app My guess is that it's your web server not accepting connections, based on the user agent that's given What you're doing, by setting a user agent, is a work around When Dada Mail connects to web pages (say, when sending out a web page) it also sets a fake user agent string, to look like a browser, rather than like an app That's the theory, anyways If I can get a confirmation on that, I'll add it to the docs for setting up the cronjob

The problem was that the sendmail command returned success after every batch and there were not any errors Is there a way to turn on more logging? I can try again I suspect it was the hosting provider and it was very frustrating to not get any errors

Super frustrating - welcome to my world! :) If the sendmail command is giving back a false positive, it's a horrible tool to have to rely on and that's where the problem is Sometimes hosts do try to give back some sort of error message, but no one seems to want to do it in any sort of reasonably similar way Dada Mail is written in a way to read the return value and act upon it - usually, it'll try 3x, before logging the address that's causing problems, and moving on to the next address Perhaps sending using the same mail server, but via SMTP would be more beneficial?

One way to debug the problem is to get access to the sendmail logs, which could be difficult, if you do not have complete access to your server

Another option is to ditch local mail sending completely, and use a third party tool like Amazon SES - for a variety of reasons, it seems the best way to go - especially if you're relying on a shared mail server, on a shared hosting account

I cannot find any error messages related to SES credentials in any of the logs, only the warning in the web interface dialog Is there somewhere I can enable more logging?

I don't believe there is for SES, but if you're getting errors like that, more information should be reported in Dada Mail's own error log There are many other ways to bump up the logging of things in other parts of Dada Mail,

http://dadamailproject
com/d/install_dada_mail-advanced_configuration
pod
html#Configure-Debugging