From turnbull.stephen.fw at u.tsukuba.ac.jp Fri Jun 1 00:35:30 2018 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Fri, 1 Jun 2018 13:35:30 +0900 Subject: [Mailman-Developers] Idea of subscription options (beside Digest) In-Reply-To: References: Message-ID: <23312.52498.162327.328914@turnbull.sk.tsukuba.ac.jp> 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 1. Create a true user class that can have multiple email addresses associated with it, as well as multiple roles; 2. Arrange that preferences are hierarchical, so that there are 1. Site defaults, which can be configured by the site administrator. 2. List defaults, which can be configured by the list owner. 3. 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. :-) From galex-713 at galex-713.eu Sat Jun 2 12:38:19 2018 From: galex-713 at galex-713.eu (Garreau, Alexandre) Date: Sat, 02 Jun 2018 18:38:19 +0200 Subject: [Mailman-Developers] Idea of subscription options (beside Digest) In-Reply-To: <23312.52498.162327.328914@turnbull.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Fri, 1 Jun 2018 13:35:30 +0900") References: <23312.52498.162327.328914@turnbull.sk.tsukuba.ac.jp> Message-ID: 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? From andreaszoellner at gmail.com Fri Jun 8 12:56:35 2018 From: andreaszoellner at gmail.com (Andreas Zoellner) Date: Fri, 8 Jun 2018 09:56:35 -0700 Subject: [Mailman-Developers] Questions around mm3 plugins/templates Message-ID: <918F0095-042B-4F00-9255-1C9F9B200C40@gmail.com> Hello, I am looking into expanding Mailman 3 with a plugins for our use case. I?ve read through the documentation but have a couple of clarifying questions that I?m hoping to get answers for here. 1a) Can I provide templates to generate text/html messages or just plain/text? 1b) if not, would that be something that could be added with a plugin or is that better handled in core? 1c) Can a html template be introduced for a third digest type in addition to mime and plain? 2) Can a template change the subject line or just the body? 3a) Can a plugin add additional fields to a user? e.g. I want to store more specific preferences around topics or maybe day of week for digest delivery or a user title 3b) Can I easily pass those additional fields to a template? 4) How can mm3 be scaled horizontally? Let?s say I have an additional rule that takes a long time to process - Can I parallelize that step somehow? Thank you Andreas From andrew at hodgson.io Tue Jun 12 05:30:09 2018 From: andrew at hodgson.io (Andrew Hodgson) Date: Tue, 12 Jun 2018 09:30:09 +0000 Subject: [Mailman-Developers] Mailman3 access with a screen reader Message-ID: Hi all, Just starting to move lists that are mostly used by blind people to Mailman3. One thing we have found is that when tending to moderation requests, if you view the message in the web interface it seems invisible to screen readers when the message is viewed on screen. The window that comes up with the message and the buttons doesn't seem to read out for some reason using Chrome or Firefox with the latest version of Jaws. Has anyone looked at current access with a screen reader with the web interface? It mostly seems to work well. Thanks. Andrew. From geoff at QuiteLikely.com Wed Jun 13 06:55:38 2018 From: geoff at QuiteLikely.com (Geoff Shang) Date: Wed, 13 Jun 2018 13:55:38 +0300 (IDT) Subject: [Mailman-Developers] Mailman3 access with a screen reader In-Reply-To: References: Message-ID: Hi Andrew, On Tue, 12 Jun 2018, Andrew Hodgson wrote: > Just starting to move lists that are mostly used by blind people to > Mailman3. One thing we have found is that when tending to moderation > requests, if you view the message in the web interface it seems > invisible to screen readers when the message is viewed on screen. The > window that comes up with the message and the buttons doesn't seem to > read out for some reason using Chrome or Firefox with the latest version > of Jaws. I have to confess that I've not yet played with Mailman 3. :( Have you tried with NVDA? It should of course work with JAWS, but I have seen situations where one screen reader sees what another does not, and NVDA costs nothing to try. Also, it's a good idea to give specific version numbers instead of "latest", as "latest" doesn't mean much in six months time. Also, browser versions as well. Cheers, Geoff. From mark at msapiro.net Wed Jun 13 10:58:15 2018 From: mark at msapiro.net (Mark Sapiro) Date: Wed, 13 Jun 2018 07:58:15 -0700 Subject: [Mailman-Developers] Mailman3 access with a screen reader In-Reply-To: References: Message-ID: On 06/12/2018 02:30 AM, Andrew Hodgson wrote: > > Just starting to move lists that are mostly used by blind people to Mailman3. One thing we have found is that when tending to moderation requests, if you view the message in the web interface it seems invisible to screen readers when the message is viewed on screen. The window that comes up with the message and the buttons doesn't seem to read out for some reason using Chrome or Firefox with the latest version of Jaws. During the last PyCon sprints we did some accessibility testing and made some changes, but I don't know if we looked at that specific area. @Terri is the one who was working on this. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From mark at msapiro.net Fri Jun 22 13:37:32 2018 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 22 Jun 2018 10:37:32 -0700 Subject: [Mailman-Developers] Mailman 2.1.27 released Message-ID: <575ec64d-1d07-8044-124b-637d96c89121@msapiro.net> I am pleased to announce the release of Mailman 2.1.27. Python 2.6 is the minimum supported, but Python 2.7 is strongly recommended. This is a routine bug fix release with a few new features and some minor security enhancements. See the attached README.txt for details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see our web site at one of: http://www.list.org https://www.gnu.org/software/mailman http://mailman.sourceforge.net/ https://mirror.list.org/ Mailman 2.1.27 can be downloaded from https://launchpad.net/mailman/2.1/ https://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From maxking at asynchronous.in Fri Jun 29 23:39:23 2018 From: maxking at asynchronous.in (Abhilash Raj) Date: Fri, 29 Jun 2018 20:39:23 -0700 Subject: [Mailman-Developers] Mailman 3.2 coming up soon Message-ID: <1530329963.2350349.1425383304.11844BCA@webmail.messagingengine.com> Hi All, I am going to release Mailman 3.2 next week. which is going to include new releases for all components, including Postorius, Hyperkitty, Django-Mailman3, MailmanClient and finally Mailman Core. Note that all of these are now Python 3 only and support Python 3.5+. There already is a very long list of new features and bugfixes in these releases, but if someone wants me to look at some last minute bugfix that you want to get-in, let me know. -- Abhilash Raj maxking at asynchronous.in