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

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

by Mark Sapiro

On 8/2/25 01:51, Stephen J. Turnbull wrote: > > IIRC all of the shunted messages that Stephen looked at with qfiles > were those special digest messages (ie, message component empty, > pointer to lists/$LIST/something.mmdf in the msg_data component). So > something is going wrong in the to-digest handler. And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful. > The number of .tmp files lying around bothers me. AFA grep CS, the > only place that can happen is in switchboard.py:136 in .enqueue: > > with open(tmpfile, 'wb') as fp: > fp.write(msgsave) > pickle.dump(data, fp, protocol) > fp.flush() > os.fsync(fp.fileno()) > os.rename(tmpfile, filename) > > where `msgsave` is already a pickled object. So either pickle.dump is > choking on something in data (the metadata, which I believe is all > primitive Python data types), or something (OOM kill?) is happening at > the OS level. A crash in pickle.dump should leave an exception log > and backtrace in the logs. > > AFAIK, Mailman does not clean up .tmp files at startup, right? That is correct. The *.pck.tmp file is created by the above code and immediately after writing is renamed to *.pck. It is done this way to prevent another process picking up a partially written *.pck. If a *.pck.tmp file is somehow left behind, it is never looked at or deleted by any Mailman code. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 3 weeks

[MM3-users] Re: Hyperkitty - Non-ascii sender address

by Mark Sapiro

On 10/28/18 12:03 PM, Guiseppin Thomas wrote: > Hi, > > I imported some mbox archives in Hyperkitty. > > I have lot issues like: > > /\Failed adding message <5b0900ab.1c69fb81.70ab.2f87(a)mx.google.com>: > ('Non-ascii sender address', <email.message.EmailMessage object at > 0x7f05f1606048>)// > //Non-ascii sender address from "Stéphane blipblop <stlablipblop at > gmail.com>" about [HATLAB][It] Re: A débarrasser ! / > > It's probably because "Stéphane". The 'Non-ascii sender address' message comes from > try: > from_str = header_to_unicode(message['From']) > from_name, from_email = parseaddr(from_str) > from_name = from_name.strip() > sender_address = from_email.encode('ascii').decode("ascii").strip() > except (UnicodeDecodeError, UnicodeEncodeError): > raise ValueError("Non-ascii sender address", message) Possibly the exception is thrown in parseaddr(), but much more likely, the email address, not the display name contains non-ascii. > Some advise to fix it ? All the other messages should have been imported. If you can find and fix the 'bad' ones in the mbox, you can make a new mbox with just those and import that. You could also import the entire mbox with fixed messages. The already added ones won't be re-imported because of duplicate Message-ID:, but it's extra processing. If the actual bad message From: header is From: Stéphane blipblop <stlablipblop(a)gmail.com> or From: Stéphane blipblop <stlablipblop at gmail.com> That shouldn't cause the error, so I'g guessing that 'blipblop' is not the actual value and the actual value in <stlablipblop at gmail.com> has non-ascii. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 7 months

[MM3-users] Re: Changing Mailman's "from" domain

by Mark Sapiro

On 5/16/19 8:21 AM, Roger Hislop (IS) wrote: > > If I subscribed an address, no confirmation email would come through. Checked the Postfix log and see this: > > May 16 14:34:50 ip-172-31-23-250 postfix/smtp[5025]: 15B87A35FB: to=<iotic-za(a)reasondigital.co.za>, relay=email-smtp.eu-west-1.amazonaws.com[52.51.155.83]:587, delay=0.22, delays=0.01/0.02/0.1/0.1, dsn=5.0.0, status=bounced (host email-smtp.eu-west-1.amazonaws.com[52.51.155.83] said: 554 Message rejected: Email address is not verified. The following identities failed the check in region EU-WEST-1: test-list-request(a)iotcouncil.org.za, test-list-bounces(a)iotcouncil.org.za (in reply to end of DATA command)) > > I've verified the domain listman.iotcouncil.org.za, so it would seem the obvious solution is to change the domain the mails come from. > > It appeared that I just change the postfix config to specify domain list so: Those addresses are the From: address (test-list-request(a)iotcouncil.org.za) and the envelope sender (test-list-bounces(a)iotcouncil.org.za) These are set by Mailman in the message and the SMTP transaction. Postfix doesn't normally rewrite them. The domain in these addresses is 'web host' defined in Mailman's domain record associated with the list which is also the domain in the list's posting address If you want Postfix to rewrite the envelope sender domain, see <http://www.postfix.org/ADDRESS_REWRITING_README.html#generic> > I see that messages TO the mailman server are also not being delivered ("-- 5.1.1 Requested action not taken: mailbox unavailable"). So there's another problem. See <https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html#postfix> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 1 month

[MM3-users] Re: Upgrade Mailmam Core from

by Mark Sapiro

