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

[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

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

1 year, 4 months

[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, 7 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, 6 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, 3 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, 2 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, 2 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

7 months, 4 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, 10 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

8 months, 2 weeks

Search results for query "sapiro"