Final thoughts on mailing list accountability stuff?

 
From: "Justin J" <justin@PROTECTED>
Date: March 14th 2011

I'm most likely going to close this topic out soon, and collate all the thoughts presented into a plan to follow for the Next Major Release of Dada Mail If you have any more ideas, please see the topic and add your voice:

http://dadamailproject
com/support/boards/viewtopic
php?t=2457

Right now, I think the best thing to do would be the following:

  • Save the date with the subscription!

Knowing the day of a subscription can help with administrating a user (or self-administrating yourself, as a subscriber), and can also help out, if you want to do a search-by-date, before sending out a mailing list message Right now, it's a little obscure how it is that you're supposed to bring up subscription history information on a particular subscriber, without slogging through the logs

  • Save the confirmation status of a subscription!

Confirmation in this case would be what the addressee has done to confirm a subscription, have they gone through a closed-loop opt-in process or not? Or, is it unknown?

This could be another field that could be searched on, throughout the program

  • Integrate some of the new, interesting email sending API's that are now out there

The ones I'm most interested in are Amazon's Simple Email Service:

http://aws
amazon
com/ses/

And PostmarkApp:

http://postmarkapp
com/

Both which required only confirmed subscribers, when sending out a mass mailing using their API's That's what the new confirmed subscription?/verified subscription? field will be for The upside to using these API's is that you also can circumvent any and all hourly email limitations your current hosting provider may have That sort of means, you can send, really really fast, which I know is what everyone wants to do :)

Since everyone is going to start out with a mixed bag of subscribers - ones that there's a record of confirmation and ones that don't, it makes sense to be able to support sending to each group of subscribers, so some people on your mailing list will benefit from sending through one of these APIs, but you can still send the rest the Same Old Way Maybe better receiving rates will be enough of a carrot to convince people to confirm their lists, without forcing them to

Some other ideas presented were really good, including being able to "remind" people you've invited and generally keep track of people who have answered an invite with either a, "yes!" or a, "no!" or haven't answered at all That way you can really see if your invitation is working

Some things I Like, but DO NOT want to do is force someone to comply to a type of subscription model - ie: requiring only confirmed subscriptions or not There's always a, "but I need " to make it work right It's like having a nightclub without a guest list Being able to label a subscription as confirmed or not is enough for me

I'd like to finalize this spec and publish it as, "What Dada Mail 5 is Going to Be" and start a Fundraiser to kickstart things

So, this is the final call for comments :) (I'll put the above as the last entry in the thread)

Thanks for everyone's help - I know it can be thankless and anonymous, but it's so important to the life of the program :)

  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)
  • Start a new thread, email: dadadev@dadamailproject.com

This is the developer discussion mailing list for Dada Mail.

If you are just looking for support Dada Mail, consult the message boards at:

https://forum.dadamailproject.com

Documentation for Dada Mail:

https://dadamailproject.com/d

Specifically, see the Error FAQ:

https://dadamailproject.com/d/FAQ-errors.pod.html

To post to this list, send a message to:

mailto:dadadev@dadamailproject.com

All subscribers of this list may post to the list itself.

Topics that are welcome:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

Dada Mail is on Github:

https://github.com/justingit/dada-mail/

If you would like to fork, branch, send over PRs, open up issues, etc.

Privacy Policy:

This Privacy Policy is for this mailing list, and this mailing list only.

Email addresses collection through this mailing list are used explicitly to work within this email discussion list.

We only collect email addresses through our Closed-Loop Opt-In system.

We don't use your email address for any other purpose.

We won't be sharing your email address with any other entity.

Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.

All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.

All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.