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

[MM3-users] Re: integrate subscribe form in Website -> CSRF-token

by Mark Sapiro

On 6/21/21 11:58 AM, Jens Günther wrote: > > We wanted to do the same with Mailman3 (Docker, 3.3.3, Postorius 1.3.4): > > <form method="POST" > action="https://$domain/postorius/lists/$short_lisname.$domain/anonymous_subscribe"> > > <input name="email" value="" type="text"><br> > <input name="email-button" value="Anmelden" type="submit"> > </form> > > When I now enter a mailaddress, the quoted error occurs. This is Django protecting against CSRF. You need to GET the for with the (hidden) CSRF token before you can POST it. > Checking another answer directly to me, there seems to be another hint :-) > > > I believe you are attempting to use the MM Core API via http > GET/POST, rather than via Postorius? That you have tried and get the > CSRF error reported? > > > > Typically this is because you need to add a token to the request to > indicate to the MM Core that your request isn't a forgery. Typically > this token is requested from Core and then presented with subsequent > requests. Have you tried this? > > > > Therefor it is needed to send also a token!? Or use another URL, not > postorius in order to subscribe!? How can I submit such a token? To submit the Token, you need to first GET the form which will have the token. Then you can include it in the POST data. This is not a satisfactory solution for your case. As hinted above, you need to use the REST API. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

[MM3-users] Re: New messages not being archived

by Mark Sapiro

On 7/19/21 9:42 AM, Sarah H wrote: > so there should be inside the docroot created by collectstatic a location /docroot/archives(or hyperkitty)/api? or is there another location that this particular page should be served from? at present the hyperkitty directory there is only css, fonts, img and js dirs. > > if I can find where this should be served from in the file system that'll give me some way to figure out what I'm actually looking for URL wise... Hyperkitty is not serving a web page. HyperKitty has an API at base_url/api with a few endpoints and generates responses to various GETs and POSTs to those endpoints. Mailman core makes calls to methods in mailman_hyperkitty/__init__.py which in turn call the HyperKitty APi and return the result. The `list_url(mlist)` method is called to get the URL to the list's archive for the List-Archive: header. It in turn does a GET for base_url/api/mailman/urls with query fragments key=<api_key> and mlist=<the fully qualified list name> to get the URL The `permalink(mlist, msg)` method is called to get the link to where HyperKitty will store the message for the Archived-At: header. It in turn does a GET for base_url/api/mailman/urls with query fragments key=<api_key>, mlist=<the fully qualified list name> and msgid=<the message-id from the message> to get the URL The `archive_message(mlist, msg)` method is called to actually archive the message. It in turn does a PUT for base_url/api/mailman/archive with the api_key, the fully qualified list name and the text of the message. See https://gitlab.com/mailman/mailman-hyperkitty/-/blob/master/mailman_hyperki… for the full detail. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

[MM3-users] Re: digest summary heavily cluttered with hrml code

by Mark Sapiro

On 10/14/20 8:46 AM, Mohsen Masoudfar wrote: > Hi, > > I am running Mailman 3.1.1 on Ubuntu 18.04. > > The user complains that the digest summary is cluttered with HTML code. What does 'summary' mean in this context? Are you referring to the 'Today's Topics:' list or the messages themselves? Is this perhaps <https://gitlab.com/mailman/mailman/-/issues/473>? > I thought, I may fix it by: > Members > {user} > Member options > Delivery mode set to [Plain Text Digest]. After setting the value and clicking [save changes], I tried to check the value by getting back to Members setting for the user, it shows the value as "Regular", which was the value before I tried to update it. There are actually 3 sets of user preferences. They are in order of priority, list based, address based and global. You can see these if you are logged in to the web UI as the user and go to 'Mailman settings' in the pull down at the top right. There are issues in Postorius if a user is a member of a list with more than one role - see <https://gitlab.com/mailman/mailman/-/issues/659>. > Question 1: How may I be sure that the value is set, if it is set? Examine the settings with `mailman shell` > Question 2: How may set it for all members of the list? Create a `mailman shell` script. > Question 3: Is there a CLI way to do this? I tried "mailman members " command. But it seems not supporting this option. Again, `mailman shell`, but this is low level and requires some knowledge of Mailman internals. -- 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: MTA setup

by Mark Sapiro

