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

[MM3-users] Re: Migrating mailman3 to latest ubuntu lts

by Mark Sapiro

On 12/18/23 6:24 AM, Helio Loureiro wrote: > Hi, > > Indeed it was the configuration. It was placed into > /etc/mailman3/mailman-web.py. After a I changed to > /etc/mailman3/settings.py a few things advanced a little bit more. > > I had to figure out how to fix mysqlclient installation since there isn't a > mention about it and the simple "pip install mysqclient" was breaking with > pkg-config issues. But it did work at the end. > > Now I can see further messages on mailman3-web than before. > > (venv) mailman@new-server ~ (v3.3.9)> mailman-web migrate > System check identified some issues: > > WARNINGS: > account.EmailAddress: (models.W036) MariaDB does not support unique > constraints with conditions. > HINT: A constraint won't be created. Silence this warning if you don't care > about it. > account.EmailAddress: (models.W043) MariaDB does not support indexes on > expressions. > HINT: An index won't be created. Silence this warning if you don't care > about it. > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, > django_mailman3, django_q, hyperkitty, postorius, sessions, sites, > socialaccount > Running migrations: > Applying account.0004_alter_emailaddress_drop_unique_email...Traceback > (most recent call last): I'm not sure why there would be an issue with this migration, but there is a possible compatibility issue depending on how you installed things. django-mailman3<=1.3.11 is not compatible with django-allauth>=0.58. In your venv, try ``` pip install django-allauth\<0.58 ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

[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

6 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

6 years

[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

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

6 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

4 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

1 year, 6 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

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

2 years, 5 months

[MM3-users] Re: unwanted chunked delivery

by Mark Sapiro

On 1/7/22 11:04 AM, mm3-omf(a)sh.werbittewas.de wrote: > debian-dist mailman3 3.3.3-1. > > every post to this list will be chunked into one delivery with 60 > recipients and one delivery with 21 recipients. > > we've searched a bit and found a config-option "max_recipients" for > bulk-transfers, but we haven't set it and (as we understand the > explaination for this option) then there should be no limit in one > transfer to the MTA. If you haven't set max_recipients, you get the default which is 500. To set it unlimited you set it to 0 > nevertheless, we've tried to set it to a high value, but even this > doesn't change anything in behaviour. Right, because chunking isn't arbitrary. Chunking is done by recipient domain. The addresses are placed in `buckets` by TLD. All `.com` goes in one bucket; `.net` and `.org` in another; `.edu`, `.us` and `.ca` in a third, and all the rest in a fourth. Then the buckets are chunked with the maximum chunk determined by max_recipients. In your case, 60 recipients are in one bucket and 21 in another. The buckets are defined at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/mta/bulk.py#L29 and the work is done at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/mta/bulk.py#L56 My question is why is this important to you? See the FAQ article at https://wiki.list.org/x/4030582 (which is for Mailman 2.1 so it talks about SMTP_MAX_RCPTS which is what max_recipients used to be called) which suggests a much smaller number. -- 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

Search results for query "sapiro"