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

[MM3-users] Re: Server 500 error for just one list, just one page

by Mark Sapiro

On 6/28/20 4:05 PM, kelly.close(a)lrewater.com wrote: > I am having a curious problem with just ONE list management page for ONE list on my server. Every other list I've checked, and every other management page for this affected list, seem fine. But when I go to the Subscribers page for this one list I get a Server 500 error, and I can't find anything in the apache or mailman logs to give me a clue (granted I'm not sure I know for sure where all the different logs are). Neither do I, but you want to look in Mailman core's mailman.log and Django's log. mailman.log is in a directory with others including smtp.log and subscribe.log. If you don't know where to find that, look in the output from `mailman conf`. The first thing to look for is [mailman] layout: which will have a value like `fhs`, `dev`, `here` or `local`. then look at [paths.xxx] log_dir: where xxx is the layout value, and if that includes $var_dir, look at [paths.xxx] var_dir: For the Django log look in settings_local.py and settings.py or whatever they're called in your case for LOGGING['handlers']['file']['filename'] > So specifically this page: https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org… That page should be the same as <https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org…>. Can you go there? Where are you finding that link? What postorius version is this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: Upgrade Mailmam Core from

by Mark Sapiro

On 9/28/22 23:18, sascha.rissel(a)gmail.com wrote: > > After this, I deleted the venv again and startet anew, again. > But this time, I explicitly did (as Stephen suggested above) >> pip install wheel > prior to >> pip install wheel mailman psycopg2-binary\<2.9 > > This time, it ran through without errors, although "wheel" is also contained in the latter command. > Can you explain that? Apparently, if you run `pip install wheel mailman psycopg2-binary\<2.9` pip attempts to build `lazr.delegates` which is a `mailman` dependency before it fully installs `wheel`. Thus the need to `pip install wheel` first. However, with both `virtualenv 20.0.17/python 3.8.10` and `virtualenv 20.4.2/python 3.9.10` `virtualenv venv` installs `wheel` in site-packages in the venv as does `python3 -m virtualenv venv`, but `python3 -m venv venv` does not. But, at least in my case, with venv built with `python3 -m venv venv` and not containing `wheel` in `site-packages` `pip install wheel mailman psycopg2-binary\<2.9` runs without error. > Second question: > There is still no directory "/etc/mailman3" created, where I can create mailman.cfg in. > Does this maybe result from the fact that in first instance, I tried to install mailman3-full via "apt-get install" and removed it again via "apt-get remove"; with manually deleting /etc/mailman3 afterwards. > > Shall I create /etc/mailman3 manually and adding "mailman" system user permissions? Yes, as the doc says at https://docs.mailman3.org/en/latest/install/virtualenv.html#installing-mail…, "After this, create a configuration file at /etc/mailman3/mailman.cfg for Mailman Core:" -- 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: Moderation Action Changed After Import

by Mark Sapiro

> > I can't confirm what was set on the old MM2 list as it is no longer > accessible. I am just going on the word of the List Owner. My opinion is > that the moderation for those list members were set to Reject on the > previous MM2 list. I am mainly interested to see if you know of this > happening to anyone else and/or perhaps there is an existing bug that > could impact the moderation settings of imported MM2 lists. If you have the config.pck and any MM 2.1 installation, you can get all the info from the config.pck. For example > /path/tp/mm2.1/bin/dumpdb /path/to/config.pck|grep member_moderation_action will show the setting with 0 = Hold, 1 = Reject and 2= Discard. Finding which members are moderated is more difficult as there is a dictionary named user_options with keys = to email addresses and integer values and the integer is a bit field defined as follows (from Defaults.py) > # Bitfield for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set > # defaults for all new lists. > Digests = 0 # handled by other mechanism, doesn't need a flag. > DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() > DontReceiveOwnPosts = 2 # Non-digesters only > AcknowledgePosts = 4 > DisableMime = 8 # Digesters only > ConcealSubscription = 16 > SuppressPasswordReminder = 32 > ReceiveNonmatchingTopics = 64 > Moderate = 128 > DontReceiveDuplicates = 256 However, to address your concern, As far as I know, import21 is doing the right thing. If you want to send me the config.pck you imported, I can try to verify that. -- 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

[MM3-users] Re: REST API authorization failed

by Mark Sapiro

On 1/9/22 5:57 AM, Axel Rau wrote: >> >> Does the `mailman info` command report what you think for REST credentials? > yes. ... > I used curl: > - - - > (mailman_33) [root@lists5 /usr/local/mailman3]# curl -v -u restadmin:??? http://localhost:8001/3.1/lists > * Trying 127.0.0.1:8001... > * Connected to localhost (91.216.35.42) port 8001 (#0) > * Server auth using Basic with user 'restadmin' >> GET /3.1/lists HTTP/1.1 >> Host: localhost:8001 >> Authorization: Basic cmVzdGFkbWluOnc2cmtuQXpJZmVRc1o4WnlkMFpBcmNjcm55OA== >> User-Agent: curl/7.80.0 >> Accept: */* >> > * Mark bundle as not supporting multiuse > < HTTP/1.1 401 Unauthorized > < Server: gunicorn > < Date: Sun, 09 Jan 2022 13:51:43 GMT > < Connection: close > * Authentication problem. Ignoring this. > < www-authenticate: Basic realm="mailman3-rest",charset="utf-8" > < content-type: application/json > < vary: Accept > < content-length: 77 > < > * Closing connection 0 > {"title": "401 Unauthorized", "description": "REST API authorization failed“} > - - - > I see "Server: gunicorn“, does this mean, I must install gunicorn? As you later reported, gunicorn is installed. It is installed as a dependency of Mailman core to serve as the REST server which is what's going on here. It also may or may not be used as the wsgi server for Django depending on how you configured that, but this is independent. Anyway, the above is saying that restadmin:??? doesn't match what's configured in Mailman core and reported by `mailman info`. Please check carefully that these are the same in both mailman.cfg admin_pass and settings MAILMAN_REST_API_PASS. -- 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: Outgoing messages fro Mailman fails DMARC

by Mark Sapiro

On 04/10/2018 02:18 AM, Henrik Rasmussen wrote: > I have set up Postfix to DKIM sign outgoing mails from GNU Mailman 3.2.0a1 which validates nicely ("dkim=pass (signature was verified)"), but DMARC fails ("dmarc=fail action=none") on the recipient end, probably because the "header.from=gmail.com;" (or similar) which means that DKIM d= will not match. Right. DMARC deals with the From: domain. For DMARC to pass, either a valid DKIM sig or SPF with domain 'aligned' with the From: domain must be true. I.e., your DKIM sig and/or SPF won't do if the From: domain is not your domain. > According to dmarc.org*) "Mailing lists usually do not take authorship of the emails they relay" so I should "consider to apply specific rules for emails coming from mailing lists". Also according to dmarc.org*) Mailman (Mailman 2 that is, and I presume Mailman 3 does too) "include features to interoperate with DMARC senders". > > I assume that the dmarc mitigations list settings in Mailman is for incoming messages, but how do I set Mailman to cope with this on outgoing messages? I'm not sure I understand what you are saying. Mailman's (both 2 and 3) DMARC mitigations allow modifying the outgoing message in some or all cases so the From: domain is the list's domain so the message won't be dealt with by the recipient MTA according to the original From: domain's DMARC policy. See <https://wiki.list.org/DEV/DMARC>. Also, <https://wiki.list.org/x/17891458> may be of interest. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 2 months

[MM3-users] Re: Importing Mailman 2 Lists apart from Django

by Mark Sapiro

On 4/30/20 7:59 AM, Brian Carpenter wrote: > Hello Mailman Users, > > Are there instructions on importing a Mailman 2 list into a Mailman 3 > core installation only? Does the import21 script not need > Django/Postorius/Hyperkitty? import21 requires only Mailman core. > It seems Django is required to import archives I guess because of the > use of Hyperkitty. How about importing archives without having a Django > installation? Is that what the prototype archiver for? The only current archive import we support is `django-admin hyperkitty_import` which imports archive .mbox files into HyperKitty. The prototype archiver is just a maildir format collection of messages. Converting an mbox file to a maildir is trivial. from mailbox import Maildir, mbox mb = mbox('/path/to/mbox', create=False) md = Maildir('/path/to/maildir', create=True) for msg in mb: md.add(msg) > We are getting ready to start working on a custom forum application for > Mailman 3 (called Empathy) and I am would like to import some mailman 2 > archives into the development server to work with. First you have to decide how Empathy will store messages. Look at <https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/management/c…>. This is how HyperKitty gets messages from a mbox and adds them to its database. It's actually fairly simple - a lot of the code is handling exceptions due to defective messages. Presumably Empathy will have a method for adding a message to the archive, so importing is just getting messages from the mbox and using Empathy's method to add it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

[MM3-users] Re: nginx configuration on a multitasking server

by Mark Sapiro

On 12/10/21 10:22 AM, David Newman wrote: > > 1. At least on my system, the proxy_pass statement will only run without > errors if I change this to a fully formed URL, e.g., 'proxy_pass > http://127.0.0.1:8000'. Is this a typo in the docs? I changed it at https://docs.mailman3.org/en/latest/install/virtualenv.html#nginx-configura… but I wonder if we shouldn't be using `uwsgi_pass` instead of proxy_pass. See https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass Are you using uwsgi or some other wsgi server. > 2. What document root(s) and alias(es) to use for Postorius and > Hyperkitty and the Django admin on a server that also runs other > services (e.g., Postfix for non-list mail and Roundcubemail)? If you can separate Mailman from other services by subdomain, you can configure them separately and for Mailman, root is irrelevant as everything is proxied or aliased in a location directive. For example, Mailman on the server that supports this list uses the lists.mailman3.org domain and we have (excerpted) ``` server { listen 443 default_server; root /usr/share/nginx/html; index index.html index.htm; # root and index are probably irrelevant as we never go there server_name lists.mailman3.org; ssl on; #ssl stuff location / { proxy_pass http://127.0.0.1:8000/; # other proxy stuff } location /static/ { alias /var/spool/mailman-web/static/; } location /robots.txt { alias /usr/share/nginx/html/robots.txt; } location /favicon.ico { alias /var/www/listorg/images/favicon.ico; } } ``` And for the other stuff we have ``` server { listen 443; server_name .list.org mirror.list.org mirror.mailman3.org; root /var/www/listorg; ssl on; # ssl stuff } -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Mark Sapiro

On 1/26/22 00:11, Stephan Krinetzki wrote: > > After we enabled the "slow query log", we got in the postgresql database the following output: > > 2022-01-25 12:49:41.538 CET [16126] LOG: unexpected EOF on client connection with an open transaction > 2022-01-25 15:34:36.047 CET [16864] LOG: duration: 30760.028 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > 2022-01-25 15:34:36.047 CET [3900] LOG: duration: 9372.471 ms statement: DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX > 2022-01-25 16:42:07.243 CET [3900] LOG: unexpected EOF on client connection with an open transaction > > Pretty sounds like a database problem? The unexpected EOF is because the gunicorn worker timed out and was killed. There are two `DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX` transactions because the first one timed out. These came from https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.… The `accept` action is processed and ultimately we get to https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/moderator.… and that in turn is doing the DELETE at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/pending.… There must be some kind of database locking causing this, but I have no clue as to what it might be. If you haven't done so, I would stop all the mailman services and the database server and then start them again. I don't know if that would help, but it might. > sometimes the log (mailmansuite.log) show us this error That too is from the gunicorn worker timing out and being killed. -- 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: unique key violation because of case sensitivity of email address

by Mark Sapiro

On 6/15/24 11:47, Jörg Schulz wrote: > After updating to the most recent version of mailman-web, the migrations > script issued an error: > > > Apply all migrations: account, admin, auth, contenttypes, > django_mailman3, django_q, hyperkitty, postorius, sessions, sites, > socialaccount > mailman-web | Running migrations: > mailman-web | Traceback (most recent call last): > mailman-web | File > "/usr/lib/python3.12/site-packages/django/db/backends/utils.py", line > 89, in _execute > mailman-web | return self.cursor.execute(sql, params) > mailman-web | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mailman-web | psycopg2.errors.UniqueViolation: duplicate key value > violates unique constraint > "account_emailaddress_user_id_email_987c8728_uniq" > mailman-web | DETAIL: Key (user_id, email)=(27, > John.Doe(a)mynicedomain.de) already exists. > mailman-web |(...) Presumably you upgraded django-allauth to a version >=0.62. Beginnin then, email addresses were no longer stored case-sensitively and the migration was dealing with that. There were other issues when addresses were store case sensitively. See https://github.com/pennersr/django-allauth/issues/3019 > Digging into the db, I found the duplicate to result from a duplicate > entry using john.doe(a)mynicedomain.de > > > Obviously, the process that originally created the entry, took case > sensitivity literally which doesn't seem to be the case any longer for > the migration script. > > I fixed this by removing one of the duplicates hoping no further errors > will come up.... > > > What would have been the better approach? Removing one of the duplicates is the solution, and beginning with django-allauth>=0.62, duplicates should no longer occur. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

[MM3-users] Re: Single-Sign-out for List member

by Mark Sapiro

On 8/13/20 7:45 PM, Stephen J. Turnbull wrote: > > That said, I have some ideas for how to make this safe for corporate > Germany, specifically, keep a database of user-specific OTKs. (These > could be time-limited -- with the server returning a "use a more > recent message's URL message -- or permanent.) For the usera/userb > reasons Mark gives, and the preview-url reason you give, this is > *still* not going to be safe for discussion lists. But if the From: > is <noreply(a)DeutscheKompany.co.de>, so you have to shoulder surf and > have a photographic memory to get the user's unsubscribe URL, it > should be reasonably secure for announce lists and newsletters. I have experience with a one way email newsletter from Constant Contact. These have a link to unsubscribe and also a link to forward the email to someone else. We ultimately added our own ``` If you want to forward this email, please press the Constant Contact "Forward this email" link below. If you use your "forward" button, you might be unsubscribed. ``` note just above those links because people were forwarding the mail and getting unsubscribed when the person they forwarded it to clicked the unsubscribe link. The real pain is once a user is unsubscribed in this way, the mailing manager can't add her back. She has to personally deal with Constant Contact do get them to remove her from their "do not mail this address" list. FWIW, our note seems to help reduce if not eliminate the problem. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

Search results for query "sapiro"