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

[MM3-users] Re: moderation notices for list-owner being redirected to mailman address

by Mark Sapiro

On 2/3/22 18:55, Philippe B wrote: > Yes, we understand that those logs are normal. And indeed we have a list called "mailman"... Could that be confusing the software somewhere?? I doubt it. Note that the log excerpt posted at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… only shows the handling of a message sent from snap_wl-bounces+mailman=caltech.edu(a)caltech.edu. The envelope sender is VERPed and indicates that this message was intentionally sent to mailman(a)caltech.edu. I.e., when the `snap_wl` list created this message it intended it to go to mailman(a)caltech.edu. > The thing is that we have a pretty convoluted setup for handling mailing lists messages, but it's always the same for all messages. That's why we don't understand why only a small fraction of all the moderation messages get misdelivered at random times for random lists. > > I think what Dan was getting at is: Are there any other logs that would show us how a message that: > > a) was accepted by Postfix on the Mailman server for local delivery to list-owner(a)lists.caltech.edu; > > b) was therefore piped into the Mailman software; But according to the header excerpt I quote at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… it isn't sent directly from Postfix to Mailman's LMTP runner. It gets there via `ec2-12-34-56-78.us-west-2.compute.amazonaws.com` I think that's where the issue occurs. It appears that isn't even on the Mailman host, the no Mailman logging is going to help. > c) came out of that processing as needing to be now delivered (remotely) to mailman(a)caltech.edu, rather than the actual address of the owner of the original list? > > Or maybe we can turn on more verbose logging or something? > PS: Not to confuse things (because it doesn't apply in my example), but what happens when a list has no owner and a message is sent to list-owner? Mail to list-owner is resent by Mailman to the list owners and moderators. If there are no owners or moderators the message goes to the configured site_owner https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/owner… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

[MM3-users] Re: hyperkitty won't list more than 5 posts and shows empty grey Activity Summary box

by Mark Sapiro

On 08/09/2017 12:56 PM, cyp(a)trojina.si wrote: > Thanks for the quick and helpful reply. (However, please note that until now I was under the impression that there had been no response yet to my question, since my post appears to indicate having 0 comments at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/2017/8/) Yes, I see that. It was apparently an issue with caching. I recently enabled memcached on the server for django and apparently there was an issue with that. I just did what @abompard suggested at <https://gitlab.com/mailman/hyperkitty/issues/131#note_30244378> and that seems to have fixed it, at least for the moment. > Yes, the one-liner did indeed help the "More ..." problem. :) > > As for the bar graph, it's showing a bar now, probably correct. But I have not seen anything about django cronjobs in the MM3 documentation, haven't set any up, can't find any in our (Ubuntu 16.04) system and haven't done anything to fix this in-between (although I have restarted mailman-core and mailman-suite a few times). Could you point me in the right direction? This is what I have in Mailman's crontab on lists.mailman3.org > @hourly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs hourly > @daily /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs daily > @weekly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs weekly > @monthly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs monthly > @yearly /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs yearly > 0,15,30,45 * * * * /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs quarter_hourly > * * * * * /opt/mailman/mailman-bundler/bin/mailman-web-django-admin runjobs minutely > > # Send periodic digests. > # I like 03:30 so they go overnight, but since we're 'global' and on UTC, > # maybe 07:30 is good. > 30 7 * * * /opt/mailman/mailman-bundler/bin/mailman digests --send I don't recall exactly where I saw that that was needed, but you can find it (except for the periodic digests bit) at <http://docs.list.org/en/latest/config-web.html#scheduled-tasks-required>. Note that that suggests a system crontab with the web server user rather than the 'mailman' user's crontab. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 10 months

[MM3-users] Re: Mailman3 not working following distribution upgrade from Debian 10 to 11.

by Mark Sapiro

