Dada Mail Support Forum

Hurray!

Weird. Is there anything strange being reported at the end of the app's own error log? That would be in, ~/.dada_files/.logs/errors.txt (since you can sometimes/somewhat log into an individual list). Part of me suspects there's some security filter being hit when you try to use Dada Mail. That would...

When you run the installer, under Backend I'm sure MySQL was selected, but did it also say "not available"?

The following Perl Cpanel module would need to be installed,
https://dadamailproject.com/d/FAQ-insta ... s.pod.html

I just tested this, and seems to work as I described.

Are you using Bridge to send out messages? If so, it's an option within the plugin labeled,

[x] Prefix message subjects with the:

(and then allows you to select a few choices)

That would only impact things if you're using the Custom Mass Mailing Layout. One way to do what you want to do is change the subject in the theme itself. Background: https://dadamailproject.com/d/features-email_themes.pod.html So the file you're probably looking for is, mailing_list_message.txt You...

Is there any more information being printed in the error log?

This error pops up when either the Stop Forum Spam check is failing, or the suspicious IP Activity check is failing. You may want to see if either are enabled in your settings (in Mailing List: Options), and disable them temporarily.

mike_m wrote: ↑

Thu Apr 20, 2023 7:55 am

Is there a way to disable/hide the subscribe_landing page for uninvited users? (I can't empty the subscribe_landing.tmpl because it is used also for invited subscribers to confirm their subscription).

Make your list a private list, then make your list hidden?

It's fairly clunky, I agree - what you describe as expected behavior was the past behavior. The problem is GDPR, which means you really shouldn't be sending out an invite message at all, as it's technically an unsolicited mass email and the subscription confirmation isn't technically a closed-loop o...

Only <!-- tmpl_var subscriber .first_name --> will be parsed correctly. Is there a way to access and display the sender's information as well? No, I don't believe the information for the actual From: header can be accessed. Good idea though! I've added it to the issue tracker for a future feature: ...

This?

https://blog.dadamailproject.com/2017/0 ... ver-https/