On 9/24/22 10:57, sascha.rissel(a)gmail.com wrote: > Hello, > > I have newly set up Mailman 3 on Ubuntu 20.04. > Sending and receiving mails between list members does work, but I am currently experiencing two issues: > 1) a lists non-members who send mails to the list don't get notified about the message being held for moderation. Moderation itself doesn't seem to work. The moderation list is always empty. > 2) Archiving is activated within list settings, but there isn't any archive created. > > I found this thread, where the first of these issues is also described: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > Here there is an incompatibility between Mailmain 3 and Python depicted, which also seems to affect me. > I am running Mailman 3.2.2 on Python 3 .8.10. This is only one of the issues with the Debian/Ubuntu packages. > So I need to either upgrade Mailman Core or downgrade Python. > I already did >> apt-get upgrade >> apt-get update > Unfortunately this didn't upgrade Mailman Core's version. > > Which steps do I have to undertake to upgrade Mailman Core? I suggest first removing the Debian/Ubuntu packages and installing the PyPI packages following docs at https://docs.mailman3.org/en/latest/install/virtualenv.html. There are also other takes on this at https://wiki.list.org/x/17891998; https://wiki.list.org/x/17892066 and https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plan… This will require some effort, but you will be freed from dependence on out of date packages. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

[MM3-users] Re: Mailman3 Queues Documentation

by Mark Sapiro

On 2/18/26 12:03, msok--- via Mailman-users wrote: > Hi Everyone, > > I'm looking for a documentation for the explanation about the Queues in Mailman3. > By the way, I'm new, I just got 5 shunt under Queues. The entries in the shunt queue are messages that threw an uncaught exception in processing. The messages and their metadata can be examined with the `mailman qfile` command. For each of these messages there will be entries in mailman.log beginning with one saying Uncaught runner exception: ... followed by a traceback followed by a message saying SHUNTING: file_id where file_id is the name of the file in the shunt queue minus the .pck extension. The exception and traceback will identify the exception and the issue that caused it. If the issue is caused by the message itself and the message is spam, you can just delete the file from the var/queue/shunt/ directory. If the issue is something else like, e.g., a configuration problem or an unreadable template, you can fix the problem and then reprocess the messages with the `mailman unshunt` command. If you need help interpreting the exception and traceback, post the traceback here. Most of the queues (all except bad and shunt) hold messages to be or being processed by the corresponding runner. For an overview of how Mailman works, see <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/archi…> and <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/8-mil…>. For some detail on runners see <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/runners/do…> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months

[MM3-users] Re: digests are created but not sent out

by Mark Sapiro

On 1/9/19 12:20 PM, "Jörg M. Schulz" wrote: > when I use the lines below, the templates are looked for in //var. > When I comment them out, the location is correct: /var/lib/mailman3/ (debian buster standard) . The user list has full access. The folder is empty. //var refers to the directory defined in mailman.cfg (or the default in mailman/config/schema.cfg) as [paths.master] var_dir: Exactly which of the following lines did you add and then comment out? Just the three lines > [language.en] > charset: utf-8 > enabled: yes or something more? > mailman.cfg: > > [mailman] > # This address is the "site owner" address. Certain messages which must be > # delivered to a human, but which can't be delivered to a list owner (e.g. a > # bounce from a list owner), will be sent to this address. It should point to > # a human. > site_owner: help(a)elternserver.de > > # This is the local-part of an email address used in the From field whenever a > # message comes from some entity to which there is no natural reply recipient. > # Mailman will append '@' and the host name of the list involved. This > # address must not bounce and it must not point to a Mailman process. > noreply_address: noreply > > # The default language for this server. > default_language: en > [language.en] > charset: utf-8 > enabled: yes > > [language.de] > description: German > charset: iso-8859-1 > enabled: yes -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 5 months

[MM3-users] Re: Subscription issue with ghost confirmations

by Mark Sapiro

On 10/29/20 5:23 AM, Brian Carpenter wrote: > I have a list owner who had his subscription policy set to confirm. > Apparently that was too hard for his list members to handle so he > changed it to moderate only. If someone sent a subscription request that > needed to be confirm, did not respond to it, and then tried subscribing > again after the member policy changed to moderate, their 2nd > subscription attempt still shows up in the confirmation queue. Is that > normal behavior. My understanding is it is. Please let me know if I am > wrong here. Are you certain that the request waiting confirmation is the second one and not the first? > The real mystery here is when someone tried subscribing again > (listname-subscribe@listdomain) hours after the subscription policy was > changed to moderate and they still showed up in the confirm queue. How > is that possible? I tested the list with two of my addresses and both > showed up in the moderation queue as expected. As far as I can tell from > the mailman logs, this was the person's first attempt at subscribing. I suspect it was not the first attempt and that the subscription waiting confirmation was requested when the policy was confirm. The real question is if a user has a subscription waiting confirmation and the policy is changed to moderate, is a second request rejected because of the request waiting confirmation. If so, I think this is a bug which should be fixed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

[MM3-users] Re: no bounce-processing with verp_probes: yes

by Mark Sapiro

