Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Held messages not delivered after approval

by Krinetzki, Stephan

Hi Mark, Hi Stephen, so I updated now my configuration a bit. The logging is now default: [logging.archiver] datefmt: %b %d %H:%M:%S %Y [logging.archiver] format: %(asctime)s (%(process)d) %(message)s [logging.archiver] level: info [logging.archiver] path: mailman.log [logging.archiver] propagate: no [logging.bounce] datefmt: %b %d %H:%M:%S %Y [logging.bounce] format: %(asctime)s (%(process)d) %(message)s [logging.bounce] level: info [logging.bounce] path: bounce.log [logging.bounce] propagate: no [logging.config] datefmt: %b %d %H:%M:%S %Y [logging.config] format: %(asctime)s (%(process)d) %(message)s [logging.config] level: info [logging.config] path: mailman.log [logging.config] propagate: no [logging.database] datefmt: %b %d %H:%M:%S %Y [logging.database] format: %(asctime)s (%(process)d) %(message)s [logging.database] level: warn [logging.database] path: mailman.log [logging.database] propagate: no [logging.debug] datefmt: %b %d %H:%M:%S %Y [logging.debug] format: %(asctime)s (%(process)d) %(message)s [logging.debug] level: info [logging.debug] path: debug.log [logging.debug] propagate: no [logging.error] datefmt: %b %d %H:%M:%S %Y [logging.error] format: %(asctime)s (%(process)d) %(message)s [logging.error] level: info [logging.error] path: mailman.log [logging.error] propagate: no [logging.fromusenet] datefmt: %b %d %H:%M:%S %Y [logging.fromusenet] format: %(asctime)s (%(process)d) %(message)s [logging.fromusenet] level: info [logging.fromusenet] path: mailman.log [logging.fromusenet] propagate: no [logging.gunicorn] datefmt: %b %d %H:%M:%S %Y [logging.gunicorn] format: %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" [logging.gunicorn] level: info [logging.gunicorn] path: mailman.log [logging.gunicorn] propagate: no [logging.http] datefmt: %b %d %H:%M:%S %Y [logging.http] format: %(asctime)s (%(process)d) %(message)s [logging.http] level: info [logging.http] path: mailman.log [logging.http] propagate: no [logging.locks] datefmt: %b %d %H:%M:%S %Y [logging.locks] format: %(asctime)s (%(process)d) %(message)s [logging.locks] level: info [logging.locks] path: mailman.log [logging.locks] propagate: no [logging.mischief] datefmt: %b %d %H:%M:%S %Y [logging.mischief] format: %(asctime)s (%(process)d) %(message)s [logging.mischief] level: info [logging.mischief] path: mailman.log [logging.mischief] propagate: no [logging.plugins] datefmt: %b %d %H:%M:%S %Y [logging.plugins] format: %(asctime)s (%(process)d) %(message)s [logging.plugins] level: info [logging.plugins] path: plugins.log [logging.plugins] propagate: no [logging.root] datefmt: %b %d %H:%M:%S %Y [logging.root] format: %(asctime)s (%(process)d) %(message)s [logging.root] level: info [logging.root] path: mailman.log [logging.root] propagate: no [logging.runner] datefmt: %b %d %H:%M:%S %Y [logging.runner] format: %(asctime)s (%(process)d) %(message)s [logging.runner] level: info [logging.runner] path: mailman.log [logging.runner] propagate: no [logging.smtp] datefmt: %b %d %H:%M:%S %Y [logging.smtp] every: $msgid smtp to $listname for $recip recips, completed in $time seconds [logging.smtp] failure: $msgid delivery to $recip failed with code $smtpcode, $smtpmsg [logging.smtp] format: %(asctime)s (%(process)d) %(message)s [logging.smtp] level: info [logging.smtp] path: smtp.log [logging.smtp] propagate: no [logging.smtp] refused: $msgid post to $listname from $sender, $size bytes, $refused failures [logging.smtp] success: $msgid post to $listname from $sender, $size bytes [logging.subscribe] datefmt: %b %d %H:%M:%S %Y [logging.subscribe] format: %(asctime)s (%(process)d) %(message)s [logging.subscribe] level: info [logging.subscribe] path: mailman.log [logging.subscribe] propagate: no [logging.task] datefmt: %b %d %H:%M:%S %Y [logging.task] format: %(asctime)s (%(process)d) %(message)s [logging.task] level: info [logging.task] path: mailman.log [logging.task] propagate: no [logging.vette] datefmt: %b %d %H:%M:%S %Y [logging.vette] format: %(asctime)s (%(process)d) %(message)s [logging.vette] level: info [logging.vette] path: mailman.log [logging.vette] propagate: no Further, I edited the logrotate: /var/log/mailman/mailman-logs/*.log { missingok daily compress delaycompress nomail notifempty rotate 14 dateext su mailman mailman olddir /var/log/mailman/mailman-logs/oldlogs postrotate /bin/kill -HUP `cat /opt/mailman/var/master.pid 2>/dev/null` 2>/dev/null || true # Don't run "mailman3 reopen" with SELinux on here in the logrotate # context, it will be blocked /opt/mailman/mailman-venv/bin/mailman reopen >/dev/null 2>&1 || true endscript } It is now more like the Fedora one and seems to be better. Now in the mailman.log I see the HOLD messages and the approved messages. The smtp.log logs just the incoming Mail, which seems to be fine. So, here a complete Trace: smtp.log: Aug 05 10:18:40 2025 (217984) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Aug 05 10:18:40 2025 (217984) Peer: ('127.0.0.1', 57074) Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) handling connection Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'LHLO lists.rwth-aachen.de' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'MAIL FROM:<SENDER> SIZE=15187' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) sender: SENDER Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'RCPT TO:<stephansmodliste(a)lists.example.com>' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) recip: stephansmodliste(a)lists.example.com Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'DATA' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'QUIT' Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) connection lost Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) Connection lost during _handle_client() The mailman.log: Aug 05 10:18:40 2025 (217983) HOLD: stephansmodliste(a)lists.example.com post from SENDER held, message-id=<b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN>: The message is not from a list member Aug 05 10:21:04 2025 (218015) held message approved, message-id: <b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN> [05/Aug/2025:10:21:04 +0200] "POST /3.1/lists/stephansmodliste(a)lists.example.com/held/211056 HTTP/1.1" 204 0 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=0&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=10&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5" [05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5" Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25 The last error is a very often in the mailman.log: Aug 05 09:46:12 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:13 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:13 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:14 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:46:24 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:50:22 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:50:24 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:53:30 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:01 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:01 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:55:09 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:57:44 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:57:46 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:50 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:52 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:52 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 09:58:53 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:01:18 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:02:02 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:07:11 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:10:36 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:11:35 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:04 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:05 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:07 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:16:58 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:17:42 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:18:30 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:20:13 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:08 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:08 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:31 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:37 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:44 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:47 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:50 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:28:57 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:22 2025 (217988) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:40 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:29:41 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:37 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:37 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:30:50 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:31:15 2025 (217987) Cannot connect to SMTP server localhost on port 25 Aug 05 10:33:42 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:33:53 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:34:27 2025 (217985) Cannot connect to SMTP server localhost on port 25 Aug 05 10:34:28 2025 (217986) Cannot connect to SMTP server localhost on port 25 Aug 05 10:38:25 2025 (230250) Cannot connect to SMTP server lists.example.com on port 25 Aug 05 10:38:25 2025 (230247) Cannot connect to SMTP server lists.example.com on port 25 Even after changing the smtp_host in mailman.cfg this error appears randomly. Sadly the mail does not get delivered. -- Stephan Krinetzki IT Center Gruppe: Anwendungsbetrieb und Cloud Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki(a)itc.rwth-aachen.de www.itc.rwth-aachen.de Social Media Kanäle des IT Centers: https://blog.rwth-aachen.de/itc/ https://www.facebook.com/itcenterrwth https://www.linkedin.com/company/itcenterrwth https://twitter.com/ITCenterRWTH https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Tuesday, August 5, 2025 12:51 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: Held messages not delivered after approval On 8/4/25 00:21, Krinetzki, Stephan wrote: >> >> And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful. > > If there were any. Maybe the "debug" level should be "info". But for which logs? The standard logging levels from lowest to highest are debug info warning error critical Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged. For every shunted message, a message like `SHUNTING: <file name without the .pck extention>` preceded by the exception and traceback is logged to error.log with level error. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py… > Maybe the restart at night after the lograte maybe the issue. As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g. ``` if queues empty: restart Mailman else: when in queue is empty, sigterm incoming runner when out queue is empty, stop Mailman when Mailman stopped, start Mailman ``` The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to krinetzki(a)itc.rwth-aachen.de

5 months, 1 week

[MM3-users] Re: Please help - Held message is crashing mailman.

by Alex King

Thanks for your help Mark, it's ideal having the pointer to the issue in gitlab. I'll raise a bug with Ubuntu because this makes mailman3 in their LTS version unusable for me. Perhaps they can backport a fix for their version in LTS, otherwise they may have a backport or PPA source where I can get a 3.2 version, or just pin some packages from cosmic or disco. I think documenting this will be useful to people who hit the issue in future (Bionic/18.04 is supported until 2023, and likely the most used until 20.04 is released). Thanks, Alex On 7/04/19 4:29 AM, Mark Sapiro wrote: > On 4/5/19 10:27 PM, Alex King via Mailman-users wrote: >> Hi, >> >> I've used mailman a lot in the past, and decided to install mailman3 in >> a recent install. I'm unimpressed so far, it seems buggy. >> >> Running on Ubuntu 18.04.2 LTS from packages, mailman3 3.1.1-9, >> mailman3-web 0+20170523-14, python-django-postorius 1.1.2-3. >> >> After a few messages, I now can't go to the "Held Messages" in >> postorius, I get a 500 error. >> >> I tried to interact on the command line, but could not work out how. >> Reading >> https://mailman.readthedocs.io/en/latest/src/mailman/docs/install.html >> and >> https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…, >> I tried: >> >> # mailman shell >> Welcome to the GNU Mailman shell >> >>>>> command = cli('mailman.commands.cli_withlist.shell') >> Traceback (most recent call last): >> File "/usr/lib/python3.6/code.py", line 91, in runcode >> exec(code, self.locals) >> File "<console>", line 1, in <module> >> NameError: name 'cli' is not defined >> >> I did a lot of reading of the manual and googled, but I have no idea >> where the cli object is supposed to come from.....? The documentation >> is confusing. > > The line > > command = cli('mailman.commands.cli_withlist.shell') > > in > <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…> > is dependent upon some behind the scenes setup to make the doctests > work. Granted this is confusing, but basically all that does is set > things up for the doctests to run the 'mailman shell' command. It is not > intended to be run from within 'mailman shell'. > > >> Anyway, after some trial and error, i found: >> >> # mailman shell >> Welcome to the GNU Mailman shell >>>>> list_manager = getUtility(IListManager) >>>>> m=list_manager.get("committee(a)[redacted].org") >>>>> from mailman.interfaces.requests import IListRequests >>>>> requests = IListRequests(m) >>>>> [x for x in requests.held_requests][0].id >> 8 >>>>> requests.get_request(8) >> Traceback (most recent call last): >> File "/usr/lib/python3.6/code.py", line 91, in runcode >> exec(code, self.locals) >> File "<console>", line 1, in <module> >> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", >> line 85, in wrapper >> return function(args[0], config.db.store, *args[1:], **kws) >> File "/usr/lib/python3/dist-packages/mailman/model/requests.py", line >> 120, in get_request >> result.data_hash, expunge=False) >> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", >> line 85, in wrapper >> return function(args[0], config.db.store, *args[1:], **kws) >> File "/usr/lib/python3/dist-packages/mailman/model/pending.py", line >> 138, in confirm >> value = json.loads(keyvalue.value) >> File "/usr/lib/python3.6/json/__init__.py", line 354, in loads >> return _default_decoder.decode(s) >> File "/usr/lib/python3.6/json/decoder.py", line 339, in decode >> obj, end = self.raw_decode(s, idx=_w(s, 0).end()) >> File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode >> obj, end = self.scan_once(s, idx) >> json.decoder.JSONDecodeError: Unterminated string starting at: line 1 >> column 1 (char 0) >> >> It seems something was written out to disk that can't be read in for >> some reason (assuming a json object on disk?) > > This is <https://gitlab.com/mailman/mailman/issues/385> which should be > fixed by <https://gitlab.com/mailman/mailman/merge_requests/333>. The > fix in in Mailman core version 3.2.0 > > >> How do I debug this further? How do I find the json being decoded? Any >> help would be appreciated. (I found mailman2 just worked, I was happy >> with that.) > > The issue is in storing a pickled representation of the json encoding of > 'rule_misses'. This gets very long if you have lots of header filters, > and with at least the mysql backend gets truncated in the database which > causes the Unterminated string error. > > I'm not sure what your options are for upgrading. The current Debian > packages are all >= 3.2.0 [1], but Ubuntu doesn't get 3.2.0 until cosmic > (18.10) [2]. > > [1] https://packages.debian.org/search?keywords=mailman3 > [2] https://packages.ubuntu.com/search?keywords=mailman3 > >> (My colleague posted a bug about this I believe but I don't have the >> link to that.) > > I haven't seen it. > >

6 years, 9 months

[MM3-users] Re: error changed after restart

by Guillermo Hernandez (Oldno7)

On 6/2/21 18:08, Abhilash Raj wrote: > > On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: >> I restarted de server and the error changed. Now the log shows >> "KeyError: 'subscription_mode'": > Did you also restart Mailman Core after the upgrade? Yes, indeed: I stopped mailman core and all the processes related. Did the upgrades. Started all again. Find the errors in the web user interface. Stopped all again. Looked for errors in the log. Restarted the complete server. Found the second error that this second mail is about to. It happens when, in the main page that shows all the lists you click to see one of them. It seems to me that it has been database structure changes in django that the upgrade is not aware... but it's a very long shot from my side. I'm using sqlite as django database and mysql for mailman. > >> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal Server >> Error: /mailman3/mailman3/lists/name_and_domain.of.the.list >> Traceback (most recent call last): >> File >> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >> line 119, in __getattr__ >> return self._get(name) >> File >> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >> line 86, in _get >> raise KeyError(key) >> KeyError: 'subscription_mode' >> >> During handling of the above exception, another exception occurred: >> >> Traceback (most recent call last): >> File >> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py", >> line 34, in inner >> response = get_response(request) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >> line 115, in _get_response >> response = self.process_exception_by_middleware(e, request) >> File >> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >> line 113, in _get_response >> response = wrapped_callback(request, *callback_args, **callback_kwargs) >> File >> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >> line 71, in view >> return self.dispatch(request, *args, **kwargs) >> File >> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py", >> line 74, in dispatch >> return super(MailingListView, self).dispatch(request, *args, **kwargs) >> File >> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >> line 97, in dispatch >> return handler(request, *args, **kwargs) >> File >> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py", line >> 295, in get >> member.subscription_mode == >> File >> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >> line 124, in __getattr__ >> self.__class__.__name__, name)) >> AttributeError: 'Member' object has no attribute 'subscription_mode' >> *********************** >> some info about the installed versions via pip list: >> pip list | grep django >> django-allauth 0.44.0 >> django-appconf 1.0.4 >> django-compressor 2.4 >> django-extensions 3.1.0 >> django-gravatar2 1.4.4 >> django-haystack 3.0 >> django-mailman3 1.3.5 >> django-picklefield 3.0.1 >> django-q 1.3.4 >> djangorestframework 3.12.2 >> >> pip list | grep mailman >> django-mailman3 1.3.5 >> mailman 3.3.3 >> mailman-hyperkitty 1.1.0 >> mailmanclient 3.3.2 >> >> pip list | grep postorius >> postorius 1.3.4 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 6/2/21 11:12, Guillermo Hernandez (Oldno7) via Mailman-users wrote: >>> I've just upgrade mailman 3 installation following Mr. Sapiro advice: >>> did a >>> >>> pip install --upgrade django-mailman3 hyperkitty mailman mailmanclient >>> mailman-hyperkitty postorius >>> >>> I did a "python3 manage.py migrate" after, too. >>> >>> And all seemed to run well. >>> >>> All the lists showed in postorius via web, but when I try to accesss >>> into one of them the browser shows an error. >>> >>> In the log you can see: >>> >>> *-*-*-*-*-*-* >>> >>> Traceback (most recent call last): >>> File >>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>> line 119, in __getattr__ >>> return self._get(name) >>> File >>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>> line 86, in _get >>> raise KeyError(key) >>> KeyError: 'get_requests_count' >>> >>> ... (And after all the traceback lines) >>> >>> AttributeError: 'MailingList' object has no attribute >>> 'get_requests_count' >>> >>> *-*-*-*-*-*-*-* >>> >>> The lists seem to be distributing messeages well.. but I cannot acces >>> via web administration (django/postorius) >>> >>> Can anyone point me in the right direction to solve this, please? >>> >>> _______________________________________________ >>> Mailman-users mailing list -- mailman-users(a)mailman3.org >>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>> >> _______________________________________________ >> Mailman-users mailing list -- mailman-users(a)mailman3.org >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>

4 years, 11 months

[MM3-users] Re: Message-Footer after migrating to Mailman3

by christopher.claus＠tgcamberg1848.de

Mark Sapiro wrote: > > ERROR 2021-05-24 16:22:22,895 1648 django.security.DisallowedHost Invalid HTTP_HOST header: 'tgc_mailman_web:8000'. The domain name provided is not valid according to RFC 1034/1035. > > WARNING 2021-05-24 16:22:22,896 1648 django.request Bad Request: /postorius/api/templates/list/homepage.gruppe.tgcamberg1848.de/list:member:regular:footer > > It appears you created the new template with Postorius, but there is an > issue for Postorius templates. Possibly your Django setting for > POSTORIUS_TEMPLATE_BASE_URL needs to be adjusted. > > Obviously I have a problem with the hostname. I set > > [code] > > POSTORIUS_TEMPLATE_BASE_URL=http://tgc_mailman_web:8000 > > [/code] > > where tgc_mailman_web is my container name. This URL ist stored in the DB-table "template" for the name=list:member:regular:footer. A call to my fqdn or to localhost > > [code] > > wget http://localhost:8000/postorius/api/templates/list/homepage.gruppe.tgcamberg... > > [/code] > > will return the footer itself - this works fine. Therefore, should i set POSTORIUS_TEMPLATE_BASE_URL to http://localhost:8000? > > If that works, yes. Hi Mark, thanks for your reply and excuse my delay. I was very busy in the last weeks but made some tests. Newly created templates with POSTORIUS_TEMPLATE_BASE_URL=http://localhost:8000 did not work. I changed it to my fqdn - at the moment I am able to access the template via this URl (e.G. http://lists.example.de:8000/postorius/api/templates/list/homepage.lists.ex…) But if I try to send an email I got the following error: Jul 09 16:00:37 2021 (27) Uncaught runner exception: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/homepage.lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused')) Jul 09 16:00:37 2021 (27) Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn conn = connection.create_connection( File "/usr/lib/python3.8/site-packages/urllib3/util/connection.py", line 84, in create_connection raise err File "/usr/lib/python3.8/site-packages/urllib3/util/connection.py", line 74, in create_connection sock.connect(sa) ConnectionRefusedError: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen httplib_response = self._make_request( File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 392, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib/python3.8/http/client.py", line 1255, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3.8/http/client.py", line 1301, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3.8/http/client.py", line 1250, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3.8/http/client.py", line 1010, in _send_output self.send(msg) File "/usr/lib/python3.8/http/client.py", line 950, in send self.connect() File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 187, in connect conn = self._new_conn() File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 171, in _new_conn raise NewConnectionError( urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 439, in send resp = conn.urlopen( File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 724, in urlopen retries = retries.increment( File "/usr/lib/python3.8/site-packages/urllib3/util/retry.py", line 439, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 173, in _one_iteration self._process_one_file(msg, msgdata) File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 266, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/python3.8/site-packages/mailman/runners/incoming.py", line 79, in _dispose process(mlist, msg, msgdata, start_chain) File "/usr/lib/python3.8/site-packages/mailman/core/chains.py", line 79, in process link.function(mlist, msg, msgdata) File "/usr/lib/python3.8/site-packages/mailman/chains/hold.py", line 232, in _process template = getUtility(ITemplateLoader).get( File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 188, in get contents = getUtility(ITemplateManager).get( File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 110, in get contents = protocols.get(actual_uri, **auth) File "/usr/lib/python3.8/site-packages/mailman/utilities/protocols.py", line 38, in get response = requests.get(url, timeout=REQUEST_TIMEOUT, **kws) File "/usr/lib/python3.8/site-packages/requests/api.py", line 76, in get return request('get', url, params=params, **kwargs) File "/usr/lib/python3.8/site-packages/requests/api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 530, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 643, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 516, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused')) I set POSTORIUS_TEMPLATE_BASE_URL=lists.example.de:8000 and I have no idea, why the connection is refused. Do you see any configuration error d or have another idea? Best regards, chrclaus

4 years, 6 months

[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'

by Odhiambo Washington

On Sat, 25 Jul 2020 at 19:58, Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/25/20 6:36 AM, Odhiambo Washington wrote: > > I decided to try this again, on FreeBSD-12.1 > > > > I still decided to follow > > https://wiki.list.org/DOC/Mailman%203%20installation%20experience which > I > > know is not the main documentation, but I find the process easier to > follow. > > I am also taking notes to see if I could share if I manage to succeed. > This > > is important for me because Python-2.7 is being removed from FreeBSD in > Dec > > 2020. I need to bail > > out of mailman-2.x before that happens so I am trying my hand again om > MM3. > > I have failed before :-) > > Even if it's not in FreeBSD, you can download Python 2.1.18 from > <https://www.python.org/downloads/release/python-2718/> and install it. > > > > (venv) [root@gw /opt/mailman/mm]# pip install flufl.lock > ... > > Even after the 'pip install flufl.lock' it still doesn't find it! > > > This is a packaging glitch with the flufl modules. Remove and reinstall > them. > > pip uninstall flufl.bounce flufl.i18n flufl.lock > pip install flufl.bounce flufl.i18n flufl.lock > > It would appear that luck isn't just on my side: root@gw:/opt/mailman/mm # pip uninstall flufl.bounce flufl.i18n flufl.lock WARNING: Skipping flufl.bounce as it is not installed. WARNING: Skipping flufl.i18n as it is not installed. Found existing installation: flufl.lock 4.0 Uninstalling flufl.lock-4.0: Would remove: /usr/local/lib/python3.7/site-packages/flufl.lock-4.0-py3.7-nspkg.pth /usr/local/lib/python3.7/site-packages/flufl.lock-4.0.dist-info/* /usr/local/lib/python3.7/site-packages/flufl/lock/* Proceed (y/n)? y Successfully uninstalled flufl.lock-4.0 root@gw:/opt/mailman/mm # pip install flufl.bounce flufl.i18n flufl.lock Collecting flufl.bounce Downloading flufl.bounce-3.0.1-py3-none-any.whl (175 kB) |████████████████████████████████| 175 kB 18 kB/s Collecting flufl.i18n Downloading flufl.i18n-3.0.tar.gz (21 kB) Processing /root/.cache/pip/wheels/5a/de/bb/5e6448d5923f53f07f181ec225bf7b1d778d42384869dcf261/flufl.lock-4.0-py3-none-any.whl Requirement already satisfied: atpublic in /usr/local/lib/python3.7/site-packages (from flufl.bounce) (1.0) Collecting zope.interface Downloading zope.interface-5.1.0.tar.gz (225 kB) |████████████████████████████████| 225 kB 35 kB/s Requirement already satisfied: psutil in /usr/local/lib/python3.7/site-packages (from flufl.lock) (5.7.2) Requirement already satisfied: setuptools in /usr/local/lib/python3.7/site-packages (from zope.interface->flufl.bounce) (40.6.2) Building wheels for collected packages: flufl.i18n, zope.interface Building wheel for flufl.i18n (setup.py) ... done Created wheel for flufl.i18n: filename=flufl.i18n-3.0-py3-none-any.whl size=27279 sha256=7adc834e27423865de03bcad268b86d9df1d24c59110c7e4d4b8bb5863fb4e53 Stored in directory: /root/.cache/pip/wheels/5c/85/09/5b346688f1283d8622ac06adf4f2682bb13d36c2f410c52eb6 Building wheel for zope.interface (setup.py) ... done Created wheel for zope.interface: filename=zope.interface-5.1.0-cp37-cp37m-freebsd_12_1_RELEASE_p7_amd64.whl size=194660 sha256=51f326627a9121d8b4df989714bdcdf516f02d55f99de38bb9d7cc9867d93146 Stored in directory: /root/.cache/pip/wheels/84/93/fd/6bcb85b4bbf697c15b066350384cf3651feb47dcd5029a0b8d Successfully built flufl.i18n zope.interface Installing collected packages: zope.interface, flufl.bounce, flufl.i18n, flufl.lock Successfully installed flufl.bounce-3.0.1 flufl.i18n-3.0 flufl.lock-4.0 zope.interface-5.1.0 root@gw:/usr/home/wash # cd /opt/mailman/mm/ root@gw:/opt/mailman/mm # virtualenv venv created virtual environment CPython3.7.8.final.0-64 in 285ms creator CPython3Posix(dest=/opt/mailman/mm/venv, clear=False, global=False) seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv) added seed packages: PyMySQL==0.10.0, Whoosh==2.7.4, gunicorn==20.0.4, mod_wsgi==4.7.1, mysqlclient==2.0.1, pip==20.1.1, psycopg2_binary==2.8.5, pylibmc==1.6.1, setuptools==49.2.0, wheel==0.34.2 activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator root@gw:/opt/mailman/mm # bash [root@gw /opt/mailman/mm]# source /opt/mailman/mm/venv/bin/activate (venv) [root@gw /opt/mailman/mm]# /opt/mailman/mm/bin/mailman-post-update + '[' False == False ']' + mkdir -p /opt/mailman/mm/static + /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput --verbosity 0 Traceback (most recent call last): File "/opt/mailman/mm/venv/bin/django-admin", line 33, in <module> sys.exit(load_entry_point('Django==3.0.8', 'console_scripts', 'django-admin')()) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/core/management/__init__.py", line 401, in execute_from_command_line utility.execute() File "/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/core/management/__init__.py", line 377, in execute django.setup() File "/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/__init__.py", line 24, in setup apps.populate(settings.INSTALLED_APPS) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/apps/registry.py", line 114, in populate app_config.import_models() File "/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/apps/config.py", line 211, in import_models self.models_module = import_module(models_module_name) File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 677, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 728, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/__init__.py", line 26, in <module> from .email import Attachment, Email File "/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/email.py", line 35, in <module> from .mailinglist import MailingList File "/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/mailinglist.py", line 37, in <module> from hyperkitty.lib.utils import pgsql_disable_indexscan File "/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/lib/utils.py", line 42, in <module> from flufl.lock import Lock ModuleNotFoundError: No module named 'flufl.lock' (venv) [root@gw /opt/mailman/mm]# What else should I try? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

5 years, 5 months

[MM3-users] Re: Timeouts

by Abhilash Raj

> On Apr 25, 2021, at 7:06 PM, tlhackque via Mailman-users <mailman-users(a)mailman3.org> wrote: > > On 25-Apr-21 20:34, Mark Sapiro wrote: >> On 4/25/21 4:37 PM, tlhackque via Mailman-users wrote: >> >>> The described timeouts are something that hyperkitty ought to be able to >>> avoid. For apache, the timeout is idle time between blocks of output. >>> Hyperkitty can avoid this by generating the archive in segments (based >>> on size, or elapsed time), flushing its output buffer, generating a >>> multi-file archive, and/or using Transfer-Encoding: chunked (chunked >>> doesn't work for http/2). It ought to be able to break the > work into >>> blocks of "n" messages & do something to generate output. Besides >>> avoiding timeouts, working in segments allows the GUI to display >>> meaningful progress (e.g. if you're loading with XMLHttpRequest, >>> "onprogress") It really oughtn't be up to the user to break up the >>> request. >> It is not the web server that times out. I'm not sure about uwsgi >> because I don't use it, but the timeouts I see are on servers that use >> gunicorn as the WSGI interface to Django and the timeout is in a >> gunicorn worker. This is controlled by the timeout setting in the >> gunicorn config. <https://docs.gunicorn.org/en/stable/settings.html#timeout> >> >> Note that even 300 seconds is not enough to download the entire >> <https://mail.python.org/archives/list/python-dev@python.org/> archive. >> >> It may be possible to get HyperKitty to chunk the output to avoid this, >> but it doesn't currently do that. Care to submit an MR? >> >> > I'm afraid (u)WSGI, Django, and gunicorn are not technologies that I > work with. > > It sounds as if hyperkitty is compiling the entire archive before > sending the first byte. > > The gunicorn doc that you pointed to says > > Workers silent for more than this many seconds are killed and restarted. > Setting it to 0 has the effect of infinite timeouts by disabling > timeouts for all workers entirely. > > "Silent" sounds like the standard webserver "you have to push some bits, > or we assume you're stuck". > > My understanding is that gunicorn is a Python persistence server that is > run behind a webserver proxy. So the (proxy) webserver (apache, nginx, > ...) timeouts also apply and would need to be increased. > > Might be interesting to try 0 (gunicorn) / 1200 (webserver) with your > python-dev archive, time it and see how much (encoded) data is > transferred... (I would expect most mailing list archives to compress > nicely, though those with binary attachments wont.) For uwsgi, I think the parameter is called `harakiri`[1][2] (I don’t know why such a name though). [1]: https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri [2]: https://uwsgi-docs.readthedocs.io/en/latest/Glossary.html > if request takes longer than specified harakiri time (in seconds), the request will be dropped and the corresponding worker recycled. This should be set to a long enough value that allows downloading the archive. If you are using http socket, then you want http-timeout. Also, to set the timeout in webserver (nginx) location / { uwsgi_read_timeout 120s; uwsgi_send_timeout 120s; uwsgi_pass 0.0.0.0:8000; include uwsgi_params; } Or some other value that you want. > But fiddling with timeouts is treating the symptom, not the root cause. > The right solution is to stream, segment (or chunk) the output, because > in the general case, no timeout is long enough. It'll always be > possible to find an archive that's just one byte (or second) longer than > any chosen timeout. (See the halting problem.) You want > the timeout > to catch a lack of progress, not total time that's a function of > transaction size. (Webservers may also have limits on transaction size > - e.g. mod_security, but they're only useful when the upper bound on a > response is knowable.) Thus, the timeout(s) should be roughly > independent of the archive size; on the order of time-to-first-byte > (which ordinarily is longer than time between segments/chunks). > > Also note that streaming requires fewer server resources than compiling > a complete archive before sending, since you don't need to create the > entire archive in memory (or in a tempfile). You only need enough > memory to efficiently buffer the file I/O and to contain the compression > tables/output buffer. Except for trivial cases, this will be > independent of the archive size. The only downside is that if the comm > link is slow, you may hold a reader lock on the source data for longer > than necessary with the current scheme. > > Seems as though this deserves an issue. I guess I could open one - but > you have the experience/test cases. Hyperkitty doesn’t actually create an archive in memory or in a temp file. It uses streaming response with on the fly compression to read from database and relay to the client for download. https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/views/mlist.… The problem could be that uwsgi seems to kill an ongoing downloading process, not an idle one for some reason. And, it seems that it is a known and intentional behavior. I don’t see a good way to disable it completely, but perhaps it can be set to a long enough value that it never essentially kills a running worker which is moving bits. -- thanks, Abhilash Raj (maxking)

4 years, 8 months

[MM3-users] Re: Time Stand Still

by Fabian A. Santiago

On November 23, 2017 11:38:00 AM EST, Barry Warsaw <barry(a)list.org> wrote: >Somewhen in the dark recesses of intarweb history, I found myself as >the project leader for both Jython (née JPython) and GNU Mailman. I'd >been involved with Jython since it was invented by Jim Hugunin around >the time he came to work with us at Pythonlabs. I'd been contributing >to Mailman since we inherited John Viega's Python-based Dave Matthews >Band list server, and put it to use replacing python.org's Majordomo >installation. > >I'd enjoyed both projects, but knew I could not lead both, so I had to >make a choice. I chose to turn over Jython to a team that's done a >much better job over the years than I ever could have. Something about >email, and especially the communication and collaboration patterns that >it facilitates, really fascinated me. I know, I know, but we all have >our lapses of sanity. Mine has lasted almost 20 years, a bit more than >"momentary" perhaps. > >I've rarely gotten paid to work on Mailman, but it did provide me some >great opportunities. Most notably it led to my 10 year stint at >Canonical. I was originally hired on there to integrate mailing lists >with Launchpad, and Mailman was the obvious choice. I learned a ton >doing that project, and working within the constraints of integrating >the two Python-based systems, especially since Launchpad was originally >not free software and Mailman was GPL'd. Later, the Zope-based >Launchpad source code was released under the AGPL, making much of the >monkeypatching unnecessary, but by then the system was solid and >reliable, and you don't fix what's not broken. > >Except, I guess I did. I took a lot of the lessons from that work, >along with a good hard look at all the problems with Mailman 2, and >began to break another cardinal rule of software development: second >system syndrome. The result is Mailman 3. It took forever, and we're >still not at complete feature parity with Mailman 2, but at least it's >Real Enough to be used at many Real Sites, including python.org and >lists.fedoraprojects.org. > >It would be ridiculous for me to take significant credit for this. I >have to acknowledge the amazing user community -- you! -- for all the >support, patches, suggestions, feedback, patience, criticism, >donations, and contributions that you've given to the project, and to >me personally over the years. And my deepest gratitude goes to all the >core developers that have stayed or come and gone, but most especially >the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark >Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and >every one of them is truly awesome, both in what they contribute >technically, and in their amazing friendships. Mailman is infinitely >better because of their involvement, and I've loved spending time with >them over the years at the Pycon sprints, making releases and sharing >teas and meals. > >My blog is called We Fear Change, and that's humorously taken from a >90's bit in Mike Myer's excellent Wayne's World movie (a phrase >actually uttered by the brilliant Dana Carvey as Garth). The irony of >course is that while we all may fear change, it's the one constant >thing we can count on. And in fact, we *require* change to thrive, >because if you aren't changing, you aren't alive. Time, and being >engaged with life's vagaries, means there's no alternative to change; >it must be embraced. > >And so, with a vague reference to the many (good!) changes in my >personal and professional life, I'm announcing that I'm stepping down >from the project leadership role of GNU Mailman, effective... nowish! >And it's with unanimous agreement among the GNU Mailman Steering >Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash >Raj as the new project leader. > >If you don't recognize Abhilash's name, you probably aren't paying >attention, at least to Mailman 3. Abhilash came to us in 2013 as a >Google Summer of Code student, and he's become one of the project's >most valuable contributors. His list of accomplishments is long, and >it includes everything from redesigning the website, to integrating CI >with our GitLab build system, porting our code to the SQLAlchemy ORM, >adding MySQL support, revving up adoption through his Docker images, >along with his great coding work on Core, Postorius, HyperKitty, and >mailmanclient. > >This transition is good for the project too. Email, its defining >protocols and standards, and its role in our daily lives, has changed >profoundly since the early days of Mailman. A fresh perspective and >enthusiasm will help keep Mailman relevant to the changing ways we -- >especially the FLOSS and tech communities -- communicate. > >Please join me in supporting Abhilash in every way possible as he takes >over in this new role as project leader. I'll be here when and if >needed, even as I create space in my "spare" time for... Something >Else. I look forward to the vision that Abhilash will bring to the >project, and I know that he will do a great job. To me, Mailman has >always been about collaboration, and the best >way for it to succeed is for you to continue to contribute your >insights, experiences, opinions, and skills with positive intention. > >-Barry > >https://www.wefearchange.org/ Congrats Abhilash! Love the docker images! Thank you Barry! Mailman rocks! -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

8 years, 1 month

[MM3-users] Re: Fwd: Re: Removing a mail addresses and users

by Allan Hansen

All, Thank you for your thoughtful responses to my call for a removal of the core vs. Django disconnect. From your responses it appears that my suggestion my issues were caused by the Mailman Core was not based in reality. Instead, the issue is how Postorius interacts with the Core. My apologies for overreaching, as the cause of my issues is not an issue to me. Keeping Core a simple list manager is fine, if Postorius is easy to use and does the expected. As a Subscriber, you are able to do switch emails in subscriptions from your options page. The URL to which is displayed in the List's Summary page when you are logged in. Yes, it requires an approval if the list's settings are set to moderate but that is going to be fixed, see this issue[1]. It is quite simple IMO to fix this one, if someone wants to take this up. Well, it’s more than that. Based on the current setup, I have asked my subscribers who want to change their subscription addresses to: a. Create an account if you do not already have one. b. Go to the user profile page. c. Select ‘E-mail Addresses’. d. Add the new e-mail to the user profile. e. Wait for the verification notice and verify the new address. e1. If it does not show send email to hansen(a)rc.org <mailto:hansen@rc.org> to get the email verified manually. f. Sign in to the account again and to the user profile (or refresh the page if not signed out). g. Select the new address as the primary address. h. Click on ‘Manage Lists’ i. For each list you are subscribed to: i1. Select the list i2. Click ‘List Options Page.’ i3. Pull down the ’Select Email’ menu. i4 Select your new email. i5. Press ‘Change email used for subscription. i6. When the moderator contacts you, explain that you are just changing your email. i6.1. If the moderator is late, send a reminder or send email to hansen(a)rc.org <mailto:hansen@rc.org> to bypass the moderator. Most people choke on these instructions, so I have unfortunately resorted to just asking them to subscribe the new address and forget about the old. This is not good for our reputation when the old addresses start bouncing. So, in more detail: I would like to ask my subscribers who want to change their address to: a. Create an account if you did not already have one. b. Go to the user profile page. c. Select ‘E-mail Addresses’. d. Select an existing address e-mail listed the user profile. e. Press new button ‘Change address’. f. When page refreshes, enter the new e-mail address. g. Press ‘Apply.' d. Wait for the verification notice. d1. If it does not show send email to hansen(a)rc.org <mailto:hansen@rc.org> to get the email verified manually. In other words, in addition to ‘Make Primary’ and ‘Re-send Verification’ and ‘Remove’, another button says: ‘Change Address’ or’ ‘Replace Address’ or some such. This button brings up another page that looks the same, but instead of ‘Add E-mail Adress’ is says : Enter New E-mail Address’ and instead of ‘Add E-mail’ is says: ‘Apply’. Then the page refreshes back to the original page, but the new address is now replacing the old address. Optionally, it can show the old address still with a ‘pending change’ until verification. Further, when the new address is verified, all lists get updated with the new address replacing the old address and all settings associated with the old address are now associated with the new address. No moderator or admin involvement needed (other than d1). You are able to sign in via web and manage your email and subscriptions. The preferences also work exactly how you described above where the lower level override the default and/or upper level settings. To some extent that is true, Abhilash, and I appreciate that. The above (address change) is a missing piece in that picture and I look forward to seeing it added, if you have time. Yours, Allan Hansen hansen(a)rc.org > On Jun 14, 2020, at 0:19 , Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Mark Sapiro writes: > >> Then the people who developed the web based management UI (Postorius) >> and archive UI (HyperKitty) chose to develop those within a Django >> framework and Django has its own concept of User separate from Mailman >> Core and that is where the disconnect occurs. >> >> It's not that Mailman Core lacks what you want. It's that Django doesn't >> use it. > > I think that's mostly right, in terms of the features that users miss. > However, as far as I know, Mailman core does lack facilities for > identification, authentication, and authorization of connections to > the REST API. And that means that the front ends have to handle > this. I would guess that's why the web interfaces are built around > Django user authentication. > > I think it would be possible to have somewhat tighter integration > between the Django "web users" and the Mailman core User objects, but > it's not necessarily going to be trivial. > > I see that Abhilash is pretty optimistic, but I fear this this is > going to be a long-tail situation where we're going to be seeing core > user vs. web-gui user integration issues in 2030 (maybe by then only 1 > every 450 days ;-). I have some ideas, maybe in a couple weeks I can > sketch them out. > > Steve > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

5 years, 7 months

[MM3-users] Re: hello， Discussion on how to subscribe to the mailing list

by 朱超

At 2023-01-17 15:56:35, "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote: >Mark Sapiro writes: > > > On 1/16/23 18:55, 朱超 wrote: > > > Hi, When I subscribe the email list in Subscription Policy is > > > confirm, Some problems happen in here： > > > 1.Some mail mua reject send the confirm the message, because the > > > length of recipient is too long. for exmaple: > > > requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain, > > > and the mail mua reject to modify about this. > > > > The default English template says in part: > > > > Before you can start using GNU Mailman at this site, you must first > > confirm that this is your email address. You can do this by replying to > > this message. > > > > Or you should include the following line -- and only the following > > line -- in a message to $request_email: > > > > confirm $token > > > > I.e. It gives an alternative method if `reply` doesn't work. You can > > provide a custom version of this template with different wording if you > > think you can improve it. > >The problem is the reply address, though. Changing the template to >suggest only the "confirm $token" in body method doesn't help people >who hit R expecting that should work, especially since many "user >fiendly" (misspelling intentional) MUAs don't display the address. >Avoiding that requires code changes, I guess? Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation. > > > > 2.It is inconvenient for users to use. Many people will > > > mistakenly think that after clicking the subscribe button, it > > > will be successful, and they will not process the email. > > > step, you can set Subscription Policy to Open, but then anyone can > > maliciously subscribe third parties to the list. > >*Please* do not do this if your server is exposed to the Internet. >There are bots that search for such servers, and sell lists of them to >people who want to DOS mailboxes. You may find yourself banned across >the Internet. > Yes.For service security, we will not set the Subscription Policy to open >The only real alternative to confirmation is approval by moderators. >I believe Mailman 3 offers that alternative as Mailman 2 did, can't >check at the moment. > > > > Regarding the discussion on the subscription method of the > > > mailing list, should we consider optimizing the subscription > > > method of the mailing list, for example: > > > 1. use the method of sending a verification code to subscribe by > > > email，When you receive the verification code sent by the > > > mailing list and fill it in again, you can subscribe > > > successfully。 > > > > How is this different from the present method. > >Just wording. I think they are thinking of the "invite" option that >was provided in Mailman 2 mass subscribe (again, I think Mailman 3 >retains it but I never ever used it so I don't recall for sure). But >it doesn't make sense for a user-initiated interaction. > > > If you want, you can make > > a custom template and include something like: > > > > Alternatively, you can confirm by going to the URL > > > > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token > >If I understand the OP's PoV correctly, I think I would change the >list information page to say "Send a personal invitation to join the >list to [email address here]. If you aren't a subscriber, you can >invite yourself." And change the word "confirm" in the confirmation >template to "subscribe". Why do you need to modify the mailman-core service， I suggest we should modify the code of the postorius, We can refer to postorius to reset the user password process， Detail, through the postorius to send email to user, and user click the url in email to confirm subscribe the email，Currently I have achieved it this way。 > > We don't include that in the default template because Mailman core > > doesn't know if you even have a web UI or how to access it if you > > do. > >We should fix that, at least if the web interface is Postorius >(wishlist, assigned to me): >https://gitlab.com/mailman/mailman/-/issues/1055 > >@mark >https://gitlab.com/mailman/mailman/-/issues/901 >Maybe we can close this? I'm not sure why it was left open since >there's no action proposed for Mailman improvement. > > > > 2. use the email to send a connection to confirm the > > > subscription，People click the link to be redirected to a > > > confirmation page to subscribe to the email。 > > > > See above. > >Indeed, AFAICS almost everything the OP is suggesting amounts to an >identical procedure as far as the Mailman server is concerned, it's >just described to the subscriber differently. The one exception is >the suggestion to eliminate the confirmation step, and while that is >supported, it's quite likely to cause problems for third parties and >eventually for the Mailman site unless you have an alternative ground >source of truth such as an employee database. > >Steve >_______________________________________________ >Mailman-users mailing list -- mailman-users(a)mailman3.org >To unsubscribe send an email to mailman-users-leave(a)mailman3.org >https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > >This message sent to tom_toworld(a)163.com

3 years

[MM3-users] Re: integrating mm3 with postfix / lmtp

by Fabian A. Santiago

On October 26, 2017 9:39:06 PM EDT, Mark Sapiro <mark(a)msapiro.net> wrote: >On 10/26/2017 06:16 PM, Fabian A. Santiago wrote: > >> >> But in my testing, I replied to a subscription confirmation message >and received back an undeliverable looping email error message from >postfix. Any clues there you can offer? I can post to the list from any >email added via the admin console. The test subscriber address was >local to my server. From an outside address, same error. > > >This usually means that postfic is trying to deliver to an address and >the message already has a Delivered-To: header with that address. > >What are the headers of the "looping" message in the report? What are >the Postfix log messages related to that message? > > >> Once I registered the new email domain, I reverted my postfix config >back to the default suggested by maxking's docker instructions. >> >> https://github.com/maxking/docker-mailman > > >I have essentially no knowledge of the docker container images, so I >can't be much help with issues specific to them. Return-Path: <MAILER-DAEMON> Delivered-To: turtl(a)deviltracks.net Received: by mail.garden-life.org (Postfix) id 39F6C2055; Thu, 26 Oct 2017 21:02:17 -0400 (EDT) Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT) From: MAILER-DAEMON(a)mail.garden-life.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: turtl(a)deviltracks.net Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="2D7231948.1509066137/mail.garden-life.org" Content-Transfer-Encoding: 7bit Message-Id: <20171027010217.39F6C2055(a)mail.garden-life.org> This is a MIME-encapsulated message. --2D7231948.1509066137/mail.garden-life.org Content-Description: Notification Content-Type: text/plain; charset=us-ascii This is the mail system at host mail.garden-life.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>: mail for gjb-online.com loops back to myself --2D7231948.1509066137/mail.garden-life.org Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; mail.garden-life.org X-Postfix-Queue-ID: 2D7231948 X-Postfix-Sender: rfc822; turtl(a)deviltracks.net Arrival-Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT) Final-Recipient: rfc822; test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com Original-Recipient: rfc822;test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail for gjb-online.com loops back to myself --2D7231948.1509066137/mail.garden-life.org Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Return-Path: <turtl(a)deviltracks.net> Received: from mail.garden-life.org (localhost [127.0.0.1]) by mail.garden-life.org (Postfix) with ESMTP id 2D7231948 for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>; Thu, 26 Oct 2017 21:02:17 -0400 (EDT) Authentication-Results: mail.garden-life.org (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=garden-life.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garden-life.org; h=references:in-reply-to:to:subject:subject:message-id:from :from:x-mailer:content-transfer-encoding:content-type :content-type:date:date:mime-version; s=dkim; t=1509066135; x= 1509930136; bh=k85upIKMt3yA1zcaSrQxE349DcmKTq86MMRdi7hh2yw=; b=X 2phB5a1/LGy0J5YIHZTnbXOeoJ55wkcBrFax3cTvvXAAbfZEBsV3BLZ9Z25GdncT CK7b3FU8He/70UAKZtcjreE1AP/hB89yX63xNSqFu2iULKIYMOhWaE/eWl897VhN NIR1mONlrQxOUf5+o16As9WPdbAiEO/TKNMUpuyk+A= X-Virus-Scanned: amavisd-new at mail.garden-life.org X-Spam-Flag: NO X-Spam-Score: 6.117 X-Spam-Level: ****** X-Spam-Status: No, score=6.117 tagged_above=2 required=6.2 tests=[RCVD_IN_PBL=3.558, RCVD_IN_RP_RNBL=1.284, RCVD_IN_SORBS_DUL=0.001, RDNS_NONE=1.274] autolearn=no autolearn_force=no Received: from mail.garden-life.org ([127.0.0.1]) by mail.garden-life.org (mail.garden-life.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3zCxRxppUkZt for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>; Thu, 26 Oct 2017 21:02:15 -0400 (EDT) Received: from rainmail.deviltracks.net (keys.fspproductions.biz [IPv6:2600:3c03::f03c:91ff:fe24:1eeb]) by mail.garden-life.org (Postfix) with ESMTPSA id 1116A2F1 for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>; Thu, 26 Oct 2017 21:02:15 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 27 Oct 2017 01:02:14 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.11.3 From: turtl(a)deviltracks.net Message-ID: <4e5829300419cfb7bf13d5a0d9ebebd1(a)deviltracks.net> Subject: Re: confirm b7322edad83ae7ec99cfc5100161c7062d2c7685 To: test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com In-Reply-To: <150906420646.31.12186705534373041145@mailman-core> References: <150906420646.31.12186705534373041145@mailman-core> X-Originating-IP: 108.53.239.102 October 26, 2017 8:30 PM, test123-confirm+b7322edad83ae7ec99cfc5100161c70= 62d2c7685@gjb-online.com=0Awrote:=0A=0A> Email Address Registration Confi= rmation=0A> =0A> Hello, this is the GNU Mailman server at gjb-online.com.= =0A> =0A> We have received a registration request for the email address= =0A> =0A> turtl(a)deviltracks.net=0A> =0A> Before you can start using GNU M= ailman at this site, you must first confirm=0A> that this is your email a= ddress. You can do this by replying to this message,=0A> keeping the Subj= ect header intact.=0A> =0A> If you do not wish to register this email add= ress, simply disregard this=0A> message. If you think you are being malic= iously subscribed to the list, or=0A> have any other questions, you may c= ontact=0A> =0A> test123-owner(a)gjb-online.com --2D7231948.1509066137/mail.garden-life.org-- Logs: mail amavis[1576]: (01576-09) Passed CLEAN {RelayedInternal}, ORIGINATING LOCAL [2600:3c03::f03c:91ff:fe24:1eeb]:33512 [2600:3c03::f03c:91ff:fe24:1eeb] <turtl(a)deviltracks.net> -> <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, Queue-ID: 15BD218EE, Message-ID: <09b6ea7c3203e7357e4e996c352223d0(a)deviltracks.net>, mail_id: UgTlYoHupO-Z, Hits: 6.117, size: 1663, queued_as: 928292055, dkim_new=dkim:garden-life.org, 451 ms, Tests: [RCVD_IN_PBL=3.558,RCVD_IN_RP_RNBL=1.284,RCVD_IN_SORBS_DUL=0.001,RDNS_NONE=1.274] Oct 26 21:47:44 mail postfix/smtp-amavis/smtp[19971]: 15BD218EE: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.64, delays=0.18/0/0/0.46, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 928292055) Oct 26 21:47:44 mail postfix/qmgr[1240]: 15BD218EE: removed Oct 26 21:47:44 mail postfix/smtp[20025]: 928292055: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, relay=none, delay=0.04, delays=0.01/0.02/0/0, dsn=5.4.6, status=bounced (mail for gjb-online.com loops back to myself) Oct 26 21:47:44 mail postfix/cleanup[19953]: 9E63E18EE: message-id=<20171027014744.9E63E18EE(a)mail.garden-life.org> Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: from=<>, size=5273, nrcpt=1 (queue active) Oct 26 21:47:44 mail postfix/bounce[20027]: 928292055: sender non-delivery notification: 9E63E18EE Oct 26 21:47:44 mail postfix/qmgr[1240]: 928292055: removed Oct 26 21:47:44 mail postfix/pipe[19986]: 9E63E18EE: to=<turtl(a)deviltracks.net>, relay=dovecot, delay=0.03, delays=0/0/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service) Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: removed [root@mail ~]# -- Thanks, Fabian S. OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC

8 years, 2 months

Search results for query "sapiro"