[Mailman-Users] Re: Member posting to a list but address not in membership list.

[Chip Davis]

Could you have included them in "accept_these_nonmembers" in "Sender 
filters" under "Privacy options..."?


-Chip-

On 1/11/2022 11:29 PM, Mark Sapiro wrote:

On 1/11/22 7:51 PM, Adam Morris wrote:

I have someone who is posting to a list I run.
I subscribed them originally but their address doesn't show up in 
the list of members so I can't change moderation status etc.

Where else could I look to find their address?


What list of members are you looking at? The list at, e.g. 
https://example.com/mailman/roster/ doesn't show hidden 
members. You have to look at 
https://example.com/mailman/admin//members.




--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Problem with the Approved message confirmation

[Chip Davis]

This happens regularly on the lists that I administer, usually as a 
result of a well-meaning subscriber 'cc:'ing a non-subscriber, who 
then replies back to both the subscriber and the list.


Since I have to deal with the moderated message anyway, I simply send 
the non-subscriber a short note explaining that their note has been 
accepted, but that further correspondence on the subject should be 
sent directly to the subscriber who 'cc:'d the note to them.


It's not automatic, but the delta effort is only slightly more than 
what is necessary to reject the attempted posting.


-Chip-

On 6/4/2021 11:12 AM, Ivan Tejeiro Izquierdo wrote:

To summarize Mark and not drive you crazy, what we need is that the person who 
sends an email to a moderate list, whether or not they belong to the list, 
receive the email that tells them if their post has been accepted or rejected.


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Need to add two addresses to a bunch of lists as allowed senders.

[Chip Davis]

I used to allow 'accept_these_nonmembers' for discussion list members 
who just couldn't seem to remember their subscription address.  This 
was true even when replying to a post due to forwards they had set up.


Then we reached the point that most of the members had multiple 
addresses and a majority wanted multiple 'accept_' addresses. 
Maintenance of those addresses became a major headache, primarily 
because there is apparently no way to associate a name with an address 
in the 'accept_' list.  Also, members would leave by unsubbing their 
primary address but had no way to delete their 'accept_' addresses.


These are discussion groups for membership organizations, so I finally 
put my foot down and said "no alternate addresses", and somehow 
everyone manages to remember their subscription address. The only 
reason I use 'accept_' addresses is for temporary special cases like 
non-members involved in special projects.


-Chip-

On 4/10/2021 8:48 AM, Christian Buser via Mailman-Users wrote:

Hi Jürgen

You need to get the other addresses of the users into your server anyway. I do 
not think a user would subscribe with an address and then again with the other 
- and probably he doesn’t even know that there is a possibility of a „silent“ 
subscription.

You have to maintain the list of „non-members whose messages are accepted“ the 
same way. I do not see any automatism. Your „work load“ remains the same.

When a message needs moderation (because someone is subscribed with a different 
address), I can manually add his „new“ address with the „no message“ option 
ticked.

Our server does not send automated membership reminders or password reminders.

Grüsse aus Helvetien
Christian




--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Newbie question - installing on GoDaddy?

[Chip Davis]

Vicki, there are a lot of moving parts to installing Mailman on a 
website, so I'm afraid you'll get more answer than you had question. ;-/


GoDaddy's least-expensive "web hosting 
" plan includes CPanel 
which, on many web-hosting vendors, provides a "one-click" 
installation of Mailman.  Unfortunately, about four years ago GoDaddy 
unceremoniously removed Mailman from their cPanel options.  That 
doesn't preclude installing Mailman on a GoDaddy-hosted website if you 
really need to, but it raises the complexity and pain astronomically.


Fortunately, there are quite a few web-hosting vendors out there who 
still include Mailman in their cPanel options; at least one of them 
has been a frequent contributor to this discussion forum.  Perhaps 
he'll contact you off-list.


Once you find a host that has a Mailman-installing cPanel however, 
you're on your own for _configuring_ Mailman to your needs, but all 
the nice folks here can help you with that.


-Chip-

On 1/17/2021 4:49 PM, Vicki Mieth wrote:
Has anyone installed mailman on a GoDaddy based website?  Did you 
have problems?
I need this functionality, but I'm not that much of a techie to feel 
comfortable without asking someone who has done this before.


Thank you.


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Removal of Line Breaks in Replies to Digest Messages

[Chip Davis]

As regards thread hijacking, there is an IETF 'In-Reply-To:' header 
 that keeps track of 
that, regardless the string in the 'Subject:' header.  Without that, 
creating a threaded email display would be a nightmare.  This is one 
of the most constant (re-)training issues I have to address as a 
Mailman admin.  That, and the necessity of trimming quotes. :-/


-Chip-

On 11/18/2020 9:09 AM, Michael Reeder LCPC wrote:

Okay, upon reflection I think I figured out what happened here.  I
 replied to an existing thread but deleted the entirety of the
 message thread and changed the subject entirely.  I thought that
 started a new message thread but perhaps the list software registers
 that as a reply to an existing thread.  I organize my email client
 by date and not by thread so I would not see this.  Apologizes to
 all if this is the case.
   
On 11/17/2020 9:21 PM, Michael Reeder LCPC -- Hygeia Regular wrote:
 
   I agree with not hijacking threads...  What hijack?  Looks to me

   like I started a new topic.  Right??


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Help with Topics

[Chip Davis]

Thank you, Gentlemen!

That was quite enlightening and _very_ helpful.

I'm very grateful for your extensive explanations and examples and am 
going to give Topics a try and see if the subscribers take to them.


-Chip-

On 10/13/2020 5:51 PM, Mark Sapiro wrote:

On 10/13/20 1:56 PM, Chip Davis wrote:

Thanks for the suggestion, Richard.

The only downside to that is that your 'Subject:' line now has least
three identifiers: the list-id, the admin-id, and the topic-id.

     Subject: [FlyGuys] [Admin] [B-26] Re: cockpit vent repair

I was hoping to avoid the Subject bloat, and it crossed my mind that the
list-id itself could be considered the common "topic".  I wasn't sure if
the string "[FlyGuys]" in the Subject would be recognized as a "topic",
or if it would be ignored because it was the list-id.  Or if it
mattered, since its primary purpose is to enable the "no-match filter"
option in the first place.


As noted in another reply, matching on subject_prefix won't work.

Also, I don't understand 'subject bloat'

Consider defining a topic named Get_only_nonmatchind with a regexp ov say

^This_is_a_bogus_topic_that_I_hope_will_never_match_a_real_message_ig35yth3hg3ot4ohj430$

And a description of say

Subscribe to this topic and enable receiving messages that don't match
any topic to receive only messages that don't match any other topic.



Any insights would be appreciated.

Question 2: If a 'Subject:' line has multiple topic-ids, will a copy of
the posting will be sent to the union set of members of the topics?

Short answer - Yes

What you call multiple topic IDs are actually just things that match a
topic regexp.

For example, if topic1 has regexp \WMailman\W and topic2 has regexp
\Wlist\W, any message containing a Subject: or Topics: header or pseudo
header containing the word Mailman (matched case insensitively) will be
delivered to every regular member subscribed to topic1 plus those
subscribed to no topics. Any message containing a Subject: or Topics:
header or pseudo header containing the word list (matched case
insensitively) will be delivered to every regular member subscribed to
topic2 plus those subscribed to no topics. Any message containing a
Subject: or Topics: header or pseudo header containing both the words
Mailman and list (matched case insensitively) will be delivered to every
regular member subscribed to topic1 plus those subscribed to topic2 plus
those subscribed to no topics.



IOW, if a member is subscribed to those topics will he get multiple
copies in that case?

No.


Question 3: What effect do Topics have on subscribers receiving the
Digest?  Are they effectively subscribed to all Topics?


Digests contain all messages without any regard to topics.



I see great potential for the use of Topics in our group, but I don't
know where to find the answers besides here.




--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Help with Topics

[Chip Davis]

Thanks for the suggestion, Richard.

