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

[MM3-users] Re: Phantom Email Address in Nonmember List

by Mark Sapiro

On 1/31/26 13:11, Steve Brown via Mailman-users wrote: > I'm still a bit confused why this address: bounce+66273f.99dcd9c-radg=lists.radg.us(a)stevebrown.us still shows up in the list of nonmembers on the list I administer. When Mailman receives a post it creates an address record for all of the sender addresses in that message if one doesn't already exist. Sender addresses are all those found in places defined by the `sender_headers` setting in the `[mailman]` section of mailman.cfg. By default these are the From: header, the envelope sender, the Reply-To: header and the Sender: header. The address bounce+66273f.99dcd9c-radg=lists.radg.us(a)stevebrown.us was created by Mailman for a VERPed message to 66273f.99dcd9c-radg(a)lists.radg.us The stevebrown.us is my personal domain and steve@stevebrown is the address I use to be a member of the list. I use administrator(a)radg.us for the owner of the list. radg.us is a small website that tells potential users how to subscribe and members how to use the list (e.g., how to change their settings or get to the archives). Unfortunately, I wasn't careful and spam/scam bots have scraped the addresses for joining, posting, or contacting the owner that I put on the site. I now have that site behind a Cloudflare firewall, but addresses are already accessible to the bad guys. The lists.radg.us domain is the "own domain" alias for the server that hosts the list run by Mailmanlists.net. What I haven't been able to figure out is what combination of events triggers the nonmember list entry. If I delete it, it comes back > in a few days or weeks. The workaround is to just leave it in the list of nonmembers, which is effective in that no other instances of that address appear, but annoying to me. Any explanation that might help me understand would be appreciated. So, presumably, some spam was sent to a list by 66273f.99dcd9c-radg(a)lists.radg.us and a held message or rejection notice was sent to that address with envelope from bounce+66273f.99dcd9c-radg=lists.radg.us(a)stevebrown.us. Then some process received that message and maybe bounced it back to a list. Try grepping your mail logs for `66273f.99dcd9c-radg` which may help understand what's happening. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 1 week

[MM3-users] Re: MM3 not starting afte an upgrade

by Mark Sapiro

On 7/23/20 4:35 AM, Gelpi Andrea wrote: > Hi, > to day in a Debian system I upgraded some packages. > > After the MM3 doesn't start anymore. ... > MM3 on start up says: > > Jul 23 13:29:39 posta mailman3[2608]: Traceback (most recent call last): > Jul 23 13:29:39 posta mailman3[2608]: File "/usr/bin/mailman", line > 11, in <module> > Jul 23 13:29:39 posta mailman3[2608]: > load_entry_point('mailman==3.2.1', 'console_scripts', 'mailman')() > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ > Jul 23 13:29:39 posta mailman3[2608]: return self.main(*args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 717, in main > Jul 23 13:29:39 posta mailman3[2608]: rv = self.invoke(ctx) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/bin/mailman.py", line 69, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return super().invoke(ctx) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return > _process_result(sub_ctx.command.invoke(sub_ctx)) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return > ctx.invoke(self.callback, **ctx.params) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke > Jul 23 13:29:39 posta mailman3[2608]: return callback(*args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/click/decorators.py", line 17, in new_func > Jul 23 13:29:39 posta mailman3[2608]: return > f(get_current_context(), *args, **kwargs) > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/commands/cli_control.py", line > 81, in start > Jul 23 13:29:39 posta mailman3[2608]: status, lock = master_state() > Jul 23 13:29:39 posta mailman3[2608]: File > "/usr/lib/python3/dist-packages/mailman/bin/master.py", line 104, in > master_state > Jul 23 13:29:39 posta mailman3[2608]: os.kill(pid, 0) > Jul 23 13:29:39 posta mailman3[2608]: PermissionError: [Errno 1] > Operation not permitted I think you have a stale lock issue and the master is trying to determine if the process that set it still exists. Remove Mailman's var/locks/master.lck* -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

[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

4 years, 3 months

[MM3-users] Re: Command Emails not Working

by Mark Sapiro

On 4/22/26 2:56 PM, Brinson, Jason T via Mailman-users wrote: > Mark, > > First, thank you for your patience. > > So, I scoured my logs looking for mentions of -join or -request emails and couldn’t find anything. So I went back and checked the source for one the emails that was in moderation and found this: > > > Received: from esa.hc4021-78.iphmx.com (esa.hc4021-78.iphmx.com [207.54.93.77]) > by cc-postoffice-01.cc.gatech.edu (Postfix) with ESMTPS id AF674400A3C > for <demo-list(a)mailman.cc.gatech.edu>; Wed, 22 Apr 2026 17:27:54 -0400 (EDT) > > Which in the logs looked like this: > ... > [root@cc-postoffice-01 ~]# journalctl -u postfix | grep AF674400A3C > Apr 22 17:27:54 cc-postoffice-01 postfix/smtpd[677096]: AF674400A3C: client=esa.hc4021-78.iphmx.com[207.54.93.77] > Apr 22 17:27:54 cc-postoffice-01 postfix/cleanup[676116]: AF674400A3C: message-id=<BN0PR07MB876638D9CD221355993FF318A02D2(a)BN0PR07MB8766.namprd07.prod.outlook.com> > Apr 22 17:27:54 cc-postoffice-01 postfix/qmgr[523389]: AF674400A3C: from=<shae(a)cc.gatech.edu>, size=14593, nrcpt=1 (queue active) > Apr 22 17:27:54 cc-postoffice-01 postfix/lmtp[677032]: AF674400A3C: to=<demo-list(a)mailman.cc.gatech.edu>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.3, delays=0.28/0/0.01/0.01, dsn=2.0.0, status=sent (250 Ok) > Apr 22 17:27:54 cc-postoffice-01 postfix/qmgr[523389]: AF674400A3C: removed > > But when you dig into the source of the message the actual to field is: > > From: "Brinson, Jason T" <shae(a)cc.gatech.edu> > To: "demo-list-join(a)cc.gatech.edu" <demo-list-join(a)cc.gatech.edu> > Subject: Test > Thread-Topic: Test > Thread-Index: AQHc0p7SggqXD6aw1U2cnq5Fx0tjdg== > Date: Wed, 22 Apr 2026 21:27:52 +0000 > Message-ID: > <BN0PR07MB876638D9CD221355993FF318A02D2(a)BN0PR07MB8766.namprd07.prod.outlook.com> > > The Message-ID matches what is in the log file, and it is obviously not addressed to just demo-list. I am missing something obvious here I feel. The To: (or Cc:) header in the message has nothing to do with it. It's the envelope recipient that determines the destination of the message. According to the log message Apr 22 17:27:54 cc-postoffice-01 postfix/lmtp[677032]: AF674400A3C: to=<demo-list(a)mailman.cc.gatech.edu>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.3, delays=0.28/0/0.01/0.01, dsn=2.0.0, status=sent (250 Ok) the envelope recipient is demo-list(a)mailman.cc.gatech.edu which was probably mapped from demo-list(a)cc.gatech.edu by postfix_vmap. What is the MUA that created this mail? What's in Mailman's smtp.log with timestamps around Apr 22 17:27:54? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 weeks, 3 days

[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

8 years, 9 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

4 years, 2 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

11 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

8 years, 9 months

[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

2 years, 10 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

7 years, 8 months

Search results for query "sapiro"