On 12/6/23 06:26, Stefan Bauer wrote: > Dear Users, > > during one of our upgrades to 3.3.x we set verp_probes: yes according to > upgrade notes[1]. > > However it looks like this disabled bounce handling completely. > > Howto verify (MM 3.3.9): > > Set > verp_probes: yes > verp_delivery_interval: 1 > restart mailman3 > create test-list > add an undeliverable recipient to the list that is known to bounce. > send 6 mails to list. Bounce score is only incremented on the first bounce for that day. > see, that all the bounce-messages are received by mailman according to > postfix log[2] So they are delivered. At this point, having set `verp_probes: yes` has no effect on the processing. It only comes in to play when the threshhold is reached. > check bounce.log - no entry. > get bounce_score from API[3] - shows bounce_score 0. This says bounces are not being processed. Is the bounces runner running? If it is there should be entries like Member undeliverable-recipient(a)realdomain.tld on list v-test.lists.lists.tld, bounce score = 1. and Member undeliverable-recipient(a)realdomain.tld already scored a bounce on list v-test.lists.lists.tld today. in bounce.log. and bounce score should be 1. This is independent of `verp_probes: yes`. If the bounce runner is not running, stop and start Mailman core. You must stop and then start, not restart. Also check mailman.log for a reason why bounces runner is not running. If bounces runner is running, check mailman.log for possible errors relating to bounce processing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[MM3-users] Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/25/22 01:14, Odhiambo Washington wrote: > On Sat, Dec 24, 2022 at 9:40 PM Mark Sapiro <mark(a)msapiro.net> wrote: >> >> How about https://mm3-lists.kictanet.or.ke/user_profile/ ? >> > > I have uncommented the line "WSGIScriptAlias /user-profile > /opt/mailman/mm/wsgi.py", > I don't see any definition for it in urls.py as well. Perhaps that's the > issue? It is defined in django_mailman3/urls.py which is referenced by re_path(r'', include('django_mailman3.urls')), > When I uncomment /user-profile, I end up with an ugly URL: > https://mm3-lists.kictanet.or.ke/user-profile/user-profile/ > > So instead of aliasing the /user-profile, I have decided to add another > definition to urls.py: > re_path(r'^user-profile/', include('allauth.urls')), > Which I think gives me a cleaner URL: > https://mm3-lists.kictanet.or.ke/user-profile/login/?next=/user-profile/ It shouldn't include `allauth.urls`. That URL is appropriate if you aren't logged in, but what do you get when you are? Go to https://lists.mailman3.org/user-profile/ and log in if necessary and you'll see what it should look like. > I also had to alias /accounts, which then brings me to: > https://mm3-lists.kictanet.or.ke/accounts/mailman3/lists/ - which I believe > is fine because one gets the > option to either login or signup. > > And I think that "/account" and "/user-profile" are synonymous. They are in your instance because of re_path(r'^user-profile/', include('allauth.urls')), but they should not be. >> It's a mod_wsgi thing. I haven't used mod_wsgi for Mailman for some time >> (I now use gunicorn on all the sites I manage), but when I did I think I >> had > > >> WSGIScriptAlias /mm3 /opt/mailman/mm/wsgi.py >> >> and all the URLs were like https://example.com/mm3/mailman3/..., >> https://example.com/mm3/archives/..., etc. >> > > I already had gunicorn working too, but I just need to also figure out this > mod_wsgi. Why? Intellectual curiosity or do you have an actual need. The bottom line is with mod_wsgi, whatever you have in your WSGIScriptAlias is going to be prepended to the URL path. If you don't want anything prepended, you need ``` WSGIScriptAlias / /opt/mailman/mm/wsgi.py ``` but then in order for user-profile to work, you need to replace ``` re_path(r'', include('django_mailman3.urls')), ``` in urls.py with the urlpatterns from django_mailman3/urls.py ``` re_path(r'^user-profile/delete$', delete_account, name='mm_user_account_delete'), re_path(r'^user-profile/$', user_profile, name='mm_user_profile'), ``` and also add ``` from django_mailman3.views.profile import delete_account, user_profile ``` to the imports in urls.py -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

[MM3-users] Re: changing the main template for subscriptions and more

by Mark Sapiro

On 2/1/22 12:40, Paul Paulchen wrote: > Hi Mark, > > thanks for your advice. Unfortunately we need some more clues. > First of all, we are using mailman docker by maxking - https://github.com/maxking/docker-mailman I do not know what the file layout is in the Docker container, so I can't verify paths. > Our version: > Mailman Core Version - GNU Mailman 3.3.5 (Tom Sawyer) > Mailman Core API Version 3.1 > Mailman Core Python Version 3.8.10 (default, May 6 2021, 06:30:44) [GCC 9.3.0] > > We put an example footer.txt into the templates folder as you mentioned: > mailman3_core => var/templates/sites/de/list:member:regular:footer.txt > Mailman user can read them As I said, I can't give you an absolute path. If you can run `mailman info` in the container, that will show the location of mailman.cfg which may help Installing the template as you have should work if it's the correct path. > Created a new list, restarted the docker-container, but it always showed the default footer.txt and not our example footer.txt from the templates folder. Any guesses or clues? Where is this default footer.txt hiding anyway? Changing languages in postorius works fine and it alters between english, german etc... just won't use our custom footer.txt The default templates are in the mailman/templates/ directory where the mailman/ directory is where all the Mailman core software is. Hopefully someone familiar with Docker and the Mailman Docker container can provide better information. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

Search results for query "sapiro"