The only downside to that is that your 'Subject:' line now has least 
three identifiers: the list-id, the admin-id, and the topic-id.


    Subject: [FlyGuys] [Admin] [B-26] Re: cockpit vent repair

I was hoping to avoid the Subject bloat, and it crossed my mind that 
the list-id itself could be considered the common "topic".  I wasn't 
sure if the string "[FlyGuys]" in the Subject would be recognized as a 
"topic", or if it would be ignored because it was the list-id.  Or if 
it mattered, since its primary purpose is to enable the "no-match 
filter" option in the first place.


Any insights would be appreciated.

Question 2: If a 'Subject:' line has multiple topic-ids, will a copy 
of the posting will be sent to the union set of members of the 
topics?  IOW, if a member is subscribed to those topics will he get 
multiple copies in that case?


Question 3: What effect do Topics have on subscribers receiving the 
Digest?  Are they effectively subscribed to all Topics?


I see great potential for the use of Topics in our group, but I don't 
know where to find the answers besides here.


Thanks!

-Chip-

On 10/13/2020 3:57 PM, Richard Damon wrote:

I create one topic that I request everyone using topic to select for
important administrative messages from the moderator of the list. That
gives them something to select if they don't want any of the normal topics.

On 10/13/20 3:21 PM, Chip Davis wrote:

I'm trying to set up Topics for a Mailman 2.1.33 list I administer,
and I'm a tad confused.

There appears to be no combination of options to allow a member of a
list to see _only_ non-topic-specific postings.

If you select one or more topics of interest, you will receive the
postings under those topics.  You will not receive any
_topic-specific_ postings that do not match your selections.
Furthermore, if you have also set "Do you want to receive messages
that do not match any topic filter?" to 'Yes', you will also receive
all messages that are _not_ associated with a topic.  Otherwise, you
will receive _only_ the postings associated with your selected
topics.  (This appears to function as expected.)

However, if you have not selected any topics, you will receive all
postings, whether topic-specific or not, regardless the setting of "Do
you want to receive messages that do not match any topic filter?".

I would like to offer the members of my lists the option of receiving:
   1. All of the postings to the list [All topic categories selected +
no-match filter=Yes]
   2. Specific topics and all non-topic postings [At least one topic
category selected + no-match filter=Yes]
   3. Specific topics only [At least one topic category selected +
no-match filter=No]
   4. Only _non-topic_ postings [No topic categories selected +
no-match filter=No]

Apparently that is not the heuristic being applied.  If no topic
categories are selected, the no-match filter setting is ignored (i.e.
defaults to 'Yes') effectively delivering all listserver traffic to
that user, and eliminating option 4.  This is "as documented" and
embarrassingly empirically demonstrated.  :-/

There seems to be no obvious way to say "I want to see only those
postings that are not topic-specific".

