RE: Bounce Handler Developments - Questions

 
From: "Mary Ann" <maryann@PROTECTED>
Date: October 19th 2011

I'm thinking of making the Soft Bounce Score, Hard Bounce Score and the Score Threshold (the score that needs to be hit before a bounced message is removed from the mailing list ) something that can be customized on a per-list basis, instead of it being a global (and impossible to set, without diving into the config file, which isn't something people seem to like to do) value. Good idea?

      YES! This would be a huge help. Being able to adjust this through the front end would be wonderful.

Going one step further, I'd like to also have a new option available (again, per-list): instead of an outright deletion of the subscriber from the mailing list, perhaps instead the address is moved to a, "currently bouncing" sublist, so that the list owner can more easily look over the addresses (and the history of the bounced messages per address) and perhaps see *why* the messages are bouncing. From there, the list owner can make a choice of:

        *  removing the address once and for all,

        *  sending a, "Hey, you're bouncing! Are you really there? Confirm that you're still there and resubscribe!"

        * allowing a list owner to just simply re-subscribe an address and remove them from the "currently bouncing" sublist

        * or, well, nothing

      This would be incredibly helpful - more so than anything else you could do with the bounce handler. Bounces are a major problem, especially when an ISP temporarily blocks a server like you mentioned, and being able to look at them and decide what to do with them would be HUGE.

I'd also like the individual address Profiles have an option to see if they're currently bouncing on any of the lists they're subscribed to, and if so, allow them to make a move on their own.

Good idea?

      Yes.

What's the contention from this group? Stick with what's used now (One bounce email address per (*entire* installation) or, change it to one bounce handler email address per *list*?

      I don't really care one way or the other about this. I can see the reasons for it and while it would be more email addresses to set up and keep up with, it would really only be more work at the beginning when you set up a list or upgrade to the new version of Dada, so I can live with it either way.

Any other ideas? :)

      When looking at the bounced email addresses to decide what to do with them, if you could set it up so that you can mass manage them (with checkboxes and a Check All/Uncheck All feature) and add the ability to filter by a string (thinking of being able to filter to single ISP) that would eliminate repetition.

      That's it off the top of my head, but I'll ponder it. Thanks!

Warm regards,

Mary Ann

Post:
mailto:[list_settings.discussion_pop_email]

Unsubscribe:
https://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/

List Information:
[PROGRAM_URL]/list/[list_settings.list]

Archive:
[PROGRAM_URL]/archive/[list_settings.list]

Developer Info:
http://dev.dadamailproject.com

Mailing List Powered by Dada Mail

  • 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.