[Mailman-Users] Re: Mailman-Users Digest, Vol 237, Issue 2

2023-11-05 Thread Jeremy


Dig around in their control panel. There should be cron jobs and the ability to 
enable ssh per "SFTP User". 

Lots of ads and upsells are in their panel now which hadn't been there before 
so be careful what you click. 

>Ugh.  Dream Host does not give me cron job / command line access. I'll 
>try begging them to do this, but more likely I'll have to manually 
>release the Digest each week.
>



--
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/
Member address: arch...@jab.org


Re: [Mailman-Users] Very strange issue With Mailman + Exchange(?)

2020-04-27 Thread Mark Sapiro
On 4/27/20 11:21 AM, Bruce Johnson wrote:
> I am not sure how to figure this out.
> 
> Lengthy explanation:
> 
> For two users and ONLY these two users, somewhere between them and mailman 
> and back, the Mailman list is being expanded to put all the members of the 
> list on the CC line. It then gets held for approval with a ’too many 
> addresses’ message.
...
> TLDR: Somehow the all the list addresses are getting stuck onto the list 
> message which then holds it for approval for ’too many addresses’.


I'm really guessing here, but I suspect that the list is not VERPing or
personalizing delivery and the default setting for SMTP_MAX_RCPTS is not
overridden with a small number.

In this case Mailman will send the outgoing message in only a few SMTP
transactions with lots of recipients each. In fact, if this is and
internal list and all the recipients are all in the same TLD, Mailman
will send to all the recipients in one transaction with multiple RCPT TO
commands. I.e., the envelope recipients for the message will be the
whole list, at least if there are fewer than 500 members.

Some MUAs will add the envelope recipients to an X-Apparently-To: header
and I wouldn't put it past Exchange to put them in Cc: even though this
could effectively break Bcc:.

All that notwithstanding, this is the outgoing message, and IIUC the
message never gets posted to the list, unless there's some convoluted
process which reflects the outgoing message back to the list.

I would start by examining the Received: chain in the headers of the
held message to see where it's been.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Trouble migrating

2020-04-27 Thread Mark Sapiro
On 4/26/20 11:04 PM, Lothar Schilling wrote:
> 
> ps -fwwA | grep qrunner
> 
> mailman   7439  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
> mailman   7440  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
> mailman   7441  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
> mailman   7442  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
> mailman   7443  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
> mailman   7444  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
> mailman   7445  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
> mailman   7446  7438  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s
> mailman   7468  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
> mailman   7469  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
> mailman   7470  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
> mailman   7471  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
> mailman   7472  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
> mailman   7473  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
> mailman   7474  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
> mailman   7475  7467  0 07:51 ?    00:00:00 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s


This may be a separate issue, but you have two Mailman instances
running. See  for how this can happen
and what to do about it.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Trouble migrating

2020-04-27 Thread Lothar Schilling

Am 26.04.2020 um 19:46 schrieb Mark Sapiro:

On 4/26/20 9:57 AM, Lothar Schilling wrote:

Yes I did check the permissons several times, everything is fine. And
no, SELinux was and still is disabled.


What user is running Mailman's qrunners?

ps -fwwA|grep qrunner

And what does

ls -laR /var/spool/mailman /var/lib/mailman

give?


ps -fwwA | grep qrunner

mailman   7439  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
mailman   7440  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
mailman   7441  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
mailman   7442  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
mailman   7443  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
mailman   7444  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
mailman   7445  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
mailman   7446  7438  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s
mailman   7468  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
mailman   7469  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
mailman   7470  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
mailman   7471  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
mailman   7472  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
mailman   7473  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
mailman   7474  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
mailman   7475  7467  0 07:51 ?    00:00:00 /usr/bin/python 
/usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s


ls -laR /var/spool/mailman

drwxrws---   mailman mailman  4096 26. Apr 17:38 archive
drwxrws---   mailman mailman  4096 26. Apr 17:52 bad
drwxrws---   mailman mailman  4096 26. Apr 17:39 bounces
drwxrws---   mailman mailman  4096  9. Okt 2015  commands
drwxrws---   root    mailman  4096 26. Apr 17:52 in
drwxrws---   mailman mailman  4096  9. Okt 2015  news
drwxrws---   mailman mailman 77824 26. Apr 17:52 out
drwxrws---   mailman mailman  4096  9. Okt 2015  retry
drwxrws---   mailman mailman  4096 26. Apr 17:38 shunt
drwxrws---   root    mailman 86016 26. Apr 17:52 virgin

ls -laR /var/lib/mailman
All files & directories have: -rwxrwsr-x   apache mailman

 /usr/lib/mailman/bin/check_perms -f
"Keine Probleme aufgetreten"

--
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] Trouble migrating

2020-04-26 Thread Mark Sapiro
On 4/26/20 9:57 AM, Lothar Schilling wrote:
> Yes I did check the permissons several times, everything is fine. And
> no, SELinux was and still is disabled.


What user is running Mailman's qrunners?

ps -fwwA|grep qrunner

And what does

ls -laR /var/spool/mailman /var/lib/mailman

give?

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Trouble migrating

2020-04-26 Thread Lothar Schilling

Hi Tom,

this is not meant for me, is it? My name's not David. Also, my problem 
is of a different kind.


Regards

Lothar Schilling

Am 26.04.2020 um 18:44 schrieb Tom Coradeschi:
David: Your qrunner exceptions sound surprisingly like a problem I had 
earlier this week with a new install of 2.1.30.


In Mailman/Archiver/pipermail.py

change line 60
from: while i>0 and (L[i-1][0] in lowercase or
to: while i>0 and (L[i-1][0] in lowercase[:26] or

Restart mailman and see how things go from there.

—
Tom Coradeschi
tc...@skylands.ibmwr.org



On 26 Apr 2020, at 12:05 PM, Lothar Schilling  wrote:

Hi everybody,

today I tried to migrate our whole mailman installation to another 
server.


Old server: Centos 6.10, Mailman 2.1.29, Python 2.6.6

New server: Centos 7.7, Mailman 2.1.30 (from the tgz file), Python 2.7.5

It seemed to be an easy transition. But then I started to realize 
I've run into problems. For example, I can't release a moderated 
message. Also, I cannot switch users from moderated to not moderated 
or hidden to unhidden. The error logs look like this:


Apr 26 17:38:16 2020 (11727) Uncaught runner exception: [Errno 1] 
Operation not permitted

Apr 26 17:38:16 2020 (11727) Traceback (most recent call last):
Apr 26 17:38:16 2020 (11727) SHUNTING: 
1587915493.168592+122b90464edb8dfe2a33eb4e84fd036f0943019c
Apr 26 17:38:16 2020 (11727) Failed to unlink/preserve backup file: 
/var/spool/mailman/virgin/1587915493.168592+bfc8cbc934795ac0c0d663ac31c3ea3df13e9b59.bak
Apr 26 17:52:18 2020 (11727) Uncaught runner exception: [Errno 2] No 
such file or directory: 
'/var/spool/mailman/virgin/1587916338.266272+f1e11334def7f62140a3442c10bd6b56268d9010.pck'

Apr 26 17:52:18 2020 (11727) Traceback (most recent call last):
Apr 26 17:52:18 2020 (11727) Skipping and preserving unparseable 
message: 1587916338.266272+f1e11334def7f62140a3442c10bd6b56268d9010
Apr 26 17:52:19 2020 (11726) Failed to unlink/preserve backup file: 
/var/spool/mailman/out/1587916338.266272+5c0165dec7b0fdd4e3851688a77b8e31a99b015d.bak
Apr 26 17:52:20 2020 (11727) Failed to unlink/preserve backup file: 
/var/spool/mailman/virgin/1587916338.285911+c4b5275fd082841b395994955b37f5f85569bba9.bak


Apr 26 17:53:13 2020 qrunner(11694): Traceback (most recent call last):
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/bin/qrunner", line 278, in 

Apr 26 17:53:13 2020 qrunner(11694): main()
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/bin/qrunner", line 238, in main

Apr 26 17:53:13 2020 qrunner(11694): qrunner.run()
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/Queue/Runner.py", line 87, in run

Apr 26 17:53:13 2020 qrunner(11694): self._cleanup()
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 263, in _cleanup

Apr 26 17:53:13 2020 qrunner(11694): BounceMixin._cleanup(self)
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 137, in _cleanup

Apr 26 17:53:13 2020 qrunner(11694): self._register_bounces()
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 126, in 
_register_bounces

Apr 26 17:53:13 2020 qrunner(11694): mlist.Save()
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/MailList.py", line 578, in Save

Apr 26 17:53:13 2020 qrunner(11694): self.__save(dict)
Apr 26 17:53:13 2020 qrunner(11694): File 
"/usr/lib/mailman/Mailman/MailList.py", line 555, in __save

Apr 26 17:53:13 2020 qrunner(11694): os.link(fname, fname_last)
Apr 26 17:53:13 2020 qrunner(11694): OSError : [Errno 1] Operation 
not permitted


Apr 26 17:53:16 2020 qrunner(11722): Traceback (most recent call last):
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/bin/qrunner", line 278, in 

Apr 26 17:53:16 2020 qrunner(11722): main()
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/bin/qrunner", line 238, in main

Apr 26 17:53:16 2020 qrunner(11722): qrunner.run()
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/Queue/Runner.py", line 87, in run

Apr 26 17:53:16 2020 qrunner(11722): self._cleanup()
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 263, in _cleanup

Apr 26 17:53:16 2020 qrunner(11722): BounceMixin._cleanup(self)
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 137, in _cleanup

Apr 26 17:53:16 2020 qrunner(11722): self._register_bounces()
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 126, in 
_register_bounces

Apr 26 17:53:16 2020 qrunner(11722): mlist.Save()
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/MailList.py", line 578, in Save

Apr 26 17:53:16 2020 qrunner(11722): self.__save(dict)
Apr 26 17:53:16 2020 qrunner(11722): File 
"/usr/lib/mailman/Mailman/MailList.py", line 555, in __save

Apr 26 17:53:16 2020 qrunner(11722): 

Re: [Mailman-Users] Trouble migrating

2020-04-26 Thread Lothar Schilling
Yes I did check the permissons several times, everything is fine. And 
no, SELinux was and still is disabled.


Am 26.04.2020 um 18:37 schrieb Mark Sapiro:

On 4/26/20 9:05 AM, Lothar Schilling wrote:

Hi everybody,

today I tried to migrate our whole mailman installation to another server.

Old server: Centos 6.10, Mailman 2.1.29, Python 2.6.6

New server: Centos 7.7, Mailman 2.1.30 (from the tgz file), Python 2.7.5

It seemed to be an easy transition. But then I started to realize I've
run into problems. For example, I can't release a moderated message.
Also, I cannot switch users from moderated to not moderated or hidden to
unhidden. The error logs look like this:

Apr 26 17:38:16 2020 (11727) Uncaught runner exception: [Errno 1]
Operation not permitted

...


It looks like you have permission issues. Have you run Mailman's
bin/check_perms?

Do you have SELinux enabled? If so, try disabling it.


--
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] Trouble migrating

2020-04-26 Thread Tom Coradeschi
David: Your qrunner exceptions sound surprisingly like a problem I had earlier 
this week with a new install of 2.1.30.

In Mailman/Archiver/pipermail.py

change line 60 
from: while i>0 and (L[i-1][0] in lowercase or
to: while i>0 and (L[i-1][0] in lowercase[:26] or

Restart mailman and see how things go from there.

—
Tom Coradeschi
tc...@skylands.ibmwr.org


> On 26 Apr 2020, at 12:05 PM, Lothar Schilling  wrote:
> 
> Hi everybody,
> 
> today I tried to migrate our whole mailman installation to another server.
> 
> Old server: Centos 6.10, Mailman 2.1.29, Python 2.6.6
> 
> New server: Centos 7.7, Mailman 2.1.30 (from the tgz file), Python 2.7.5
> 
> It seemed to be an easy transition. But then I started to realize I've run 
> into problems. For example, I can't release a moderated message. Also, I 
> cannot switch users from moderated to not moderated or hidden to unhidden. 
> The error logs look like this:
> 
> Apr 26 17:38:16 2020 (11727) Uncaught runner exception: [Errno 1] Operation 
> not permitted
> Apr 26 17:38:16 2020 (11727) Traceback (most recent call last):
> Apr 26 17:38:16 2020 (11727) SHUNTING: 
> 1587915493.168592+122b90464edb8dfe2a33eb4e84fd036f0943019c
> Apr 26 17:38:16 2020 (11727) Failed to unlink/preserve backup file: 
> /var/spool/mailman/virgin/1587915493.168592+bfc8cbc934795ac0c0d663ac31c3ea3df13e9b59.bak
> Apr 26 17:52:18 2020 (11727) Uncaught runner exception: [Errno 2] No such 
> file or directory: 
> '/var/spool/mailman/virgin/1587916338.266272+f1e11334def7f62140a3442c10bd6b56268d9010.pck'
> Apr 26 17:52:18 2020 (11727) Traceback (most recent call last):
> Apr 26 17:52:18 2020 (11727) Skipping and preserving unparseable message: 
> 1587916338.266272+f1e11334def7f62140a3442c10bd6b56268d9010
> Apr 26 17:52:19 2020 (11726) Failed to unlink/preserve backup file: 
> /var/spool/mailman/out/1587916338.266272+5c0165dec7b0fdd4e3851688a77b8e31a99b015d.bak
> Apr 26 17:52:20 2020 (11727) Failed to unlink/preserve backup file: 
> /var/spool/mailman/virgin/1587916338.285911+c4b5275fd082841b395994955b37f5f85569bba9.bak
> 
> Apr 26 17:53:13 2020 qrunner(11694): Traceback (most recent call last):
> Apr 26 17:53:13 2020 qrunner(11694):   File "/usr/lib/mailman/bin/qrunner", 
> line 278, in 
> Apr 26 17:53:13 2020 qrunner(11694):  main()
> Apr 26 17:53:13 2020 qrunner(11694):   File "/usr/lib/mailman/bin/qrunner", 
> line 238, in main
> Apr 26 17:53:13 2020 qrunner(11694):  qrunner.run()
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/Queue/Runner.py", line 87, in run
> Apr 26 17:53:13 2020 qrunner(11694):  self._cleanup()
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 263, in _cleanup
> Apr 26 17:53:13 2020 qrunner(11694): BounceMixin._cleanup(self)
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 137, in _cleanup
> Apr 26 17:53:13 2020 qrunner(11694):  self._register_bounces()
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 126, in 
> _register_bounces
> Apr 26 17:53:13 2020 qrunner(11694):  mlist.Save()
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/MailList.py", line 578, in Save
> Apr 26 17:53:13 2020 qrunner(11694):  self.__save(dict)
> Apr 26 17:53:13 2020 qrunner(11694):   File 
> "/usr/lib/mailman/Mailman/MailList.py", line 555, in __save
> Apr 26 17:53:13 2020 qrunner(11694):  os.link(fname, fname_last)
> Apr 26 17:53:13 2020 qrunner(11694): OSError :  [Errno 1] Operation not 
> permitted
> 
> Apr 26 17:53:16 2020 qrunner(11722): Traceback (most recent call last):
> Apr 26 17:53:16 2020 qrunner(11722):   File "/usr/lib/mailman/bin/qrunner", 
> line 278, in 
> Apr 26 17:53:16 2020 qrunner(11722):  main()
> Apr 26 17:53:16 2020 qrunner(11722):   File "/usr/lib/mailman/bin/qrunner", 
> line 238, in main
> Apr 26 17:53:16 2020 qrunner(11722):  qrunner.run()
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/Queue/Runner.py", line 87, in run
> Apr 26 17:53:16 2020 qrunner(11722):  self._cleanup()
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 263, in _cleanup
> Apr 26 17:53:16 2020 qrunner(11722): BounceMixin._cleanup(self)
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 137, in _cleanup
> Apr 26 17:53:16 2020 qrunner(11722):  self._register_bounces()
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 126, in 
> _register_bounces
> Apr 26 17:53:16 2020 qrunner(11722):  mlist.Save()
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/MailList.py", line 578, in Save
> Apr 26 17:53:16 2020 qrunner(11722):  self.__save(dict)
> Apr 26 17:53:16 2020 qrunner(11722):   File 
> "/usr/lib/mailman/Mailman/MailList.py", 

Re: [Mailman-Users] Trouble migrating

2020-04-26 Thread Mark Sapiro
On 4/26/20 9:05 AM, Lothar Schilling wrote:
> Hi everybody,
> 
> today I tried to migrate our whole mailman installation to another server.
> 
> Old server: Centos 6.10, Mailman 2.1.29, Python 2.6.6
> 
> New server: Centos 7.7, Mailman 2.1.30 (from the tgz file), Python 2.7.5
> 
> It seemed to be an easy transition. But then I started to realize I've
> run into problems. For example, I can't release a moderated message.
> Also, I cannot switch users from moderated to not moderated or hidden to
> unhidden. The error logs look like this:
> 
> Apr 26 17:38:16 2020 (11727) Uncaught runner exception: [Errno 1]
> Operation not permitted
...


It looks like you have permission issues. Have you run Mailman's
bin/check_perms?

Do you have SELinux enabled? If so, try disabling it.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] dkim for several mailman lists on one server

2020-04-24 Thread Mark Sapiro
On 4/24/20 2:36 PM, csa--- via Mailman-Users wrote:
> Ubuntu 16, Mailman 2.1.20, postfix 3.1.0
> 
> I'm running several mailing lists each with a virtual domain. I set up DKIM
> for lists.domainname.tld but am getting DKIM signature missing at
> https://dkimvalidator.com . It's saying it wants a DKIM for
> hostname.domainname.tld. When I look at the mail log I see entries like this


The configuration of opendkim is outside the scope of this list. As an
example however, the server that sends this list's mail is
mail.python.org, but it dkim signs from the python.org domain.

In any case, the public key text record needs to be in DNS at
sss._domainkey.ddd where sss is the selector and ddd is the domain in
the DKIM signature.


> Apr 19 07:49:42 hostname opendkim[1738]: 091CE1205AE: s=ppsdkim d=ucsf.edu
> SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad signature
> 
> Apr 24 09:25:31 hostname opendkim[1738]: 3B7CA120431: s=mail
> d=domainname.tld SSL error:04091068:rsa routines:INT_RSA_VERIFY:bad
> signature
> 
> Lastly, I'm confused by the term in the Mailman interface of  ' host_name'
> where it says
> 
...> Is the host-name literal for my server? Right now I have it set at
> lists.domainname.tld. Is that incorrect?


Mailman's host_name setting should be the domain to wich you send list
mail. If the list's posting address is listn...@lists.domainname.tld,
then lists.domainname.tld is correct, but if you post to
listn...@domainname.tld, then host_name should be domainname.tld.


> Finally, my mailing list distribution success is mixed. Some users get them,
> while others do not.


And without information from the failed recipients ISPs as to why they
discarded or spam filtered the mail, you won't know why, unless of
course they outright bounce it in which case the reason should be in the
bounce DSNs.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Toggle plain text setting for new users

2020-04-22 Thread Johannes Rohr
Am Mittwoch, 22. April 2020, 17:59:53 CEST schrieb Mark Sapiro:
> On 4/22/20 7:36 AM, Johannes Rohr wrote:
> > What I am asking about is the per-user setting:
> > 
> > When you go to /members  you will see that in the members table, the
> > second column from the right is called "plain" and if the box is ticket,
> > messages are delivered as plain text. And the preset is that the box /is/
> > ticked.
> > 
> > I would like to find out how I can toggle the preset.
> 
> First of all, that setting is only applicable for digest subscriber and
> controls whether they are sent the plain text or the HTML version of the
> digest.

Ah, ok, thanks Ben!! In that case it doesn't really matter because very few 
people receive the digests.

[...]

> The default for the 'plain' setting is Digest options ->
> mime_is_default_digest. The global default for new lists is the
> mm_cfg.py setting DEFAULT_MIME_IS_DEFAULT_DIGEST.

Great, thanks!!

Johannes


--
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] Toggle plain text setting for new users

2020-04-22 Thread Mark Sapiro
On 4/22/20 7:36 AM, Johannes Rohr wrote:
> 
> What I am asking about is the per-user setting: 
> 
> When you go to /members  you will see that in the members table, the second 
> column 
> from the right is called "plain" and if the box is ticket, messages are 
> delivered as plain text. 
> And the preset is that the box /is/ ticked. 
> 
> I would like to find out how I can toggle the preset.


First of all, that setting is only applicable for digest subscriber and
controls whether they are sent the plain text or the HTML version of the
digest. If the 'digest' setting just left of the 'plain' setting is
unchecked, the 'plain' setting has no effect.

The default for the 'plain' setting is Digest options ->
mime_is_default_digest. The global default for new lists is the
mm_cfg.py setting DEFAULT_MIME_IS_DEFAULT_DIGEST.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Toggle plain text setting for new users

2020-04-22 Thread Johannes Rohr
Am Mittwoch, 22. April 2020, 16:09:49 CEST schrieb Mailman-admin:
> Hello
> 
> Per default mailman is distributing whatever it gets.
> Check your settings in admin page topic "Content filtering".

Thanks, but I am not asking about global filtering rules (which are disabled 
anyway (The 
preset is that filter_content is set to "no").

What I am asking about is the per-user setting: 

When you go to /members  you will see that in the members table, the second 
column 
from the right is called "plain" and if the box is ticket, messages are 
delivered as plain text. 
And the preset is that the box /is/ ticked. 

I would like to find out how I can toggle the preset.

Cheers,

Johannes


> 
> 
> Kind regards,
> Christian Mack
> 
> Am 22.04.20 um 15:11 schrieb Johannes Rohr:
> > Dear all,
> > 
> > I would like to toggle a default setting for new users, name the
> > HTML/plain text switch. In our use case, having everything converted to
> > plain text by default is not very practical.
> > 
> > I am not sure how I achieve this, this question isn't mentioned in the
> > FAQ either. I am looking for a global switch to be put in mm_cfg.py or a
> > local config option for each of the lists. So far I haven't found either.
> > 
> > Would greatly appreciate any hint!!!
> > 
> > Johannes
> 
> --
> 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/jorohr%40gmail.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] Toggle plain text setting for new users

2020-04-22 Thread Mailman-admin

Hello

Per default mailman is distributing whatever it gets.
Check your settings in admin page topic "Content filtering".


Kind regards,
Christian Mack

Am 22.04.20 um 15:11 schrieb Johannes Rohr:

Dear all,

I would like to toggle a default setting for new users, name the
HTML/plain text switch. In our use case, having everything converted to
plain text by default is not very practical.

I am not sure how I achieve this, this question isn't mentioned in the
FAQ either. I am looking for a global switch to be put in mm_cfg.py or a
local config option for each of the lists. So far I haven't found either.

Would greatly appreciate any hint!!!

Johannes



--
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] Who gets notices - was: Topic Filtering

