Rework/Improvement of mailing-list functionality

[jens-maus]

Originally on 2010-03-06 00:25:03 +0100

---

The current mailing-list feature of YAM is more than just plainly useless and unintuitive. Currently a user has to configure a mailing list by creating a new folder and configuring the mailing list settings in the folder settings. This, however, seems to be somewhat awkward and not very intuitive and cumbersome.

Proposed change

A possible change/improvement could be:

• move the folder-wise mailing list configuration to the global YAM config window (own section)
• a user should be able to configure a mailing list in the YAM config using the following settings:
  1. configure mailing list address (To)
  2. configure if a mailing list sets a Reply-To: header or not (important for proper Mail-Reply-To support).
  3. set an optional destination folder where incoming mails should be moved to (this should generate hidden filter rules to move the mail to that folder based on To, etc. address)
  4. allow to setup the above settings semi-automatically like currently possible in the folder settings.
• the Mail-Reply-To and Mail-Followup-To features should respect these new configuration settings.
• the mailing-list To-addresses should be suggested when creating a new mail and entering something in the To recipient gadget
• when starting to create a new mail while being in a folder linked to a particular mailing list the write window should immediately contain the To address of that mailing list in the To recipient gadget.

[jens-maus]

Originally on 2014-05-12 09:21:30 +0200

---

Now that mailing list handling problems seem to be more and more common (see ticket #555) I feel we need to invest more time into completely rethinking how mailing lists should be handled in YAM. We have to not only move the configuration from a folder-wise configuration to a general YAM-wide configuration with options to bind these to specific folders (if this is still required). This would greatly improve the overall mailing list functionality. Thus, we will move that ticket to the 2.10 milestone.

[cpm1]

Well, as you closed #646: Remove the old broken mailing list "support" and replace it by a proper implementation of the List headers according to the RFCs and different reply-options as mentioned in #646. Thanks.

[jens-maus]

Thanks for you comments. The priority of this ticket is however already set to high, so this isn't a matter of putting more priority to this topic, but simple lack of resources to do so. So feel free to contribute ;-)

[tboeckel]

Ok, let's start over here. While it sounds quite simple to me to support at least the "List-Post" header as an alternative reply address this will reveal some more complications if the idea of multiple reply addresses is thought over more intensively.

Currently YAM already asks the user which addresses are to be used when replying to a mail with more than a single reply address. I suppose this to be a major feature of YAM in contrast to other mail clients where it is far too easy to reply to only one person instead of all possible recipient.

However, for a mailing list it would be quite annoying if the user gets asked whether to reply to the sender only or to the list or to both for each replied mail. For example, Thunderbird offers two button ("Reply" and "Reply to list"), but unfortunately "Reply" (to the sender) is the default action when pressing CTRL+R. How should this situation be handled in YAM and how should the GUI reflect these possible choices? It should be possible to reply to the sender only instead of the list easily, while still prefering the mailing list and recipient.

[cpm1]

I think you are overcomplicating something, which has already been solved in several MTUAs.

If List headers are available:

1. offer a new button "Reply to list" between "Reply" and "Forward" buttons (main and message window);
2. add a new menu item "Reply to list ... -L" to the message menu (or any other not yet used shortcut if L is already used);

If the user hits this button, set the List-Post: contents as recipient. Basic, but proper mailing list support done.

Now if the user hits the normal "Reply" button instead, go through the existing code path, show the multiple-address-requester if necessary, etc. You could even add a "Reply to list" option in that very requester, if List headers were found, to allow even the laziest people to find a way to answer to the list.