Search results for "Postorius" - Mailman-users

Re: Wrong info in moderation mail when held due to match of a header rule

by tlhackque

On 17-Oct-20 18:40, Mark Sapiro wrote: > On 10/17/20 1:31 PM, tlhackque via Mailman-users wrote: >> I might also add the rule number or config filename:line, as in >> >> Header "{name}": rule in {file}:{n} matched value "{value}" >> >> This would be helpful when backtracking from a rejected message to the >> cause. >> >> A sample expansion might be: >> >> Header "X-Spam": rule in foo.conf:83 matched value "yes" > > These rules are not in a configuration file. They are in the headermatch > table in the database and the rules for a particular list are exposed on > the Header filters tab in Postorius or at the REST > lists/LISTNAME/header-matches endpoint. > > Perhaps something like > > {name}: header match rule, pattern "{pattern}" matched value "{value}" > > example: > > subject: header match rule, pattern "sex|long|list|of|other|bad|words" > matched value "This is a post about filtering based on words like sex in > the subject." > > but that could be just adding more clutter. > I considered including the regex in each message, but that seemed redundant - and potentially long. Thus the pointer. Perhaps number the rules for each list, and use that index? The ROWID would seem to be a candidate for the number. Then Postorius could simply number the rules in its tab; the REST API can add the ROWID as a rule_ID field in the returned JSON. (The fact that it's a ROWID rather than an index or unique name is an implementation detail.) If many rules are anticipated, it might want an endpoint or option to fetch a rule by ID. Then it would be easy to drill down on a specific event for diagnosis. e.g. shunt_reason: (or whatever) { cause: "header_match" header: "subject" header_value: "This is a post about filtering based on words like sex in the subject." rule_id: 47 /* or pattern_id? */ } displays as subject: header match rule 47, matched value "This is a post about filtering based on words like sex in the subject." and lists/LISTNAME/header-matches/47 returns { rule_id: 47 pattern: "sex|long|list|of|other|bad|words" position: 3 /* Whatever else is in your table... I haven't looked since I postponed using MM3. eg */ comment:"Required by policy 869.202" last_updated_by: "Corporate Prude" last_updated_on: "1-Apr-1762" }, while lists/LISTNAME/header-matches returns an array of those structures, presumably as today. With those capabilities, the UI can be enhanced so that clicking on a shunted message gives the summary reason, and clicking on the summary gives the regex. I expect that the header and value will be sufficient for understanding an issue most of the time. Looking at the regex is less common, and only necessary when it needs to be updated... I still think that it is more readable and less verbose to order the message as a declarative sentence: Header "subject": rule 47 matched value "sex" but that may be a matter of personal taste. The UI can sort that out... Note that from your description, using ROWID may cause rules in a particular list to have gaps in the rule numbering. I don't think that's a big issue, though Postorious could paper that over - perhaps use the position attribute. Doesn't seem worth doing something more complex. The advantage is that it doesn't require any DB change now. But aliasing it to "rule_id" allows for any future demand to name the rules or use some other numbering scheme. I may have some details wrong - I found mm3 not ready for my needs and am thus out of date - but I hope the high level approach that I outlined is useful.

5 years, 11 months

Re: Mailman Header Behavior

by Samir Faci

Perfect, Thanks. Is there a way to set this as a default for all new lists being created? Still working on the new styles, I imagine that can be set there during the selection of the list type. -- Samir Faci On Fri, May 15, 2020 at 9:44 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/15/20 9:31 AM, Samir Faci wrote: > > > > Is there a way to force mailman to ensure that the list name shows up in > > the from field? > > In Postorius Settings -> DMARC Mitigations set DMARC mitigation action > to Replace From with list address and set DMARC Mitigate unconditionally > to Yes. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Thank you Samir Faci https://keybase.io/csgeek

6 years, 4 months

Re: Unable to remove non-member

by Mark Sapiro