2020-04-08 Thread Mark Sapiro
On 4/7/20 8:20 AM, Batchelor, Oliver wrote:
> 
> Do list administrators get moderator messages too? The administrator of one 
> of my department lists is an administrator, but keeps getting prompts to 
> approve things. Any info on this?


Yes. owners get moderator messages too. See
 for more info,

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Topic Filtering

2020-04-08 Thread Batchelor, Oliver
Hi All,

I am new to managing the listservs at my university and have some questions on 
which I cannot locate documentation. I am sure there is some detail I am 
overlooking, but thanks anyway.

Do list administrators get moderator messages too? The administrator of one of 
my department lists is an administrator, but keeps getting prompts to approve 
things. Any info on this?

Thanks!


Oliver Batchelor

Learning Design Engineer

Instructional Technology & Research Support

Loyola University Chicago

obatche...@luc.edu<mailto:obatche...@luc.edu>


From: Mailman-Users  on 
behalf of John Marsden 
Sent: Sunday, April 5, 2020 7:02 AM
To: mailman-users@python.org 
Subject: Re: [Mailman-Users] Topic Filtering

Hello Mark

Thanks for this further clarification.

I can live with the anomaly (have to!) but it is good to know the position.

Regards

John

John Marsden
Webmaster:
www.lancashirebmd.org.uk<http://www.lancashirebmd.org.uk> 
www.cumbriabmd.org.uk<http://www.cumbriabmd.org.uk>
www.1851-unfilmed.org.uk<http://www.1851-unfilmed.org.uk> 
www.mlfhs.org.uk<http://www.mlfhs.org.uk>

On 03/04/2020 16:02, Mark Sapiro wrote:
> On 4/3/20 2:24 AM, John Marsden wrote:
>> Hello Mark
>>
>> Thanks for this confirmation. I suspected it would be the case, but it
>> is good to have it confirmed. Maybe one for the developers to think
>> about...
>>
>> Do you, or does anyone else, know whether Mailman 3 behaves in the same
>> way?
>
> Yes, it's the same in MM 3. Also MM 3 does not implement Topics,
> although we have been looking a dynamic sublists which is a way for
> users to decide which threads to receive or not receive.
>
> None of this will affect digests. There is currently no mechanism for
> building individualized digests and it is unlikely there ever will be.
>
--
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/obatchelor%40luc.edu
--
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] Topic Filtering

2020-04-05 Thread John Marsden

Hello Mark

Thanks for this further clarification.

I can live with the anomaly (have to!) but it is good to know the position.

Regards

John

John Marsden
Webmaster:
www.lancashirebmd.org.uk www.cumbriabmd.org.uk
www.1851-unfilmed.org.uk www.mlfhs.org.uk

On 03/04/2020 16:02, Mark Sapiro wrote:

On 4/3/20 2:24 AM, John Marsden wrote:

Hello Mark

Thanks for this confirmation. I suspected it would be the case, but it
is good to have it confirmed. Maybe one for the developers to think
about...

Do you, or does anyone else, know whether Mailman 3 behaves in the same
way?


Yes, it's the same in MM 3. Also MM 3 does not implement Topics,
although we have been looking a dynamic sublists which is a way for
users to decide which threads to receive or not receive.

None of this will affect digests. There is currently no mechanism for
building individualized digests and it is unlikely there ever will be.


--
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] Topic Filtering

2020-04-03 Thread Mark Sapiro
On 4/3/20 2:24 AM, John Marsden wrote:
> Hello Mark
> 
> Thanks for this confirmation. I suspected it would be the case, but it
> is good to have it confirmed. Maybe one for the developers to think
> about...
> 
> Do you, or does anyone else, know whether Mailman 3 behaves in the same
> way?


Yes, it's the same in MM 3. Also MM 3 does not implement Topics,
although we have been looking a dynamic sublists which is a way for
users to decide which threads to receive or not receive.

None of this will affect digests. There is currently no mechanism for
building individualized digests and it is unlikely there ever will be.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Topic Filtering

2020-04-03 Thread John Marsden

Hello Mark

Thanks for this confirmation. I suspected it would be the case, but it 
is good to have it confirmed. Maybe one for the developers to think about...


Do you, or does anyone else, know whether Mailman 3 behaves in the same way?

Regards

John

John Marsden
Webmaster:
www.lancashirebmd.org.uk www.cumbriabmd.org.uk
www.1851-unfilmed.org.uk www.mlfhs.org.uk

On 02/04/2020 19:05, Mark Sapiro wrote:

On 4/1/20 8:00 AM, John Marsden wrote:

This works perfectly for those members who subscribe to receive
individual messages, but those who subscribe to Digests still receive
ALL messages in their digests, despite having selected the topic.

As far as I can see, this is a 'feature' of Mailman 2 and there appears
to be no obvious way to supply digests of messages which are restricted
to a selected topic.

Am I correct in this assumption? Is there a way to limit the digests to
messages relating only to topics selected by the list member?


You are correct. There is no mechanism within Mailman to create
individualized digests. Mailman creates a plain digest and a MIME format
digest, but both formats contain all messages.


--
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] Topic Filtering

2020-04-02 Thread Mark Sapiro
On 4/1/20 8:00 AM, John Marsden wrote:
> 
> This works perfectly for those members who subscribe to receive
> individual messages, but those who subscribe to Digests still receive
> ALL messages in their digests, despite having selected the topic.
> 
> As far as I can see, this is a 'feature' of Mailman 2 and there appears
> to be no obvious way to supply digests of messages which are restricted
> to a selected topic.
> 
> Am I correct in this assumption? Is there a way to limit the digests to
> messages relating only to topics selected by the list member?


You are correct. There is no mechanism within Mailman to create
individualized digests. Mailman creates a plain digest and a MIME format
digest, but both formats contain all messages.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] New installation sudo /etc/init.d/mailman start

2020-03-22 Thread scoutdubna
Christian Mack

Thanks for your reply.  Blooming obvious now you have pointed it out.  I had
to do one or two more things to get the web interface to work eg implement
cgi but now at least that part is working.

Thanks again.

CHRIS



--
Sent from: http://mailman.9.n7.nabble.com/Mailman-Users-f3.html
--
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] Find a smtp server to send out emails

2020-03-20 Thread eddydonovan
You could definitely try other SMTP services like Sendinblue, Pepipost, etc.

I have found more at -
https://digitalmarketingtipsy.com/email-marketing/best-smtp-services/

and also at
https://digitalmarketingtipsy.com/email-marketing/best-smtp-servers/

These posts feature some good SMTP servers that I too use for personal use.



--
Sent from: http://mailman.9.n7.nabble.com/Mailman-Users-f3.html
--
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] New installation sudo /etc/init.d/mailman start

2020-03-20 Thread Mailman-admin

Hello

Am 18.03.20 um 13:06 schrieb scoutdubna:


I have made a new installation of mailman using
https://www.howtoforge.com/how-to-install-and-configure-mailman-with-postfix-on-debian-squeeze

This is on an Ubuntu 18.04 server hosted by IONOS

I get all the way through but when I input the start command
sudo /etc/init.d/mailman start
I get the error sudo: /etc/init.d/mailman: command not found

Any ideas please?



Ubuntu 18.04 uses mostly systemd.
Try:
sudo service mailman start
or
sudo systemctl start mailman


Kind regards,
Christian Mack
--
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] mailman queues