On 12/23/24 09:01, Arte Chambers via Mailman-users wrote: > Output from mailman log after sending a test message to the list: > > Dec 23 16:52:23 2024 (684048) Traceback (most recent call last): > File > "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py", > line 158, in _archive_message > url = self._send_message(mlist, msg) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File > "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py", > line 228, in _send_message > raise ValueError(result.text) > ValueError: > <!doctype html> > <html lang="en"> > <head> > <title>Bad Request (400)</title> > </head> > <body> > <h1>Bad Request (400)</h1><p></p> > </body> > </html> mailman_hyperkitty is sending the message to hyperkitty to be archived and receiving the 400 response. Presumably it has previously requested and received the list_url and the permalink to put in the message headers. This can be confirmed by the presence of List-Archive: and Archived-At: headers with values in the messages from the list. So the configuration seems to be correct to allow mailman_hyperkitty to communicate with hyperkitty. It is not clear why, but this code https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/views/mailma… is getting the ValueError. That can come from one of three places in https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/lib/incoming…. The lack of a Message-ID: is not it because Mailman's lmtp runner will add one. Most likely it is the non-ascii sender address from https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/lib/incoming… What do you get from ``` mailman qfile var/archives/hyperkitty/spool/xxx.pck ``` where xxx.pck is one of the (hopefully smaller) files. In particular, what is the From: header in that? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 months, 3 weeks

[MM3-users] Re: I'm seeing a lot of database locked errors

by Mark Sapiro

