Justin J edited this page Nov 8, 2016 · 65 revisions
Clone this wiki locally

Dada Mail Wishlist!

Please add your own Wishes.

Bounce Handler

Partial Purge of Bounce Scores

In the cases where an email provider blocks a mail server, there are high hard bounce counts for emails from the blocked provider for the period that the server is blocked. It would be helpful to be able to filter the Erase Bounce Scorecard to only include certain domains so that the entire scorecard doesn't have to be erased just to get rid of the counts for the email addresses from the provider that was temporarily blocking the mail server.

Resend Previous Mass Mailings to individual addresses easily

it would be nice, as a trouble-shooting method and also as a service feature - when a member calls me to complain that they didn't get an issue, if there was a process to this effect: I could immediately view a member record in Membership, and then tick the left-hand box beside their record, and then have a button to click on to trigger "re-send a newsletter" or "re-send last newsletter" - maybe it displays the archives, and lets me click on the one to re-send, or tick a check box beside multiple issues, and then send each issue again to that subscriber - would be useful functionality. I expect I could then get a verbal "yeah" or "nope" from him in a few seconds, and then go on to help the member to debug (trash? spam bin?, email changed? etc.)...<shrug>

Multiple Autoresponders

Dada has almost all of the major features found in commercial mailing solutions, but one of the few that is missing is the ability to set up multiple autoresponse emails with dates scheduled for sending based on the date subscribed (IE send immediately, send on day 1, send on day 5, etc.). That would be very helpful for automated mailings that are sent to each new subscriber over a course of days or weeks after subscribing.

Updating membership records