2020-03-17 Thread Mark Sapiro
On 3/16/20 1:20 PM, k...@keldix.com wrote:
> I have a problem with removing failing subscription requests
> eg from a bogus requester. I thought I could remove the request
> from a queue somewhere but cannot find it.
> the subscription requests keep recurring, over 1000 in my maillog -postfix


The requests waiting user confirmation are in the file
lists/LIST_NAME/pending.pck. Requests waiting moderator action are in
the file lists/LIST_NAME/requests.pck.

There are scripts at  (mirrored at
) which can help with this. In
particular, "erase" and "list_requests". Also, the withlist script
"discard_subs.py".

More recent Mailman has defenses against robotic web subscribes, but
none are in 2.1.9.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] rejecting messages with any HTML

2020-03-12 Thread Mark Sapiro
On March 12, 2020 1:11:28 AM GMT+00:00, "Jason A. Donenfeld"  
wrote:
>Hi,
>
>I run several mailing lists over at lists.zx2c4.com using mailman
>2.1.30rc1. I would like to reject incoming messages that have any HTML
>parts in them at all. Or, perhaps, I'd like to whitelist a few
>different mimetypes, and reject incoming messages with parts that
>don't match. I noticed that mailman has a feature to strip out
>disallowed mimetypes, and also to reject messages that are empty after
>such stripping. But I could not find a button to reject the entire
>message (with a nice reject reply, preferably) based on the presence
>of a certain mimetype. Am I missing something?


No. Mailman has no such facility.


>I should note that this isn't an unusual desire. Several
>kernel-orienting lists, such as net...@vger.kernel.org, will reject
>your message if it has HTML in any part of it, and send you back an
>email letting you know what happened.


Given that many, if not most, user's MUAs send multipart/alternative "text", 
this seems to be something that would be problematic for all but lists with 
highly technical users.




-- 
Mark Sapiro 
Sent from my Not_an_iThing with standards compliant, open source software.
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-03 Thread Mark Sapiro
On 3/3/20 6:47 AM, Jim Popovitch via Mailman-Users wrote:
> 
> Can you share with me (us) the number and size, along with the industry
> or operations arena, of those people who are creating their own web UI.


I have no information about that.


> I honestly don't believe that there is that much interest for that
> outside of a handful of entities (Brian, CPanel, Canonical, and
> LinkedIn?).  I feel like if the interest was greater, we'd see more
> evidence of that in the Gitlab issue tracker and or on the MM3 lists.  
> Convince me that I'm wrong.


By the same reasoning, if there was real interest in porting the Mailman
2.1 code base to Python 3, we'd be seeing that too.

I'm not trying to convince you of anything. All I'm saying is what I've
said all along and that is that I believe that if you want a smaller,
easier to install Python 3 based Mailman, the best way to accomplish
that is to build a light weight, non-Django web UI that communicates
with Mailman 3 core via the REST API and, for Python at least, the
existing mailmanclient bindings.

If you believe some other way is better, that's fine. It doesn't matter
to me because I'm not doing it. I am willing and available to help
anyone such as Brian with implementation of an alternative to Postorius
to the extent that I can.

There are already alternatives to HyperKitty. There is the 'prototype'
archiver which archives messages in maildir format and also the ability
to archive to mail-archive.com and MHonArc. See
.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] multiple explicit reply addresses?

2020-03-03 Thread Christian F Buser via Mailman-Users

My work-around would then be:

Set up an address on my server, say specialr...@mydomain.dom, which acts 
as a forwarder to the two addresses e...@x.com and e...@y.com


Christian


Mark Sapiro schrieb am 03.03.20 um 17:26:

On 3/3/20 2:25 AM, Bernie Cosell wrote:

I don't want to break my lists, so I'll ask first..:o)Does mailman do the 
right
thing if I want explicit replies to go to two addresses?   It seems very 
explicit that
the explicit reply address is singular.. would making it e...@x.com, e...@y.com
work?

It won't work. The code uses email.utils.parseaddr() which accepts
various display-name and address formats, but only one address.
'e...@x.com, e...@y.com' will result in only 'e...@x.com' in the Reply-To:.



--
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] multiple explicit reply addresses?

2020-03-03 Thread Mark Sapiro
On 3/3/20 2:25 AM, Bernie Cosell wrote:
> I don't want to break my lists, so I'll ask first..:o)Does mailman do the 
> right 
> thing if I want explicit replies to go to two addresses?   It seems very 
> explicit that 
> the explicit reply address is singular.. would making it e...@x.com, 
> e...@y.com 
> work?

It won't work. The code uses email.utils.parseaddr() which accepts
various display-name and address formats, but only one address.
'e...@x.com, e...@y.com' will result in only 'e...@x.com' in the Reply-To:.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-03 Thread Jim Popovitch via Mailman-Users
On Mon, 2020-03-02 at 17:18 -0800, Mark Sapiro wrote:
> On 3/2/20 1:55 PM, Jim Popovitch via Mailman-Users wrote:
> > There are plenty of people who are still happy with pipermail and some
> > of the other search options (Google, htdig, etc)  What benefit does a
> > REST api provide to church groups, and tech lists like nanog or mailop? 
> 
> It provides a stable, documented management interface so people can
> create their own web UIs to control Mailman 3 in whatever way they want.
> Granted your end user's aren't going to do this, but the people who want
> it can, and more easily than by porting Mailman 2.1 to Python 3.

Can you share with me (us) the number and size, along with the industry
or operations arena, of those people who are creating their own web UI.

I honestly don't believe that there is that much interest for that
outside of a handful of entities (Brian, CPanel, Canonical, and
LinkedIn?).  I feel like if the interest was greater, we'd see more
evidence of that in the Gitlab issue tracker and or on the MM3 lists.  
Convince me that I'm wrong.

-Jim P.


--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Mark Sapiro
On 3/2/20 1:55 PM, Jim Popovitch via Mailman-Users wrote:
> 
> There are plenty of people who are still happy with pipermail and some
> of the other search options (Google, htdig, etc)  What benefit does a
> REST api provide to church groups, and tech lists like nanog or mailop? 


It provides a stable, documented management interface so people can
create their own web UIs to control Mailman 3 in whatever way they want.
Granted your end user's aren't going to do this, but the people who want
it can, and more easily than by porting Mailman 2.1 to Python 3.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-03-02 Thread Brian Carpenter

On 3/2/20 4:55 PM, Jim Popovitch via Mailman-Users wrote:

While I applaud Brian's efforts, I'm not convinced that I would run PHP
on a public facing portal, even in 2020.  But that's just me, others may
feel differently.


And so it begins.


--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Jim Popovitch via Mailman-Users
On Mon, 2020-03-02 at 10:54 -0800, Mark Sapiro wrote:
> On 3/2/20 8:56 AM, Jim Popovitch via Mailman-Users wrote:
> 
> > Barry's roadmap
> > for Python2 -> Python3 seems to counter the narrative that MM2 is ill-
> > advised to be ported to Python3 (btw, that was posted in Jan of this
> > year).
> 
> The question is what do people want when they say they want Mailman 2
> ported to Python 3.

I believe they want Mailman 2, as it is today, but with a fully
supported language that it depends on.  Lets be clear, the upgrade from
MM2 to MM3 is not the same as a traditional upgrade path, MM3 is a whole
new application.  It's an application upgrade the same way the Space
Shuttle was an upgrade from the Apollo capsules.  Different designs,
whole new concepts, years of pie-in-the-sky and dry marker dust.  While
that is important to some, it may not matter to others (and I think that
is the situation today).  I really want to know who all the "we need a
REST interface now!" people are.

I'm reminded of that great diagram from years past about "what the
customer wanted", "what the developer envisioned", "what the tester
tested", etc.  It's a great reminder of how quagmires are created.

> If it means, porting to Python 3 and fixing a few things on the way such
> as adding a real backend database, a concept of "user" and a REST API,
> it's at least partially done. It's Mailman 3 core.
> 
> If it means cloning the MM 2.1 web UI and pipermail archiver, that is
> almost certainly not worth the effort.

There are plenty of people who are still happy with pipermail and some
of the other search options (Google, htdig, etc)  What benefit does a
REST api provide to church groups, and tech lists like nanog or mailop? 

BTW, I've run some technical discussion lists for 2 decades now, I can
recall the number of times someone has said "we need an archive search
feature" on 1 hand.
 
> A compromise is exactly what Brian proposes. Mailman 3 with a new web
> UI, light weight, not based on Django and easy to install. Mailman 3 was
> explicitly designed to be separate from a web management UI and Archiver
> and to allow different implementations of those to integrate easily with
> core.

While I applaud Brian's efforts, I'm not convinced that I would run PHP
on a public facing portal, even in 2020.  But that's just me, others may
feel differently.

> Postorius and HyperKitty are part of Mailman 3 because we needed
> something and that is what people were willing to commit to do. We
> always hoped there would be alternatives, and it seems that now Brian is
> working on one. There's room for more.

-Jim P.


--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Dave Stevens
On Sat, 29 Feb 2020 10:53:19 -0500
Jim Popovitch via Mailman-Users  wrote:

> but I have vague recollections that both Barry and Mark have 
> > said repeatedly that doing so would be substantially  anything built on the 
> > MM2
> > architecture.  

assuming that's so I think the "anything built on the MM2
architecture" is perhaps misconceived. I don't need to be told that
MM2 is awkward to set up and run but millions of people get and send
mail that way every day and it mostly "just works." This very large
body of users it what matters most to actually getting work done, not
the developers' wishes and preferences - "more effort than they are
willing to put into...". I think increasingly as time goes by that the
new New Coke analogy is a good fit.

D
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Mark Sapiro
On 3/2/20 8:56 AM, Jim Popovitch via Mailman-Users wrote:

> Barry's roadmap
> for Python2 -> Python3 seems to counter the narrative that MM2 is ill-
> advised to be ported to Python3 (btw, that was posted in Jan of this
> year).


The question is what do people want when they say they want Mailman 2
ported to Python 3.

If it means, porting to Python 3 and fixing a few things on the way such
as adding a real backend database, a concept of "user" and a REST API,
it's at least partially done. It's Mailman 3 core.

If it means cloning the MM 2.1 web UI and pipermail archiver, that is
almost certainly not worth the effort.

A compromise is exactly what Brian proposes. Mailman 3 with a new web
UI, light weight, not based on Django and easy to install. Mailman 3 was
explicitly designed to be separate from a web management UI and Archiver
and to allow different implementations of those to integrate easily with
core.

Postorius and HyperKitty are part of Mailman 3 because we needed
something and that is what people were willing to commit to do. We
always hoped there would be alternatives, and it seems that now Brian is
working on one. There's room for more.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] MM3 filter content

2020-03-02 Thread Mark Sapiro
On 3/2/20 12:35 AM, Eduardo Costa via Mailman-Users wrote:
> Hello,
> 
> How do I manage to activate and define the content filters in order to
> remove attachments at MM3?


The list for questions about Mailman 3 is mailman-us...@mailman3.org
.

That said, the MM 3 settings Filter content, Collapse alternatives and
Convert html to plaintext are exposed in Postorius -> Settings -> Alter
messages.

The other settings: filter_action, filter_extensions, filter_types,
pass_extensions and pass_types are not currently exposed in Postorius.
 They can be set via mailman shell.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Jim Popovitch via Mailman-Users
On Mon, 2020-03-02 at 17:17 +0900, Stephen J. Turnbull wrote:
> Jim Popovitch via Mailman-Users writes:
> 
>  > Interestingly enough, here's a roadmap on exactly how to do it:  :)
> 
> Jim, you're not helping.  

Stephen, thank you for taking the time to respond.  Although I would
have preferred you respond to the questions that I asked, I believe I
can now see why you don't want to.  Your "Dave Matthews" subthread sent
me down a youtube rabbit's hole of Barry's videos and links. TBH, I can
see why bringing those to the surface aren't favorable. Barry's roadmap
for Python2 -> Python3 seems to counter the narrative that MM2 is ill-
advised to be ported to Python3 (btw, that was posted in Jan of this
year).

> Until there are "I'll do it" hands up, no
> port to Python 3 that is faithful to current Mailman 2 is viable.

That is a piece of a much bigger puzzle.  How are we to attract interest
in coding for MM2 when (omg wow) for the past 10+ years key people have
been drumming a beat that MM2 is dead.

> Pushing it just serves to annoy those who are currently doing work for
> Mailman that they care more about.

I get that, but others may care more about MM2, you yourself have even
somewhat begrudgingly acknowledged this.

> By contrast, your question about security fixes was an entirely
> appropriate clarification, and #ThankYouForPersisting on that
> subthread.

#Mailman3MightBeTheNewNewCoke :-)

-Jim P.



--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-03-02 Thread Stephen J. Turnbull
Jim Popovitch via Mailman-Users writes:

 > Interestingly enough, here's a roadmap on exactly how to do it:  :)

Jim, you're not helping.  Until there are "I'll do it" hands up, no
port to Python 3 that is faithful to current Mailman 2 is viable.
Pushing it just serves to annoy those who are currently doing work for
Mailman that they care more about.

By contrast, your question about security fixes was an entirely
appropriate clarification, and #ThankYouForPersisting on that
subthread.

Steve

--
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] The last release from the GNU Mailman project

2020-03-02 Thread Stephen J. Turnbull
Mark Sapiro writes:

 > I'd say it depend on the details of how serious the vulnerability is,
 > how easy it is to exploit and how hard it is to fix. I am not opposed to
 > Mailman 2.1.30-x security fix releases.

Mark speaks for me, although it's been a long time since I've worked
on Mailman 2, and never on the release process itself. (A short pause
for M-x all-hail-mark.)  I'm happy to help where I have competence on
anything Mark deems necessary, and possibly stuff he doesn't think
rise to the level of justifying a release.

Steve
--
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] The last release from the GNU Mailman project

2020-02-29 Thread Jim Popovitch via Mailman-Users
On Sat, 2020-02-29 at 10:46 -0800, Mark Sapiro wrote:
> On 2/29/20 7:02 AM, Jim Popovitch via Mailman-Users wrote:
> > If
> > a CSF/CSS is identified in Mailman v2.1.30 in May-2020, what will be
> > done to address it?
> 
> I'd say it depend on the details of how serious the vulnerability is,
> how easy it is to exploit and how hard it is to fix. I am not opposed to
> Mailman 2.1.30-x security fix releases.


Thank you, it is reassuring to hear you say that. 

-Jim P.

--
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] The last release from the GNU Mailman project

2020-02-29 Thread Mark Sapiro
On 2/29/20 7:02 AM, Jim Popovitch via Mailman-Users wrote:
> 
> If
> a CSF/CSS is identified in Mailman v2.1.30 in May-2020, what will be
> done to address it?


I'd say it depend on the details of how serious the vulnerability is,
how easy it is to exploit and how hard it is to fix. I am not opposed to
Mailman 2.1.30-x security fix releases.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-29 Thread Mark Sapiro
On 2/28/20 11:28 PM, Stephen J. Turnbull wrote:
> Mark Sapiro writes:
> 
>  > Well, Steve channeled me earlier, so I'll return the favor.
> 
> And did it with extreme precision and accuracy.  Sorry if I created
> any misunderstandings.


