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

[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, 5 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, 4 months

[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, 9 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, 7 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, 2 months

[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

5 years, 1 month

[MM3-users] Re: Mailman Core 3.3.2 is now out

by Mark Sapiro

On 11/22/20 1:22 AM, Torge Riedel wrote: > > I like to ask what to do with other packages when upgrading mailman. I > noted, that after upgrading mailman, all requirements are fulfilled, but > a lot updates are available: > > (venv) mailman@basis2:~/core$ pip3 list --outdated > Package Version Latest Type > ------------------- ------- ------ ----- > aiosmtpd 1.2 1.2.2 sdist > alembic 1.4.2 1.4.3 wheel > atpublic 1.0 2.1.1 sdist > dkimpy 1.0.4 1.0.5 sdist > dnspython 1.16.0 2.0.0 wheel > flufl.i18n 2.0.2 3.1.3 sdist > flufl.lock 3.2 5.0.3 sdist > idna 2.9 2.10 wheel > importlib-metadata 1.6.1 2.0.0 wheel > importlib-resources 2.0.1 3.3.0 wheel > passlib 1.7.2 1.7.4 wheel > PyMySQL 0.9.3 0.10.1 wheel > requests 2.23.0 2.25.0 wheel > SQLAlchemy 1.3.17 1.3.20 wheel > urllib3 1.25.9 1.26.2 wheel > zipp 3.1.0 3.4.0 wheel > zope.component 4.6.1 4.6.2 wheel > zope.event 4.4 4.5.0 wheel > zope.interface 5.1.0 5.2.0 wheel > > Should I update them (regularly) or may I break something in mailman? In some cases and at some times, Mailman itself specifies a version <= something for a dependency. There have been issues where an upgraded dependency is not compatible with current Mailman. You can look at the install_requires section of setup.py to see if there are any specific version requirements, but this is not fool proof. For example, flufl.lock 5.0 broke Mailman core (See https://gitlab.com/mailman/mailman/-/issues/754) This was fixed in core version 3.3.2. Thus, If Mailman is working with the set of installed dependencies that you have and all of them satisfy >= requirements in setup.py, it's probably safest to leave them as is. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: Change digest frequency and default threshold

by Mark Sapiro

On 10/12/2018 03:46 AM, Henrik Rasmussen wrote: > > As of /opt/mailman/core/var/queue/digest/ and /opt/mailman/core/var/queue/shunt/ no, but there is three files in /opt/mailman/core/var/queue/bad/ > > -rw-rw---- 1 root root 398 Oct 10 14:42 1539175326.8246331+4b7e80db0d22f01c2d4363e323320fcd34560657.psv > -rw-rw---- 1 root root 398 Oct 11 12:11 1539252672.3947155+ae2631d9f6514d74c77a38f09f821ee71515f9d9.psv > -rw-rw---- 1 root root 398 Oct 11 12:24 1539253469.5928977+15b0842462ddd3abcac8d688e5bbb195b07409bc.psv > > They seems to be binary, ... They are Python pickles. The fact that they are owned by 'root' probably means 'mailman digest' was run as 'root'. it should be run as 'mailman'. The files are preserved 'unparseable' queue files - probably unparseable because they can't be read because of the permissions error. You can view them with 'mailman qfile'. I expect this will show an 'empty' message and metadata containing in this case listid: 'test.lists.example.com' digest_path: '/opt/mailman/var/lists/test.lists.example.com/digest.1.9.mmdf' volume: 1 digest_number: 9 and a few other things like version and _parsemsg This is the 'digest' queue entry that tells DigestRunner to produce digests from the file in digest_path. > It seem to say PermissionError: [Errno 13] Permission denied, but inside the container, the directoried in /opt/mailman/var/queue is The permissions error is possibly on these files: -rw-rw---- 1 100 nogroup 103433 Oct 10 14:36 digest.1.7.mmdf -rw-rw---- 1 100 nogroup 155540 Oct 11 11:29 digest.1.8.mmdf -rw-rw---- 1 100 nogroup 104002 Oct 11 12:21 digest.1.9.mmdf or on the digest queue entries and it is because 'mailman digests' is not being run as the mailman user. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 11 months

[MM3-users] Re: Installation Wooes

by Mark Sapiro

On 5/3/20 8:13 PM, Samir Faci wrote: > > Postfix Failed Logs. > > May 4 03:07:36 lists postfix/smtpd[1968155]: disconnect from > unknown[198.199.98.177] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 > May 4 03:07:36 lists postfix/smtpd[1968155]: connect from > unknown[198.199.98.177] > May 4 03:07:36 lists postfix/smtpd[1968155]: 745B31473C6: > client=unknown[198.199.98.177] > May 4 03:07:36 lists postfix/cleanup[1968158]: 745B31473C6: > message-id=<158856165549.136760.840427238489827082@lists> > May 4 03:07:36 lists postfix/qmgr[1964759]: 745B31473C6: > from=<booh-bounces(a)lists.domain.org So mailman and Postfix are on different machines. That may complicate things, but > <mailto:booh-bounces@lists.domain.org>>, size=5474, nrcpt=1 (queue active) > May 4 03:07:36 lists postfix/smtpd[1968155]: disconnect from > unknown[198.199.98.177] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 > May 4 03:07:36 lists postfix/lmtp[1968159]: 745B31473C6: > to=<booh-owner(a)lists.domain.org <mailto:booh-owner@lists.domain.org>>, > relay=lists.domain.org <http://lists.domain.org>[198.199.98.177]:8024, > delay=0.03, delays=0/0/0/0.02, dsn=2.0.0, status=sent (250 Ok) This was a successful delivery. > May 4 03:07:36 lists postfix/qmgr[1964759]: 745B31473C6: removed > May 4 03:07:38 lists postfix/smtpd[1968155]: connect from > unknown[198.199.98.177] > May 4 03:07:38 lists postfix/smtpd[1968155]: NOQUEUE: reject: RCPT from > unknown[198.199.98.177]: 554 5.7.1 <csgeek(a)domain.com > <mailto:csgeek@domain.com>>: Relay access denied; > from=<booh-bounces+csgeek=domain.com(a)lists.domain.org > <mailto:domain.com@lists.domain.org>> to=<csgeek(a)domain.com > <mailto:csgeek@domain.com>> proto=ESMTP helo=<[127.0.1.1]> You are sending from a remote machine 198.199.98.177 to a presumably remote domain domain.com so relay access is denied as it should be. You need to add 198.199.98.177 to mynetworks in Postfix. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: Updating from Ubuntu-20.04 LTE installation

by Mark Sapiro

On 5/23/20 7:02 PM, Peter Adebahr via Mailman-users wrote: > > Our installation was done by "apt-get install" in Ubuntu 20, thus still > running MM 3.2.2 (and python 3.8.2). > > Do you have any advise, how to upgrade from there to your current > version? I know this might be a bit dangerous, but with today's VMs the > risk is much less than it used to be: It shouldn't be difficult, but I can't give you details because I don't know exactly how the Debian/Ubuntu package installs things. Also I don't know whether "current version" refers to the 3.3.1 release or the head of the https://gitlab.com/mailman/mailman master branch. > Do you think it would be possible, just to replace the code and library > parts, keeping the database and config files as is? Yes. It should be fairly straightforward. You first need to find where the Mailman Core package is. You should be able to just replace the contents of the `mailman` package directory with ours. You may be able to do this via pip pip install --upgrade mailman globally or within Mailman's virtualenv if it is installed in a virtualenv. However, there are caveats. There are Debian patches at <https://sources.debian.org/patches/mailman3/3.2.2-1/>. The big `0002` patch replaces importlib_resources with importlib.resources because importlib_resources is not available in Debian. Most of the patches apply to tests, and for the actual working code, we fixed this differently as of Mailman 3.3.1, so I don't think you need the Debian patches. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 3 months

Search results for query "sapiro"