If I put the list's subject_prefix in as the Topic1 regexp (escaped as
necessary), would the member be able to select it and specify
'no-match filter=No' to receive _only_ the non-topic-specific
postings?  (I would test this question myself, but see "embarrassingly
empirically demonstrated", above.)

If this question has already been addressed in a document somewhere,
please point me to it.

Thanks!

-Chip-


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Help with Topics

[Chip Davis]

I'm trying to set up Topics for a Mailman 2.1.33 list I administer, 
and I'm a tad confused.


There appears to be no combination of options to allow a member of a 
list to see _only_ non-topic-specific postings.


If you select one or more topics of interest, you will receive the 
postings under those topics.  You will not receive any 
_topic-specific_ postings that do not match your selections.  
Furthermore, if you have also set "Do you want to receive messages 
that do not match any topic filter?" to 'Yes', you will also receive 
all messages that are _not_ associated with a topic.  Otherwise, you 
will receive _only_ the postings associated with your selected 
topics.  (This appears to function as expected.)


However, if you have not selected any topics, you will receive all 
postings, whether topic-specific or not, regardless the setting of "Do 
you want to receive messages that do not match any topic filter?".


I would like to offer the members of my lists the option of receiving:
  1. All of the postings to the list [All topic categories selected + 
no-match filter=Yes]
  2. Specific topics and all non-topic postings [At least one topic 
category selected + no-match filter=Yes]
  3. Specific topics only [At least one topic category selected + 
no-match filter=No]
  4. Only _non-topic_ postings [No topic categories selected + 
no-match filter=No]


Apparently that is not the heuristic being applied.  If no topic 
categories are selected, the no-match filter setting is ignored (i.e. 
defaults to 'Yes') effectively delivering all listserver traffic to 
that user, and eliminating option 4.  This is "as documented" and 
embarrassingly empirically demonstrated.  :-/


There seems to be no obvious way to say "I want to see only those 
postings that are not topic-specific".


If I put the list's subject_prefix in as the Topic1 regexp (escaped as 
necessary), would the member be able to select it and specify 
'no-match filter=No' to receive _only_ the non-topic-specific 
postings?  (I would test this question myself, but see "embarrassingly 
empirically demonstrated", above.)


If this question has already been addressed in a document somewhere, 
please point me to it.


Thanks!

-Chip-
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Help with Topics

[Chip Davis]

[Re-sent after not getting my copy back from the listserver after five 
hours.]


I'm trying to set up Topics for a Mailman 2.1.33 list I administer, 
and I'm a tad confused.


There appears to be no combination of options to allow a member of a 
list to see _only_ non-topic-specific postings.


If you select one or more topics of interest, you will receive the 
postings under those topics.  You will not receive any 
_topic-specific_ postings that do not match your selections.  
Furthermore, if you have also set "Do you want to receive messages 
that do not match any topic filter?" to 'Yes', you will also receive 
all messages that are _not_ associated with a topic.  Otherwise, you 
will receive _only_ the postings associated with your selected 
topics.  (This appears to function as expected.)


However, if you have not selected any topics, you will receive all 
postings, whether topic-specific or not, regardless the setting of "Do 
you want to receive messages that do not match any topic filter?".


I would like to offer the members of my lists the option of receiving:
  1. All of the postings to the list [All topic categories selected + 
no-match filter=Yes]
  2. Specific topics and all non-topic postings [At least one topic 
category selected + no-match filter=Yes]
  3. Specific topics only [At least one topic category selected + 
no-match filter=No]
  4. Only _non-topic_ postings [No topic categories selected + 
no-match filter=No]


Apparently that is not the heuristic being applied.  If no topic 
categories are selected, the no-match filter setting is ignored (i.e. 
defaults to 'Yes') effectively delivering all listserver traffic to 
that user, and eliminating option 4.  This is "as documented" and 
embarrassingly empirically demonstrated.  :-/


There seems to be no obvious way to say "I want to see only those 
postings that are not topic-specific".


If I put the list's subject_prefix in as the Topic1 regexp (escaped as 
necessary), would the member be able to select it and specify 
'no-match filter=No' to receive _only_ the non-topic-specific 
postings?  (I would test this question myself, but see "embarrassingly 
empirically demonstrated", above.)


If this question has already been addressed in a document somewhere, 
please point me to it.


Thanks!

-Chip-
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: Reply-To: Poster via archive?

[Chip Davis]

... and, one hopes, elides the irrelevant archive postings.  [Sorry, 
one of my eldest crotchets.]


-Chip-

On 9/23/2020 2:11 PM, Mark Sapiro wrote:

If the user wants to reply to the poster in this way, she needs to edit
the recipients when composing the mail. I recognize this is
inconvenient, but no changes are contemplated.

On 9/23/20 8:11 AM, Thomas Gramstad wrote:

A subscriber to a list I have with a public archive, has NOMAIL set and
only reads and responds via the archive. But even though the list is set
up with Reply-To: Sender as default, this subscriber, even when he is
logged in, gets Reply-To list instead of Reply-To to poster when he
replies via the archive. Is there a way to reply to poster when reading
and replying via the official list archive?

--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: extracting a lists's setting to move the list to a new domain

[Chip Davis]

As a lowly list admin with a number of cPanel-hosted Mailman2 lists, I 
cannot avail myself of such tools without opening a ticket with my 
ISP.  While they have been very responsive in the past, I don't feel 
that's a generosity of which I should frequently avail myself. Also, I 
wanted to have a backup from which I could recreate any list, as well 
as a tracking process for all changes I make.


So I wrote two Rexx program, one to extract the membership 
information, including all the admin settings available via the web 
interface.  The other program extracts almost all of the list 
configuration settings/values accessible via the admin web interface.  
("Almost all" because some screens have never changed from their 
defaults, and I haven't gotten around to including them.)


All they require is the Regina interpreter and the REXX/CURL function 
library (libcurl), both GPL'd offerings, if anyone is at all interested.


-Chip-

On 9/20/2020 6:38 PM, Mark Sapiro wrote:

On 9/20/20 1:42 PM, Brian Carpenter wrote:

On 9/20/20 4:35 PM, Steven Jones wrote:

I cant find anything on extracting a list's settings, owners etc and
then using those to create a new list on a new domain.

Is there a simple operational command to extract and inject?


The tool for this is mailman's bin/config_list which can both esport and
import list configuration but not list membership.



Do you have root or admin access to the server? There are tools in the
bin directory that allows for such functions via the command line. You
can retrieve your list roster using the who command via email. Also the
list/listname/config.pck has all that information but again you need to
have root access to the server to retrieve that. Here are some
directions to use the WHO command:


As Brian notes, the email `who` command can be ysed to extract list
membership as can the command line bin/list_members, and either of these
lists can be used as input to bin/add_members or the admin Mass
Subscribe function, but these operations do not preserve user options,
passwords, etc.

The one single way to move everything is to obtain a copy of Mailman's
lists//config.pck file and move it, and maybe also get the
lists archives/private/.mbox/.mbox file and use it
to rebuild the archive.

See  for more info.

All the above assumes the new domain is on a different server. If it is
just a different virtual domain on the same server, see
.



--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

If only this were a meeting conducted under Robert's Rules, the Chair 
would have invoked cloture, or at least referred this issue back to 
committee.  All interested parties have made their arguments, 
positions have hardened, and debate has become unrevealing.


Insofar as anything ever dies on the Internet, this abused equine is 
pinin' for the grassy fjords.


Please, can we convert this into a three-way private conversation, and 
consign this nearly ninety-entry email thread to history?  My screen 
isn't wide enough to handle the indentation required.


-Chip-

On 9/15/2020 3:41 PM, Jim Popovitch via Mailman-Users wrote:

On Wed, 2020-09-16 at 03:51 +0900, Stephen J. Turnbull wrote:

Jim Popovitch via Mailman-Users writes:

  > I personally think that you, Stephen, are digging high and low to find
  > any reason for Mailman2 to not continue forward under the Mailman
  > umbrella.

Digging??  Wake up, Jim!  It's *official policy* that Mailman 2 will
not receive new features under the Mailman umbrella.  It has been so
for *years*.  And the reasons have been the same for just as long:
It's because we don't want to support them.  Mark and I have both been
quite clear about that.

If you will support Mailman 2 going forward as we (ie, mostly Mark)
have supported it to date, that would be fine.  But you've explicitly
denied that you want to do that work.  You don't think it's necessary.
We think it addresses the needs of the users who need us most, so
we'll keep doing it our way, ie, we will support no new features.

Wait, so you do want to continue to support mm2 users, but you don't
want to support them in any fashion if someone else other than you and
Mark manages just the new features? (BTW, NEWS lists New Features were
added as recently as 2020-April) Do you feel that you would be obligated
to support something that was added to mm2 that you didn't feel should
be added or that you couldn't provide support for?  Is that what this is
all about?



  > Obstruction much?

There you go with the abuse again.  But I'll answer you politely.

Mailman is free software.  There's no "obstruction" at all, it's
almost impossible to obstruct you -- you have the code, it's easy to
find well-known places to host your releases and issue tracker, and
we're not going to stop you from announcing them here or on the wiki.
You don't need anything else.

You demand a bunch of perks: use of the Mailman brand, commit rights
in the official Mailman 2 repository, manager access to the tracker (I
assume), a seat in the cabal, etc.

I demanded nothing. I was told by Mark that I would need to apply for
all those perks (sans the Cabal seat) when all I offered to do was
support/test/debug/evaluate/approve new features in launchpad.


You also apparently think you have
the right to tell Mark and me which releases we should support.

No I don't, and I don't know why you can't differentiate between Mailman
and yourself.  Mailman should, and can, support multiple versions.  You
and Mark should feel free to contribute wherever you feel comfortable;
but I draw the line at you saying mm2 should die because you don't want
to support it under the parameters and guidelines designed and
established by yourself (and Mark).  I think the genuine problem here is
that it's a 2 man show when it should be a much larger body.

Now, no one should be shielded from criticism when they attempt to
abandon an installed base of users.  Remember, we are at this juncture
today because several people spoke up, over the past year, about all the
repeated "Final Release" warnings. It took at least 2 days of back-n-
forth emails just to get someone to say publicly that mm2 security
issues would indeed still be addressed going forward (why was it so
difficult to come to that reasoning?).   Also, don't forget that this
time last Summer there were some discussions on this list about how mm2
would be eol on 1/1/2020 because that was the Python team's v2 eol.


My question is: what do our users get in return?  If they wanted "bright!
new! shiny!", they'd migrate to Mailman 3.  I don't see much in the
plus column.  On the minus side, Mark and I will spend time supporting
your new features, time we can't spend on "classic" Mailman 2 issues,
Python 2 EOL issues, or on Mailman 3 development, which is what the
project is committed to, as Mark and I are.

I don't see that as a good deal for Mark and me, or for the great
majority of Mailman 2 users.

Why just you and Mark?  What about any of the other many people who
contribute and help in various ways?

-Jim P.


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
 

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

As it turns out, as I was hitting 'Send', Christian F Buser posted:

I am just a user of a Mailman 2 installation on cPanel. And I am reading here 
because i get some answers to my questions and help if something goes wrong.

As long as cPanel bundles MM2, I need from time to time some support from the 
real experts. And even if MM2 would not be improved at all in the future, I 
hope that this list will stay alive.
... which is a much more succinct version of what I was trying to 
say.  And perhaps I should have substituted "needs" for 
"requirements", in order to avoid any intimation of a demand.  I am 
genuinely grateful for all the help I've received, primarily from 
following other admins' issues reported here.


Ironically, I was writing in support of Mark's and Stephen's position 
on the matter.  As a member of Mark's cohort, the odds are I'll never 
need a "New! Improved!" MM2, or MM3.


-Chip-

On 9/13/2020 6:00 PM, Mark Sapiro wrote:

On 9/13/20 12:39 PM, Chip Davis wrote:

Speaking as _a_ user, my requirements are simple:
   1.  MM2 must continue to work,
   2.  support must continue to be provided.

Any proposal that jeopardizes those fundamentals must be rejected.

By "support", I mean everything except new functionality: bug fixes,
installation/administration hand-holding, dumb questions not properly
answered by the user community, the occasional "Why does Mailman do
this?" query, and any number of issues that depend on the encyclopedic
institutional knowledge residing in Mark's and Stephen's crania.

This includes structural changes to way email is handled (DMARC,
encryption, etc.).  This does not include additional language tables, or
any of the issues on my personal laundry list of "I sure wish Mailman
had a way to ...".


This thread started because I refused to accept a merge request to add a
new feature, hCAPTCHA, to the subscribe form. The reason I gave was "no
new features", although I have other reservations about CAPTCHAs in general.

I think I have made my position clear and I think it includes my doing
all the things Chip wants, although I'm 78 years old, and it's not
unlikely that I will die before Mailman 2.1 finally does.

What I am opposed to is third parties making changes to the code base
and expecting me to continue to make releases, so I ask that any
potential group of Mailman 2.1 developers either fork the project in
which case, they can do whatever they want with their fork, or if they
want to commit changes to the Mailman 2.1 branch on Launchpad that they
be willing to take over the entire job.



--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

I am loathe, as a lowly list administrator (on cPanel hosts, at that) 
to participate in the clash of titans,  but this _is_ the 
"mailman-users" discussion list.  It is somewhat distressing to see so 
little participation by the Mailman2 users, who will be most affected 
by any changes in its support.


Speaking as _a_ user, my requirements are simple:
  1.  MM2 must continue to work,
  2.  support must continue to be provided.

Any proposal that jeopardizes those fundamentals must be rejected.

By "support", I mean everything except new functionality: bug fixes, 
installation/administration hand-holding, dumb questions not properly 
answered by the user community, the occasional "Why does Mailman do 
this?" query, and any number of issues that depend on the encyclopedic 
institutional knowledge residing in Mark's and Stephen's crania.


This includes structural changes to way email is handled (DMARC, 
encryption, etc.).  This does not include additional language tables, 
or any of the issues on my personal laundry list of "I sure wish 
Mailman had a way to ...".


-Chip-

On 9/13/2020 1:06 PM, Mark Sapiro wrote:

On 9/13/20 9:29 AM, Jim Popovitch via Mailman-Users wrote:

Just what is the Cabal willing to accept in a proposal?

Try us and see?

My own opinion is I would want a commitment to take over what I
currently do including making releases on Launchpad, distributing them
to sourceforge and gnu.org, updating version info on
https://www.list.org/ (and mirrors) and announcing them. I would be
willing to mentor someone through this process.

I would ask for all that because I am not willing to make releases of
code I haven't audited, and if I were willing to audit all the changes,
we wouldn't be having this conversation at all. And, I don't see what
use there is of just updating the branch on Launchpad without making
releases.

You may have ideas about how this can work without all that. That's why
I think we want to see and discuss your proposal.



--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

Thank you, Steve, for your thoughtful and measured reply.  I have a 
clearer picture of the ramifications of Jim's proposal, to the degree 
that he has specified it.  The longer the thread festered, the fewer 
salient points were made, so I can't say that I support it or not.  
But it's not my call in the first place.


I'm glad you have no quarrel with me.  I am merely a Mailman admin 
with no control over any of my installations.  I hope that by the time 
my ISPs drop MM2, there will be ample tools to make the conversion to 
MM3 relatively painless.  Despite an exhaustive search, I can find no 
suitable and affordable alternative.


BTW, the original Rexx interpreter was written in IBM Assembler 
(proprietary), Regina in C (GPL), ooRexx in C/C++ (CPL), NetRexx in 
NetRexx(!) (CPL), and BSF4ooRexx in ooRexx (CPL/AL).  There has been 
no "branching" whatsoever.  Yet there is a lively cross-platform 
collaboration when issues arise, from architecture down to patch. And 
yes, sometimes it can get testy. ;-)


Thank you for you patience.  I consider this matter closed.

-Chip-

On 8/30/2020 1:29 AM, Stephen J. Turnbull wrote:

I wrote a long screed, full of piss and vinegar.  But on reflection,
clearly nobody is reading what I wrote earlier, so let's try pithy and
dry.  It's still long. :-(

Chip Davis writes:

  > OK guys, what's really going on here?

I don't know.  I can tell you I'm done with Jim.  You'll have to ask
him about what he thinks is going on.

I have differences of opinion with you and Carl, but no quarrel.

  > Is this about turf?

Not on our side.  I have genuine concerns.  In Mark's most recent
post, he writes:

  > We only asked that these potential new members actually ask to join
  > the GNU Mailman project as members.

That doesn't look like a concern with turf to me.  Mark may not have
the same concerns I do, or any at all, I don't know.  We'll have to
wait until he gets back.  In the meantime, I'll lay out mine.

  > Is there something about Jim's proposal that requires resources
  > (money, proprietary code, prestige, etc.) from the GNU Mailman group?

Mailman is a GNU project.  Under the GPL, Jim's proposal *needs* no
resources from the GNU Mailman Project, and no blessing from us,
either.  He has the code, and the physical resources are easy to come
by elsewhere.

Certainly it makes economic sense to use the existing repository and
other project resources to support further Mailman 2 development.  It
won't cost Mailman 3 or the Mailman Project anything to share.  But
nobody else has any *right* to any of those resources, and especially
not to the time that Mark and I devote to user support.  If you think
otherwise, you are wrong both as a matter of law and as a matter of
free software philosophy.
  
In this connection, Carl Zwanzig writes:


  > it's vastly different to say "Pay no attention to that GPL,
  > no one is allowed to maintain or improve that code."

That's incoherent.  The complaint is that people *are* maintaining and
improving the code, but we don't allow them to use our resources and
reputation to distribute their code.  That complaint is groundless.
It is fully within the GPL, letter and spirit, to refuse to distribute
code, whether others' or our own.  The spirit of the GPL is that you
can use your own resources to distribute both your code and ours.

Just ask politely, and if you want my support for you to freely commit
to and distribute from the project's Mailman 2 branch, I ask you to
commit to providing support for all its users.

Or don't commit to serving users, just don't free-ride on the Mailman
name and you can have my support.  That was the idea of my original
request to Jim.

Back to Chip:

  > [Are you] genuinely concerned that the continued viability of MM2
  > would be a threat to MM3[?]

Brian may be, and I'd like to hear why.  But at present I am not.

My concern is that a small group of highly competent power users will
take over the Mailman 2 repo, Mark and I will disengage from this list
and Mailman 2 bug channels, and support for ordinary Mailman 2 users
will go in the toilet because the new team is focused on developing an
EOL application in an EOL language, not on user support.

  > I have a little experience [with multiple "branches" of REXX] here.

With all due respect, I don't think it's relevant to what Jim has
proposed so far.  There's a detailed explanation in the "screed", but
the gist is that Mailman 2 and Mailman 3 use completely different
architectures and interfaces, so expertise simply doesn't transfer
between them.  Of recently active developers only Mark and I have
experience with both code bases, and I at least want to wash my hands
of Mailman 2.  AFAICS, the developer teams will have little to talk
about with each other.

As far as the communities go, perhaps we could work together somewhat.
We have a common history, we support the same kind of ad

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

OK guys, what's really going on here?

Stephen and Mark, you are both thoughtful writers and crucial members 
of the Mailman team.  Jim, you have made a generous offer that seems 
to have the support of the Mailman 2 user community, at least.


Is this about turf?  Is there something about Jim's proposal that 
requires resources (money, proprietary code, prestige, etc.) from the 
GNU Mailman group?  I really can't see a zero-sum game here, unless 
you are genuinely concerned that the continued viability of MM2 would 
be a threat to MM3.


I have a little experience here.  In 1979 an IBM programmer developed 
Rexx, which became the lingua-franca for all IBM operating systems.  
Internally, IBM developed an O-O version of Rexx which was available 
only on OS/2.  In 1997, after many years of negotiation, IBM donated 
one of its proprietary products to an open-source project for the 
first time.  I was the president of the Rexx Language Association and 
established the ooRexx Project to port it to Linux and care for it.  
In 2011, IBM gave us NetRexx, Rexx for the Java virtual machine.  We 
now also support BSF4ooRexx, which is the full ooRexx for the JVM.


These are three quite diverse codebases, each with their 
contributors/committers and project-level discussion groups, but there 
is quite a bit of cross-team communication and collaboration. Is there 
any reason why this can't be the case with Jim and whatever team he 
can assemble?  I can see that it won't immediately lift the entire 
burden of MM2 off of Mark's shoulders, but it's a better start (and 
example to set) than simply declaring EOL on MM2 and leaving thousands 
of admins in the lurch.


What am I missing?

-Chip-
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

OK Brian, so your answers to my questions are:

 "I have a profit motive to encourage MM3 adoption"
   ... and ...
 "I'm baffled that all the people on the Mailman *2* discussion list 
are not scrambling to adopt MM3"


Have I got that about right?

For the record, I have enjoyed exemplary support from all three of my 
"cheap budget hosts" whenever I've had an issue.  And yes, one of them 
is A2.


I will sign off of this thread by pointing out that your first 
contribution to it was a reply to my posting supporting Jim's generous 
offer to help support the MM2 community, in which you stridently 
attempted to convince us to convert over to MM3 instead.


Respectfully, we decline.

-Chip-

On 8/26/2020 11:17 PM, Brian Carpenter wrote:

On 8/26/20 10:29 PM, Chip Davis wrote:
What I don't understand is your vitriolic objection to Jim's offer. 
How is that any skin off your nose? Do you see this as a zero-sum 
game in which every MM2 instance that doesn't "upgrade" is a threat 
to MM3?  If it's as superior as you claim, there should be a 
thunderous stampede to adopt MM3.  The bazaar will speak 
eloquently.  What, exactly, is the cock you have in this pit?


Bottom Line: As long as there are inexpensive cPanel hosts running 
Mailman 2, *I have no choice*.   So I greatly appreciate Jim's 
offer to pick up the burden and allow Mark to move on. 


I watched for years how cheap budget hosts provided crap support for 
the software that they hosted. I watched Mark for years take on that 
extra burden of making up for their crap support because of it via 
the old MM2 user list.


I am sure Mark has moved on from Mailman 2, at least he has said 
that on numerous occasions. It is you folks that won't let him. You 
want to keep using MM2 and you want the developers to keep 
supporting it. That pressure can/does hinder the work on Mailman 3.


I really did not like Jim's comment and that set me off:

"I hate to say this, but I'm sensing an exclusivity in your and 
Mark's comments. Is Mailman a open source project or is it an 
exclusive club?"


I really don't like your comments either towards me in the quote 
above and the way you mis-represented Mailman 3 in your reply to
Odhiambo. I offer shared and dedicated environments for Mailman 3 
and none of my clients have to worry about the complexities of 
Mailman 3 at all. I didn't like the way Carl quoted an old piece of 
information and when he was corrected, proceeded to dig in his 
heels. I didn't like a lurker who never posted to any Mailman list 
before, suddenly come out of the woodwork to mock me on the use of 
"long life"


By the way there is always a choice. I have been offering Mailman 3 
shared list hosting for almost 2 years now. It's that few extra 
dollars a month that is a budget breakers for cheap host users. Oh 
well.


I know now that none of you have any intention of using or 
supporting Mailman 3. My pro MM3 comments have been mocked, ignored, 
and discarded. Ok. Fine. I think none of you has shown any respect 
or appreciation in the work that has been done to propel the Mailman 
project into the modern web development world. That shows that all 
you really care about is your wallets and how much you may have to 
work to move your lists to a Mailman 3 environment. This isn't about 
Mailman at all. It's about how can have a mailing list and stay 
using a cheap budget host. For Jim? Well I don't really care why he 
doesn't use Mailman 3. I think his claims about wanting to support 
Mailman is a joke. If he really wanted to support the Mailman 
project, then he would throw his weight behind Mailman 3.




--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

Brian, your analysis is spot-on.

All of my MM2 instances support non-profit organizations which cannot 
afford the cost of the Internet bandwidth for a second-hand server in 
someone's basement, much less a part-time sysadmin. *_I_* am the only 
technical staff they have, and I am unpaid.  So yes, all of my Mailman 
instances run on an assortment of those "cheap cPanel hosts" you think 
so little of.  And I'm paying for most of them, myself.


I am retired, but my entire career was spent in mainframe OS systems & 
application software development, installation, and support. I have a 
great deal of experience recovering from the premature adoption of 
/New! Improved!
/system software.  If it is a problem for a sixty year old software 
behemoth like IBM, I have absolutely no confidence that a volunteer 
open source effort is immune.


So *you are absolutely correct about the issue here*: I am 
volunteering my time & talents so there is /_no _//_money_/, and I 
have enough experience that there is a _/justified /__/fear/_.


What I don't understand is your vitriolic objection to Jim's offer. 
How is that any skin off your nose?  Do you see this as a zero-sum 
game in which every MM2 instance that doesn't "upgrade" is a threat to 
MM3?  If it's as superior as you claim, there should be a thunderous 
stampede to adopt MM3.  The bazaar will speak eloquently.  What, 
exactly, is the cock you have in this pit?


Bottom Line: As long as there are inexpensive cPanel hosts running 
Mailman 2, *I have no choice*.   So I greatly appreciate Jim's offer 
to pick up the burden and allow Mark to move on.


-Chip-
"I shoot dumps for fun. They are the ultimate Sudoku."

On 8/26/2020 5:05 PM, Brian Carpenter wrote:

On 8/26/20 3:14 PM, Chip Davis wrote:
All of my dozen Mailman instances run on shared servers.  I have no 
control over the release/distro on which I am hosted.  But my 
providers have a bazillion (est.) customers running Mailman2 and, 
for a number of reasons, are not terribly eager to force us all to 
convert to Mailman3.  By all reports, it is not an easy migration, 
nor are all features supported.  From their standpoint, maintaining 
a stable, if backlevel, Python2 to support MM2 is merely a matter 
of DASD, with far lower support costs than moving to Py3/MM3.


I think Jim's conclusion of MM2's continued viability is valid, and 
the idea of having a subset of the dev team continue to 
support/enhance it is a good idea.  And I like the "Classic 
Mailman" moniker. :-)


Python 3 is already a part of all major linux distributions. So the 
framework should already be there for a Mailman 3 installation. As 
for migrating a Mailman 2 list to Mailman 3, that is easy. The 
Mailman developers have come up with 2 scripts that do a great job 
of migrating Mailman 2 lists into a Mailman 3 server.


What happens when another "Dmarc" occurs? That event dramatically 
impacted mailing lists everywhere. At the time, only Mailman 2 
needed to be patched and the Mailman developers did a great job of 
doing so quickly. However would that happen now if such an event 
repeated itself? Most likely not. Mailman 3 would get the attention 
and rightfully so.


You are all looking at the wrong thing here. The real question here 
is why are you not wanting to move to a Mailman 3 environment? It's 
not hard to install anymore. It has a future. It is modern. It as a 
long life expectancy and, most importantly, its being supported and 
developed.


I think the issue here is money and fear. Cheap cPanel hosts include 
Mailman 2 with their budget hosting packages and I am pretty sure 
that is who you are using. Well fine, then let those hosts take on 
the responsibility of keeping Mailman 2 up to date. That is what 
open source is all about. For me, Mailman 2 is a dinosaur and its 
interface is over 20 years old. Mailman 3 is entering the world of 
modern web development and that is a great thing for users of 
Mailman. There are still users of Majordomo. But they are very few 
now and for good reason. Mailing lists are evolving and have moved on.


Get off a ship that is no longer sailing ahead and wants to instead 
to permanently anchor in place. It's ok, the new ship is more modern 
and has AC!




--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Re: mailman v2.x

[Chip Davis]

I'm afraid I disagree.

All of my dozen Mailman instances run on shared servers.  I have no 
control over the release/distro on which I am hosted.  But my 
providers have a bazillion (est.) customers running Mailman2 and, for 
a number of reasons, are not terribly eager to force us all to convert 
to Mailman3.  By all reports, it is not an easy migration, nor are all 
features supported.  From their standpoint, maintaining a stable, if 
backlevel, Python2 to support MM2 is merely a matter of DASD, with far 
lower support costs than moving to Py3/MM3.


I think Jim's conclusion of MM2's continued viability is valid, and 
the idea of having a subset of the dev team continue to 
support/enhance it is a good idea.  And I like the "Classic Mailman" 
moniker. :-)