None whatsoever, at least not from me ;)

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-29 Thread Jim Popovitch via Mailman-Users
On Thu, 2020-02-27 at 14:51 -0500, Bill Cole wrote:
> On 27 Feb 2020, at 14:24, Jim Popovitch via Mailman-Users wrote:
> 
> > Personally, I'd like to see the GNU Mailman project have a formal
> > Mailman 2.3 release that supports Python3, I feel that there would be 
> > a
> > lot of support for that.
> 
> I'm sure there would be widespread applause and congratulations if such 
> a thing were actually released. That sort of "support" is unhelpful 
> towards actually making such a release.
> 
> The needed support is the actual skilled effort of writing the required 
> Python3 code. I don't have the time to hunt down the specific 
> statements, but I have vague recollections that both Barry and Mark have 
> said repeatedly that doing so would be substantially more effort than 
> they are willing to put into anything built on the MM2 architecture.


Interestingly enough, here's a roadmap on exactly how to do it:  :)

https://engineering.linkedin.com/blog/2020/how-we-retired-python-2-and-improved-developer-happiness


-Jim P.

--
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] The last release from the GNU Mailman project

2020-02-29 Thread Jim Popovitch via Mailman-Users
On Sat, 2020-02-29 at 16:28 +0900, Stephen J. Turnbull wrote:
> Mark Sapiro writes:
> 
>  > Well, Steve channeled me earlier, so I'll return the favor.
> 
> And did it with extreme precision and accuracy.  Sorry if I created
> any misunderstandings.
> 
> The only thing I have to add is that mailman-users@python.org is not
> going away.  Furthermore, I expect that Mark and I, at least, will be
> here for the foreseeable future.  That's because not only are existing
> Mailman 2 installations not going away any time soon, there's every
> reason to believe that people will continue installing Mailman 2 for
> quite some time (even if it might be more convenient for *us* if
> everybody would switch to Mailman 3 ;-).
> 
> Steve

Steve, given your comments above, please expand upon this scenario:  If
a CSF/CSS is identified in Mailman v2.1.30 in May-2020, what will be
done to address it?

-Jim P.

--
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] The last release from the GNU Mailman project

2020-02-28 Thread Stephen J. Turnbull
Mark Sapiro writes:

 > Well, Steve channeled me earlier, so I'll return the favor.

And did it with extreme precision and accuracy.  Sorry if I created
any misunderstandings.

The only thing I have to add is that mailman-users@python.org is not
going away.  Furthermore, I expect that Mark and I, at least, will be
here for the foreseeable future.  That's because not only are existing
Mailman 2 installations not going away any time soon, there's every
reason to believe that people will continue installing Mailman 2 for
quite some time (even if it might be more convenient for *us* if
everybody would switch to Mailman 3 ;-).

Steve

--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-28 Thread Stephen J. Turnbull
Phil Stracchino writes:
 > On 2020-02-28 05:44, Stephen J. Turnbull wrote:

 > > str in Python 1, and the history of Mailman as an MLM for an American
 > > rock band (who needs no steekin' accents, we just hammer and bend the
 > > strings!)
 > 
 > This is clearly a story I didn't know.  :)  And now I'm curious...

John Viega was a friend of somebody in the Dave Matthews Band, maybe
Matthews himself.  In the mid-90s, they needed a mailing list to tell
people where they were playing, John didn't like any of the MLMs
available, so he wrote Mailman.  For more info, you'd have to chase
down John or Barry Warsaw, I think.  Maybe Mark knows more.

Barry wrote a chapter on Mailman in "The Architecture of Open Source
Applications", there is some historical stuff in there.  And
https://www.google.com/search?client=firefox-b-d=dave+matthews+band+GNU+Mailman
brings up a bunch of relevant-looking links.

Thanks for asking, I may have to follow some of those myself!

Steve

P.S. It is a great story, and a great advert for free/open source
software!

--
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] The last release from the GNU Mailman project

2020-02-28 Thread Stephen J. Turnbull
Brian Carpenter writes:
 > On 2/28/20 1:55 PM, Mark Sapiro wrote:
 > > Quite a few core settings are not exposed in Postorius but we're
 > > chipping away at that.
 > 
 > Is there a list somewhere to see what core settings have not been 
 > exposed in Postorius yet?

Implicit in the Postorius UI and the list of REST API endpoints. ;-)
Making that explicit is part of the task I proposed for myself.

I don't think that there are a lot.

Steve
--
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] The last release from the GNU Mailman project

2020-02-28 Thread Stephen J. Turnbull
@mailman-users
I'm going to get into a lot of design here, so I'm moving the thread to
mailman-develop...@python.org.  Reply-To set; please respect.  Brian
kept in Reply-To as a courtesy, don't know if he's subscribed over there.

@mailman-developers Brian is planning to develop an alternative web UI
for admin and archives.  I don't see this as a disincentive to
Postorius or HyperKitty development (proposed implementation language
is PHP, so we'll still need something we can support that we can
bundle), and alternatives have always been part of the vision.  I for
one plan to cooperate, and hope others feel the same.  Thread starts
here on mailman-users:

https://www.mail-archive.com/mailman-users@python.org/msg72530.html

@Brian
If you aren't subscribed to mailman-developers, and don't want to
subscribe,, I'll try to keep you in the loop.

Brian Carpenter writes:

 > I agree and understand. The forum side is not being considered at
 > this time until we get the admin interface nailed down. Right now I
 > am looking at Discourse as a motivation for developing the forum
 > side.  I also think for mailing lists to survive in the future,
 > integrating both approaches to communications is what modern users
 > are looking for.

The Python developers looked at Discourse, I think there's actually a
fair amount of activity.  "I think" because I don't participate in
their forum server, not even entirely sure it's Discourse (checked, it
is).  I don't miss it at all.  I don't think the Discourse users miss
mailing lists at all.  There seems to be near zero crosstalk, even
less crosstalk between Discourse and the lists than there is between
the lists and the issue tracker.

I don't know what would happen with better integration.  Discourse
integration of email, uh, "is poor" IMHO, which in my opinion is an
indication that integration is somewhere between very hard and
impossible -- the original author of Discourse seems to be a brilliant
designer and programmer, with plenty of sympathy for user needs.  If
he didn't do it well, it's surely not at all easy.  A lot of people
feel as you do that "both" is the right answer, and there certainly
was a lot of demand for "both" in Python when Discourse was set up
there.

 > I just think the current interfaces and the decision to go with
 > Django has hurt Mailman 3 rather than help it.

That's assuming that the likely alternative was a non-Django framework
rather than "ssh to the host and fire up python mailman.client".  It
was "ssh to the host and fire up python mailman.client", though. ;-)

 > I also mirror Jim's question of who is the "we" in this
 > conversation.

In practice, it was an "I": Barry Warsaw started rewriting the core
around a decade ago.  Then when a beta-ready version became imminent a
few years later, a couple more "I"s, IIRC Terri Oda and Florian Fuchs
wrote much of Postorius (which Barry named), and the Fedora folks did
HyperKitty because they wanted a forum-like archiver it for the Fedora
lists.  For the last few years, both Postorius and HyperKitty have
been maintained and developed by the "Mailman project team", but those
are the folks primarily responsible for the original design decisions
AIUI.

That's how this works.  People see a need, they start hacking on it
without fanfare because they're not committed to it, once they have an
idea of how much work a commitment involves and they're OK with that
they commit and announce, which often has a chilling effect on
independent alternatives, and tends to cut out users who don't know
they need pay attention if they want input to something that will be
available years later (if at all).  I don't know what to do about the
users; Barry did talk about Mailman 3 on-list occasionally, mostly in
response to issues raised about Mailman 2.

 > Why wasn't I invited? :-D

As always in open source, everybody in general is invited, (almost)
nobody gets a personal invitation.[1]  It's unfortunate that the way
things work folks like you and Jim don't find it so easy to pop over
to mailman-developers to find out about these things in advance, but
we also don't want to burden mailman-users with nitty-gritty details
that that may never be relevant to them.

 > What prevents Mailman 3 from replacing Mailman 2 completely?

Mailman 2 ain't broke, so I don't advise people who are happy with
their installations to try to fix it.  Not even by installing Mailman
3. ;-)

 > Is it because of the interfaces for Mailman 3 totally left Mailman
 > 2 behind or was it the decision to use Django?

Mailman 3 cannot be a drop-in replacement for Mailman 2 because by
design Mailman 3 core has no comprehensive administrative or user
access, except via shell access to the Mailman server.  Otherwise, the
only user access is subscribe/unsubscribe by mail, and I don't think
there's any administrative access by mail (maybe moderation can be
enabled? but it would be disabled by default because mail is tres
insecure by default).

 > Cannot Mailman 3 

Re: [Mailman-Users] The last release from the GNU Mailman project

2020-02-28 Thread Brian Carpenter

On 2/28/20 1:55 PM, Mark Sapiro wrote:

Quite a few core settings are not exposed in Postorius but we're
chipping away at that.


Is there a list somewhere to see what core settings have not been 
exposed in Postorius yet?


--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.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] The last release from the GNU Mailman project

2020-02-28 Thread Mark Sapiro
On 2/28/20 10:24 AM, Jim Popovitch via Mailman-Users wrote:
> 
> I think that is Brian's and a lot of other people's concern.  3 years to
> implement something into MM3 that was a core feature in MM2.  I realize
> this next question is going to sound bombastic, I assure you it's not
> meant that way:  What other things are missing or not available
> presently in MM3 that are taken for granite in MM2?


I think almost nothing is missing from Mailman core. We don't have
'sibling lists' or 'topics', but other than that, I think it's all there.

Quite a few core settings are not exposed in Postorius but we're
chipping away at that.


>> We are a small project. We have very few people working on Mailman on a
>> regular basis, and everyone is a volunteer, no one is paid. If you want
>> things to happen faster, please contribute.
>>
> 
> ~$ grep "Jim Popovitch" ~/devel/Mailman/NEWS | wc -l
> 10
> 
> I don't think that I've been sitting on the fence, in fact I think I've
> been contributing a lot if you include not just source contributions but
> also the PPAs.  I wouldn't say that I'm a principal developer, but I'm
> not off in some remote corner unfamiliar with the product and project.


I know that you (Jim P) have contributed a lot to MM 2 and we all and I
in particular appreciate that, but I was thinking specifically of MM 3.

Note also that I still spend a lot of time helping people with MM 2
questions. This is time that could otherwise be spent on MM 3. This is a
big part of why I've said 2.1.30 will be the last MM 2 release.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-28 Thread Jim Popovitch via Mailman-Users
On Fri, 2020-02-28 at 10:07 -0800, Mark Sapiro wrote:
> On 2/28/20 6:17 AM, Jim Popovitch via Mailman-Users wrote:
> > On Fri, 2020-02-28 at 19:52 +0900, Stephen J. Turnbull wrote:
> > > Brian Carpenter writes:
> > > 
> > >  > I have hired a professional PHP developer to begin work on a new 
> > >  > admin/forum interface for Mailman 3.
> > > 
> > > Too bad.  I really sympathize with your goals but am unlikely to be
> > > able to contribute directly to implementation (assuming an eventual
> > > open-sourcing).  Never learned PHP, not going to do it anytime soon.
> > 
> > Stephen, It's difficult for me to parse your thought process on this.
> > Why do you say "Too bad" about someone wanting to improve something that
> > you admit you want no part of?
> 
> Well, Steve channeled me earlier, so I'll return the favor. I think
> Steve is saying "Too bad" he is only talking about the choice of PHP as
> a platform rather than Python. We absolutely encourage people to develop
> alternatives to Postorius and HyperKitty for archiving and web
> management of Mailman. I think all Steve is saying is he could be more
> helpful with Python as opposed to PHP.
> 
> See this paragraph:
> 
> > > That's OK, the point of REST is so *you* *can* do that.  I can only
> > > speak for myself, but we can help to some extent on the Python side of
> > > the REST interface.
> 
> 
> > Who is this "we", you referenced them a few times in this email.
> 
> See the initial paragraph in the Acknowledgements section at
> ;.
> 
> 
> 
> > I'm fairly confident in saying that Mark has said (repeatedly now) that
> > there will never ever ever ever ever be another Mailman2 release beyond
> > v2.1.30.  Stephen, why do you say there will be? Do you have the project
> > authority to make that statement?  Who do I beleive?
> 
> Actually, I have said there will not be another release from the GNU
> Mailman project. That does not preclude anyone from forking that project
> from Launchpad and doing whatever with it.

I get that, but that sounds sharply different than what Stephen was
saying.

