Bounce Handler Developments - Questions
I'm starting to do some work on the bounce handler. You can follow my work at:
The first change I've made is to put the Scorecard in that first main screen, instead of having to press a button to see it, and also to changing the navigation to be AJAX calls, so you can quickly zoom through the scorecard, without a whole page refresh. It's nice.
I'm also working on some of the bounce rules and the algorithms that parse the bounced messages and get them working better and in some cases, up to date.
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?
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
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? There's instances where bounces happen when a mailing list is temporarily put on a email black list - not necessarily because of any action from the mailing list (ie; shared mail servers with another user causing the problems). These temporary problems can go unnoticed for a while and messages can bounce from a large part of your list. Before you know it, a percentage of your list has been unsubscribed because of bouncing. Not good! This type of bouncing should be easily undone by the list owner. Thus, all these new tools.
The other big question is one of preference:
Right now, the bounce handler email address is global, and works for all mailing lists at once. Some people have asked if it's possible to set this per-list. The argument is that there's problems with information about one list bleeding over to another list and they'd like to keep mailing lists as separate as possible. They also would like the domains of the list owner to match the domain of the bounce handler, for hosting accounts that host more than one domain at one time (and where this is easily done)
The argument against having a bounce handler email address per mailing list is, you have to set up a new bounce handler email address, per mailing list. Which, in the long run, is easier.
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?
Any other ideas? :)
- 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: firstname.lastname@example.org
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:
To post to this list, send a message to:
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
- 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:
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.
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: email@example.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.