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

[MM3-users] Re: Speed up importing mailman2 lists

by Mark Sapiro

On 2/19/25 06:08, t.maintz(a)fz-juelich.de wrote: > We are currently planning to migrate from mailman2 to mailman3 as a container, have around 1500 lists and would like to complete the migration ideally in a few hours. We would like to switch off mailman2 to have a defined state of the lists and import them to mailman3. The import of all lists via script takes about 3 days. Parallelizing the imports does not work due to lockings in the database. > However, we cannot accept a downtime of 3 days. Does anyone have tips on how we can speed up the procedure or are there best practices for larger environments? What Mailman 3 version are you importing to? I ask because prior to Mailman core 3.3.1, user's passwords were imported and the encryption of the password was quite time consuming. If in fact you are importing to Mailman <3.3.1, see https://gitlab.com/mailman/mailman/-/merge_requests/565 for a patch that will speed this up considerably and see https://mail.python.org/archives/list/mailman-developers@python.org/thread/… for discussion of this change. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

[MM3-users] Re: Table 'mailmansuite.django_q_ormq' doesn't exist ("Delete this thread" -> 'HTTP-500 -> NoneType' object has no attribute 'all')

by Mark Sapiro

On 05/29/2017 02:16 PM, Simon Liebold via Mailman-users wrote: > > Now, I get to see the confirmation view and upon confirming I see these > (luckily different) errors like below (same with Django 1.10): > > Could not delete message P2GJLK4JPDU2K6ZKBSDUWASF2TVHCJTT: (1146, "Table > 'mailmansuite.django_q_ormq' doesn't exist") > Could not delete message 4I2TRZTFXMMH2XRQAS73IAEIYROFE5YM: (1146, "Table > 'mailmansuite.django_q_ormq' doesn't exist") > > True, this table doesn't exist in the database. It isn't created by > python manage.py migrate. > > The error is served with HTTP-200. No stack trace in mailmansuite.log. Do you have django_q in INSTALLED_APPLICATIONS in your Django config and do you have # # Asynchronous tasks # Q_CLUSTER = { 'timeout': 300, 'save_limit': 100, 'orm': 'default', } in your Django config and are you running django-admin qcluster at startup? See <https://mail.python.org/pipermail/mailman-developers/2017-May/026064.html>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 11 months

[MM3-users] Re: uncaught bounce messages

by Mark Sapiro

On 10/26/21 8:18 AM, Seth Seeger wrote: > > I have just upgraded to 3.3.4 from 3.3.2 (via docker). > > Do we need to do anything more than reset the delivery status? I am getting (seemingly) continual emails about bounces. I keep running the recipe in the link which resets everyone's delivery status. I've grep'd one member's address out of bounce.log (see below my signature). > > Is it just catching up on old bounces? There is no significant change in bounce processing from 3.3.2 to 3.3.4 If you really upgraded from 3.3.2, I don't know what would be responsible. On the other hand, it looks like you may in fact have upgraded from Mailman < 3.3.1 in which case, those are old, previously unprocessed bounces, and your log certainly looks like that. If you think some or all users shouldn't have had delivery disabled, you can run the mailman shell seccion in the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… to re-enable them and let current bounce processing handle the truly undeliverable ones. -- 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: Broken web UI after upgrade

by Mark Sapiro

On 12/16/22 03:36, Odhiambo Washington wrote: > > I am probably getting closer to where the problem is. By looking at nginx > error_log while access the site, I see that there are > just two CSS files that are missing, as shown in the error lo here: > https://pastebin.ubuntu.com/p/7wbwMgqMyS/ > > Question is - why is it specifically looking for these two files > - /opt/mailman/mm/static/CACHE/css/output.93545e20bc30.css > -/opt/mailman/mm/static/CACHE/css/output.e1f0c6022e8f.css > > Where are these files supposed to come from and why are they missing? > I have looked at my current CACHE directory and compared with the backup of > the same site before upgrade and these files aren't the same either: They come from django admin `compress` which used files created by django admin collectstatic. I suggest you run ``` django-admin collectstatic --clear --noinput --verbosity 2 django-admin compress --verbosity 2 ``` where `django-admin` is your django admin command. If this doesn't fix the issue, perhaps the more verbose output will help find the issue. -- 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: Speed up importing mailman2 lists

by Mark Sapiro

On 2/24/25 05:36, t.maintz(a)fz-juelich.de wrote: > > Can you tell me how to implement this in Postfix? Here's what we do on mail.python.org which supports both Mailman 2.1 and Mailman 3 lists. We also use an alias domain as described at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… because python.org is a virtual_alias_domain. The relevant settings in main.cf are alias_maps = ... hash:/srv/mailman/data/aliases lmtp_destination_recipient_limit = 1 recipient_delimiter = + relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains transport_maps = ... hash:/opt/mailman/mm/var/data/postfix_lmtp virtual_alias_domains = python.org ... virtual_alias_maps = ... hash:/srv/mailman/data/virtual-mailman hash:/opt/mailman/mm/var/data/postfix_vmap The alias_maps and the hash:/srv/mailman/data/virtual-mailman setting in virtual_alias_maps are MM 2.1 settings. The hash:/opt/mailman/mm/var/data/* settings are MM 3. Since transport_maps takes priority over aliases, if there is a MM 3 list in hash:/opt/mailman/mm/var/data/postfix_lmtp, mail for that list will be delivered to MM 3 via LMTP. If not, and the destination is a MM 2.1 list, delivery will be via the virtual_alias_mapping hash:/srv/mailman/data/virtual-mailman -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