> I personally am not interested in porting Mailman 2 to Python 3. That's
> already been done. The result, with a real backend database and some
> extensions such as the concept of "user" that doesn't exist in MM 2, is
> Mailman 3 core.
> 
> 
> > What I'm reading between the lines is that
> > nothing but Django was considered for MM3 (by "we") and everything else
> > is inferior and not worth the time.  I'd love to be wrong on that.
> 
> The web based archiving and list management we distribute are based on
> Django because that's how the people who developed those things wanted
> to do it.
> 
> The whole point of Mailman 3 is all that stuff is separate from the core
> engine and communicates with core via a REST API, so there can be lots
> of different web management UIs. We knew if we released Mailman 3 core
> only without a web UI for list management and archive access, no one
> would use it, so we needed those things and the people who were willing
> to implement them built what we have.
> 
> We certainly hoped that there would be people like Brian implementing
> alternatives and we're glad to see it.
> 
> > > Agreed.  I didn't even know bounce processing wasn't working until
> > > this summer (my production lists are all in-house to personal
> > > acquaintances to same-university addresses -- if mail isn't flowing to
> > > somebody, it's not going to anybody, even Mailman!)
> > 
> > MM3 has been on python.org for a while, was it not noticed there either?
> 
> Of course. We began discussing this almost 3 years ago
> ;. The
> implementation was mostly done last year by a GSOC student.

I think that is Brian's and a lot of other people's concern.  3 years to
implement something into MM3 that was a core feature in MM2.  I realize
this next question is going to sound bombastic, I assure you it's not
meant that way:  What other things are missing or not available
presently in MM3 that are taken for granite in MM2?

> We are a small project. We have very few people working on Mailman on a
> regular basis, and everyone is a volunteer, no one is paid. If you want
> things to happen faster, please contribute.
> 

~$ grep "Jim Popovitch" ~/devel/Mailman/NEWS | wc -l
10

I don't think that I've been sitting on the fence, in fact I think I've
been contributing a lot if you include not just source contributions but
also the PPAs.  I wouldn't say that I'm a principal developer, but I'm
not off in some remote corner unfamiliar with the product and project.

-Jim P.





--
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/

Re: [Mailman-Users] The last release from the GNU Mailman project

2020-02-28 Thread Mark Sapiro
On 2/28/20 6:17 AM, Jim Popovitch via Mailman-Users wrote:
> On Fri, 2020-02-28 at 19:52 +0900, Stephen J. Turnbull wrote:
>> Brian Carpenter writes:
>>
>>  > I have hired a professional PHP developer to begin work on a new 
>>  > admin/forum interface for Mailman 3.
>>
>> Too bad.  I really sympathize with your goals but am unlikely to be
>> able to contribute directly to implementation (assuming an eventual
>> open-sourcing).  Never learned PHP, not going to do it anytime soon.
> 
> Stephen, It's difficult for me to parse your thought process on this.
> Why do you say "Too bad" about someone wanting to improve something that
> you admit you want no part of?


Well, Steve channeled me earlier, so I'll return the favor. I think
Steve is saying "Too bad" he is only talking about the choice of PHP as
a platform rather than Python. We absolutely encourage people to develop
alternatives to Postorius and HyperKitty for archiving and web
management of Mailman. I think all Steve is saying is he could be more
helpful with Python as opposed to PHP.

See this paragraph:

>> That's OK, the point of REST is so *you* *can* do that.  I can only
>> speak for myself, but we can help to some extent on the Python side of
>> the REST interface.



> Who is this "we", you referenced them a few times in this email.


See the initial paragraph in the Acknowledgements section at
.



> I'm fairly confident in saying that Mark has said (repeatedly now) that
> there will never ever ever ever ever be another Mailman2 release beyond
> v2.1.30.  Stephen, why do you say there will be? Do you have the project
> authority to make that statement?  Who do I beleive?


Actually, I have said there will not be another release from the GNU
Mailman project. That does not preclude anyone from forking that project
from Launchpad and doing whatever with it.

I personally am not interested in porting Mailman 2 to Python 3. That's
already been done. The result, with a real backend database and some
extensions such as the concept of "user" that doesn't exist in MM 2, is
Mailman 3 core.


> What I'm reading between the lines is that
> nothing but Django was considered for MM3 (by "we") and everything else
> is inferior and not worth the time.  I'd love to be wrong on that.


The web based archiving and list management we distribute are based on
Django because that's how the people who developed those things wanted
to do it.

The whole point of Mailman 3 is all that stuff is separate from the core
engine and communicates with core via a REST API, so there can be lots
of different web management UIs. We knew if we released Mailman 3 core
only without a web UI for list management and archive access, no one
would use it, so we needed those things and the people who were willing
to implement them built what we have.

We certainly hoped that there would be people like Brian implementing
alternatives and we're glad to see it.

>> Agreed.  I didn't even know bounce processing wasn't working until
>> this summer (my production lists are all in-house to personal
>> acquaintances to same-university addresses -- if mail isn't flowing to
>> somebody, it's not going to anybody, even Mailman!)
> 
> MM3 has been on python.org for a while, was it not noticed there either?


Of course. We began discussing this almost 3 years ago
. The
implementation was mostly done last year by a GSOC student.

We are a small project. We have very few people working on Mailman on a
regular basis, and everyone is a volunteer, no one is paid. If you want
things to happen faster, please contribute.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-28 Thread Brian Carpenter

On 2/28/20 5:52 AM, Stephen J. Turnbull wrote:

Too bad.  I really sympathize with your goals but am unlikely to be
able to contribute directly to implementation (assuming an eventual
open-sourcing).  Never learned PHP, not going to do it anytime soon.
That's OK, the point of REST is so*you*  *can*  do that.  I can only
speak for myself, but we can help to some extent on the Python side of
the REST interface.



Help with interfacing with Mailman Core via REST will be nice to have. 
My programmer was happy to hear that Mailman core utilized REST but I am 
sure he may have some questions. I have a Discord server setup for 
development communication purposes that I can add you and hopefully Mark 
Sapiro to it if you want. We are also setting up the project on Gitlab 
as a private repository for now.


Usability testing is also very important and the new admin interface 
will need it. This is another part someone like you can be of an immense 
help. I am open to any sort of volunteers at this point.




A word of advice: we, too, talked about "modern forum software and
interfaces that users expect", but implementing them well is a lot
harder than we expected.  I'm not saying it's too hard for your
developer, but stay on top of that project!  Mail is hard to combine
with forums, and it's easy to stray into the weeds.


I agree and understand. The forum side is not being considered at this 
time until we get the admin interface nailed down. Right now I am 
looking at Discourse as a motivation for developing the forum side. I 
also think for mailing lists to survive in the future, integrating both 
approaches to communications is what modern users are looking for. I 
also think the approach Mailman 3 core did with using a database and 
REST api is brilliant and forward thinking. I just think the current 
interfaces and the decision to go with Django has hurt Mailman 3 rather 
than help it.


I also mirror Jim's question of who is the "we" in this conversation. 
Why wasn't I invited? :-D




Sure, but that's still quite a ways away.  The main issues I can see
would be related to TLS, where old versions of the protocol seem to be
deprecated more and more rapidly, but it's probably easier to patch
Python 2 for that than to port Mailman 2 to Python 3.  Sure, there may
be non-TLS CVEs against Python 2, but I really can't see them being as
serious as the kinds of issues that Mailman 2 itself, not to mention
any site with mail service, would have.


What prevents Mailman 3 from replacing Mailman 2 completely? Is it 
because of the interfaces for Mailman 3 totally left Mailman 2 behind or 
was it the decision to use Django? Cannot Mailman 3 be used as a 
standalone 'traditional' mailing list without the need for something 
like Hyperkitty? Can Pipermail be modified to work with Mailman 3 as 
perhaps a stopgap for Mailman 2 users to feel more comfortable with 
migrating to Mailman 3? I host hundreds of Mailman 2 lists and I cannot 
get my clients interested in Mailman 3. It doesn't have all of the 
features that Mailman 2 has when it comes to list settings, at least not 
visible and Hyperkitty is just not impressive to look at when it comes 
to providing a community feel.


I want to research to see if it is possible to provide a browser base 
interface to convert/import a Mailman 2 list into a Mailman 3 list 
without the need of using a command line. Again I am just focusing on 
the list (admin) settings to be imported at this point not archives into 
a forum setting.




This makes no sense to me.  If your problem with Django is that it's
written in Python, you've got the REST interface.  That's as far as
our responsibility goes.  See "REST is the approach" below.


I assume Django was primarily chosen was because it was written in 
Python. Maybe I am wrong here.  My main problem with Django is you have 
to handle a 3rd interface with Mailman 3. So we have three: Postorius, 
Hyperkitty, and Django. When it comes to a U.I. perspective, Django's 
admin interface leaves a lot to desire. I am hoping to merge the need to 
use two interfaces for administration of a mailman 3 list to one, 
beautiful, easy to use, superfast and glorious administrative interface. 
In other words, One Admin Interface To Rule Them All. I am having some 
fun here but there is a lot of truth that describes my intentions. When 
I first explored using Mailman 3 and I came across the word: Django, I 
said "what the heck is that???". I am pretty sure I am not the only with 
that response. I am still, btw, saying that about Django because I am 
having a very difficult time wrapping my head around its logic.




That's not a problem we created.  Our recommendation is, as it always
has been, build from source.  And the problem is not going to go away.
Users want turnkey packages such as containers, distros can't be
stopped from building distro packages.  If you open source your
interfaces, you'll run into the same issues.


I am not trying to blame 

Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-28 Thread Phil Stracchino
On 2020-02-28 05:44, Stephen J. Turnbull wrote:
> Mailman has the opposite problem.  We *wish* str was Unicode from the
> get-go, but it wasn't, and Mailman 2 is rife with potential encoded/
> decoded confusion because of the nature of email and the dual usage of
> str in Python 1, and the history of Mailman as an MLM for an American
> rock band (who needs no steekin' accents, we just hammer and bend the
> strings!)


This is clearly a story I didn't know.  :)  And now I'm curious...



-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
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] The last release from the GNU Mailman project

2020-02-28 Thread Jim Popovitch via Mailman-Users
On Fri, 2020-02-28 at 19:52 +0900, Stephen J. Turnbull wrote:
> Brian Carpenter writes:
> 
>  > I have hired a professional PHP developer to begin work on a new 
>  > admin/forum interface for Mailman 3.
> 
> Too bad.  I really sympathize with your goals but am unlikely to be
> able to contribute directly to implementation (assuming an eventual
> open-sourcing).  Never learned PHP, not going to do it anytime soon.

Stephen, It's difficult for me to parse your thought process on this.
Why do you say "Too bad" about someone wanting to improve something that
you admit you want no part of?

> That's OK, the point of REST is so *you* *can* do that.  I can only
> speak for myself, but we can help to some extent on the Python side of
> the REST interface.
> 
> A word of advice: we, too, talked about "modern forum software and
> interfaces that users expect", but implementing them well is a lot
> harder than we expected.  I'm not saying it's too hard for your
> developer, but stay on top of that project!  Mail is hard to combine
> with forums, and it's easy to stray into the weeds.

Who is this "we", you referenced them a few times in this email.


>  > 2. Mailman 2 does need to be ported to python 3 eventually
> 
> Sure, but that's still quite a ways away.  The main issues I can see
> would be related to TLS, where old versions of the protocol seem to be
> deprecated more and more rapidly, but it's probably easier to patch
> Python 2 for that than to port Mailman 2 to Python 3.  Sure, there may
> be non-TLS CVEs against Python 2, but I really can't see them being as
> serious as the kinds of issues that Mailman 2 itself, not to mention
> any site with mail service, would have.

I'm fairly confident in saying that Mark has said (repeatedly now) that
there will never ever ever ever ever be another Mailman2 release beyond
v2.1.30.  Stephen, why do you say there will be? Do you have the project
authority to make that statement?  Who do I beleive?

>  > 3. The decision to use Django. Maybe great for Python users
> 
> This makes no sense to me.  

I'm no fan of PHP, but I'd bet that a majority of web frontend
developers, who "Never learned Django" would say that using Django
"makes no sense to" them.  What I'm reading between the lines is that
nothing but Django was considered for MM3 (by "we") and everything else
is inferior and not worth the time.  I'd love to be wrong on that.

> If your problem with Django is that it's
> written in Python, you've got the REST interface.  That's as far as
> our responsibility goes.  See "REST is the approach" below.
> 
>  > 4. [W]ay too many methods of installing it which means all kinds of
>  > versions of Mailman 3 are in production today because Mailman
>  > versions are dependent upon what method of installation a person
>  > chooses: Distro Package, Docker, Source, others?
> 
> That's not a problem we created.  Our recommendation is, as it always
> has been, build from source.  And the problem is not going to go away.
> Users want turnkey packages such as containers, distros can't be
> stopped from building distro packages.  If you open source your
> interfaces, you'll run into the same issues.
> 
>  > I think the highest priority is to get Mailman 3 core up to speed
>  > in offering everything that Mailman 2 offers such as bounce
>  > processing.
> 
> Agreed.  I didn't even know bounce processing wasn't working until
> this summer (my production lists are all in-house to personal
> acquaintances to same-university addresses -- if mail isn't flowing to
> somebody, it's not going to anybody, even Mailman!)

MM3 has been on python.org for a while, was it not noticed there either?

>  > Then perhaps a whole new approach to interfacing with Mailman 3
>  > core is in order.
> 
> REST *is* the "Mailman 3 approach" to interfacing.  Historically, at
> the time Mailman 3 core got whipped into shape to start beta testing,
> we went with Django for Postorius, because it was the "hot" framework
> of the day, and that's what the developers who volunteered wanted to
> work with.  Of course it had to be a Python framework since we'd be
> maintaining it.  HyperKitty was a little bit different: the Fedora (or
> Red Hat?) people wanted Mailman 3 for internal reasons, and they
> contributed a pile of labor, and (AFAIK) independently chose Django
> and developed the UI based on it (which is why we have two separate
> Django configs).
> 
> *However*, the original idea was that *we* didn't know much about UI
> development, especially the peripheral features of archiving such as
> search and access control, and we wanted to encourage third parties to
> develop their own, or to integrate Mailman lists into their larger
> platforms which already provided user interfaces.
> 
>  > I hope I did not offend anyone here
> 
> The main Postorius devs aren't hanging out here, and we get only a
> little contact in the summer with the HyperKitty devs since the Fedora
> support got cut three or four years ago. 

Re: [Mailman-Users] The last release from the GNU Mailman project

2020-02-28 Thread Stephen J. Turnbull
Brian Carpenter writes:

 > I have hired a professional PHP developer to begin work on a new 
 > admin/forum interface for Mailman 3.

Too bad.  I really sympathize with your goals but am unlikely to be
able to contribute directly to implementation (assuming an eventual
open-sourcing).  Never learned PHP, not going to do it anytime soon.
That's OK, the point of REST is so *you* *can* do that.  I can only
speak for myself, but we can help to some extent on the Python side of
the REST interface.

A word of advice: we, too, talked about "modern forum software and
interfaces that users expect", but implementing them well is a lot
harder than we expected.  I'm not saying it's too hard for your
developer, but stay on top of that project!  Mail is hard to combine
with forums, and it's easy to stray into the weeds.

 > 2. Mailman 2 does need to be ported to python 3 eventually

Sure, but that's still quite a ways away.  The main issues I can see
would be related to TLS, where old versions of the protocol seem to be
deprecated more and more rapidly, but it's probably easier to patch
Python 2 for that than to port Mailman 2 to Python 3.  Sure, there may
be non-TLS CVEs against Python 2, but I really can't see them being as
serious as the kinds of issues that Mailman 2 itself, not to mention
any site with mail service, would have.

 > 3. The decision to use Django. Maybe great for Python users

This makes no sense to me.  If your problem with Django is that it's
written in Python, you've got the REST interface.  That's as far as
our responsibility goes.  See "REST is the approach" below.

 > 4. [W]ay too many methods of installing it which means all kinds of
 > versions of Mailman 3 are in production today because Mailman
 > versions are dependent upon what method of installation a person
 > chooses: Distro Package, Docker, Source, others?

That's not a problem we created.  Our recommendation is, as it always
has been, build from source.  And the problem is not going to go away.
Users want turnkey packages such as containers, distros can't be
stopped from building distro packages.  If you open source your
interfaces, you'll run into the same issues.

 > I think the highest priority is to get Mailman 3 core up to speed
 > in offering everything that Mailman 2 offers such as bounce
 > processing.

Agreed.  I didn't even know bounce processing wasn't working until
this summer (my production lists are all in-house to personal
acquaintances to same-university addresses -- if mail isn't flowing to
somebody, it's not going to anybody, even Mailman!)

 > Then perhaps a whole new approach to interfacing with Mailman 3
 > core is in order.

REST *is* the "Mailman 3 approach" to interfacing.  Historically, at
the time Mailman 3 core got whipped into shape to start beta testing,
we went with Django for Postorius, because it was the "hot" framework
of the day, and that's what the developers who volunteered wanted to
work with.  Of course it had to be a Python framework since we'd be
maintaining it.  HyperKitty was a little bit different: the Fedora (or
Red Hat?) people wanted Mailman 3 for internal reasons, and they
contributed a pile of labor, and (AFAIK) independently chose Django
and developed the UI based on it (which is why we have two separate
Django configs).

*However*, the original idea was that *we* didn't know much about UI
development, especially the peripheral features of archiving such as
search and access control, and we wanted to encourage third parties to
develop their own, or to integrate Mailman lists into their larger
platforms which already provided user interfaces.

 > I hope I did not offend anyone here

The main Postorius devs aren't hanging out here, and we get only a
little contact in the summer with the HyperKitty devs since the Fedora
support got cut three or four years ago. ;-)  If I know Mark he
started a little miffed but calmed down quickly since diverse UIs have
always been part of the vision.

 > I would be interested to know if the developers of Mailman 3 are
 > interested in the initiative I have taken to develop new interfaces
 > for Mailman 3

As far as I know this is precisely what we wanted to happen in the
first place.  We knew that we would have to have a bundlable
user/admin interface and an archiver with a web interface, but the
original intent was not that they dominate Mailman installations.  We
should have known better, given the huge popularity of Mailman 2 with
Pipermail (oh, Lordy) as the archiver, but hope springs eternal 

I think further discussion should move to mailman-developers, though,
and please introduce your UI developer(s) to us on mailman-developers
soonish.  Nobody has huge amounts of time to put into work on Mailman
right now AFAIK, but I expect we will be willing to cooperate on any
Mailman features or fixes your developer needs in the REST interface
"in good time".

I'm going to be very busy until March 11, but after that I'll have
some time.  Ginning up a 

Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-28 Thread Stephen J. Turnbull
Phil Stracchino writes:

 > Rewriting without breaking is hard.

True.

 > There is a Python framework called Twisted.

Not an example appropriate to Mailman, though.  The Twisted people were
doing amazing things with str, to which Unicode was irrelevant, because
their job was to shovel bytes from here to there correctly but as fast
as possible.  (Mercurial has a similar story, and a similar visceral
hatred for Python 3.)

Mailman has the opposite problem.  We *wish* str was Unicode from the
get-go, but it wasn't, and Mailman 2 is rife with potential encoded/
decoded confusion because of the nature of email and the dual usage of
str in Python 1, and the history of Mailman as an MLM for an American
rock band (who needs no steekin' accents, we just hammer and bend the
strings!)  There are two decades of hacks and patches in Mailman 2 to
catch the squirmers that somehow manage to be str where unicode is
needed or vice versa, and every single one of those would need to be
reverse engineered in a Python 3 environment.  Not a job I would want
to do: like Barry, I would rewrite from scratch (and probably redesign
as well).  But every part converted would be a joy to work with in
the future.

 > As best I can determine, the task of updating it to be Python 3
 > compatible has now been under way for ten years (with most of that
 > time, only one person working on it).

But that's because Python 3 deliberately encouraged decoding streams
of bytes, by making it hard to process bytes the same way as str in
Python 2.  It wouldn't have been hard to make the bytes type identical
to str except for the internal representation, so that programs like
Twisted and Mercurial would just need to be converted so that
*everything* was bytes except for the error messages.  But that was
deliberately avoided: a lot of (Python 2) str methods were not
inherited by bytes.  (In fact, some were re-added later, but too late
to make the bit-shovelers happy.)  So the Twisted people hated Python
3 with a passion.

I'm not surprised that only one person would work on the port, I'm
surprised they found even one!

Steve
--
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] Setting MM 3 attributes

2020-02-27 Thread Dave McGuire
On 2/27/20 10:18 PM, Mark Sapiro wrote:
>>> Setting Maximum message size works in current Postorius. What version do
>>> you have?
>>
>>   I'm running 1.1.2; it's from the Ubuntu repo.
> 
> Actually, the issue is Mailman core, not Postorius. max_message_size was
> not exposed in REST before version 3.2.0.

  Ahh I see.

  I sure wish the distribution packagers would do a better job of
keeping up with new releases.  I'm an old-school UNIX guy, very much
accustomed to building everything from source (under SunOS, Ultrix, etc)
and I still maintain that these package management systems create more
problems than they solve. ;)

  I got motivated and tried setting that variable via the mailman shell,
