[Mailman-Developers] Idea of subscription options (beside Digest)

[Garreau, Alexandre]

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…