If only I had the skills to assist him, but I don't think he has any 
need for IBM Assembler and Rexx expertise.  :-/


-Chip-

On 8/26/2020 11:05 AM, Odhiambo Washington wrote:

On Wed, 26 Aug 2020 at 16:35, Jim Popovitch via Mailman-Users <
mailman-users@python.org> wrote:

Hi Folks,
So, I have volunteered to spearhead an effort to add one or two more
people to the Mailman Coders group[2] in order to vet and approve new
features that continue the long tradition of providing value to Mailman
2.x.  Who's with me on this?

I am not a developer at all and will never be one, but seeing as Python2.x
is being dropped soon in most platforms and
mailman-2.x relies on it, it only makes sense for me that efforts are made
to better mailman-3.x and let 2.x go away slowly.

--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

[Mailman-Users] Minor nit needs correction/explanation

[Chip Davis]

Under Privacy Options -> Recipient filters -> max_num_recipients, the 
Details say:


"*max_num_recipients* (privacy): Ceiling on acceptable number of 
recipients for a posting.


If a posting has this number, or more, of recipients, it is held for 
admin approval. Use 0 for no ceiling."


OK, which is it?

Is the number specified in fact the "ceiling on _acceptable_ number of 
recipients" or "if a posting has this number ... of recipients, it is 
held for admin approval"?