and it worked a treat.  Thanks again for hitting me with the clue bat.

 -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA
--
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] Setting MM 3 attributes

2020-02-27 Thread Mark Sapiro
On 2/27/20 6:21 PM, Dave McGuire wrote:
> 
>> Setting Maximum message size works in current Postorius. What version do
>> you have?
> 
>   I'm running 1.1.2; it's from the Ubuntu repo.

Actually, the issue is Mailman core, not Postorius. max_message_size was
not exposed in REST before version 3.2.0.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Setting MM 3 attributes

2020-02-27 Thread Dave McGuire
On 2/27/20 9:08 PM, Mark Sapiro wrote:
> On 2/27/20 5:44 PM, Dave McGuire wrote:
>>
>>   Not to hijack, but is it possible to set the maximum message size by
>> the mailman shell?  I've a problem with that in one of my MM3 lists, I
>> really need to set that, but the web interface does not allow me to set
>> it.  I get the dreaded "Unknown attribute: max_message_size" error.
>> Could you loan me a clue?
> 
> Not only does this not really belong in this thread, it doesn't even
> belong on this list.> 
> 
> would be a better place, but since you asked...

  Yeah, I figured, sorry about that Mark.

> Setting Maximum message size works in current Postorius. What version do
> you have?

  I'm running 1.1.2; it's from the Ubuntu repo.

> Yes you can set it in mailman shell
> 
> mailman shell -l l...@example.com
> 
> The variable 'm' is the l...@example.com mailing list
 m.max_message_size = 100(or whatever you want to set it to)
 commit()


  I've made a note of it, and will give it a shot tomorrow.  Thanks, and
I'm sorry for the OT post!

  -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA
--
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] Setting MM 3 attributes

2020-02-27 Thread Mark Sapiro
On 2/27/20 5:44 PM, Dave McGuire wrote:
> 
>   Not to hijack, but is it possible to set the maximum message size by
> the mailman shell?  I've a problem with that in one of my MM3 lists, I
> really need to set that, but the web interface does not allow me to set
> it.  I get the dreaded "Unknown attribute: max_message_size" error.
> Could you loan me a clue?

Not only does this not really belong in this thread, it doesn't even
belong on this list.

would be a better place, but since you asked...

Setting Maximum message size works in current Postorius. What version do
you have?

Yes you can set it in mailman shell

mailman shell -l l...@example.com

The variable 'm' is the l...@example.com mailing list
>>> m.max_message_size = 100(or whatever you want to set it to)
>>> commit()
>>>



-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Dave McGuire
On 2/27/20 8:01 PM, Mark Sapiro wrote:
>> Bounce processing will still not be available for new users of Mailman
>> which is my big concern. I assume new lists will have to have those
>> settings adjusted via the Mailman shell?
> 
> Sure it will. All the settings have reasonable defaults just like MM 2.1
> 
> bounce_info_stale_after: 7d
> bounce_notify_owner_on_disable: True
> bounce_notify_owner_on_removal: True
> bounce_score_threshold: 5
> bounce_you_are_disabled_warnings: 3
> bounce_you_are_disabled_warnings_interval: 7d
> process_bounces: True
> 
> True, until they are exposed in some list admin UI they will need to be
> set via mailman shell or the REST API, but bounce processing will work
> out of the box in Mailman core 3.3.1.

  Not to hijack, but is it possible to set the maximum message size by
the mailman shell?  I've a problem with that in one of my MM3 lists, I
really need to set that, but the web interface does not allow me to set
it.  I get the dreaded "Unknown attribute: max_message_size" error.
Could you loan me a clue?

Thanks,
-Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Mark Sapiro
On 2/27/20 5:01 PM, Mark Sapiro wrote:
> 
> True, until they are exposed in some list admin UI they will need to be
> set via mailman shell or the REST API, ...

That is IF they need to be changed from the default.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Mark Sapiro
On 2/27/20 3:09 PM, Brian Carpenter wrote:
> 
> Bounce processing will still not be available for new users of Mailman
> which is my big concern. I assume new lists will have to have those
> settings adjusted via the Mailman shell?


Sure it will. All the settings have reasonable defaults just like MM 2.1

bounce_info_stale_after: 7d
bounce_notify_owner_on_disable: True
bounce_notify_owner_on_removal: True
bounce_score_threshold: 5
bounce_you_are_disabled_warnings: 3
bounce_you_are_disabled_warnings_interval: 7d
process_bounces: True

True, until they are exposed in some list admin UI they will need to be
set via mailman shell or the REST API, but bounce processing will work
out of the box in Mailman core 3.3.1.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Brian Carpenter

On 2/27/20 5:30 PM, Mark Sapiro wrote:

I don't know why Mailman 3's DMARC mitigation is considered improved
over Mailman 2.1. It's the same. The Settings and Postorius UI for them
are more logical than MM 2.1, but they ultimately boil down to the same
things.

The latest Mailman core (not yet released but available at
  fully implements
bounce processing. Prior to this, bounce events were stored in the
database but not processed. Now they are.
As I said, it's in the latest version of core. The list specific
settings: 'bounce_info_stale_after', 'bounce_notify_owner_on_disable',
'bounce_notify_owner_on_removal', 'bounce_score_threshold',
'bounce_you_are_disabled_warnings',
'bounce_you_are_disabled_warnings_interval' and 'process_bounces' are
not currently exposed in Postorius, but if Mailman 2.1 lists are
imported with import21, they will be set appropriately and they will be
in Postorius eventually.


I don't speak from experience in regards to my comment made on DMARC 
mitigation. It was based on observing comments that have been made.


Bounce processing will still not be available for new users of Mailman 
which is my big concern. I assume new lists will have to have those 
settings adjusted via the Mailman shell?


--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.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] The last release from the GNU Mailman project

2020-02-27 Thread Mark Sapiro
On 2/27/20 1:37 PM, Brian Carpenter wrote:

Brian makes a number of good points. I just have a couple of
remarks/questions.


> 5. MM3 DMARC handling seems to have improved from reviews I have seen
> but NO BOUNCE PROCESSING.

I don't know why Mailman 3's DMARC mitigation is considered improved
over Mailman 2.1. It's the same. The Settings and Postorius UI for them
are more logical than MM 2.1, but they ultimately boil down to the same
things.

The latest Mailman core (not yet released but available at
 fully implements
bounce processing. Prior to this, bounce events were stored in the
database but not processed. Now they are.


> My goodness. How do list managers keep their
> mailing lists clean? I know how much a hit to an IP address reputation
> can be done when a server is sending messages out to invalid email
> addresses. However I don't think I can fix that right? It is a Mailman
> core issue? So let's say it does get added to MM Core. How long will it
> show up in Postorius? Especially since not every feature in MM Core is
> revealed in Postorius already.


As I said, it's in the latest version of core. The list specific
settings: 'bounce_info_stale_after', 'bounce_notify_owner_on_disable',
'bounce_notify_owner_on_removal', 'bounce_score_threshold',
'bounce_you_are_disabled_warnings',
'bounce_you_are_disabled_warnings_interval' and 'process_bounces' are
not currently exposed in Postorius, but if Mailman 2.1 lists are
imported with import21, they will be set appropriately and they will be
in Postorius eventually.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Brian Carpenter

On 2/27/20 2:44 PM, Mark Sapiro wrote:

I
have said before that a much better use of time and resources would be
the implementation of a light weight, non-Django web UI for Mailman 3,
but I don't see anyone raising a hand to do either.


Let me be more clearer on this.

I have hired a professional PHP developer to begin work on a new 
admin/forum interface for Mailman 3. The work begins next week. We are 
only focusing on the admin (Postorius) interface initially. I also am in 
the process of hiring a front end developer for the new interfaces. I 
believe in the Mailman project, and as someone who has benefited from 
offering Mailman hosting services for years, I don't want to see it go 
away. The problems however are this:


1. Mailman 2 is great. The interface for it is very outdated. This turns 
people off. UI design has come a long way and people are use to using 
modern UIs.


2. Mailman 2 does need to be ported to python 3 eventually but Mailman 3 
is already there so why spend extra time and resources on doing that? 
That is a good question and the answer may be to look at the way Mailman 
3 development is currently being handled. Also Mark Sapiro clearly wants 
us to put our support behind Mailman 3 which is good and he has my 
support with that.


3. Mailman 2 doesn't integrate well with other applications due to no 
REST api which I think is what modern users want these days. Mailman 3 
has a REST api which is great but again I am having issues with the way 
Mailman 3 is being developed.


4. So lovers/users of Mailman are stuck between a rock and hard place: 
Mailman 2 or Mailman 3? Which way to go?


For me, Mailman 3 is the way to go but I can no longer wait on the two 
interfaces of Mailman 3 to be brought to modern standards. 
Postorius/Hyperkitty came out flawed right from the beginning:


1. Outdated U.I.

2. All of Mailman Core features/functions not being revealed in 
Postorius. This is something I intend to fix quickly with the new U.I. 
as soon as I figure out what those features/functions are. Anyone want 
to provide a list of that to me off-list so I can pass it on to my 
programmer?


3. The decision to use Django. Maybe great for Python users but not for 
me and perhaps for others. This is also brings additional confusion. 
Mailman 3 has THREE interfaces: Postorius, Hyperkitty, and the Django 
admin interface.


4. Very poor documentation for Mailman 3 and way too many methods of 
installing it which means all kinds of versions of Mailman 3 are in 
production today because Mailman versions are dependent upon what method 
of installation a person chooses: Distro Package, Docker, Source, others?


5. MM3 DMARC handling seems to have improved from reviews I have seen 
but NO BOUNCE PROCESSING. My goodness. How do list managers keep their 
mailing lists clean? I know how much a hit to an IP address reputation 
can be done when a server is sending messages out to invalid email 
addresses. However I don't think I can fix that right? It is a Mailman 
core issue? So let's say it does get added to MM Core. How long will it 
show up in Postorius? Especially since not every feature in MM Core is 
revealed in Postorius already.


6. Social Media integration via Django is awful.

7. Hyperkitty just does not cut it in appearance and usability when it 
comes to a modern list forum. I am simply unable to compete with the 
growing number of applications that are being offered that has a better 
browser UI for communicating with list members.


I think the highest priority is to get Mailman 3 core up to speed in 
offering everything that Mailman 2 offers such as bounce processing. 
Then perhaps a whole new approach to interfacing with Mailman 3 core is 
in order. That part I have decided to work on because no matter how 
great MM3 core is, if the interfaces are poor then modern users will 
move on to something else.


I hope I did not offend anyone here or show disrespect to the hours and 
hours that have been spent on the Mailman 3 project. That was never my 
intention and I love Mailman and its community of users.


I would be interested to know if the developers of Mailman 3 are 
interested in the initiative I have taken to develop new interfaces for 
Mailman 3 that are more modernized and user-friendly.


--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.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] The last release from the GNU Mailman project

2020-02-27 Thread Dave McGuire
On 2/27/20 3:40 PM, Brian Carpenter wrote:
>> If you want to port Mailman 2 to Python 3, you are welcome to do it. I
>> have said before that a much better use of time and resources would be
>> the implementation of a light weight, non-Django web UI for Mailman 3,
>> but I don't see anyone raising a hand to do either.
> 
> I am doing that. I have hired a programmer and work beings for a new
> Mailman 3 UI next week.

  Whoa, wow...does this mean (when it's ready) that we'll be able to
dump the steaming pile that is django??

-Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA
--
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] The last release from the GNU Mailman project

2020-02-27 Thread Brian Carpenter

On 2/27/20 2:44 PM, Mark Sapiro wrote:

If you want to port Mailman 2 to Python 3, you are welcome to do it. I
have said before that a much better use of time and resources would be
the implementation of a light weight, non-Django web UI for Mailman 3,
but I don't see anyone raising a hand to do either.


I am doing that. I have hired a programmer and work beings for a new 
Mailman 3 UI next week.


