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

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

[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

5 years, 8 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

5 years, 4 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

5 years, 4 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

4 years, 4 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

9 months, 2 weeks

[MM3-users] Re: Mail control not given from Mailman 3 to postfix

by Mark Sapiro

On 7/7/20 10:23 AM, Shashikanth Komandoor wrote: > > I did not see any log records based on that message id in mailman.log. > There is a lot much of shunt queue but I don't see any file with the > required message id. The same is the bad queue also. The message-id will not be logged in mailman.log for these issued. For each such issue, there will be a log message indicating the exception with a traceback and a 'shunting' message. To see the actual problem message, you can use `mailman qfile` to examine the shunted .pck file. > I find below two lines at that particular time stamp by when the log > recorded in vette.log > > > > *Uncaught runner exception: sequence item 0: expected str instance, Header > foundTypeError: sequence item 0: expected str instance, Header found* > > But I am not sure if the above lines are related to that missing message or > not. Almost certainly, but examine the shunted message with `mailman qfile` to be sure. > I am using postgresql as database. FYI, if it brings an idea to you to help > me. That's not relevant to this issue. Examine the tracebacks and shunted messages. If the problem is not obvious from that, you can post here for help. We need the complete error message with full traceback and the raw message text. For the message, we are primarily interested in all the headers including sub-part headers. Sub-part bodies can be truncated and headers sanitized for privacy if necessary, but the fewer changes you make to the raw message text, the better. -- 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

[MM3-users] Re: Missing Base64 encoding from control message reply

by Mark Sapiro

On 8/22/25 00:06, Perske, Frank via Mailman-users wrote: > > The original email with the “confirm” was sent by Outlook/Exchange. There are only Postfix servers between Exchange and Mailman. > > From: "..." <...@...> > To: "'...-request@...'" > <...-request@...> > Subject: AW: confirm a041af0edea02cb5abddbd13573cabf9f4e37d6e This should work assuming the token is known. You might try setting verp_confirmations: yes in the [mta] section of mailman.cfg. This will cause the confirmation request to be From: the list's -confirm address with the token with a Subject: like `Your confirmation is needed to join the LISTNAME mailing list.` which might make a reply work better. > How can I enable further debugging? Then I could try to reproduce the problem. You could try a patch like ``` --- a/src/mailman/runners/command.py +++ b/src/mailman/runners/command.py @@ -44,6 +44,7 @@ from zope.interface import implementer NL = '\n' log = logging.getLogger('mailman.vette') +dlog = logging.getLogger('mailman.debug') class CommandFinder: @@ -161,6 +162,7 @@ class CommandRunner(Runner): """The email command runner.""" def _dispose(self, mlist, msg, msgdata): + dlog.info('Message to command runner:\n%s', msg.as_string) message_id = msg.get('message-id', 'n/a') # The policy here is similar to the Replybot policy. If a message has # "Precedence: bulk|junk|list" and no "X-Ack: yes" header, we discard ``` This will write the contents of messages to the -request address to Mailman's debug.log which may help determine what's happening. Please note https://docs.mailman3.org/en/latest/install/docker.html which says in part `If you have any issues using the container images, please report them directly on the Github repo for docker-mailman.` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months

[MM3-users] Re: Member Issue Discovered

by Mark Sapiro

On 10/19/20 7:42 PM, Brian Carpenter wrote: > On 10/19/20 10:23 PM, Mark Sapiro wrote: >> And the import21 created the user and address records for this user. > > Does the same thing for a new subscriber as well. So there is no pathway > to change a real name that is associated with an email address. None. > Zilch. Mailman 2 made this so easy and Mailman 3 made it impossible. I > will let someone else file the bug report. You don't really think that > this is an issue which means it will be years before it is addressed. So > I will save me some time. I will learn to live with it. I didn't say I didn't think it was a real issue. I mostly questioned whether a new subscription should change an existing display_name. I agree that there should be a way for a user to change the display_name associated with her address. I'm not so sure about a list admin. And in any case, I'm only one person. I'm not the only one deciding what's important and what's not. I only decide what I want to work on, not what anyone else thinks is important or wants to work on, so even if I think something is not worth doing, that doesn't mean it won't get done, and once again for emphasis, I do thing a user should be able to change the display name associated with her address(es). Mailman 3 is totally different from Mailman 2.1 in this respect. Mailman 2.1 had no concept of user. All it knew was addresses subscribed to lists and an address subscribed to one list had no connection to the same address subscribed to another list or being an owner or moderator of a list. Mailman 3 does have a concept of user and addresses belonging to a user. This complicates things in some ways. In Mailman 2.1 we could have "The Boss <user(a)example.com" as a member of one list and "Just a Peon <user(a)example.com>" as a member of another list. In Mailman 3 that is not possible unless the addresses are tweaked in some way to make them different. You don't seem to be concerned about the case where I subscribe to a second list with a different display name and am surprised to find my display name changed on the first list, but it's something that I have to consider. As far as filing or not filing an issue, issues in the GitLab trackers are how we track these things. Threads on mailing lists are appropriate for discussion of issues, but if something is going to get changed or fixed, an issue in the tracker is the way to ensure it doesn't get put aside and forgotten. If this is as important to you as it seems to be, please file the issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: list footer questions

by Kelly Close

I agree Mark. I can't see the issue but those search rules are clear. I'm glad to know I can "force" it to work with the table records but I would like to figure out the more systemic issue in case it could affect other things. ~Kelly -- K. Kelly Close, P. E. Senior Project Manager | Water Rights Engineer | Technology Team Lead Office: 303-455-9589 | Direct: 303-867-7665 Kelly.Close(a)LREwater.com <http://www.lrewater.com/> LREWATER.COM <http://lrewater.com/> 1221 Auraria Parkway, Denver, CO 80204 ***CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.* On Sun, Jun 7, 2020 at 5:14 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/7/20 3:47 PM, Mark Sapiro wrote: > > > > However, you shouldn't have needed to do that. I only mentioned it in > > case there was an entry for the name and context with a URI pointing > > elsewhere. The default if there is no entry is to use Mailman's normal > > search rules which include > > templates/lists/<list-id>/en/list:member:regular:footer.txt. > > > > The search rules are documented in the code at > < > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/utilities/i18n… > >. > > > -- > 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/ >

6 years

Search results for query "sapiro"