On 9/11/23 5:00 PM, bryan.kartzman(a)yu.edu wrote: > Thanks. That worked. I converted the sqlite3 database to a postgresql database and I configured the database in the DATABASES definition of the Django settings. The database lock errors have disappeared but I am getting a Django warning of an improper datetime field. I assume that is related to the database conversion. Any advice for a possible solution? These are the error messages: > ... > /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 18:51:09.290256) while time zone support is active. > warnings.warn("DateTimeField %s received a naive datetime (%s)" > ... > /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField OrmQ.lock received a naive datetime (2023-09-11 20:29:35.702222) while time zone support is active. > warnings.warn("DateTimeField %s received a naive datetime (%s)" > ... These fields and perhaps others need to be defined in Postgresql as timestamp with time zone. E.g. ``` Table "public.hyperkitty_mailinglist" Column | Type | Collation | Nullable | Default ------------------------+--------------------------+-----------+----------+---------------------------------------------------- id | integer | | not null | nextval('hyperkitty_mailinglist_id_seq'::regclass) name | character varying(254) | | not null | display_name | character varying(255) | | not null | description | text | | | subject_prefix | character varying(255) | | not null | archive_policy | integer | | not null | created_at | timestamp with time zone | | not null | list_id | character varying(254) | | | archive_rendering_mode | character varying(255) | | | ... Table "public.django_q_ormq" Column | Type | Collation | Nullable | Default ---------+--------------------------+-----------+----------+------------------------------------------- id | integer | | not null | nextval('django_q_ormq_id_seq'::regclass) key | character varying(100) | | not null | payload | text | | not null | lock | timestamp with time zone | | | Indexes: "django_q_ormq_pkey" PRIMARY KEY, btree (id) ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years

[MM3-users] Re: Member Issue Discovered

by Mark Sapiro

On 10/19/20 6:11 PM, Brian Carpenter wrote: > > No one set their preferred address here at all. The first incident was > an imported list member who was not a registered user. And the import21 created the user and address records for this user. > They wanted their > real name changed to something else. The list owner tried to figured out > how to do that, found no way to do it, figured out it was just easier to > unsubscribe them, and resubscribed them to the list using a different > name. The old name showed up again. This is a bug and please fix it > soon. If you feel this is a bug that needs to be fixed, file an issue or issues reporting it. > This has nothing to do with being subscribed to other lists. In your particular instance that's true. > I can > probably come up with a workaround using Affinity (one of the benefits > of moving away from Postorius) but I can't imagine this not being a > serious issue as Mailman 3/Postorius is more widely adopted. File an issue at https://gitlab.com/mailman/postorius/-/issues asking for the ability to change the display name associated with an address and/or an issue at <https://gitlab.com/mailman/mailman/-/issues> requesting that adding an address with a display_name as a member, non-member, moderator or owner of a list override an existing display_name for that address. I don't think you can do this in affinity because I don't think there is currently a REST endpoint to do it. You can do it easily in mailman shell, but that doesn't help the user or list admin. -- 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

[MM3-users] Re: So near, and yet so far (Configuring Mailman)

by Mark Sapiro

On 1/29/21 9:01 AM, Jack Lenox via Mailman-users wrote: > Hello all, > > I've spent more time than I care to admit trying to configure Mailman. And I almost have it all working now, but I just can't seem to get my Mailman/Postfix combo to receive emails. > > When I try to send emails to lists I'm rebuffed with undelivered notices with: > > <testlist(a)lists.fiftyshadesof.green>: Host or domain name not found. Name service error for name=lists type=AAAA: Host not found > and: > <testlist(a)lists.fiftyshadesof.green>: Host or domain name not found. Name service error for name=lists.fiftyshadesof.green type=MX: Host not found, try again > > This to me appears to be an issue with my DNS settings, but I can't work this out either. I have an A record for lists.fiftyshadesof.green pointing at my server, and an MX record pointing at that: > > lists.fiftyshadesof.green. 0 IN MX 0 lists.fiftyshadesof.green. > lists.fiftyshadesof.green. 0 IN A 193.37.35.191 > > I have driven myself mad with this and would very much appreciate any advice anyone can offer. It appears this is strictly a Postfix issue. I.e. it is rejecting the incoming mail. There are a few things to consider. Have you restarted Postfix? I don't offhand remember details, but Postfix keeps its own internal notion of some things (not sure if DNS is among them). Beyond that, what does `postconf -n` report and for things in that that reference Mailman stuff, what's in the referenced files? And, what's in /var/log/mail.log when you send to testlist(a)lists.fiftyshadesof.green? -- 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: Bottom line of message footer

by Mark Sapiro

On 2/14/21 5:40 PM, Tom Stoddard wrote: > Here's another question that I have. A regular message just came into my > email from one of the lists I'm a member of and it had a 3 line footer. > The first two lines are fine, they just include the list's email address > and an address to send unsubscribe requests to. The third line is this: > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > It looks to me like it should be a link to the group's list info page. > Is this a bug or is there something I can do to fix it? It looks like it > might be missing a forward slash after the first "s". This is a list whose msg_footer was imported by The Mailman 3 process that imports Mailman 2.1 lists. This import process will recognize the default msg_footer and not create a list specific template for it, but other things in the footer result in a list specific template which needs to be reviewed for issues like this. The way for you to fix it is to create a list:member:regular:footer (and maybe a list:member:digest:footer) template in your web UI which will then override the existing list specific template. The available replacements are listed at <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>. In templates they are all $ strings, e.g. $name. The %(name)s replacements are Mailman 2.1 and won't work. Also, there is no replacement for web_page_url because Mailman Core doesn't know what that is, so you have to include the actual 'https://.../' value if you want to include a web link. -- 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: cleanup lost users completly - mailman shell

by Mark Sapiro

On 2/21/22 03:28, Paul Paulchen wrote: > > Thanks to this thread, I know how to find the lost souls in our mailman environment > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > > >>> um = getUtility(IUserManager) > >>> for usr in um.users: > ... if len(list(usr.memberships.members)) > 0: > ... continue > ... adr = usr.addresses[0] > ... print(f'Name: {adr.display_name}, Email: {adr.email}, Created: {usr.created_on}') > > So I can see them now. Is there a technique, to clean them up? To get rid of them out of the system? > I am not a python programmer, but I guess there is a way to use, instead of a single user, a list of users in the delete command of the mailman shell? The replies by Guillermo and Andrew both point to a message/thread containing the same clean_users.py script. This script will do some of what you want, but maybe not all of it. It will delete Django users who have no corresponding Mailman user or have a corresponding Mailman user that has no role on any list, and optionally delete the Mailman user as well. What it won't do is delete a Mailman user that has no role on any list if there is no corresponding Django user. For that you would want to add to the above fragment so it becomes: ``` >>> um = getUtility(IUserManager) >>> for usr in um.users: ... if len(list(usr.memberships.members)) > 0: ... continue ... adr = usr.addresses[0] ... print(f'Name: {adr.display_name}, Email: {adr.email}, Created: {usr.created_on}') ... um.delete_user(usr) ... print(' Deleted.) ... >>> commit() ``` -- 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: Problems with SPOOFED_UNAUTH

by Mark Sapiro

On 9/10/25 04:24, M.Ede via Mailman-users wrote: > Thanks, I will not do any DMARC mitigations for my list. > > When I switch to anonymous list, my Headers looks like this: > [QUOTE] > Authentication-Results: mailserv.er; > dkim=none; > dmarc=pass (policy=none) header.from=t-online.de; > spf=pass (mailserv.er: domain of sender(a)t-online.de > designates 194.25.134.17 as permitted sender) > smtp.mailfrom=sender(a)t-online.de ... > > Ist there any possibility to change smtp.from or to remove it when using anonymous lists? This is a bug. It was not recognized that the Authentication-Results: header could expose the sender. This should be fixed. The following patch will remove the header. Hopefully it will not have unwanted side effects. What in your MTA is providing this? I don't think opendkim or openarc include an smtp.from in Authentication-Results: ``` --- a/src/mailman/handlers/cleanse.py +++ b/src/mailman/handlers/cleanse.py @@ -91,6 +91,8 @@ class Cleanse: # And something sets these del msg['x-mailfrom'] del msg['x-envelope-from'] + # In some cases Authentication-Results: can expose the sender. + del msg['authentication-results'] # And now remove all but the keepers. self.remove_nonkeepers(msg) i18ndesc = str(uheader(mlist, mlist.description, 'From')) ``` > (I habe found a solution to configure rspamd to whitelist my mailinglist, but I think there should be a better solution, right?) That's an rspamd issue. If you can find out exactly what causes rspamd to hit SPOOFED_UNAUTH, there may be something we can do in Mailman. It seems from the above Authentication-Results: that you are not DKIM signing your list's outgoing mail with the list domain? You should do that in your outgoing MTA. That may avoid the SPOOFED_UNAUTH. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 days, 1 hour

Search results for query "sapiro"