I hope I am going to explain this properly... We run an offline partner database and it would be very useful to be able not have the email address as the primary source of reference for partners in the database. An example is in PHPList, you can create a profile field (which in Dada Mail's case would need to be to be set NOT to display on the sign up form) where I can store additional data that identifies a partner like a partner ID. Now if I have a batch of partners who have updated their details including email address (again this is an offline database) I upload a CSV and use the partner ID as the primary key for reference. This way I can update all details for which there are profile fields including email addresses. Dadamail seems to use the email address as the primary reference so if I want to update a number of email addresses I have to search for each individually and change. I realise this means that the membership email can be changed without interaction from the person owning the emailing address, but it would would then also be useful to be able to send a confirmation email to the recipient on the new email address to verify that that change is authorised, before the data is finally updated on the database, similar to an invite and confirm scenario.

Dada Mail uses email addresses as basically the primary key for mailing lists, but it also does have the idea of Profiles. Email addresses are still used when making relationships with mailing lists, but a profile should have its own primary key. The scenario you're asking for would be awkward to fit in with Dada Mail though, and would take an entire architectural redesign

Password Protect Directories

Emails Should Not Be Case Sensitive

When inputting an email and password to access a password-protected directory, the login fails if the email is not all lowercase. It would be more user-friendly if emails were case insensitive.


Email Tracker Summary of Mass Mailing to List Owner

Emailing a summary of the tracker stats for each mailing (after 4-8 hours or so - preferably let the list owner set the time) including the number of bounces, opens, clickthroughs, and the other few items summed up at the top of the tracker page would be incredibly helpful. It would give an idea of performance, but more importantly, it would alert the list owner to any potential problems with the mailing such as excessive bounces due to ISP blocking.

Summary Page

It would be useful to have the tracker summary page display unique opens instead of total opens since that is the more commonly needed statistic. (If it could also display the % for opens on that page, that would be helpful, but that might be a space issue.)


Starting New Log Files Periodically

Log files on active lists become extremely large (hundreds of MB or more, sometimes exceeding the host's memory limits for a hosting account). An option in the admin dashboard to automatically create a new log file and save the old one with the date appended every XXX days/weeks/months would be helpful in keeping the file size manageable. Ideally, this would come with the ability to search both the current log and any older logs in the Logs area of the dashboard, as well as offering the option to purge/delete old logs.

Mass Mailing

Add Operators for Partial Mailing List Sending

Related Forum Topic

It'd be good to have numeric operators (Is Less Than / Is Greater Than) added to the existing operators for partial mailing list sending. That way simple date filtering can be done to send mail only to a certain age group (calculations on a DoB field), for example.

I'm thinking in particular storing a date in the format YYYYMMDD in a profile field, which would allow simple date calculations.

Make sure the temp subscription list for a mass mailing is fresh

(this could almost be seen as a bug)

We sometimes keep the emails in the list in queue so that all the emails will go, one after the other. But if the users unsubscribe in between, they are still receiving the pending emails. I guess the Dada mail is actually taking the subscriber list for the first email and using the same list for sending the rest of the emails.

Message Archives

Threaded Archive Views

https://metacpan.org/module/Mail::Thread could help with this!

Subscription Management

Reasons for Unsubscribing

It would useful if unsubscribers had the option to tell us why they're unsubscribing. I just unsubscribed from a mailing list that uses PHPList, and this list had an optional "Tell us the reason you're unsubscribing" box. That reminded me of how often I've wished I'd known the reasons behind unsubscriptions from the Dada Mail lists I manage.


Access the original poster in via the templating system.

Just being able to refer to the original poster via a template tag would be a good idea, like this:

   (originally posted by <!-- tmpl_var original_poster --> )

Use P.P. mode for Announce Only Lists

Because announce only lists often have emails being sent to the list sent from off-domain addresses, DMARC is triggered. For discussion lists we can enable P.P. mode to circumvent the problem, but not for announce only lists. Emails from off-domain are getting lots of bounces. It would be very helpful to have P.P. mode available for announce only lists, and it would be fantastic if we could have template tags (mentioned below) for the sender's name & email so that we could have that display at the top of each message to make it clear who the message is from. If there was also an option in the settings to choose the "reply to" address to be the sender email instead of the list email, that would be even better.

Rejecting Messages based on the Date: header

It may be useful to reject messages that Dada Bridge sees as too, "old", by simply reading out the Date: header and comparing it what the date is now. Sometimes, if there's problems with some part of Dada Bridge, messages queue up (perhaps for days) and once everything is cleared, you then get awash with outdated messages that go to the list all of a sudden.

Moderation of non-subscribed addresses


I've used Mailman in the past, and it's behavior is that is sends a moderation request, which has the possibility to add the e-mail address to the Authorized Senders list, or to just pass it along. And off course to reject the message.

I'm using Dada mail for a small private subscription list. The logic behind this is that sometimes when a subscribed user sends or replies to a message on this list, they sometimes select (willingly or by accident) another account in their e-mail client.

Perhaps this can be feature request? So that there's an option to allow messages from unsubscribed email-addresses to go to the moderator queue?

More flexibility with prepending Subject lines in discussion lists

May I suggest/request that for this setting, we be allowed to specify the exact text that gets used in the subject? Eg. if we don't want the actual list name to be used but some other word instead, or perhaps we don't want the list name surrounded by [square] brackets, but by {curly} or (regular) brackets instead, or whatever.

I'd certainly like to be able to specify the text that gets prefixed to the Subject field myself. Due to reasons I won't bore you with, I'd prefer to use something other than the listname in square brackets.

So my vote would be for the Discussion List plugin to just have a field which is by default set to [<!-- tmpl_var list_settings.list -->] but which I can change to whatever I fancy. :)

PGP Support

The below is from an email from a subscriber of Dada Mail List:

        Yes, that's right.  OpenPGP provides two main functions with email:
        encrypting and signing.

        Encrypting is obvious, concealing the message or file contents from
        everyone except those to whom the message was encrypted (or anyone
        with the symmetric session key).  Messages are encrypted with public
        keys and decrypted by each recipient with their private key.  Well,
        technically messages are encrypted with a symmetric cipher and
        protected with a single use passphrase (the session key), then that
        session key is encrypted with the public keys of each recipient.  When
        a recipient receives an encrypted message their OpenPGP software
        (usually GPG or PGP) decrypts the session key component using their
        private key and passphrase and uses the session key to decrypt the

        Signing uses the private key to produce a digital hash (e.g. SHA256 or
        SHA512) of the message or files.  Recipients of signed messages then
        use the sender's public key to verify that the message was actually
        signed by the sender.  If it was the signature is then determined to
        be either a good signature or a bad signature.  A good signature
        indicates that the message has not been modified in transit.  A bad
        signature indicates that either something went wrong during the
        signing process or that the message was modified in some way.  If the
        message in the sender's outbox or sent folder is good, but the
        recipient receives a bad signature then something (or worse, someone)
        has modified the message.

        If you reply, you're more than welcome to baby-step me on this
        topic, I'm dim on a lot of things in life :)

        OpenPGP supports two methods for signing and/or encrypting messages:
        PGP/in-line and PGP/MIME.

        PGP/in-line has the advantage of working with almost anything, but it
        fills the message with base64 encoded text.  It also frequently breaks
        extended character sets when used with signatures, but not encryption.
        This can be a real problem when corresponding with users from northern
        and eastern Europe or Asia, who use those character sets in their
        names.  Also, the visible presence of base64 encoded data can confuse
        some users.  Furthermore, PGP/in-line will only encrypt or sign the
        body of the message and not any attachments.

        PGP/MIME works with any supported character set and takes advantage of
        the other features of MIME.  It also uses the base64 encoding, but
        encases it in MIME wrappers to keep that out of most users' faces and
        to use them with other multi-part MIME components.  A message
        encrypted or signed using PGP/MIME will affect the message body and
        any attachments sent at the time it was sent.  It does not sign the
        headers or other attachments (e.g. footers) appended after the message
        leaves the mail client.

        When this message is sent it will be sent with a PGP/MIME signature
        and a copy of my public key.  You will be able to view the message
        source and see the PGP/MIME structure to see what I mean.

        The OpenPGP RFC has full details on how it works and section 6
        discusses the base64 encoding and MIME support:


        MIME itself is covered in RFCs 2045, 2046, 2047, 2048 and 2049:


        What's happening with Dada Mail is that it supports enough of MIME to
        recognise that a PGP/MIME component is a MIME component (systems that
        don't will treat the PGP/MIME signature as an attachment).  So you're
        already part of the way there.  The problem is that the list footer
        message appended to every post to any list, is written to the bottom
        of the message body instead of attached as another MIME component.  By
        doing this the PGP/MIME signature will *always* read as a bad
        signature because the message has been modified in transit (by Dada

        If that footer were attached in MIME format instead of rewriting the
        message body, the PGP/MIME signatures would be preserved and the
        messages should be verified correctly, as would any attachments.  Mail
        clients which support MIME (i.e. most of them, including text based
        ones like Mutt and Elm) should still display the footer seamlessly
        beneath the message.

        By the way, one of the reasons I'm concerned about this for the
        particular organisation using Dada Mail is that it is a political
        party and my country, Australia, has a bit of a history with faked
        email scandals.  The biggest one being the OzCar Affair in 2009:


        There was another one last year which I blogged about and I think you
        can probably guess what my recommended solution was:


Pretty interesting stuff!

Strip out ALL attachments

Currently, you have to list the MIME types you'd like removed. Perhaps a simple, "remove everything!" would be helpful

Template tags for sender of message

Template tags are used for the reciever of a message, but perhaps a set could be used, for the sender as well.

    <!-- tmpl_var sender_subscriber.email -->

Yadda yadda.

Ability to reply to the sender or the mailing list

9.4.1 allows for mailing list replies to go to either the original sender or the whole list, and an additional option that would allow the responder to chose to reply to either would be useful. Unsure as the best way to engineer this setting- perhaps an option to have the original sender is included as a CC in postings?

Sender Header

Adding the Sender header to emails


I'd love for Dada Mail to (optionally) add a Sender header to outbound mail, as some other mailing list apps already do. It particularly makes sense for discussion lists, where the From header is always that of the person sending the email through the list, and therefore the From header varies from email to email (and might not always be recognised by the recipients in a large mailing list). The Sender header then can be set to the identity of the mailing list itself, which then provides a quick and easy way for the recipeints to see that the email came from that list, particularly when they don't recognise the name in the From header. However even for announce-only lists, the Sender header might be useful in some cases.

Some mail clients will even display the Sender header by showing that the email came from "Mailing List Name on behalf of John Smith", which can be particularly helpful.

The Sender header should be customisable on a list-by-list basis. Both the "name" part and the "email" part of the Sender header should be customisable. Some list owners might want to set the Sender header to that of the list owner's address (bounce address), while other owners might want to set the Sender header to the discussion list (Dada Bridge) address. Yet other owners might not want/need the Sender header at all, so it should be disabled by default and only available for those who want it.

Other benefits include making it easier for the recipients to filter the emails (they can filter on the Sender header), and making it easier for the recipients to whitelist the emails (by adding the list's address, which is contained in the Sender header, to their whitelist or their address book). The Sender header is also used by some mail authentication schemes, such as Sender-ID and DomainKeys, for authentication of mail sent from a mailing list.

For further information on why I think the Sender header is a good idea, please check out the discussion at the above URL.

Amazon SES

The error messages about blacklisted email addresses, going over a sending quota are pretty easy to grok and it would be nice if there was more close integration with Dada Mail and SES for these. for example, if Amazon SES comes back that you're over your sending quota for the day, well, stop sending messages! :)

Beatitude: Test Messages to Everyone (not just List Owners)

For some reason, the only option to send a test message to, is the list owner. That should be opened up to allow you to send a test message to anybody.


"Fast" Invitations

it would be nice to not have to see the "Send a List Invite" screen, but instead, just send out the invitation as it is - save a step.

as of v5.1.0, the invite message is hidden, unless you want to reveal and customize it - justingit

Blacklist link invites?

Is it possible to add a "no thanks, not now and not ever" link to an invite which would instantly add the email address to the blacklist?

Sending out a few thousand invites recently it became apparent that some recipients thought they were already subscribed (even although it was clearly worded as an invite), replying with "UNSUBSCRIBE" as the subject among other things. I manually went into admin and added these to the blacklist to make sure that they wouldn't get any future invites if they happen to be on any invite list.

It would be handy of I could have added to the invite, something like: -

"You are currently not subscribed and will not receive regular mailings from us.

You may, however, receive further invites to join our mailing list in future. If you'd rather not receive these click on this link...."

with the link adding the address to the blacklist...

Subscriber field data editing by list owner

Would like the addition of a parameter selectable by the DADA Administrator to allow List Owners to edit Profile Field content data. The Admin should know whether the member listings are compatible enough to allow this.

In v7 and above, look for the option, Allow Profile Field Editing in, Membership - Options

Time Zone Tweaking

Dates and Times shown are server-centric, and if you live in a different part of the world, they're not very useful when figuring out when you've sent something.


It'd be nice to have an option in SMTP Options to use STARTTLS (which usually works on ports 25 and 587) besides plain SSL on port 465 which is slowly being deprecated.

STARTTLS should be mutually exclusive with SSL (maybe 3 radio buttons: NO ENCRYPTION / SSL / STARTTLS)

Membership charts

I'd like to be able to suppress the charts in the Membership views, particularly on the Recent Activity page, where the chart preceeds the text and takes up a lot of screen space. The charts aren't really of any use to me or the other list administrators in my particular application of Dada Mail.

User variables available in thank you email

It would be nice to customise a link based on the value of afield in the user profile....

eg User signs up for emailing list indicates they own a dog

The thank you for subscribing includes a link to a pdf about dogs

eg Thank you for subscribing to the pet emailing list here is a thank you download

www.somewebsite.com\download\{user field variable}.pdf in this case www.somewebsite.com\download\dog.pdf

Some else indicates they own a cat