It would be clearer (regardless what the code does) if the answer was 
to change the Details to read:


"If a posting has more than this number of recipients, it is held for 
admin approval."


Then change the code if actually necessary.

-Chip-


--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
   https://mail.python.org/archives/list/mailman-users@python.org/

Re: [Mailman-Users] send_reminders frequency

[Chip Davis]

I administer around a dozen (mostly v2.1) Mailman lists, but they are 
all on shared servers running cPanel or some equivalent "we won't let 
you get your hands dirty" interface.  Not by my choice, and with 
wildly varying support from the server vendors.


I often see questions about how to do something or another that I 
would dearly love to do, only to find that the simple, straightforward 
procedure recommended is beyond my server credentials.  It would be 
very helpful to me if those answers acknowledged that:


 * this can't be done on a shared server implementation, don't bother
   trying
 * this can also be done on a shared server, and here's how (or at
   least, the magic words to ask your vendor)

For example, the recent answer about "cloning" lists (impossible 
unless you have full access to the server's filesystem, then trivially 
easy) was disappointing because I have multiple lists that need to 
stay in-synch.  So I wrote a Rexx program that screen-scrapes the 
Mailman configuration screens and generates a checklist of each 
extracted setting, input field, textarea, etc. for use when cloning a 
new list.  It's a kludge compared to simply copying a couple of files 
into a new directory, but it works for those of us out here in the 
cheap seats.


