[Profile Register/Log In] (What's This?)

RE: Bounce Handler Developments - Questions

From: "Mary Ann" <maryann@thehomeschoolmom.com>
Subject: RE: Bounce Handler Developments - Questions
In-Reply-To: Bounce Handler Developments - Questions
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



<< Previous: Re: Dada Bridge strips out emails in CC

| Archive Index |

Next: question about $MAILOUT_AT_ONCE_LIMIT >>

(archive rss , atom rss/atom )

this list's archives:


This mailing list is to discuss the nerdy programming development of Dada Mail -

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

http://dadamailproject.com/support/boards

To post to this list, send a message to:

dadadev@dadamailproject.com

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

Some on topic... topics include:

  • Positive Crits 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 internal 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 -

At the moment, there aren't many people with CVS access for Dada Mail - if you would like CVS access, please first talk about the changes you propose and how it will affect the program. If the idea is sound and agreed upon, the change will be comitted. A good track record of this will allow you to have CVS access. Some reasons that patches will not be accepted is if the patch breaks compatibility with a previous version of the program, the patch is too centric to your own problem or the patch simply isn't very good.

Please, please please familiarize yourself with the documentation at:

http://dadamailproject.com/support/documentation/

Since no one wants to answer the same question twice.

Another sneaky reason for this mailing list is to test out the discussion list capabilities of Dada Mail, since Dada Mail is used for the mailing list itself.

NOTE - because of this, there may be times that this list will be somewhat broken. Although we're not planning on breaking the program by using it, we're giving you the heads up that this may well happen anyways.

Subscribe to Dada Mail Developers

* Required

Loading