--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-27 Thread Dimitri Maziuk via Mailman-Users
On 2/27/20 2:08 PM, Phil Stracchino wrote:
...
> What has this yielded?
> 
> "Most of the most commonly used parts" of Twisted are now Python 3
> compatible.

I hear this how upgrading any django installation from one python-3
version to another python-3 version usually goes. I.e. long-term, at
this point we're still better off porting MM2 than switching to MM3.

Not sure why, though: Jan 2020 has come and gone and all my python-2
scripts are still working. Amazingly enough.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Mark Sapiro
On 2/27/20 11:54 AM, Dennis Putnam wrote:
> 
> I didn't realize that there were OS dependencies in the DMARC
> mitigation. I thought it was all within the mailman code.


It's not an OS dependency. It's a downstream package dependency. If I
look at , The
newest RHEL/Centos RPM is 2.1.15-26.el7_4.1. Any DMARC mitigations in
this package were backported by RedHat as there were no DMARC
mitigations upstream before 2.1.16.

There does appear to be an EL-8 rpm at
.
You might consider trying that.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-27 Thread Phil Stracchino
On 2020-02-27 14:51, Bill Cole wrote:
> On 27 Feb 2020, at 14:24, Jim Popovitch via Mailman-Users wrote:
> 
>> Personally, I'd like to see the GNU Mailman project have a formal
>> Mailman 2.3 release that supports Python3, I feel that there would be 
>> a
>> lot of support for that.
> 
> I'm sure there would be widespread applause and congratulations if such 
> a thing were actually released. That sort of "support" is unhelpful 
> towards actually making such a release.
> 
> The needed support is the actual skilled effort of writing the required 
> Python3 code. I don't have the time to hunt down the specific 
> statements, but I have vague recollections that both Barry and Mark have 
> said repeatedly that doing so would be substantially more effort than 
> they are willing to put into anything built on the MM2 architecture.

Rewriting without breaking is hard.

There is a Python framework called Twisted.  It has a lot of useful
features.  Also a lot of vices, but a lot of useful features.  As best I
can determine, the task of updating it to be Python 3 compatible has now
been under way for ten years (with most of that time, only one person
working on it).

What has this yielded?

"Most of the most commonly used parts" of Twisted are now Python 3
compatible.



-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-27 Thread Bill Cole

On 27 Feb 2020, at 14:24, Jim Popovitch via Mailman-Users wrote:


Personally, I'd like to see the GNU Mailman project have a formal
Mailman 2.3 release that supports Python3, I feel that there would be 
a

lot of support for that.


I'm sure there would be widespread applause and congratulations if such 
a thing were actually released. That sort of "support" is unhelpful 
towards actually making such a release.


The needed support is the actual skilled effort of writing the required 
Python3 code. I don't have the time to hunt down the specific 
statements, but I have vague recollections that both Barry and Mark have 
said repeatedly that doing so would be substantially more effort than 
they are willing to put into anything built on the MM2 architecture.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
--
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] Handling Munged From Addresses

2020-02-27 Thread Dennis Putnam
On 2/27/2020 1:38 PM, Mark Sapiro wrote:
> On 2/27/20 10:17 AM, Dennis Putnam wrote:
>> Thanks for the reply. I am not seeing that. The From: looks like this:
>>
>> From: Rushtalk Discussion List via Rushtalk 
>
> That must be a RedHat thing having to do with their backport of DMARC
> mitigations. If you don't like it, install from source.
>
>
>> In "General Options" for that list I set the item "Replace the From:
>> header address with the list's posting address to mitigate issues
>> stemming from the original From: domain's DMARC or similar policies."
>> with "Munge From." Did I set the wrong thing?

>
> That will apply From: munging to all posts. I have no idea what the
> RedHat package does, but if in Privacy options... -> Sender filters you
> have dmarc_moderation_action and dmarc_quarantine_moderation_action set
> General Options -> from_is_list to No and set dmarc_moderation_action to
> Munge From and dmarc_quarantine_moderation_action to Yes and if you have
> it, dmarc_none_moderation_action to No.
>
> This will apply From: munging only to those messages From: a domain that
> publishes DMARC policy = reject or quarantine.
>
>
Hi Mark,

I didn't realize that there were OS dependencies in the DMARC
mitigation. I thought it was all within the mailman code.

In any case I'll look through those options and see what they do in
RHEL. Thanks.



signature.asc
Description: OpenPGP digital signature
--
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] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

2020-02-27 Thread Mark Sapiro
On 2/27/20 11:24 AM, Jim Popovitch via Mailman-Users wrote:
> 
> Who decides that there will be no more releases of MM2 from the GNU
> Mailman project?  


I do. I am the release manager and the only one making releases so I get
to decide.


> I've got to be honest, Mailman 3 still looks unstable to me.  I get that
> it's working on python.org where there are people working on it day
> after day, but surely you realize there are a ton of Mailman2 sites that
> don't have the time to develop and maintain their own install day after
> day.  Look at the MM3 list, there are people who do nothing but offer
> full time Mailman hosting and they have problem after problem.  And then
> there's the whole "I don't need a CMS for a MLM" argument.  I personally
> believe there's a lot more life left in MM2 than a few people want to
> admit. 


That's all well and good, but MM 2.1 is stable product that works. Why
does it need added/changed features at this point?


> OK, there's the Python2 EOL issue, but python2 isn't disappearing
> overnight, certainly not this month or next (as you say the case should
> be with MM2).  


Where do you get the idea that I said MM 2 will be disappearing? I never
said that. I just said there will be no further releases after 2.1.30.

This list will not go away, and I will not stop reading/responding until
the need for that goes away assuming I live that long


> I guess I'm just still a bit shocked to see you rush to abandon
> something so popular and established.


I'm not rushing to abandon anything. I'm just saying don't expect
Mailman 2.1.31 from the GNU Mailman project.


> Personally, I'd like to see the GNU Mailman project have a formal
> Mailman 2.3 release that supports Python3, I feel that there would be a
> lot of support for that.


If you want to port Mailman 2 to Python 3, you are welcome to do it. I
have said before that a much better use of time and resources would be
the implementation of a light weight, non-Django web UI for Mailman 3,
but I don't see anyone raising a hand to do either.


-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Handling Munged From Addresses

2020-02-27 Thread Mark Sapiro
On 2/27/20 10:27 AM, Dennis Putnam wrote:
> 
> From: Jane Doe (jane.doe at domain.tld) via Listname
> 

On 2/27/20 10:27 AM, Jim Popovitch via Mailman-Users wrote:
>
> Sorry, I meant this:
> 
> From: Jane Doe (jane.doe#domain.tld) via Listname 

Both of those still have the domain which is also considered problematic

We could consider

From: Jane Doe (jane.doe at domain dot tld) via Listname


for Mailman 3, but that seems unduly kludgy. There won't be any change
in Mailman 2.1 which is only waiting for i18n updates for the final
2.1.30 release which will be the last release from the GNU Mailman project.

The point is that we (apparently not RedHat's backport, but upstream)
already include the sender's display name and we try very hard to ensure
that compliant MUAs produce the same result for 'reply', 'reply-all' and
'reply-list' whether or not the From: is munged. I think that should be
sufficient.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Mark Sapiro
On 2/27/20 10:17 AM, Dennis Putnam wrote:
> 
> Thanks for the reply. I am not seeing that. The From: looks like this:
> 
> From: Rushtalk Discussion List via Rushtalk 


That must be a RedHat thing having to do with their backport of DMARC
mitigations. If you don't like it, install from source.


> In "General Options" for that list I set the item "Replace the From:
> header address with the list's posting address to mitigate issues
> stemming from the original From: domain's DMARC or similar policies."
> with "Munge From." Did I set the wrong thing?


That will apply From: munging to all posts. I have no idea what the
RedHat package does, but if in Privacy options... -> Sender filters you
have dmarc_moderation_action and dmarc_quarantine_moderation_action set
General Options -> from_is_list to No and set dmarc_moderation_action to
Munge From and dmarc_quarantine_moderation_action to Yes and if you have
it, dmarc_none_moderation_action to No.

This will apply From: munging only to those messages From: a domain that
publishes DMARC policy = reject or quarantine.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Dennis Putnam
On 2/27/2020 1:23 PM, Mark Sapiro wrote:
> On 2/27/20 10:05 AM, Jim Popovitch via Mailman-Users wrote:
>> I've been wondering if we should change that to something like this:
>>
>>  From: Jane Doe (jane@domain.tld) via Listname
>> 
>
> We specifically do not do that because it is said that multiple email
> addresses in From: trigger spam filters.
>

From: Jane Doe (jane.doe at domain.tld) via Listname





signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Jim Popovitch via Mailman-Users
On Thu, 2020-02-27 at 10:23 -0800, Mark Sapiro wrote:
> On 2/27/20 10:05 AM, Jim Popovitch via Mailman-Users wrote:
> > I've been wondering if we should change that to something like this:
> > 
> >  From: Jane Doe (jane@domain.tld) via Listname
> > 
> 
> We specifically do not do that because it is said that multiple email
> addresses in From: trigger spam filters.
> 

Sorry, I meant this:

From: Jane Doe (jane.doe#domain.tld) via Listname 
 


-Jim P.

--
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] Handling Munged From Addresses

2020-02-27 Thread Mark Sapiro
On 2/27/20 10:05 AM, Jim Popovitch via Mailman-Users wrote:
> 
> I've been wondering if we should change that to something like this:
> 
>  From: Jane Doe (jane@domain.tld) via Listname
> 


We specifically do not do that because it is said that multiple email
addresses in From: trigger spam filters.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Handling Munged From Addresses

2020-02-27 Thread Dennis Putnam
On 2/27/2020 12:58 PM, Mark Sapiro wrote:
> On 2/27/20 7:22 AM, Dennis Putnam wrote:
>> I think this may have been addressed but I can't find it. Now that I am
>> munging the from address to mitigate DMARC, recipients can no longer
>> tell who the message is from. What are other folks doing to handle that?
>> Other than having list members add their own signature? Thanks.
>
> The From: header in the munged message contains the sender's display
> name as in
>
> From: Jane Doe via ListName 
>
> and depending on list settings the original From: is in either Reply-To:
> or Cc:.
>
> If this is not sufficient, perhaps the recipients can use smarter email
> clients ;)
>
> Also, if you are Munging the From: on all messages via the from_is_list
> setting, it is better to use dmarc_moderation_action for this so only
> those From: headers that need it are munged. The only reason to use
> from_is_list is if those users whose domains publish DMARC reject or
> quarantine policy feel they are singled out and treated as second class
> users.
>
>
Hi Mark,

Thanks for the reply. I am not seeing that. The From: looks like this:

From: Rushtalk Discussion List via Rushtalk 

In "General Options" for that list I set the item "Replace the From:
header address with the list's posting address to mitigate issues
stemming from the original From: domain's DMARC or similar policies."
with "Munge From." Did I set the wrong thing?


signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Jim Popovitch via Mailman-Users
On Thu, 2020-02-27 at 09:58 -0800, Mark Sapiro wrote:
> On 2/27/20 7:22 AM, Dennis Putnam wrote:
> > I think this may have been addressed but I can't find it. Now that I am
> > munging the from address to mitigate DMARC, recipients can no longer
> > tell who the message is from. What are other folks doing to handle that?
> > Other than having list members add their own signature? Thanks.
> 
> The From: header in the munged message contains the sender's display
> name as in
> 
> From: Jane Doe via ListName 


I've been wondering if we should change that to something like this:

 From: Jane Doe (jane@domain.tld) via Listname



This would be better for mobile email clients which can't/don't easily
display reply-to or other headers.

-Jim P.

--
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] Possible Backup Issue

2020-02-27 Thread Dennis Putnam
On 2/27/2020 12:47 PM, Mark Sapiro wrote:
> On 2/27/20 6:27 AM, Dennis Putnam wrote:
>> It has not happened in 2 days however, there are no files in any of
>> those directories. Does that not imply the backups are not working? Is
>> that handled by a cronjob?
>
> This has nothing to do with backups per se. The error messages are
> somewhat different.
>
>> Feb 25 12:02:06 2020 (14100) Uncaught runner exception: [Errno 2] No
>> such file or directory
> The above actually goes with a set below (pid 14100).
>
>
>> Feb 25 12:02:06 2020 (5133) Uncaught runner exception: [Errno 2] No such
>> file or directory:
>> '/var/spool/mailman/out/1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d.pck'
>> Feb 25 12:02:06 2020 (5133) Traceback (most recent call last):
>>   File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop
>> msg, msgdata = self._switchboard.dequeue(filebase)
>>   File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 154, in dequeue
>> fp = open(filename)
>> IOError: [Errno 2] No such file or directory:
>> '/var/spool/mailman/out/1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d.pck'
>
> The above says OutgoingRunner has listed its queue and is now trying to
> retrieve the indicated .pck file from the queue, but it is gone. The
> only way this can happen is if another instance of OutgoingRunner has
> retrieved the message in the mean time.
>
>
>> Feb 25 12:02:06 2020 (5133) Skipping and preserving unparseable message:
>> 1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d
> This goes with the above, but is spurious. The missing file exception is
> assumed to be an unparseable message, but it's not.
>
>
>> Feb 25 12:02:06 2020 (14100) Traceback (most recent call last):
>>   File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop
>> msg, msgdata = self._switchboard.dequeue(filebase)
>>   File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 158, in dequeue
>> os.rename(filename, backfile)
>> OSError: [Errno 2] No such file or directory
>>
>> Feb 25 12:02:06 2020 (14100) Skipping and preserving unparseable
>> message: 1582657325.390982+30007f7a3ce65a426ba60c1ab46d996c33d2bb9a
>
> Here again, we are trying to retrieve a queued message that another
> instance has already retrieved.
>
> The rest of the messages are similar.
>
> As best as I can tell, this is all due to the issue discussed at
> . If the server has been rebooted since
> this happened, that would have fixed it.
>
>
Hi Mark,

Thanks. I'll just keep an eye on it to see if it recurs.



signature.asc
Description: OpenPGP digital signature
--
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] Handling Munged From Addresses

2020-02-27 Thread Mark Sapiro
On 2/27/20 7:22 AM, Dennis Putnam wrote:
> I think this may have been addressed but I can't find it. Now that I am
> munging the from address to mitigate DMARC, recipients can no longer
> tell who the message is from. What are other folks doing to handle that?
> Other than having list members add their own signature? Thanks.


The From: header in the munged message contains the sender's display
name as in

From: Jane Doe via ListName 

and depending on list settings the original From: is in either Reply-To:
or Cc:.

If this is not sufficient, perhaps the recipients can use smarter email
clients ;)

Also, if you are Munging the From: on all messages via the from_is_list
setting, it is better to use dmarc_moderation_action for this so only
those From: headers that need it are munged. The only reason to use
from_is_list is if those users whose domains publish DMARC reject or
quarantine policy feel they are singled out and treated as second class
users.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Possible Backup Issue

2020-02-27 Thread Mark Sapiro
On 2/27/20 6:27 AM, Dennis Putnam wrote:
> 
> It has not happened in 2 days however, there are no files in any of
> those directories. Does that not imply the backups are not working? Is
> that handled by a cronjob?