Thanks,

-Chip-

On 1/29/2020 1:23 PM, Mark Sapiro wrote:

On 1/29/20 7:43 AM, dmaziuk via Mailman-Users wrote:


apologies if this is a faq and my google-fu's failing to find the 
answer: can I change send_reminders to e.g. yearly?



Mailman's cron/mailpasswds is run via cron. You can edit Mailman's 
crontab to run it on whatever schedule you like.




--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Easy question for this crowd

[Chip Davis]

 I wish.  All my listservers are on various shared hosts running 
cPanel.  An experience not unlike making love in haz-mat suits... :-/


-Chip-

On 6/2/2019 11:17 AM, Mark Sapiro wrote:

On 6/2/19 7:49 AM, Chip Davis wrote:


Thanks to Mark's help crafting the proper RE, I haven't had an '.icu'
UCE in over 15 hours (knock wood).



If you have access to Mailman's logs, the discards are logged in the
'vette' log with entries like

Message discarded, msgid: <...>


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Easy question for this crowd

[Chip Davis]

No, and No.  Apparently you missed my original post (5/30 11:57AM) on 
this topic where I asked if my RE that would do exactly that.



I've supported a dozen Mailman listservers for over a dozen years. This doesn't 
represent much real effort most of the time.  I've had to block specific users 
often and specific domains rarely, but this is the first time I've had to block 
an entire TLD.

Recently I've been gifted with an inordinate amount of UCE from many different 
domains under the '.icu' TLD.

Since Python RE's are _almost_ the same as the UNIX RE's I used many years ago, 
if I put

^@.*\.icu$

in discard_these_nonmembers, will it block all domains in that TLD?

And not block anyone else?


Thanks to Mark's help crafting the proper RE, I haven't had an '.icu' 
UCE in over 15 hours (knock wood).


For a more general solution for all of my lists, I'm looking into his 
suggestion of using a Spam Filter that triggers on the SpamAssassin 
score header inserted by my ISP.


Thanks, Mark for you patience and help.

-Chip-

On 6/1/2019 3:42 PM, Phil Stracchino wrote:

On 6/1/19 1:44 PM, Chip Davis wrote:

 I guess my question wasn't so "easy" after all ... :-(

What was a daily trickle is now a flood of UCE from different domains
in the .icu TLD.  I hope someone can suggest some sort of prophylaxis
that I haven't tried.


Do you get any actual, legitimate mail from .icu?  Do you have any real
subscribers from .icu?  If not, I'd consider just blocking the entire
TLD.  I've blocked several of the new shit TLDs from which I was
receiving nothing but spam, and it's enormously reduced my volume of spam.



--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Easy question for this crowd

[Chip Davis]

 I guess my question wasn't so "easy" after all ... :-(

What was a daily trickle is now a flood of UCE from different domains 
in the .icu TLD.  I hope someone can suggest some sort of prophylaxis 
that I haven't tried.


Is it possible that 'general_nonmember_action = Hold' is overriding my 
Spam Filter Rule?  I still need to intercept legitimate subscribers 
who attempt to post under a different address, depending on which 
device they happen to be using.  :-/


Is there any way to tell Mailman to honor my ISP's SpamAssassin score?
The headers of a UCE that got though and was Held for Approval may be 
seen at http://www.aresti.com/UCEheaders/


===
dmarc_moderation_action = Munge From
dmarc_quarantine_moderation_action = Yes
dmarc_none_moderation_action = No
 -
accept_these_nonmembers = [list if specific userids]
hold_these_nonmembers = []
reject_these_nonmembers = []
discard_these_nonmembers = []
generic_nonmember_action = Hold
forward_auto_discards = Yes
 -
header_filter_rules = Spam Filter Rule 1: ^from: .*@.*\.icu\s
  Action = Discard
===

Any help will be greatly appreciated.

-Chip-
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Easy question for this crowd

[Chip Davis]

Thanks, Mark.  I hadn't thought of the "from:" being embedded in the 
Subject: header.  And your RE correction makes perfect sense once I 
see it. ;-)


I'm pretty sure I don't have access to 'mm.config.[anything]' so I 
assume it's the default value.  Odds are, it was my imperfect RE that 
was keeping if from tripping.


Thanks All,

-Chip-

On 5/31/2019 10:11 AM, Mark Sapiro wrote:

On 5/30/19 9:20 PM, Chip Davis wrote:


About 12 hours after I put that RE in place, I got another one from a
different domain in '.icu'.  It was held for moderation, not
automatically discarded.

I have:
   8 email addresses in accept_these_nonmembers
   0 email addresses in hold_these_nonmembers
   0 email addresses in reject_these_nonmembers
   ^@.*\.icu$ in discard_these_nonmembers
   'Hold' for generic_nonmember_action
   'Yes' for forward_auto_discards
but it seemed to make no difference; the UCE was still held for moderation.



The *_these_nonmembers checks only check one address which is what
Mailman considers the sender of the message. What address this is
depends on a config setting. The doc says:


 This can return either the From: header, the Sender: header or the
 envelope header (a.k.a. the unixfrom header).  The first non-empty
 header value found is returned.  However the search order is
 determined by the following:

 - If mm_cfg.USE_ENVELOPE_SENDER is true, then the search order is
   Sender:, From:, unixfrom

 - Otherwise, the search order is From:, Sender:, unixfrom


So in your case, it may not be checking the From:



I'm going to try putting "from: .*@.*\.icu" in header_filter_rules and
see if that makes any difference.



It probably should to be "^from: .*@.*\.icu\s" to avoid matching
something like

Subject: mail from: u...@server.icu not discarded

or

From: u...@sub.icure.com




--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Easy question for this crowd

[Chip Davis]

Well, it was worth a try. :-/

About 12 hours after I put that RE in place, I got another one from a 
different domain in '.icu'.  It was held for moderation, not 
automatically discarded.


I have:
  8 email addresses in accept_these_nonmembers
  0 email addresses in hold_these_nonmembers
  0 email addresses in reject_these_nonmembers
  ^@.*\.icu$ in discard_these_nonmembers
  'Hold' for generic_nonmember_action
  'Yes' for forward_auto_discards
