-
Notifications
You must be signed in to change notification settings - Fork 40
WishList (Deprecated)
Please use Issues:
https://github.com/justingit/dada-mail/issues
and tag your issue with the label, feature request
instead of adding your wishlist item, here.
Please add your own Wishes.
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.
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>
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.
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
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.
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.
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.)
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.
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.
(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.
MailChimp and other commercial mailing list providers let you schedule messages for delivery at a designated time in the recipient's time zone. I'd love to be able to say, "Everyone gets this message when it's 9:30 a.m. in their respective time zone, regardless of what time it is in mine."
https://metacpan.org/module/Mail::Thread could help with this!
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.
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 --> )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.
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.
http://dadamailproject.com/support/boards/viewtopic.php?t=2751&p=10714#p10714
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?
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. :)
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
message.
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:
https://tools.ietf.org/html/rfc4880
MIME itself is covered in RFCs 2045, 2046, 2047, 2048 and 2049:
https://tools.ietf.org/html/rfc2045
https://tools.ietf.org/html/rfc2046
https://tools.ietf.org/html/rfc2047
https://tools.ietf.org/html/rfc2048
https://tools.ietf.org/html/rfc2049
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
Mail).
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:
https://en.wikipedia.org/wiki/Utegate
There was another one last year which I blogged about and I think you
can probably guess what my recommended solution was:
http://www.adversary.org/wp/?p=432Pretty interesting stuff!
Currently, you have to list the MIME types you'd like removed. Perhaps a simple, "remove everything!" would be helpful
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.
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?
http://dadamailproject.com/support/boards/viewtopic.php?f=7&t=2770
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.
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! :)
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.
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
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...
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
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)
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.
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
www.somewebsite.com\download\cat.pdf
etc...