This has nothing to do with backups per se. The error messages are
somewhat different.

> Feb 25 12:02:06 2020 (14100) Uncaught runner exception: [Errno 2] No
> such file or directory

The above actually goes with a set below (pid 14100).


> Feb 25 12:02:06 2020 (5133) Uncaught runner exception: [Errno 2] No such
> file or directory:
> '/var/spool/mailman/out/1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d.pck'
> Feb 25 12:02:06 2020 (5133) Traceback (most recent call last):
>   File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop
> msg, msgdata = self._switchboard.dequeue(filebase)
>   File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 154, in dequeue
> fp = open(filename)
> IOError: [Errno 2] No such file or directory:
> '/var/spool/mailman/out/1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d.pck'


The above says OutgoingRunner has listed its queue and is now trying to
retrieve the indicated .pck file from the queue, but it is gone. The
only way this can happen is if another instance of OutgoingRunner has
retrieved the message in the mean time.


> Feb 25 12:02:06 2020 (5133) Skipping and preserving unparseable message:
> 1582657325.390982+504a3666a91ef8722e1af700669bf0190e00417d

This goes with the above, but is spurious. The missing file exception is
assumed to be an unparseable message, but it's not.


> Feb 25 12:02:06 2020 (14100) Traceback (most recent call last):
>   File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop
> msg, msgdata = self._switchboard.dequeue(filebase)
>   File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 158, in dequeue
> os.rename(filename, backfile)
> OSError: [Errno 2] No such file or directory
> 
> Feb 25 12:02:06 2020 (14100) Skipping and preserving unparseable
> message: 1582657325.390982+30007f7a3ce65a426ba60c1ab46d996c33d2bb9a


Here again, we are trying to retrieve a queued message that another
instance has already retrieved.

The rest of the messages are similar.

As best as I can tell, this is all due to the issue discussed at
. If the server has been rebooted since
this happened, that would have fixed it.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Possible Backup Issue

2020-02-27 Thread Dennis Putnam
On 2/26/2020 9:14 PM, Mark Sapiro wrote:
> On 2/26/20 8:18 AM, Dennis Putnam wrote:
>> mailman   5129  5125  0 Feb24 ?    00:00:16 /usr/bin/python
>> /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
>>
>> I think that means there is only 1 process.
>
> Yes, but maybe that wasn't the case at the time of those messages. Are
> the errors continuing? Also, I indicated BounceRunner as I was looking
> at the last messages you posted. There are also ones involving
> OutgoingRunner and VirginRunner
>
> Also, there should be files in /var/spool/mailman/bad/ which you may be
> able to examine with Mailman's dumpdb which are the unparseable message(s).
>
>
Hi Mark,

It has not happened in 2 days however, there are no files in any of
those directories. Does that not imply the backups are not working? Is
that handled by a cronjob?



signature.asc
Description: OpenPGP digital signature
--
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] Possible Backup Issue

2020-02-26 Thread Mark Sapiro
On 2/26/20 8:18 AM, Dennis Putnam wrote:
> 
> mailman   5129  5125  0 Feb24 ?    00:00:16 /usr/bin/python
> /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
> 
> I think that means there is only 1 process.


Yes, but maybe that wasn't the case at the time of those messages. Are
the errors continuing? Also, I indicated BounceRunner as I was looking
at the last messages you posted. There are also ones involving
OutgoingRunner and VirginRunner

Also, there should be files in /var/spool/mailman/bad/ which you may be
able to examine with Mailman's dumpdb which are the unparseable message(s).

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Possible Backup Issue

2020-02-26 Thread Dennis Putnam
On 2/26/2020 11:09 AM, Mark Sapiro wrote:
> On 2/26/20 6:56 AM, Dennis Putnam wrote:
>> I'm not sure why I am getting these errors but it seems to be associated
>> with backups. Is there a backup cronjob that didn't run, fail or is
>> something else wrong? The directories do exist but not the indicated pck
>> files. TIA
>
> I haven't looked at this in full detail, but is there more than one
> BounceRunner running processing the same slice. What does
>
> ps -fwwA|grep BounceRunner
>
> give? If there is more than one process showing
> "--runner=BounceRunner:0:1" see the article at
>  for advice on completely stopping
> Mailman and starting only one instance.
>

mailman   5129  5125  0 Feb24 ?    00:00:16 /usr/bin/python
/usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s

I think that means there is only 1 process.



signature.asc
Description: OpenPGP digital signature
--
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] Possible Backup Issue

2020-02-26 Thread Mark Sapiro
On 2/26/20 6:56 AM, Dennis Putnam wrote:
> I'm not sure why I am getting these errors but it seems to be associated
> with backups. Is there a backup cronjob that didn't run, fail or is
> something else wrong? The directories do exist but not the indicated pck
> files. TIA


I haven't looked at this in full detail, but is there more than one
BounceRunner running processing the same slice. What does

ps -fwwA|grep BounceRunner

give? If there is more than one process showing
"--runner=BounceRunner:0:1" see the article at
 for advice on completely stopping
Mailman and starting only one instance.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Archives Permission Denied

2020-02-26 Thread Dennis Putnam
On 2/25/2020 5:11 PM, Mark Sapiro wrote:
> On 2/25/20 10:25 AM, Dennis Putnam wrote:
>
>> So shouldn't 'check_perms -f' have fixed that?
>
> check_perms is not perfect. See below for more.
>
>
>> This is a server used strictly for mailman. There are only 2 users with
>> access so I am not worried about the caveat in that article. It looks
>> like you are giving me options and I am not sure what to do now?
>
> Either way works, but in your case, I would ensure
> /var/lib/mailman/archives/private is group mailman and mode is 2771.
> With this setting, check_perms will say
>
>> Warning: Private archive directory is other-executable (o+x).
>>  This could allow other users on your system to read private 
>> archives.
>>  If you're on a shared multiuser system, you should consult the
>>  installation manual on how to fix this.
> which you can ignore. The reason I suggest this is so you don't need to
> be concerned about the owner of /var/lib/mailman/archives/private
>
>
Got it. Thanks Mark.



signature.asc
Description: OpenPGP digital signature
--
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] Archives Permission Denied

2020-02-25 Thread Mark Sapiro
On 2/25/20 10:25 AM, Dennis Putnam wrote:

> So shouldn't 'check_perms -f' have fixed that?


check_perms is not perfect. See below for more.


> This is a server used strictly for mailman. There are only 2 users with
> access so I am not worried about the caveat in that article. It looks
> like you are giving me options and I am not sure what to do now?


Either way works, but in your case, I would ensure
/var/lib/mailman/archives/private is group mailman and mode is 2771.
With this setting, check_perms will say

> Warning: Private archive directory is other-executable (o+x).
>  This could allow other users on your system to read private archives.
>  If you're on a shared multiuser system, you should consult the
>  installation manual on how to fix this.

which you can ignore. The reason I suggest this is so you don't need to
be concerned about the owner of /var/lib/mailman/archives/private

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Archives Permission Denied

2020-02-25 Thread Dennis Putnam
On 2/25/2020 12:12 PM, Mark Sapiro wrote:
> On 2/25/20 6:34 AM, Brian Carpenter wrote:
>> On 2/25/20 5:49 AM, Dennis Putnam wrote:
>>> IOError: [Errno 13] Permission denied:
>>> '/var/lib/mailman/archives/private/rushtalk/2020-February.txt'
>>>
>>>   I ran check_perms and it found no issues. However, when I look at the
>>> ownership of the archives I get this:
>>>
>>> -rw-r--r--.    1 root mailman   72404 Feb 16 14:26 2020-February.txt
>>>
>>> Shouldn't either the owner be mailman or permissions be -rw-rw-r--? TIA.
> ...
>> From what I am seeing with my own servers, the permissions should be 664.
>>
> That's true, but more importantly, /var/lib/mailman/ should be 2775 and
> group mailman as should all the sub-directories  archives, data, lists,
> locks, logs, qfiles and spam. /var/lib/mailman/archives/private is
> tricky. it should be group mailman and either 2771 or owned by the web
> server user and 2770. See
>  for more on this.
>
So shouldn't 'check_perms -f' have fixed that?

This is a server used strictly for mailman. There are only 2 users with
access so I am not worried about the caveat in that article. It looks
like you are giving me options and I am not sure what to do now?



signature.asc
Description: OpenPGP digital signature
--
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] Membership List Include Legend Link Wrong

2020-02-25 Thread Dennis Putnam
On 2/25/2020 9:37 AM, Brian Carpenter wrote:
> On 2/25/20 5:36 AM, Dennis Putnam wrote:
>> The link to include legend on the membership management page is:
>>
>> http://localhost.localdomain/mailman/admin/rushtalk/members/list?legend=yes
>>
>>
>> Why is that not defaulting to the real host and how do I fix it? TIA.
>
> Have you tried running:
>
> /mailman_installation_directory/bin/withlist -l -r fix_url listname -u
> listdomain
>
> for the list to see if that fixes the issue?
>
Yes, I did that once when I first start the migration but I must have
made some inadvertent changes at some point. I ran it again and it
worked. Thanks.



signature.asc
Description: OpenPGP digital signature
--
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] Archives Permission Denied

2020-02-25 Thread Mark Sapiro
On 2/25/20 6:34 AM, Brian Carpenter wrote:
> On 2/25/20 5:49 AM, Dennis Putnam wrote:
>> IOError: [Errno 13] Permission denied:
>> '/var/lib/mailman/archives/private/rushtalk/2020-February.txt'
>>
>>   I ran check_perms and it found no issues. However, when I look at the
>> ownership of the archives I get this:
>>
>> -rw-r--r--.    1 root mailman   72404 Feb 16 14:26 2020-February.txt
>>
>> Shouldn't either the owner be mailman or permissions be -rw-rw-r--? TIA.
> 
...
> From what I am seeing with my own servers, the permissions should be 664.
> 

That's true, but more importantly, /var/lib/mailman/ should be 2775 and
group mailman as should all the sub-directories  archives, data, lists,
locks, logs, qfiles and spam. /var/lib/mailman/archives/private is
tricky. it should be group mailman and either 2771 or owned by the web
server user and 2770. See
 for more on this.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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] Membership List Include Legend Link Wrong

2020-02-25 Thread Brian Carpenter

On 2/25/20 5:36 AM, Dennis Putnam wrote:

The link to include legend on the membership management page is:

http://localhost.localdomain/mailman/admin/rushtalk/members/list?legend=yes

Why is that not defaulting to the real host and how do I fix it? TIA.


Have you tried running:

/mailman_installation_directory/bin/withlist -l -r fix_url listname -u 
listdomain


for the list to see if that fixes the issue?

--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
https://discourse.emwd.com/

Mailman 2 & 3 Hosting
https://www.mailmanhost.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] Archives Permission Denied

2020-02-25 Thread Brian Carpenter

On 2/25/20 5:49 AM, Dennis Putnam wrote:

IOError: [Errno 13] Permission denied:
'/var/lib/mailman/archives/private/rushtalk/2020-February.txt'

  I ran check_perms and it found no issues. However, when I look at the
ownership of the archives I get this:

-rw-r--r--.    1 root mailman   72404 Feb 16 14:26 2020-February.txt

Shouldn't either the owner be mailman or permissions be -rw-rw-r--? TIA.


Hi Dennis,

I hope you are doing well.

From what I am seeing with my own servers, the permissions should be 664.

--
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.com/

Mailan 2 & 3 Hosting
https://www.mailmanhost.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] I18n for Mailman 2.1.30

2020-02-19 Thread Mark Sapiro
On 2/17/20 3:44 PM, Mark Sapiro wrote:
> Over a month ago, I posted the following announcement particularly
> asking for i18n updates prior to the final release of Mailman 2.1.
> 
> To date I have only received updates for the Japanese translation.


I have now received an updated German translation thanks to Ludwig
Reiter. I have also received a work in progress of the Brazilian
Portugese translation from Emerson de Mello, so no one else needs to
work on 'de' or 'pt_BR'.

If you can help with any of the other translations you can submit a bzr
merge proposal on Launchpad or send an updated mailman.po file and or
templates directly to me.

I would like to get all this by the end of March.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] Mailman 2.1.30rc1 released

2020-02-17 Thread Mark Sapiro
Over a month ago, I posted the following announcement particularly
asking for i18n updates prior to the final release of Mailman 2.1.

To date I have only received updates for the Japanese translation.

If you can help update any of the other translations, please submit
changes as indicated below.


On 1/11/20 7:09 PM, Mark Sapiro wrote:
> I am pleased to announce the release of Mailman 2.1.30rc1.
> 
> 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. See the
> attached README.txt for details.
> 
> Mailman 2.1.30 will be the last release of the Mailman 2.1 branch from
> the GNU Mailman project. It contains some new strings which are
> untranslated in most of the i18n translations. If you can help update
> any of the translations, please contribute your changes.
> 
> Changes can be submitted via a bzr merge proposal on Launchpad or by
> sending an updated mailman.po file and or templates directly to me. This
> will be the last chance to get i18n updates into a release.
> 
> 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/
> 
> Mailman 2.1.30rc1 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, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] mailman 2.1.18 for RHEL 5

2020-02-17 Thread Mark Sapiro
On 2/17/20 2:27 AM, Dennis Putnam wrote:

> It turns out that the only version available for RHEL 7 is 2.1.12.
> However, the mailman documentation indicates that also has DMARC
> mitigation.


What documentation? I assume Red Hat's. In any case, what you will have,
as others have said, is 2.1.12 with who knows what later features and
fixes backported by Red Hat to make what they call 2.1.12-xx.yy, and if
you run into trouble, we (this list) my not be able to help.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan



signature.asc
Description: OpenPGP digital signature
--
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] mailman 2.1.18 for RHEL 5

2020-02-17 Thread dmaziuk via Mailman-Users

On 2/17/2020 11:24 AM, Lindsay Haisley (linode) wrote:





This is common practice for all major distributions. The only way to keep up 
with upstream versions is to install from same from the git-go. This has its 
own pitfalls, but I do this for Mailman and have never had a problem.


I'm still hoping to some day get a round tuit for trying to fit MM2 in a 
docker container. You know exactly what codebase you have from the 
git-go, and if the new one does not cut it, the good old container is 
still there to fall back to.


The clue is strong with docker people.

D
--
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] mailman 2.1.18 for RHEL 5

2020-02-17 Thread Lindsay Haisley (linode)


On Feb 17, 2020, at 10:45 AM, Phil Stracchino  wrote:
> 
>> On 2020-02-17 10:56, Bill Cole wrote:
>> RedHat has a policy of nailing down nominal versions of software with 
>> each major RHEL release and then backporting whatever fixes they deem 
>> important into their packages over the life of the major release, adding 
>> their own subordinate versioning. 

> An unfortunate side effect of this is that it makes it very difficult to
> support some software on Red Hat because you don't know for sure what
> codebase you're actually running, except that it's probably neither fish
> nor fowl nor good red meat.

This is common practice for all major distributions. The only way to keep up 
with upstream versions is to install from same from the git-go. This has its 
own pitfalls, but I do this for Mailman and have never had a problem.

Sent from my iPhone


--
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


  1   2   3   4   5   6   7   8   9   10   >