Idea of subscription options (beside Digest)
In case you were lacking useful high-level features idea, while arguing recently about good netiquette of citing, not citing, puting or not puting original sender in this or that header, and also less recently about who to exclude/censor/ban or not from a mailing list, I found some that might be useful so to standardize mailing lists working per user instead of per mailing-list, so at subscription propose potential following options, beside “Digest mode”:
“Don’t send me mail with ‘X’ and ‘Y’ CW” (CW = content-warning): X being either specified in subject line (more accessible) such as “[CW X, Y]”, or in a specific header (more discrete) such as “X-Content-Warning: X, Y”, where X and Y are tags/abbreviations such as “sex” (for sexually-explicit)/“nsfw”, “politics” / “sexism” / etc. (more shocking or offending stuff), etc. or even maybe generalizing the concept to more common stuff such as “ot” for “off-topic”, “flamewar”, “rp” for “roleplaying” so that to make the concept more widely known and tested. May be really useful to continue threads that might really interest people and strive for democratic debate, without risking to repulse some people from the mailing-list, and without having to ban some people or discussions, and without continuing the discussions in private (that might exclude silent and not-enough-participating people).
“Mail me too, altogether as other mailing-list members”: this has become a widely inconsistant behavior for me between mailing lists and mailing-lists softwares, I can never recall it, nor can I recall to configure my user-agent to store a copy of what I sent or not. A such option, instead of making this consistent over a single mailing list or software, would make it consistent per user, and might be more convenient for them. Also could help expliciting the configured default for each mailing-list
“Mail me regularely a reminder” (about that I’m subscribed and how to unsubscribe, may be really useful for low-trafic mailing lists) or even “unsubscribe be after X delay of inactivity”.
“Don’t mail me again mails that are already also addressed to me” (when the member is already cited in To, Cc, or Bcc for instance) since some people do complain about receiving some mails several times, and it might relieve mailing lists of sending more mails.
“Don’t mail me mails from threads I’ve not participated in, except first message”, the most complicated, and would require to keep a list of participant to a mailing-list, or a local mapping of message-id to source mail addresses (so you can check References header instead of recursively Reply-To). But this might encourage a lot of people to join a lot of mailing lists, and some mailing lists to touch a lot more people, as the traffic would be lower, and they might still react to announces and important stuff discussed there.
“Don’t mail me mails from threads I didn’t started”: actually a misunderstandement of the previous one that I did explain, also a lot more easy to implement I guess, and that may be useful for mailing lists which don’t allow to send mail through them if you’re not subscribed. May be a disablable option in case you wan’t your subscribers list to stay a list of people who follow your list, and not just a list of people who may want to post, otherwise you might prefer allow everybody to post to your mailing list.
Hope I’m encouraging and giving more ideas than I’m disturbing or seeming expectative. I find these would be really lovely features, but not being a lot used to python, nor to going into large unknown code base, I don’t think that would easy for me to improve mailman for those… but I’d like, if you have time and that doesn’t disturb you, to have your opinion on these.
Thank you anyway!
Garreau\, Alexandre writes:
that might be useful so to standardize mailing lists working per user instead of per mailing-list,
This won't happen in Mailman 2. In Mailman 3, what we've done is
Create a true user class that can have multiple email addresses associated with it, as well as multiple roles;
Arrange that preferences are hierarchical, so that there are
Site defaults, which can be configured by the site administrator.
List defaults, which can be configured by the list owner.
User settings, configured by the user.
4a. User per-list settings, configured by the user.
4b. User per-address settings, configured by the user.
with the later settings overriding the earlier ones. (I forget the precedence between 4a and 4b, so "4a" and "4b" rather than "4" and "5".)
I think that does what you want, right?
so at subscription propose potential following options,
I'm not sure if you intended this, but I will take a look at the default welcome messages. It might be useful to provide a list of available options that the user can tweak for their subscriptions, or even their whole initial configuration, in the welcome message.
“Don’t send me mail with ‘X’ and ‘Y’ CW” (CW = content-warning): X being either specified in subject line (more accessible) such as “[CW X, Y]”,
Either this is "topic" (created by the list owner and used by the posters), which we already have in Mailman 2, and are improving for Mailman 3, or it is AI, and doesn't belong in Mailman (see the discussion of filtering below).
a widely inconsistant behavior for me between mailing lists and mailing-lists softwares, I can never recall it, nor can I recall to
In Mailman 2, this is a general property, and is due to the lack of a real "user" concept in the software design. It will be much better for you in Mailman 3. If you want a consistent experience across lists, get your list administrators to use Mailman consistently! ;-)
“Mail me regularely a reminder” (about that I’m subscribed and how to unsubscribe, may be really useful for low-trafic mailing lists)
Already in Mailman, but many list owners prefer to disable it because their users consider the reminder to be spam, and report it to their email providers, who may make real list traffic undeliverable to all subscribers on their platform. (Not so much a problem today, but AOL was infamous for this.)
or even “unsubscribe be after X delay of inactivity”.
I'd oppose this on the grounds that it's going to be rarely used, and an annoyance for list managers who get hate mail from ex-subscribers who forgot they set that option.
“Don’t mail me again mails that are already also addressed to me” (when the member is already cited in To, Cc, or Bcc for instance) since some people do complain about receiving some mails several times, and it might relieve mailing lists of sending more mails.
Already in Mailman. This is a possible exception to the rule that filtering is best done by the user agent, but it can be equally well done by the user agent.
In general, filtering is best done in the user agent because it needs to be extremely flexible, really a special-purpose programming language. If yours doesn't do it, consider switching; it's a feature I use all the time. I couldn't even keep up with my employer's mail without it (it's in Japanese which has to be the world's most difficult second language ;-).
BTW, in the following I'm going to recommend changing to a competent user agent many times. I know that "the customer is always right", and that users hate changing mail clients. But I *don't* recommend switching because implementing these features is a lot of work for us. The main point is that it is *impossible* for us to *make these decisions well* on the server, while the *client* has the option of making the decision itself, or asking the user. The client will do a *much better* job. Even if the user is not a hacker, configuring a powerful client will serve her needs more accurately than anything we can provide server-side, except for the very simplest cases like "don't send duplicates".
Also, note that *we* don't care about the work as such: it's a labor of love. The problem with work is that it takes time (often years) for volunteer developers to deliver such features, while competent clients are available *now*.[1] The sooner users switch to them and learn to use them, the longer they'll be happy. :-)
Here's an example, which looks simple but in fact really requires the mailing list manager software to read both the posts and your mind:
“Don’t mail me mails from threads I’ve not participated in, except first message”,
There's no good way to identify threads as a human would want it done, because of thread hijacking and topic drift. Inevitably subthreads you want to see will get suppressed, which requires a "send me what I didn't see" feature on the server side, which is a huge complication and in any case involves significant delay. This is partially alleviated by referring to threads archived by the server on a website, but means you have to switch back and forth between your mail client (or inbox tab) and the browser (or archive tab). Most people have enough bandwidth that just receiving 10x as many emails is not a burden as long as the user agent makes it easy to skip them.
In particular, many user agents provide a feature where threads are "collapsed" at the start, and only get expanded when the user decides to read one. This is exactly what you describe as a user experience, and the implementation ("send all mail") matters only if you are severely storage- or bandwidth-restricted. This seems likely only if the mailing list is used to distribute large multimedia attachments, but in my experience this is very rare nowadays -- people use the web for that.
a lot of mailing lists, and some mailing lists to touch a lot more people, as the traffic would be lower, and they might still react to announces and important stuff discussed there.
This is best done by having separate low-traffic lists, or using topics, although both have serious problems in the user experience too. A good user agent is worth its weight in gigaflops.
“Don’t mail me mails from threads I didn’t started”:
The only time I would find this useful is when I've sent a problem report to a mailing list rather than a bug tracker. In that case I'd ask the vendor to set up a tracker or web forum like StackExchange.
Do you have another use case? I didn't find "subscriber-only" persuasive as a general matter; there are lots of discussion lists which require subscription to post nowadays, as it's a relatively useful barrier to spam. And once again, a competent user agent or filter like procmail could do this for you.
Hope I’m encouraging and giving more ideas than I’m disturbing or seeming expectative. I find these would be really lovely features,
Most are already present, or beyond current server-side technology while already acceptably implemented in good user agents. I hope you'll look into configuring them in Mailman lists you're already using (in Mailman 2, for many options you can set them for all lists on that server with that address subscribed, so it's not that inconvenient). And as we roll out new releases of Mailman 3, with better support for user configuration options, I hope you'll support the administrators of lists you use in migrating to Mailman 3. (At present because of the complete reorganization of the database, it's painstaking to upgrade, but we're working on that.)
Steve
Footnotes: [1] You probably don't want to ask me to recommend one; I use Emacs and procmail. :-)
Le 01/06/2018 à 13h35, Stephen J. Turnbull a écrit :
Garreau\, Alexandre writes:
that might be useful so to standardize mailing lists working per user instead of per mailing-list,
This won't happen in Mailman 2. In Mailman 3, what we've done is
[…]
I think that does what you want, right?
In great part, yes indeed. However my core asking was more about making some settings possible user-wide rather than like currently only system or list-wide, as you said later.
so at subscription propose potential following options,
I'm not sure if you intended this, but I will take a look at the default welcome messages. It might be useful to provide a list of available options that the user can tweak for their subscriptions, or even their whole initial configuration, in the welcome message.
That’s exactely what I was asking, as long as, maybe, more checkboxes on the web interface too: as I mainly used webinterface, since it is (probably because of configured mail queue delay) always faster (quasi instantaneous), while mails can be a lot slower (not to get an automated answer but even to take effect, as the web confirmation link for instance stays valid quasi until reception of confirmation mail, so receiving rather than sending is probably the bottleneck there).
“Don’t send me mail with ‘X’ and ‘Y’ CW” (CW = content-warning): X being either specified in subject line (more accessible) such as “[CW X, Y]”,
Either this is "topic" (created by the list owner and used by the posters), which we already have in Mailman 2, and are improving for Mailman 3, or it is AI, and doesn't belong in Mailman (see the discussion of filtering below).
Would it be AI to binarily filter according keywords manually specified by user? It only is filtering by keyword. With keyword either present in topic, or in a special header (would be better imho). And with their filtering as an user option (on subscription, via mail or web interface) *and* as a list-wide config (so by default some keyword, typically, defined by some general policy, so that users don’t receive certain mail unless they explicitly allowed so).
“Mail me regularely a reminder” (about that I’m subscribed and how to unsubscribe, may be really useful for low-trafic mailing lists)
Already in Mailman, but many list owners prefer to disable it because their users consider the reminder to be spam, and report it to their email providers, who may make real list traffic undeliverable to all subscribers on their platform. (Not so much a problem today, but AOL was infamous for this.)
But wouldn’t it be useful to have it controlable also on a per-user basis?
or even “unsubscribe be after X delay of inactivity”.
I'd oppose this on the grounds that it's going to be rarely used, and an annoyance for list managers who get hate mail from ex-subscribers who forgot they set that option.
Ok, thank for this relevant information answer :)
“Don’t mail me again mails that are already also addressed to me” (when the member is already cited in To, Cc, or Bcc for instance) since some people do complain about receiving some mails several times, and it might relieve mailing lists of sending more mails.
Already in Mailman. This is a possible exception to the rule that filtering is best done by the user agent, but it can be equally well done by the user agent.
In general, filtering is best done in the user agent because it needs to be extremely flexible, really a special-purpose programming language. If yours doesn't do it, consider switching; it's a feature I use all the time. I couldn't even keep up with my employer's mail without it (it's in Japanese which has to be the world's most difficult second language ;-).
I agree, the same for me, and I was also a bit confused because I only received this mail in my misc folder (and not my list folder), from your mail server, without the “list-*” headers, and never received the list version: is this setting enabled here? Then why (if you too consider this bad?)?
Also I’m asking this because, and that was the main incentive to write to this list, I recently argued with some person on a GNU mailing-list and with Evolution hackers about the practice of putting the individual person you answer to in the “to” header and other correspoundance and the mailing-list in the “cc” one.
I (and most corresponders I know I had on GNU mailing-list) considered these headers of being of semantic significance (the implementations always being configurable, especially the mail user agent, but not only), while others considered this practice a bad-netiquette practice as well as a source of network as well as file noise.
File noise being reducable by a well configured user-agent (still Evolution hackers seems to be a bit reluctant, because of considering this a bad practice), and network noise by either MUA/MTA (not sending to others when sending to mailing-list) or mailing-lists (not re-sending the message to people already included). Though giving MTA capabilities to MUA (like making them contact directly the distant MTAs) or embedding mailing-list related capabilities into MTA seems less realistic and likely than to add this as a mailing-list setting.
So, because of such complains, I’d think a such setting, but *per-user* (that you might configure either at subscription via the web interface, either by mail) might be useful for such people, and for maintaining arguments for a such semantic usages of headers (that I see is also in practice here).
I know that "the customer is always right", and that users hate changing mail clients. But I *don't* recommend switching because implementing these features is a lot of work for us.
Also, note that *we* don't care about the work as such: it's a labor of love. The problem with work is that it takes time (often years) for volunteer developers to deliver such features, while competent clients are available *now*.[1] The sooner users switch to them and learn to use them, the longer they'll be happy. :-)
Having competence and user-friendliness not inversely-proportional is not always a feature of now x) and sometimes MUA such as claws, thunderbird, evolution or kmail are not configurable enough…
The main point is that it is *impossible* for us to *make these decisions well* on the server, while the *client* has the option of making the decision itself, or asking the user. The client will do a *much better* job. Even if the user is not a hacker, configuring a powerful client will serve her needs more accurately than anything we can provide server-side, except for the very simplest cases like "don't send duplicates".
Here's an example, which looks simple but in fact really requires the mailing list manager software to read both the posts and your mind:
“Don’t mail me mails from threads I’ve not participated in, except first message”,
There's no good way to identify threads as a human would want it done, because of thread hijacking and topic drift. Inevitably subthreads you want to see will get suppressed, which requires a "send me what I didn't see" feature on the server side, which is a huge complication and in any case involves significant delay. This is partially alleviated by referring to threads archived by the server on a website, but means you have to switch back and forth between your mail client (or inbox tab) and the browser (or archive tab). Most people have enough bandwidth that just receiving 10x as many emails is not a burden as long as the user agent makes it easy to skip them.
I thought to either comparing canonicalized (stripped, whitespace-joint, unicode-canonicalized, prefix (re/aw/etc., fwd, etc.) stripped, suffix stripped (“\(was:.*\)|was.*|\[was:.*\]”) subject lines, that would be imperfect but do most of the work most of the time, either identifying threads using reply-to and references, that would require storing information for each thread, or subthread (or even message-id), for instance in a database… so really much complicated work yes, but not impossible. Just to ask, would it would be. As I got this suggested. But it was by people who said you shouldn’t expect to participate in a mailing-list you’re not subscribed to (yet considering them as public places).
In particular, many user agents provide a feature where threads are "collapsed" at the start, and only get expanded when the user decides to read one. This is exactly what you describe as a user experience, and the implementation ("send all mail") matters only if you are severely storage- or bandwidth-restricted. This seems likely only if the mailing list is used to distribute large multimedia attachments, but in my experience this is very rare nowadays -- people use the web for that.
That feature was, in my mind, exactely a question of bandwitch, as I consider too that otherwise user-agent should do the work. Yet it may be possible that the person who I have talked about this with may have thought to it as a largerly convenience feature. It stays at the same time of minoritary usefulness, limited usage and complexity of implementation :/
a lot of mailing lists, and some mailing lists to touch a lot more people, as the traffic would be lower, and they might still react to announces and important stuff discussed there.
This is best done by having separate low-traffic lists, or using topics, although both have serious problems in the user experience too. A good user agent is worth its weight in gigaflops.
For high-traffic mailing-lists this is true, but creating an ad-hoc announcement-like mailing-list for each low/medium-level one would be exagerated…
“Don’t mail me mails from threads I didn’t started”:
The only time I would find this useful is when I've sent a problem report to a mailing list rather than a bug tracker. In that case I'd ask the vendor to set up a tracker or web forum like StackExchange.
Do you have another use case? I didn't find "subscriber-only" persuasive as a general matter; there are lots of discussion lists which require subscription to post nowadays, as it's a relatively useful barrier to spam. And once again, a competent user agent or filter like procmail could do this for you.
As I said, if the limitation is network (or if the user-agent nor the user is unlikely to change) and you want not to be bothered by your required subscription in order to post some mail, that may be useful. Of course for now this is a suggestion for comment, and it’d have to be balanced with (un)ease of implementation.
Hope I’m encouraging and giving more ideas than I’m disturbing or seeming expectative. I find these would be really lovely features,
Most are already present, or beyond current server-side technology while already acceptably implemented in good user agents. I hope you'll look into configuring them in Mailman lists you're already using (in Mailman 2, for many options you can set them for all lists on that server with that address subscribed, so it's not that inconvenient). And as we roll out new releases of Mailman 3, with better support for user configuration options, I hope you'll support the administrators of lists you use in migrating to Mailman 3. (At present because of the complete reorganization of the database, it's painstaking to upgrade, but we're working on that.)
Yes, as lists.gnu.org is still running mailman 2, maybe without my knowing all of these are now implemented inside mailman 3 at a user level without me to know ^^'
BTW, in the following I'm going to recommend changing to a competent user agent many times.
I already did that, what I can’t do is to convince people I discuss with to, that generally won’t work as an argument in favor of this of that netiquette or “correct usage” on mailing-lists: yet standards (headers, “netiquette”) are harder than implementations… and as mailman is one implementation…
Footnotes: [1] You probably don't want to ask me to recommend one; I use Emacs and procmail. :-)
I do too, except I never used VM nor Rmail, and I currently have my maildir filled by my MTA (which listen on my VPN public IPs) on my laptop, mostly using mobile 3G, yet currently, thanks to bittorrent I guess, I upload a lot lot more than I download (including mail traffic) so I guess that’s the reason I’m don’t get to pay more than planned (although they don’t refund me either x))
Yet I then don’t have neither something to recommand others, beside hoping Emacs get more ergonomical default keybindings and flexible graphical abilities in the future, for my english-fluent (tech or young enough) correspondants, for the other, the lack of internationalization will eternally remains…
participants (2)
-
Garreau, Alexandre -
Stephen J. Turnbull