but it seemed to make no difference; the UCE was still held for 
moderation.


I'm going to try putting "from: .*@.*\.icu" in header_filter_rules and 
see if that makes any difference.


Any other ideas?

-Chip-

On 5/30/2019 7:03 PM, Robert Heller wrote:

At Thu, 30 May 2019 11:57:44 -0400 Chip Davis  wrote:



I've supported a dozen Mailman listservers for over a dozen years.
This doesn't represent much real effort most of the time.  I've had to
block specific users often and specific domains rarely, but this is
the first time I've had to block an entire TLD.

Recently I've been gifted with an inordinate amount of UCE from many
different domains under the '.icu' TLD.

Since Python RE's are _almost_ the same as the UNIX RE's I used many
years ago, if I put

^@.*\.icu$

in discard_these_nonmembers, will it block all domains in that TLD?


Yes.



And not block anyone else?


Yes.

I've done this, and then I took things a step further:

What *I* have done (because I can), is configure rejection of both domains AND
cidrs at the Postfix level, putting REJECT's in both /etc/postfix/access and
/etc/postfix/cidr.clients. (I use *REJECT* for a reason: I figure if these
idiots are going to make trouble for me, I'll make trouble for them -- eg now
they will will get reject messages. Also when the addresses are from legit
mail servers, the admins there will get a wake up call and presumably do
something -- I have discovered that there is really little point in sending
anything to the [so-called] 'abuse' addresses.)

I've also configured mimedefang and spamassassin to *reject* spam at the
Postfix as well.  Very little gets though now.



Thanks,

-Chip Davis-

Mailman 2.1.27 > shared host
linux 2.6.32-696.18.7.el6.x86_64
cPanel 80.0.10
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/heller%40deepsoft.com





--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Easy question for this crowd

[Chip Davis]

I've supported a dozen Mailman listservers for over a dozen years. 
This doesn't represent much real effort most of the time.  I've had to 
block specific users often and specific domains rarely, but this is 
the first time I've had to block an entire TLD.


Recently I've been gifted with an inordinate amount of UCE from many 
different domains under the '.icu' TLD.


Since Python RE's are _almost_ the same as the UNIX RE's I used many 
years ago, if I put


^@.*\.icu$

in discard_these_nonmembers, will it block all domains in that TLD?

And not block anyone else?

Thanks,

-Chip Davis-

Mailman 2.1.27
shared host
linux 2.6.32-696.18.7.el6.x86_64
cPanel 80.0.10
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] held messages not visible in web interface

[Chip Davis]

When this has happened to me, it was because the poster removed the 
post on his own.  When a post is held for moderation, the sender gets 
a note to that effect which includes a URL where they can go to cancel 
the held post.


At least, that's the way my Mailman instances work.  YMMV, of course.

-Chip-

On 2/4/2019 2:08 PM, Keith Seyffarth wrote:


I have run into an interesting issue on one of my several mailman
mailing lists.

Notifications are sent to the admins that there are messages being held
for moderation, but when you log in to the admin interface and go to
"Tend to pending moderator requests," there are no messages held.

This is on Mailman 2.1.15 on a PLESK server on CentOS.

Any idea what may be going on here, or how to make these messages
visible again?

Thanks,
Keith


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Automatic subscription based on e-mail subject

[Chip Davis]

On 2/1/2019 3:30 AM, R. Diez via Mailman-Users wrote:


This is becoming tiresome...


Indeed.  Except I'd substitute the second-person pronoun for the third...

Mailman has a long page with settings like digest mode, stop delivery 
(holiday mode), and many, many more. Other communication platforms 
like Google Group allow you to manage subscriptions per topic. How 
about some new settings like this:


[ x ]  Automatically follow topics/subjects/threads I have 
participated in.


What you are asking for is not impossible but it is not a SMOP.  It 
will require a significant effort on the part of volunteer developers 
and result in a significant increase in the size of the package, with 
a concomitant increase in volunteer support and administration effort.



And, as has been pointed out previously in this discussion, there is a
difference between mailing lists and web forums or bulletin boards...


There is no such difference. It is all in your head. 


You have been provided several patient, thoughtful, and perfectly 
clear explanations that there _is_ a difference between a listserver 
and a forum/BB, starting with the distinction between a "push" 
interface and a "pull" one.


There are 
communication platforms that have both interfaces, e-mail and web.


Yes, but they are not as lithe or lissome as Mailman, and more 
difficult to administer.


Other systems can do it. I understand that you do not want to 
implement it yourself in Mailman, but why oppose the idea?


One word: spork.

There are plenty of web forum offerings, many free, that have some 
sort of email access, usually as an afterthought.  As such, they are 
the software equivalent of a spoon into which someone cut notches, 
making it a lousy fork and a poor spoon.


I, for one, have no time to waste logging into dozens of fora looking 
for postings of interest.  Such postings are emailed to me, in the 
same way that notes to all of my email accounts are.  My MUA does the 
spam-filtering, searching, sorting, filing, display, and composition 
functions.  I need only that one (programmable) tool to handle all my 
inputs.


-Chip-

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Reply-to options not working

[Chip Davis]

Apologies for mangling my description of the problem.  The senders 
with the hard-coded "Reply-To:" are not the ones complaining that 
their emails aren't going to the list, it's those who thought they 
replied to the list who complain that it went as a private message 
back to the OP.


IMHO, all replies to a discussion list posting should go back to the 
discussion by default.  Any responder is free to change that for a 
particular reply, but the default should be to maintain the discussion.


If a poster really wants private replies, the author is free to ask 
for them, and may actually get a few. (Most will still go back to the 
list because it's sooo much trouble to change the "To:" header.)


These are folks who constantly hijack threads because they always 
start a new topic by hitting 'Reply' to whatever posting they just 
received...


-Chip-

On 1/29/2018 12:14 PM, Chip Davis wrote:
I am loathe to weigh in on this architectural design discussion, but 
it seems to ignore the PEBCAK effect.


I admin about a dozen _discussion_ Mailman lists as a mitzvah for 
various organizations I'm fond of, none of which are well-populated 
with computer scientists.  Exhibit A is the number of subscribers who 
have free email accounts at Yahoo, AOL, or bellsouth.net (who 
subcontracts their email processing to Yahoo).


I have a constant problem with well-meaning, but essentially ignorant, 
email users who, upon seeing a "Reply To:" field in their MUA's setup 
screen, dutifully fill it in with their email address.  Then they 
complain that even though they "replied to the list", their email went 
only to the poster.


That's why I have to "first_strip_reply_to", and it appears, will 
still have to do so in your new paradigm, Stephen.  You can't defeat 
ignorance, only battle it to a bloody draw.


I've been doing this for years, and it seems that the proliferation of 
POS (not "point-of-sale") cellphone email clients has made things 
exponentially worse.  They are more concerned with adding a button to 
to automatically order whatever is in highlighted text from Amazon, 
than with RFC's.


-Chip-

On 1/28/2018 11:43 PM, Stephen J. Turnbull wrote:

Jordan Brown writes:

  > I want "Reply" to go to the author, and "Reply All" to go to the 
author,

  > the list, and any other To or CC destinations.  I simply can't
  > understand any other answer.  I don't understand why anybody 
feels a

  > need for "Reply List".

Your preference is noted, but you are definitely in a minority of
those whose opinions I've seen over the decades.  Even those who use
Reply and Reply All as you do (I do on this list, for example),
usually have considered it suboptimal.  The preferences of list owners
also should be respected, to the extent that replying users don't
care.  The prevalence of reply-to-munging says that they (or perhaps a
majority of their subscribers) want replies to automatically go to the
list.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: 
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/chip%40aresti.com




--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: 
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/chip%40aresti.com


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Reply-to options not working

[Chip Davis]

I am loathe to weigh in on this architectural design discussion, but 
it seems to ignore the PEBCAK effect.


I admin about a dozen _discussion_ Mailman lists as a mitzvah for 
various organizations I'm fond of, none of which are well-populated 
with computer scientists.  Exhibit A is the number of subscribers who 
have free email accounts at Yahoo, AOL, or bellsouth.net (who 
subcontracts their email processing to Yahoo).


I have a constant problem with well-meaning, but essentially ignorant, 
email users who, upon seeing a "Reply To:" field in their MUA's setup 
screen, dutifully fill it in with their email address.  Then they 
complain that even though they "replied to the list", their email went 
only to the poster.


That's why I have to "first_strip_reply_to", and it appears, will 
still have to do so in your new paradigm, Stephen.  You can't defeat 
ignorance, only battle it to a bloody draw.


I've been doing this for years, and it seems that the proliferation of 
POS (not "point-of-sale") cellphone email clients has made things 
exponentially worse.  They are more concerned with adding a button to 
to automatically order whatever is in highlighted text from Amazon, 
than with RFC's.


-Chip-

On 1/28/2018 11:43 PM, Stephen J. Turnbull wrote:

Jordan Brown writes:

  > I want "Reply" to go to the author, and "Reply All" to go to the author,
  > the list, and any other To or CC destinations.  I simply can't
  > understand any other answer.  I don't understand why anybody feels a
  > need for "Reply List".

Your preference is noted, but you are definitely in a minority of
those whose opinions I've seen over the decades.  Even those who use
Reply and Reply All as you do (I do on this list, for example),
usually have considered it suboptimal.  The preferences of list owners
also should be respected, to the extent that replying users don't
care.  The prevalence of reply-to-munging says that they (or perhaps a
majority of their subscribers) want replies to automatically go to the
list.

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/chip%40aresti.com



--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] change links in mail footer to https