On 9/29/20 4:54 AM, Brian Carpenter wrote: > On 9/29/20 12:40 AM, Mark Sapiro wrote: >> Is that all it said? The code says it is >> >> The user could not be removed: <error message> >> >> Where <error message> is the relevant HTTP error. > > It says: > > The user could not be removed: > > Nothing comes after the colon. > I see the issue. when mailmanclient processes the delete request from Postorius it calls the REST API DELETE method with the URL lists/<listname>/<role>/<address> and the address is `quoted` with urllib.parse.quote_plus, co in this case, the URL becomes lists/<listname>/nonmember/z_email%2Fdomain.org.za(a)domain.org.za This is all fine except the REST API doesn't call urllib.parse.unquote_plus to change the %2F back to slash. This is now reported at <https://gitlab.com/mailman/mailman/-/issues/774>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

Re: Django Internal Server Error on held_messages

by Mark Sapiro

On 3/24/22 04:02, Hasan Berkay Çağır via Mailman-users wrote: > Hello, > > We've been running a Mailman3 instance with Debian 10's official package: > > Mailman Core Version: GNU Mailman 3.2.1 (La Villa Strangiato) > Mailman Core API Version: 3.0 > Mailman Core Python Version: 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] > > For some reason, and only on some lists, when we try to see held messages on Postorius, we get an error message "An error occurred while processing your request." and the following error email: > > """ > Internal Server Error: /postorius/lists/list.example.com/held_messages As Andrew suggests, you will probably find exceptions with tracebacks in Mailman core's mailman.log. This is probably /var/log/mailman/mailman.log in the Debian package. If you find such and you can't determine the problem from them, post one here. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

Re: mailman3 on new Debian 12 installation, got ssl apache working on all URLs except /mailman3

by Mark Sapiro

On 3/31/25 06:26, Philip Bondi wrote: > My /etc/mailman3/urls.py is empty. > > Should I, like it indicates in https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > cp /opt/mailman/venv/lib/python3.11/site-packages/mailman_web/urls.py /etc/mailman3/urls.py > chown mailman:mailman /etc/mailman3/urls.py > and add to /etc/mailman3/settings.py > > ROOT_URLCONF = 'urls' You can do all of that, but it's probably unnecessary. What is in /opt/mailman/venv/lib/python3.11/site-packages/mailman_web/urls.py? compare it to https://gitlab.com/mailman/mailman-web/-/blob/master/mailman_web/urls.py > After completing above, https://systemdatabase.ca/mailman3 still gives > Service Unavailable It appears that https://systemdatabase.ca/postorius works so the issue is almost certainly that your urls.py is missing path('mailman3/', include('postorius.urls')), -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

Re: Mailman3 without Hyperkitty in docker

by Abhilash Raj

On Thu, Feb 28, 2019, at 5:19 PM, Abhilash Raj wrote: > On February 27, 2019 11:53:34 PM PST, Danil Smirnov <danil(a)smirnov.la> wrote: > >Hi Mark, > > > >Actually all this stuff happens inside the container after it's started > >and > >initialized without errors. I didn't amend the image anyhow. > > > >Also I have the configuration based on docker-compose.yaml provided in > >the > >repository which works just fine for mailman-web image. > > > >The very same config with postorius image (+ UWSGI_STATIC_MAP param) > >fails > >with 500 error... > > > >Now answering your questions: > > > >ср, 27 февр. 2019 г., 22:56 Mark Sapiro <mark(a)msapiro.net>: > > > >> do you have django-q in INSTALLED_APPS in your Django settings and > >what > >> is set for Q_CLUSTER? > >> > > > >I've checked settings.py inside the container and I haven't found any > >of > >the mentioned configurations there. > > > >Does the manage.py that's being run here point to the right > >settings.py? > >> > > > >No clue. > > > >Also I wonder why we have some Hyperkitty-related cronjobs in non-HK > >configured image? > > > >https://github.com/maxking/docker-mailman/blob/master/postorius/mailman-web… > > Because I am a dum dum ;-) > > Will work on removing those crons and stuff. Would be nice if you > opened an issue on Github so that I don't forget. Should now be fixed in the latest image. > > >Danil > > > > > > > >> -- > >> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > >> San Francisco Bay Area, California better use your sense - B. > >Dylan > >> _______________________________________________ > >> Mailman-users mailing list -- mailman-users(a)mailman3.org > >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org > >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > >> > >_______________________________________________ > >Mailman-users mailing list -- mailman-users(a)mailman3.org > >To unsubscribe send an email to mailman-users-leave(a)mailman3.org > >https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- thanks, Abhilash Raj (maxking)

7 years, 6 months

Re: Not able to start mailman server

by Stephen J. Turnbull

Mark Sapiro writes: >>>>> Kartheek wrote: > > I am trying to setup postorius using this website - I've used up all my bandwidth for now with the "can't send mail in Docker" thread, but FWIW Kartheek appears to be using Homebrew to manage third party packages on Mac, and in particular to install Python. I don't recall specifically with respect to Python, but I suspect that there's a "Homebrew system 'python'" (I know Homebrew does that with certain important programs that the Homebrew system depends on). That might very well confuse pip and other setup programs, since Homebrew likes to put stuff in places where you normally wouldn't find them to avoid conflicts (eg, multiple versions of Python). I can't be more specific about problems, and you'd hope that such stuff would "just work", but that might at least explain Mailman looking for stuff in "wrong places" (which might actually be right for Homebrew). Steve

5 years, 1 month

REST API for list owners/moderators

by Stephen J. Turnbull

mathias(a)koerber.org writes: > Does Mailman 3 have an REST API that allows list-owners/moderators > to perform list-management functions without having access to the > whole server/other lists etc? No. You can provide selective access to a selection of REST API endpoints via a front-end webserver such as Apache or nginx, but it would be rather painful, and possibly also rather insecure.[1] > The documentation seems to only indicate a single one-admin-user > REST API that should not even be accessible from outside? That's right. If the documentation only "indicates" that, we should fix the documentation. The point of separating Postorius from core was to put authentication and authorization in the hands of people who know how to do it (ie, Django). Footnotes: [1] That depends on what threats you're worried about. But the endpoint hierarchy is designed to make sense to application programmers, not to make it easy to disable access to "dangerous" endpoints that allow deleting lists or extracting user information.

2 years, 8 months

Re: Mailman3 is wrongly display name a list member

by Allan Hansen

Thank youi, Stephen. Oops. When I wrote below that I set the name 'B' in the account, I did describe it wrongly. Sorry. The member just wants one name, 'A' for all her subsriptions. Somehow the 'B' got into the system when we upgraded from Mailman 2 to Mailman 3. I removed the address from all the lists, set the account display name to 'A' in Django, verified that she was not subscribed to any list at all, and then resubscribed her again as 'A'. In other words, no 'B' anywhere - straight 'A's. Nevertheless, the new subscriptions still show up as 'B'. Now, for the workaround: " If you want a new subscription to set the display name for an address, the workaround would be to delete the address, then reconfirm the address, and resubscribe the address to all the relevant lists." I modified the above workflow to: Removed the address from all the lists. Set the account display name to 'A' in Django. Verify that she is not subscribed to any list at all. Deleted the email address in Django (under 'Email addresses'). Resubscribed her as 'A'. In other words, no 'B' anywhere - straight 'A's. Nevertheless, the new subscriptions still has 'B' when I list it in Postorius. Further: When I search for 'Email addresses' in Django's list of emails (by account or email), it no longer exists. When I search under 'Users' (by account or email), it exists with 'A' as the display (which she entered when she created the account). Then since the email does not exist, under 'Email addresses' in Django, I go to 'Add email address', enter her account name and address. This gives and error: 'Select a valid choice. That choice is not one of the available choices.' I get this error no matter which 'Save...' button I press. I then tried to get into REST as per your advice here: " I think just starting Python 3 on the Mailman host as the Mailman user (we recommend "mailman" but Debian prefers "list", YMMV) and typing >>> from mailman.testing.documentation import dump_json >>> dump_json('http://localhost:8001/3.1/addresses/a@foo.com', ... method='PATCH', data={'display_name': 'A'}) " I get this, after setting myself up as user mailman (which works when entering mailman commands): mailman@list:~/scripts$ python3 Python 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from mailman.testing.documentation import dump_json Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'mailman' Looking around, I found mailman related stuff in /opt/mailman/mm and a file called 'mailman' in opt/mailman/mm/bin but hesitated editing your command above to: /opt/mailman/mm/mailman.testing.documentation (I don't want to mess up my system). So no go... Sorry for ranting. __ Please: 1. Always use the display name and email set up in the account everywhere. 2. Allow the member to change her display name using the account UI. 3. Allow the member to change her address and apply the new address to all list subscriptions. Yours, Allan On 1/11/22, 7:20 , "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote: Allan Hansen writes: > When I subscribe 'A' <a(a)foo.com>, Mailman3 changes it to 'B' > <a(a)foo.com>. If I recall correctly, this issue occurs because Subscription objects have no display name attribute, but User and Address objects do. First, the advice part: > What can I do to help this member? Unfortunately the mailman command line utility doesn't seem to allow changing the display name. The REST interface does, though. I think just starting Python 3 on the Mailman host as the Mailman user (we recommend "mailman" but Debian prefers "list", YMMV) and typing >>> from mailman.testing.documentation import dump_json >>> dump_json('http://localhost:8001/3.1/addresses/a@foo.com', ... method='PATCH', data={'display_name': 'A'}) should do what you want. Note the numbers "8001" (Mailman core's REST port) and "3.1" (the API version) may be different on your system, I'm assuming the default install of a recent Mailman release. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… for information about accessing the REST API and https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… for a few more details on the update process. On to the rants, if you care. > I went into Django and added the name 'B' to the subscriber's > account (the name was empty). > > I then unsubscribed <a(a)foo.com> from the lists and resubscribed 'A' > <a(a)foo.com>. > > The subscription again lists as 'B' <a(a)foo.com>. Does the user need to have different display names for different addresses? (I don't think it's possible to have different display names for the same address on different lists because there's no display name at all for Subscription objects.) If the answer is "no", the correct thing to do is to set the desired display name on the user's account. If the answer is "yes", there doesn't seem to be any way to do this with current Postorius/HyperKitty. Postorius doesn't expose the display name anywhere that I can see, and HyperKitty only manages the account's "real name". > This brings up a previous discussion of display names on this list, > but I have not been able to find any solution to the need to change > Mailman3's display names for a subscriber. It is beyond weird that > unsubscribing, setting the account display name and resubscribing > the member fishes back up the old and wrong display name. Unless you explained what you did incorrectly this is not weird, it's the expected result. You set "B" in the account, that's what's going to show up as the display name. It is not obvious that a new subscription should change an existing display name for a user or an address, given that there is no way to set a list-specific display name. It could go either way, and for the user I would definitely not change it, for the address I tend to agree that a new subscription should not change the address's display name. I agree that it's weird that neither Postorius nor HyperKitty seems to expose a way to set Address display names, though. If you want a new subscription to set the display name for an address, the workaround would be to delete the address, then reconfirm the address, and resubscribe the address to all the relevant lists.

4 years, 8 months

Re: Issues with Mail delivery after Mailman 3 installation

by Stephen J. Turnbull

Chihurumnaya Ibiam via Mailman-users writes: About disabling dovecot: > I don't plan on shutting down the host anytime soon, so hopefully, > I remember to the next time it restarts. systemctl stop dovecot systemctl disable dovecot systemctl daemon-reload should do the trick without rebooting the host. > Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, > relay_domains, local_recipient_maps. Do you have lists.sugarlabs.org in $virtual_mailbox_domains? As Mark points out, virtual mailboxes make life more complicated. Also, I don't think postfix_lmtp should be in $relay_domains (that table contains addresses which won't match domains being looked up). If anything it should be postfix_domains. > > It's problematic for Mailman because that means that *all* local mail > > will be delivered to Mailman, which will reject it if it's not > > list-related. > I'm totally fine with this because that's why we setup the host, I'm sorry, that was unclear. By "list-related", I meant that "the key Postfix is trying to match is an exact match for a key in the postfix_lmtp table". Because these are hash tables, it is Postfix's responsibility to strip "+extension" from the recipient address before presenting the stripped address to the table for matching -- the table can't do it. Specifically, this applies to the confirmation and VERP cookies that may be attached to addresses for various reasons. > a mailing list, which should work just fine but then it seems > they need to connect to this host. > 165968 Feb 5 04:48:46 lists postfix/smtp[1941010]: connect to > weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused > 165969 Feb 5 04:48:46 lists postfix/smtp[1941010]: B785D1A897F: to= > <root(a)weblate.sugarlabs.org>, relay=none, delay=17323, > delays=17323/0.02/0.33/0, dsn=4.4.1, status=deferred (connect to > weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused) This is a problem at weblate.sugarlabs.org. Is it supposed to be receiving mail? I don't think that this is an authentication problem (SASL authentication takes place after connection), although if "weblate" expects authenticated TLS that might be the problem. So "lists" needs to be whitelisted (eg in $mynetworks) at weblate (I suppose Postfix is also the MTA at "weblate"?) If you have only the toplevel domain sugarlabs.org whitelisted, you may need to set another parameter to automatically include subdomains such as lists.sugarlabs.org. > No, I'm not running mailman as root, it's run as mailman. > Seeing as that's the case, would I still need to change lmtp_port? Yes, as far as I know. That's because by convention ports < 1024 can only bound to programs running as root (enforced by the kernel). I don't understand how Mailman is receiving mail configured to listen on port 24. This may have something to do with dovecot running. However I really don't understand the lsof output, because you present logs that indicate that Mailman is processing mail for lists, but nothing was listening or connected on port 24. You also say Postorius and HyperKitty are running, but nothing showed up on port 8000, which is where they would be listening. Maybe I got the lsof options wrong, but it did find Postgres and Mailman's REST API. > It did get it working, I can see mail being sent in the logs. > I sent a ping to the systems list just to get delivery confirmation > and I'm yet to get a response. I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.) > > > > What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output? > > > > > python3 1592922 mailman 27u IPv4 177685024 0t0 TCP > > localhost:8001 (LISTEN) > > > python3 1592949 mailman 27u IPv4 177685024 0t0 TCP > > localhost:8001 (LISTEN) > > > python3 1592950 mailman 27u IPv4 177685024 0t0 TCP > > localhost:8001 (LISTEN) > > > > The above are Mailman (actually, a gunicorn application) listening for > > connections to its REST API. These are HTTP listeners used by > > Postorius and HyperKitty (I guess those aren't running?), not for email. > > > > Postorius and HyperKitty are running. But they should show up as several Python applications running as mailman, listening or connected on port 8000. But they're not here. Try "lsof -i :8000 -i :24". > This is one that's consistent with Dovecot in the logs; This is Postfix sending a non-delivery notification about A26F71A8977: > 157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978 The <> tells us that this is the nondelivery notification referred to as AC7381A8978 so there's no return address to send to: > 157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active) postfix/local looks at mailbox_transport and sends it to lmtp, where dovecot is listening; > 157325 Feb 4 12:27:02 lists postfix/local[1593315]: AC7381A8978: passing <mailman(a)lists.sugarlabs.org> to transport=lmtp > 157326 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Connect from 127.0.0.1 Postfix is done with A26F71A8977, and pops it off the queue: > 157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed dovecot denies knowing about a local user named "mailman", rejecting it: > 157328 Feb 4 12:27:02 lists postfix/lmtp[1593316]: AC7381A8978: > to=<mailman(a)lists.sugarlabs.org>, relay=localhost[127.0.0.1]:24, delay=0.04, > delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] > said: 550 5.1.1 <mailman(a)lists.sugarlabs.org> User doesn't exist: > mailman(a)lists.sugarlabs.org (in reply to RCPT TO command)) dovecot says "I'm done here": > 157329 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Disconnect from 127.0.0.1: Logged out (state=READY) > Which we've established that mailman doesn't know how to deliver to local > users. So that's a bounce from dovecot. I don't know enough about dovecot or your configuration of dovecot to guess what happened. > Could be, doesn't seem to be an issue at the moment so I won't worry about > it. The Message-ID is syntactically well-formed. I'm worried about side effects from the hostname not being the FQDN in mail protocols. As long as all the configurations for Postfix use the FQDN (Postfix is smart enough to abbreviate when that's useful), there shouldn't be any problems like that. > Yes, earlier when I set it up I had set the port for Mailman to use as 465. OK. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

7 months, 2 weeks

Mailman-users search results for query "Postorius"