On 2/18/22 11:28, gordon(a)dickens.com wrote: > Thanks Mark! > > Here is the Traceback from the error: > > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", line 34, in inner > response = get_response(request) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 115, in _get_response > response = self.process_exception_by_middleware(e, request) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line 113, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 71, in view > return self.dispatch(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/generic.py", line 74, in dispatch > return super(MailingListView, self).dispatch(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line 97, in dispatch > return handler(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/views/list.py", line 326, in get > primary_email = set_preferred(request.user, mm_user) > File "/opt/mailman/venv/lib/python3.9/site-packages/postorius/utils.py", line 64, in set_preferred > primary_email = EmailAddress.objects.get_primary(user) > File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/account/managers.py", line 30, in get_primary > return self.get(user=user, primary=True) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/manager.py", line 82, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/db/models/query.py", line 419, in get > raise self.model.MultipleObjectsReturned( > > Exception Type: MultipleObjectsReturned at /mailman3/lists/testing.dickens.com/ > Exception Value: get() returned more than one EmailAddress -- it returned 3!\ Thank you for this info. I've never seen this exact issue. What you have is a Django User with more than one primary email address. It may be you. Go to the Django web admin UI at https://host2.mailhub4u.com/admin/account/emailaddress/?q=gordon where you should see multiple email addresses for user `gordon`, three of which are primary. Go to each address and uncheck primary for all but one of them. If it's not you, see the Mult_primary script at https://gitlab.com/mailman/django-mailman3/-/issues/53#note_842641913 to find who, but this script would need to be modified for other than a postgresql database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

What should I do to tell Postfix to use my domain?? for example send emails using the email account mailing(a)labbrands.com Thank you El mar., 25 jul. 2017 a las 15:10, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/25/2017 12:58 PM, Rafael Mora wrote: > > I got this error starting mailman service: > > > > > > [mailman@localhost ~]$ source env2Traceback (most recent call last): > > File "/usr/local/lib/python3.6/asyncio/base_events.py", line 1043, in > > create_server > > sock.bind(sa) > > OSError: [Errno 99] Cannot assign requested address > ... > > What do you think? > > > I think you have configured > > lmtp_host: mail.example.com > > which is wrong. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

7 years, 10 months

[MM3-users] Re: mail loops back to myself

by Mark Sapiro

On 6/8/25 16:04, Florian Sukup wrote: > > Postfix on its own is working fine. > > I set up mailman, created a site/domain (lists.yyy.com) My hostname is > host.xxx.com . My IP has a RDNS entry: reverse.rrr.com . Why is the RDNS to reverse.rrr.com and not host.xxx.com. It is important for mail delivery to have full circle DNS. I.e. the sending server should have an A record for its IP and revers DNS for that IP should point back to the sending server's name. I'm guessing that rrr.com is a hosting provider and you don't control the rDNS for that IP, but you should try to get them to change it for you. Without that change, delivery of your outbound mail, at least to large ISPs, will be problematic at best. > When I send an email to my mailing list mylist(a)lists.yyy.com I receive > an error email. The logfile says the following: > > ... > Jun 9 00:23:38 arvak postfix/smtpd[]: connect from host.xxx.com[m.y.i.p] > Jun 9 00:23:38 arvak postfix/relay/smtp[]: warning: host > reverse.rrr.com[178.251.71.190]:25 greeted me with my own hostname > host.xxx.com > Jun 9 00:23:38 arvak postfix/relay/smtp[]: warning: host > reverse.rrr.com[m.y.i.p]:25 replied to HELO/EHLO with my own hostname > host.xxx.com See above. > Jun 9 00:23:38 arvak postfix/relay/smtp[]: 094895FADB: > to=<mylist(a)lists.yyy.com>, relay=reverse.rrr.com[m.y.i.p]:25, > delay=0.06, delays=0.03/0.01/0.02/0, dsn=5.4.6, status=bounced (mail for > lists.yyy.com loops back to myself) What is the output from `postconf -n`? > Jun 9 00:23:38 arvak postfix/smtpd[114119]: disconnect from > host.xxx.com[m.y.i.p] ehlo=1 quit=1 commands=2 > ... > > The MX record of lists.yyy.com points to reverse.rrr.com. Not sure if > this is the best idea? reverse.rrr.com has no A or AAAA record. An MX MUST point to a domain that has an A or AAAA record. The MX should point to host.xxx.com. > Can anyone give me a hint where to search for this error? The output from `postconf -n` would help. Also, have you set up postfix per https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… ? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 week, 2 days

[MM3-users] Re: archives html user interface menu selection retention after refresh

by Mark Sapiro

On 6/28/23 10:38 PM, Ken Alker wrote: > I have just started studying the archives feature and I've noticed that > if I select "Most Active" in the top menu and then I refresh my browser, > the refreshed screen jumps back to Recent after the refresh. In fact, > if ANY of the five menu items across the top are selected and then a > browser refresh is performed, the result is that one is always taken > back to the Recent menu item. It was not apparent to me for a couple of > days that this was happening and I'd convinced myself there was some bug > in the Recent vs. Most Active lists because the Most Active list changed > entirely after I did a refresh, when, in fact, I was then viewing the > Recent list again. Confusing. This is the expected behavior. the various Recent, Most Active, ... tabs use # fragments to switch the view, but these don't change the URL that the browser went to (the one in the browser's address bar) so a refresh goes to that original URL which defaults to the `Recent` view. > Is there some way that whatever menu item was being viewed before a > refresh could be retained so that the same menu item is shown after a > refresh? Probably not without significant redesign of the web UI. > Thinking this through even further, I suppose a side-affect of this > request could be that visiting the same page much later (ie. not > immediately after a refresh) may result in the page NOT defaulting to > the Recent menu item any longer (unless once could clear the "last menu > item" memory when the viewer moves AWAY from or closes the page). I > don't have enough familiarly with the interface to suggest if this would > be a bad side-effect, or good, but would this, indeed become a > side-affect that would have to be thought through? It would depend on how the feature was designed, but this is probably moot as such a feature is unlikely to be implemented as it seems the potential benefit doesn't warrant the additional complexity. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: LookupError: unknown encoding: _iso-2022-jp$esc

by Mark Sapiro

On 09/07/2018 08:30 AM, Thor Atle Rustad wrote: > This happens when I open a page of Held Messages containing an offending > message. I get Server Error (500) in Postorius. Here is the mailman.log: > > > Sep 07 15:25:39 2018 (32) REST request handler error: > Traceback (most recent call last): > File "/usr/local/lib/python3.6/wsgiref/handlers.py", line 137, in run > self.result = application(self.environ, self.start_response) > File > "/usr/local/lib/python3.6/site-packages/mailman/database/transaction.py", > line 50, in wrapper > rtn = function(*args, **kws) > File "/usr/local/lib/python3.6/site-packages/mailman/rest/wsgiapp.py", > line 214, in __call__ > return super().__call__(environ, start_response) > File "/usr/local/lib/python3.6/site-packages/falcon/api.py", line 244, in > __call__ > responder(req, resp, **params) > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 160, in on_get > resource = self._make_collection(request) > File "/usr/local/lib/python3.6/site-packages/mailman/rest/helpers.py", > line 159, in _make_collection > for resource in collection] > File "/usr/local/lib/python3.6/site-packages/mailman/rest/helpers.py", > line 159, in <listcomp> > for resource in collection] > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 150, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 77, in _make_resource > resource['msg'] = msg.as_string() > File "/usr/local/lib/python3.6/site-packages/mailman/email/message.py", > line 54, in as_string > value = email.message.Message.as_string(self) > File "/usr/local/lib/python3.6/email/message.py", line 158, in as_string > g.flatten(self, unixfrom=unixfrom) > File "/usr/local/lib/python3.6/email/generator.py", line 116, in flatten > self._write(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 181, in _write > self._dispatch(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 214, in _dispatch > meth(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 243, in > _handle_text > msg.set_payload(payload, charset) > File "/usr/local/lib/python3.6/email/message.py", line 315, in set_payload > payload = payload.encode(charset.output_charset) > LookupError: unknown encoding: _iso-2022-jp$esc I think this should be fixed in Mailman core 3.2.0. It is related to Mailman core issues 256, 437 and 470 and merge requests 197, 322, 350 and 375. In particular, it looks like you are missing at least <https://gitlab.com/mailman/mailman/merge_requests/375>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 9 months

[MM3-users] Re: Mailman Core 3.3.2 is now out

by Mark Sapiro

On 11/22/20 1:10 AM, Torge Riedel wrote: > > today I did this on my setup and got the following exception after > "systemctl restart mailman": > > # systemctl status mailman.service > mailman.service - GNU Mailing List Manager > Loaded: loaded (/opt/mailman/core/mailman.service; enabled; vendor > preset: enabled) > Active: failed (Result: exit-code) since Sun 2020-11-22 09:59:53 CET; > 46s ago > Process: 30520 ExecStop=/opt/mailman/core/bin/mailman.sh stop > (code=killed, signal=TERM) > Process: 30597 ExecStart=/opt/mailman/core/bin/mailman.sh start > (code=exited, status=1/FAILURE) > Main PID: 1223 (code=exited, status=0/SUCCESS) > > Nov 22 09:59:53 basis2 mailman.sh[30597]: File > "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/protocol.py", line > 220, in check_error > Nov 22 09:59:53 basis2 mailman.sh[30597]: > err.raise_mysql_exception(self._data) > Nov 22 09:59:53 basis2 mailman.sh[30597]: File > "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/err.py", > line 109, in raise_mysql_exception > Nov 22 09:59:53 basis2 mailman.sh[30597]: raise errorclass(errno, > errval) > Nov 22 09:59:53 basis2 mailman.sh[30597]: sqlalchemy.exc.InternalError: > (pymysql.err.InternalError) (1060, "Duplicate column name > 'archive_rendering_mode'") > Nov 22 09:59:53 basis2 mailman.sh[30597]: [SQL: ALTER TABLE mailinglist > ADD COLUMN archive_rendering_mode INTEGER] > Nov 22 09:59:53 basis2 mailman.sh[30597]: (Background on this error at: > http://sqlalche.me/e/2j85) > Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Control process > exited, code=exited status=1 > Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Failed with result > 'exit-code'. > Nov 22 09:59:53 basis2 systemd[1]: Failed to start GNU Mailing List > Manager. > > I checked the database and - yes - there is already such a column in the > DB. So I tried it the "hacker" way and just removed the column from the > DB and give "systemctl restart mailman" a second try. Now it worked and > the column is back. > > I don't know if this column was already there from 3.3.1. That column was added in 3.3.2 by <https://gitlab.com/mailman/mailman/-/merge_requests/644> It is the migration to add that column that failed in the above. It appears that somehow that migration was previously run and added the column, but the version_num entry in the alembic_version table was not updated to indicate that that migration had been run. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Hyperkitty 1.1.1 to HyperKitty 1.2.1

by Mark Sapiro

On 09/30/2018 11:42 PM, Thomas G wrote: > Hi, > > I would like to migrate my current Mailman3.1/Hyperkitty data to a fresh > install in Mailman3.2. > > I didn't found how migrate the archives. >>From : HyperKitty - Version: 1.1.1 - Python2.7 > To : HyperKitty - Version: 1.2.1 - Python3.5 As Abhilash said, you shouldn't need to migrate anything but the search index. > I exported a mbox from hyperkitty (web interface) and tried to re-import > it, without result. > """""""""""""""""""""""""""""""""""""""" > xxxx @xxxxxx :/opt/mailman# python3.5 manage.py hyperkitty_import -l > listedetests(a)hatlab.fr /home/admin/listedetests(a)hatlab.fr.mbox.gz > > Importing from mbox file /home/admin/listedetests(a)hatlab.fr.mbox.gz to > listedetests(a)hatlab.fr You can't import a gzipped mbox. You have to gunzip it. > Computing thread structure > Synchronizing properties with Mailman > Warming up cache > The full-text search index is not updated for this list. It will not be > updated by the 'minutely' incremental update job. To update the index > for this list, run the 'manage.py update_index_one_list > listedetests(a)hatlab.fr' command. > """""""""""""""""""""""""""""""""""""" > The database stay empty (and web interface): > """""""""""""""""""""""""""""""""""""" > mailmandbnameprod=# select * from hyperkitty_email; > id | message_id | message_id_hash | subject | content | date | timezone > | in_reply_to | archived_date | thread_depth | thread_order | > mailinglist_id | parent_id | sender_id | thread_id | sender_name > ----+------------+-----------------+---------+---------+------+----------+-------------+---------------+--------------+--------------+----------------+-----------+-----------+-----------+------------- > (0 rows) > """""""""""""""""""""""""""""""""""""" > > Any idea to do this importation ? Why is the database empty? It should be as it was with the prior HyperKitty. Also, it doesn't seem to be the issue here, but if you don't specify a --since option to hyperkitty_import, it won't import any messages older than the most recent message in the existing archive. i.e., if there are any messages in the existing archive, the default for --since is the date of the most recent such message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 8 months

[MM3-users] Re: Moderate mails from owner

by Mark Sapiro

On 4/30/19 1:04 AM, Henrik Rasmussen wrote: > @Mark: I am really sorry for the delayed responses, but this is a very low frequency list. I have subscribed to the list using a non-Microsoft address to see the outcome. > > The mails does indeed contain 'X-Mailman' headers. > > X-Mailman-Rule-Hits:nonmember-moderation > X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation It looks like the message hit the nonmember-moderation rule and was accepted. This can happen in a few ways: First we determine the senders. Assuming the config is default, these are the addresses in From:, the envelope sender, and addresses in Reply-To: and Sender: if any. The only address I can see in the message headers that hasn't been altered by Mailman is the From: and maybe Reply-To: which you have munged to [LISTNAME](a)senderdep.example.com. Anyway that unmunged address and possibly others from the original incoming message will be users of the list with role nonmember. Now each of those (possibly only the one) nonmember(s) is checked for a moderation action. Since the message does not appear to have been held or processed through rules beyond nonmember-moderation, we presumably found a moderation action of accept. This can happen in a few ways., If this list was originally imported from Mailman 2.1 by the 'mailman import21' command, there may be a legacy accept_these_nonmembers attribute for the list. If so, and if a nonmember sender address matches an address or pattern in the list's accept_these_nonmembers, the message will be accepted. Otherwise if the moderation_action for a nonmember sender address is accept the message will be accepted. You need to check the list's accept_these_nonmembers attribute and the non-member address's moderation action. If you have recent Postorius, you can see nonmembers and their options from the 'users' -> Non-members view. In any case, you can do something like mailman shell -l list.example.com Welcome to the GNU Mailman shell The variable 'm' is the list.example.com mailing list >>> m.accept_these_nonmembers returns a possibly empty list Then for the sender addresses >>> memb = m.nonmembers.get_member('sender address') >>> memb.moderation_action This may return <Action.accept: 3> in which case you may want >>> memb.moderation_action = m.default_nonmember_action -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

Search results for query "sapiro"