[Chip Davis]

Thanks, Mark.

I'll sent that URL to Tech Support and ask them to fix my servers. 
Depending on how they respond, I may contact one of the vendors on 
that list.


With so many lists running on cPanel, I was hoping that someone had 
already figured out a way to do it (or get it done).


-Chip-

On 12/9/2017 2:06 PM, Mark Sapiro wrote:

On 12/09/2017 10:40 AM, Chip Davis wrote:

That's all well and good Mark, but surely you know that any fix that
involves issuing a shell command is useless for those of us responsible
for lists on a shared server running cPanel (or equivalent).



The OP indicated that he had changed DEFAULT_URL_PATTERN. If he can do
that, he can run fix_url.



Is there a procedure that we can implement, or are we just SOL?



I know nothing about setting a cPanel domain to use https, but I imaging
more that just the Mailman part of this requires action by a server admin.

The real underlying issue with cPanel is the fact that Mailman just
"comes in the box" with cPanel. There are some hosting services using
cPanel who are very conscientious and cooperative in supporting their
customers use of Mailman, but unfortunately, there are others who only
offer Mailman because it "comes in the box" and are unwilling to put any
effort into supporting it.

If your host won't cooperate, see
<https://wiki.list.org/COM/Mailman%20hosting%20services> for possible
replacements.


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] change links in mail footer to https

[Chip Davis]

That's all well and good Mark, but surely you know that any fix that 
involves issuing a shell command is useless for those of us 
responsible for lists on a shared server running cPanel (or equivalent).


Is there a procedure that we can implement, or are we just SOL?

Has anyone had any success forwarding the procedure to your host's 
tech support?


-Chip-

On 12/9/2017 1:02 PM, Mark Sapiro wrote:

On 12/09/2017 02:23 AM, Johannes Rohr wrote:

Hi, all the links in mails generated by mailman start with http, even
though DEFAULT_URL_PATTERN starts with https. How can I change this?



See .

--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Replying to the List

[Chip Davis]

On 12/7/2017 2:29 PM, Mark Sapiro wrote:

On 12/07/2017 09:15 AM, Phil Stracchino wrote:


Short version for free:  Edit /etc/mailman/mm_cfg.py and add the
following line anywhere AFTER 'from Defaults import *':

DEFAULT_REPLY_GOES_TO_LIST = 1



It is not necessary and probably not effective in this case to edit
mm_cfg.py. That only sets the default for new lists.

What is wanted in this case is the settings on the web admin UI General
Options page under Reply-To: header munging. In particular:

Where are replies to list messages directed? Poster is strongly
recommended for most mailing lists.
(Details for reply_goes_to_list)


And I have no problem with that (except that editorial advice probably 
doesn't belong on a settings page) because it refers to a "mailing 
list".  I have no statistics, but my exposure to Mailman has been 
almost exclusively as a "discussion list".  Therefore, all of the 
Mailman instances that I admin ignore this "strong recommendation" and 
set 'reply_goes_to_list' to 'This list'.  Yes, that does open the 
DMARC/DKIM can-o-worms, but just about everything useful does... :-/


Perhaps it would be useful to new Mailman admins if there were some 
sort of Quick Start Tutorial that covered appropriate initial settings 
for using Mailman as a:

 - Mailing List
 - Discussion List
 - Suggestion Box
 - IRC bot
 - etc.

-Chip-
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] cause of bounces

[Chip Davis]

On 10/10/2017 6:20 PM, p...@tokyoprogressive.org wrote:


Thank you, Mark.  Had to resend this as I forgot to remove the quotes in the 
first attempt. Re it being a DMARC issue, all the options look bad (except 
telling people to use another email provider).


Which is exactly what I do with the dozen-ish lists that I host/admin. 
 Friends don't let friends use Yahoo... :-(


-Chip-
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] list sponsorships

[Chip Davis]

As Matt pointed out to me off-list, a lot of FOSS is provided for a 
profit.


I live about five miles from Red Hat, and teach Linux for a living. 
Perhaps I should have been more specific that "I have a 
philosophical/ethical problem with MY charging for simply providing a 
FOSS service."


While I would love to monetize the time I put into adminning the 
lists, it would be a pain to fairly calculate (or keep track of) it, 
so I consider it a mitzvah.


YMMV,

-Chip-

On 5/15/2017 5:17 PM, Richard Shetron wrote:

What I've always done is offered special pricing, usually at least 50%
off for charitable 503(c) and other 'public service' type groups.  It
more depended on the resources they required and the amount of hand
holding.

On 5/15/17 3:13 PM, Chip Davis wrote:

All of the Mailman lists I host/admin are provided free of charge,
as a value-add to the members of various non-profit groups.  Insofar
as the actual costs of providing a discussion or announcement list
are hard to tease out, the best I could do would be to apportion the
total costs of the servers they are on across all the other services
I get. The income would be nice to offset my expenses but
administering it would be nearly as great as that of adminning the
lists themselves. So I treat it as my contribution to good causes.

Also, I have a philosophical/ethical problem with charging for
simply providing a FOSS service.  I know it's allowed but still...

[snip]
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/chip%40aresti.com


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] list sponsorships

[Chip Davis]

All of the Mailman lists I host/admin are provided free of charge, as 
a value-add to the members of various non-profit groups.  Insofar as 
the actual costs of providing a discussion or announcement list are 
hard to tease out, the best I could do would be to apportion the total 
costs of the servers they are on across all the other services I get. 
The income would be nice to offset my expenses but administering it 
would be nearly as great as that of adminning the lists themselves. 
So I treat it as my contribution to good causes.


Also, I have a philosophical/ethical problem with charging for simply 
providing a FOSS service.  I know it's allowed but still...


-Chip-

On 5/15/2017 1:53 PM, Mark Sapiro wrote:

On 05/15/2017 07:29 AM, Matt Morgan wrote:

Has anybody experimented with (or succeeded with) any form of mailman list
sponsorship? A nonprofit professional assocation I work for asked me for
advice about it. If there are current examples I'd be curious to see them.



I'm not sure if this is anything like what you have in mind, but if you
look at the bottom of any of the https://mail.python.org/mailman/* pages
(e.g. ) you will
see s DigitalOcean logo and a Hosted by DigitalOcean link. DigitalOcean
is in a sense a sponsor in that they provide the VPS that hosts
mail.python.org and we get a little bit of credit for click-throughs on
that link.


--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org