[MM3-users] Re: How can I remove anything added by Mailman 3 to the forwarded email

by Mark Sapiro

On 5/9/22 06:00, gscaglia(a)ksdata.it wrote: > I need to use Mailman 3 exclusively for forwarding emails to my customers divided by type. > > The emails must arrive exactly as they are, without any additions, and the lists are managed only by me: the customer ignores that he is subscribed to a list and receives the message as if it were one to one. > > How can I remove anything added by Mailman 3 to the forwarded message, therefore also the links for managing my membership (unsubscribe and modify)? In Postorius do the following: In Templates set list:member:regular:footer empty In Settings: in List Identity set Subject prefix empty in Alter Messages set Personalize None Filter content No Anonymous list No Include RFC2369 headers No Include the list post header No First strip reply to No Reply goes to list No Munging in DMARC Mitigations set DMARC mitigation action No DMARC mitigations in Archiving set Archive policy Do not archive this list -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

[MM3-users] Re: How to debug bounces?

by Mark Sapiro

On 5/7/26 09:55, Stephen J. Turnbull wrote: > > > > Stephen Daniel writes > > > > > > > 550 5.7.9 This mail has been blocked because the sender is unauthenticated. > > > > Yahoo requires all senders to authenticate with either SPF or DKIM. > > > > Authentication results: DKIM = FAILURE - SPF XXX.org with ip X.Y.Z.W = > > > > SUCCESS. > > That is quite weird -- it says SPF authentication *succeeded*, which > should be sufficient. It's possible it's a Yahoo misconfiguration > which will fix itself, as far as SPF is concerned. But you should > still find out what's going on with DKIM. I think this may be Yahoo policy in that SPF passed but wasn't aligned with the From: domain, thus DMARC failed. It appears that Yahoo, and in some cases Gmail reject mails which fail DMARC even if the From: domain publishes no DMARC policy or DMARC policy = none. The only way around this in current Mailman is to apply DMARC mitigations unconditionally. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 day, 8 hours

[MM3-users] Re: Mailman not able to process "big" requests

by Mark Sapiro

On 04/24/2018 12:36 AM, Abhilash Raj wrote: > On Mon, Apr 23, 2018, at 10:41 PM, Jonas Felber wrote: >> We also have a problem with sending out emails to "large" (>50) groups, >> as they seem to not getting sent out at all. Do you have any idea what >> the problem here could be? > > Which MTA are you using? What do you see in mailman's logs and MTA's logs? > > I haven't seen this kind of problem before with Mailman 3. This very list is hosted using Mailman 3 and I believe has more than 50 subscribers. Nor have I seen this issue. This list currently has 158 non-digest members. There are several @python.org Mailman 3 lists with over 100 non-digest members including the active yt-users(a)python.org list with 301 members, and I have gotten no reports of an issue like this. Also, there are over 600 lists at <https://lists.fedoraproject.org/>, and I don't think this is an issue there either. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years

[MM3-users] Re: installation

by Mark Sapiro

On 11/21/20 10:42 AM, Christian Stalberg via Mailman-users wrote: > I am working through installing mailman3 on Ubuntu 20.04.1 LTS / apache > 2.4.41 / postfix 3.4.13 and have a couple of questions. > > > > I've installed Django, cloned the mailman-suite repo, installed and tested > apache with Mod_wsgi [ according to > https://tecadmin.net/install-apache-with-python-mod-wsgi-on-ubuntu-20-04/ ] > and it worked fine. Now I am at 'Setting up a WSGI' server in the MM3 > instructions where it says I am to configure uwsgi.ini file. Does that .ini > file go in /opt/mailman/mailman where other .ini files reside? You are mixing apples and oranges. The doc at <https://tecadmin.net/install-apache-with-python-mod-wsgi-on-ubuntu-20-04/> uses mod_wsgi in apache, It doesn't use uwsgi at all. > In setting up the apache virtual server [ according to > https://docs.mailman3.org/projects/postorius/en/latest/deployment.html?highl > ight=apache#apache-with-mod-wsgi ] I do not find a postorius.wsgi which > WSGIScriptAlias points to. The file in your WSGIScriptAlias directive should be the wsgi.py file in mailman-suite/mailman-suite_project/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Importing issue from mailman2 to mailman3

by Mark Sapiro

On 3/7/21 3:42 AM, David Partain via Mailman-users wrote: > > Most of it's going fine, as best I can see. However, I get exceptions on some lists that look like this: > > Traceback (most recent call last): ... > pymysql.err.DataError: (1406, "Data too long for column 'info' at row 1") > > My assumption is that what's in the "Info" field on the old mailman2 config is simply too long. Is that correct? Yes. For MySQL and MariaDB the info column is VARCHAR(255). It probably should be defined as a type that allows a longer value, but for now with those DB engines, it is limited to 255 bytes. > In that case, I suppose the right thing is to (1) edit each one, reducing the size, which'll create a new config.pck, (2) pull it over to the new machine, and (3) run the import again. > > Seem reasonable? Yes, that's the workaround. Or you could start over with postgresql as the DB which doesn't have that limitation. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

Search results for query "sapiro"