Re: iOS unsubscribe
> I understand the whole thing about stopping automated processes, but I don’t think this has to be automated to that degree. Just inserting the same link that is at the bottom (the one that takes them to the unsubscribe page) would work fine.
I'm a little confused, as the article you linked just says that iOS sends an email using the email embedded in the List-Unsubscribe header, and does nothing with the unsubscribe link. So, removing the email would do... I guess remove the unsub button?
> It seems inefficient for each list manager to have to handle this in code and keep up with manually making the change after each update, when this is a trend that isn’t going to go away.
Well, there is no feature to manipulate the List-Unsubscribe header, that's true. It's probably not going to be a priority for me to add this feature. I'm faced many times with the problem that adding features means adding complexity, and complexity itself causes confusion. I'm not sure if it seems worth it, in this scenario, but rather use the best practices as spec'd in the RFC. It's true that many times my decisions are not always something that users agree with, but the source is there to allow that sort of customization.
> As it is, Dada is forcing them to use the option that doesn’t do what it is supposed to (unsubscribe the email) and makes work for the list manager (by generating a reply that has to be manually dealt with). I can’t see how this is an advantage to anyone.
I mean, I sort of disagree, it's doing what it's supposed to do: it's alerting the list owner that someone wants to unsubscribe. It does require manual intervention by the list owner, but the list owner should, I think know how to remove someone from their list manually, as the scenario will still happen: people do just reply directly to the mailing list, asking to be removed. The List Owner will never be able to remove themselves from this responsibility.
- 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 used for this mailing list are used only for this mailing list and are not sold or transfered. You will not be subscribed to any other lists on this site as well.