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

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

by Mark Sapiro

On 11/22/20 1:10 AM, Torge Riedel wrote: > > today I did this on my setup and got the following exception after > "systemctl restart mailman": > > # systemctl status mailman.service > mailman.service - GNU Mailing List Manager > Loaded: loaded (/opt/mailman/core/mailman.service; enabled; vendor > preset: enabled) > Active: failed (Result: exit-code) since Sun 2020-11-22 09:59:53 CET; > 46s ago > Process: 30520 ExecStop=/opt/mailman/core/bin/mailman.sh stop > (code=killed, signal=TERM) > Process: 30597 ExecStart=/opt/mailman/core/bin/mailman.sh start > (code=exited, status=1/FAILURE) > Main PID: 1223 (code=exited, status=0/SUCCESS) > > Nov 22 09:59:53 basis2 mailman.sh[30597]: File > "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/protocol.py", line > 220, in check_error > Nov 22 09:59:53 basis2 mailman.sh[30597]: > err.raise_mysql_exception(self._data) > Nov 22 09:59:53 basis2 mailman.sh[30597]: File > "/opt/mailman/core/venv/lib/python3.6/site-packages/pymysql/err.py", > line 109, in raise_mysql_exception > Nov 22 09:59:53 basis2 mailman.sh[30597]: raise errorclass(errno, > errval) > Nov 22 09:59:53 basis2 mailman.sh[30597]: sqlalchemy.exc.InternalError: > (pymysql.err.InternalError) (1060, "Duplicate column name > 'archive_rendering_mode'") > Nov 22 09:59:53 basis2 mailman.sh[30597]: [SQL: ALTER TABLE mailinglist > ADD COLUMN archive_rendering_mode INTEGER] > Nov 22 09:59:53 basis2 mailman.sh[30597]: (Background on this error at: > http://sqlalche.me/e/2j85) > Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Control process > exited, code=exited status=1 > Nov 22 09:59:53 basis2 systemd[1]: mailman.service: Failed with result > 'exit-code'. > Nov 22 09:59:53 basis2 systemd[1]: Failed to start GNU Mailing List > Manager. > > I checked the database and - yes - there is already such a column in the > DB. So I tried it the "hacker" way and just removed the column from the > DB and give "systemctl restart mailman" a second try. Now it worked and > the column is back. > > I don't know if this column was already there from 3.3.1. That column was added in 3.3.2 by <https://gitlab.com/mailman/mailman/-/merge_requests/644> It is the migration to add that column that failed in the above. It appears that somehow that migration was previously run and added the column, but the version_num entry in the alembic_version table was not updated to indicate that that migration had been run. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Hyperkitty 1.1.1 to HyperKitty 1.2.1

by Mark Sapiro

On 09/30/2018 11:42 PM, Thomas G wrote: > Hi, > > I would like to migrate my current Mailman3.1/Hyperkitty data to a fresh > install in Mailman3.2. > > I didn't found how migrate the archives. >>From : HyperKitty - Version: 1.1.1 - Python2.7 > To : HyperKitty - Version: 1.2.1 - Python3.5 As Abhilash said, you shouldn't need to migrate anything but the search index. > I exported a mbox from hyperkitty (web interface) and tried to re-import > it, without result. > """""""""""""""""""""""""""""""""""""""" > xxxx @xxxxxx :/opt/mailman# python3.5 manage.py hyperkitty_import -l > listedetests(a)hatlab.fr /home/admin/listedetests(a)hatlab.fr.mbox.gz > > Importing from mbox file /home/admin/listedetests(a)hatlab.fr.mbox.gz to > listedetests(a)hatlab.fr You can't import a gzipped mbox. You have to gunzip it. > Computing thread structure > Synchronizing properties with Mailman > Warming up cache > The full-text search index is not updated for this list. It will not be > updated by the 'minutely' incremental update job. To update the index > for this list, run the 'manage.py update_index_one_list > listedetests(a)hatlab.fr' command. > """""""""""""""""""""""""""""""""""""" > The database stay empty (and web interface): > """""""""""""""""""""""""""""""""""""" > mailmandbnameprod=# select * from hyperkitty_email; > id | message_id | message_id_hash | subject | content | date | timezone > | in_reply_to | archived_date | thread_depth | thread_order | > mailinglist_id | parent_id | sender_id | thread_id | sender_name > ----+------------+-----------------+---------+---------+------+----------+-------------+---------------+--------------+--------------+----------------+-----------+-----------+-----------+------------- > (0 rows) > """""""""""""""""""""""""""""""""""""" > > Any idea to do this importation ? Why is the database empty? It should be as it was with the prior HyperKitty. Also, it doesn't seem to be the issue here, but if you don't specify a --since option to hyperkitty_import, it won't import any messages older than the most recent message in the existing archive. i.e., if there are any messages in the existing archive, the default for --since is the date of the most recent such message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 7 months

[MM3-users] Re: Moderate mails from owner

by Mark Sapiro

On 4/30/19 1:04 AM, Henrik Rasmussen wrote: > @Mark: I am really sorry for the delayed responses, but this is a very low frequency list. I have subscribed to the list using a non-Microsoft address to see the outcome. > > The mails does indeed contain 'X-Mailman' headers. > > X-Mailman-Rule-Hits:nonmember-moderation > X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation It looks like the message hit the nonmember-moderation rule and was accepted. This can happen in a few ways: First we determine the senders. Assuming the config is default, these are the addresses in From:, the envelope sender, and addresses in Reply-To: and Sender: if any. The only address I can see in the message headers that hasn't been altered by Mailman is the From: and maybe Reply-To: which you have munged to [LISTNAME](a)senderdep.example.com. Anyway that unmunged address and possibly others from the original incoming message will be users of the list with role nonmember. Now each of those (possibly only the one) nonmember(s) is checked for a moderation action. Since the message does not appear to have been held or processed through rules beyond nonmember-moderation, we presumably found a moderation action of accept. This can happen in a few ways., If this list was originally imported from Mailman 2.1 by the 'mailman import21' command, there may be a legacy accept_these_nonmembers attribute for the list. If so, and if a nonmember sender address matches an address or pattern in the list's accept_these_nonmembers, the message will be accepted. Otherwise if the moderation_action for a nonmember sender address is accept the message will be accepted. You need to check the list's accept_these_nonmembers attribute and the non-member address's moderation action. If you have recent Postorius, you can see nonmembers and their options from the 'users' -> Non-members view. In any case, you can do something like mailman shell -l list.example.com Welcome to the GNU Mailman shell The variable 'm' is the list.example.com mailing list >>> m.accept_these_nonmembers returns a possibly empty list Then for the sender addresses >>> memb = m.nonmembers.get_member('sender address') >>> memb.moderation_action This may return <Action.accept: 3> in which case you may want >>> memb.moderation_action = m.default_nonmember_action -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

[MM3-users] Re: Message IDs

by Mark Sapiro

On 10/15/21 3:19 AM, Philip Colmer wrote: > > I'm not sure that the message ID identifies the author, does it? No, but it identifies the message, and while Mailman has made some cosmetic modifications to the headers, it is still the same message. > I've just done a quick test of sending myself an email and then replying to it. > > The original email has a message ID of > CAKTSSThxADLoO=Cy5cNzHoihGb5dYbmB0iw_ThTqe9T9At9efw(a)mail.gmail.com > > In the reply, the following headers are present: > > References: <CAKTSSThxADLoO=Cy5cNzHoihGb5dYbmB0iw_ThTqe9T9At9efw(a)mail.gmail.com> > In-Reply-To: <CAKTSSThxADLoO=Cy5cNzHoihGb5dYbmB0iw_ThTqe9T9At9efw(a)mail.gmail.com> > Message-ID: <CAKTSSTh-Fgy63MbDQtWS=oPCw0kGxTmj5RxRe6r1U0W=Die4mQ(a)mail.gmail.com> > > Would it be reasonable for Mailman 3 to use "References:" to keep the > original Message ID and then add a new Message ID? No, because the message from the list is not a reply to the incoming message. It is the incoming message. > I think that what Mailman 3 is doing is similar to forwarding the > email. If I forward an email, again the headers change: If you want Mailman to 'forward' the message, set DMARC mitigation action to wrap the message. >> The IETF has addressed the issue of non-identical but equivalent >> messages with the Resent-Message-ID field (and in general the whole >> suite of Resent-* fields. > > Mailman doesn't appear to be adding that header. Would that be an > acceptable solution instead of the one I suggested above? Mailman doesn't add the header, but even if it did, I doubt it would solve the problem with Gmail. > I appreciate your view that Google is broken. I'm just trying to find > an acceptable solution to the end-user perception of "I've sent an > email to the list but I haven't received a copy back". That is going > to be a big issue/headache for us. It's a long standing PITA with Google. See <https://wiki.list.org/x/4030680>. Your Gmail users can partially mitigate this by setting their Acknowledge posts option to Yes. Note also that Mailman core communicates with archivers to determine what goes in the Archived-At: header and this value is usually based on the Message-ID:. Changing the Message-ID: could possibly render that value incorrect. -- 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: Held for notification - runner exception: 'ascii' codec can't encode character

by Mark Sapiro

On 1/2/22 11:00 AM, Seth Seeger wrote: > > I have a case where a user (set to be moderated), posts a message. She got the appropriate email back saying she was being held for moderation. However, the moderator did not get the email. I found the following block in mailman.log: > > Dec 28 19:37:44 2021 (33) Uncaught runner exception: 'ascii' codec can't encode character '\u2019' in position 5: ordinal not in range(128) > Dec 28 19:37:44 2021 (33) Traceback (most recent call last): > File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 173, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 266, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/runners/incoming.py", line 79, in _dispose > process(mlist, msg, msgdata, start_chain) > File "/usr/lib/python3.8/site-packages/mailman/core/chains.py", line 79, in process > link.function(mlist, msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/chains/hold.py", line 234, in _process > text = MIMEText(expand(template, mlist, substitutions), > File "/usr/lib/python3.8/email/mime/text.py", line 42, in __init__ > self.set_payload(_text, _charset) > File "/usr/lib/python3.8/email/message.py", line 315, in set_payload > payload = payload.encode(charset.output_charset) > UnicodeEncodeError: 'ascii' codec can't encode character '\u2019' in position 5: ordinal not in range(128) > Dec 28 19:37:44 2021 (33) SHUNTING: 1640720264.0541506+b139f885caa9444586b43093a09991b7c19581e6 > > There are two owners listed, one of them is also listed as the moderator. This is redundant. Having the same user as both owner and moderator only results in possible duplicate notifications. There is no reason to have an owner also be a moderator. > "mailman version" says: GNU Mailman 3.3.4 (Tom Sawyer) We are running from Docker. I can send you the pck file offline if that would help. Please do send me the shunted .pck. what is going on is this is an English language list which has character set `ascii` and the notice for some reason has non-ascii, possbbly the Subject: or the user's display name has non-ascii. But possibly the message itself is defective. In any case, I'd like to get the shunted message to see if there's something we should fix. -- 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: Mailman3 service on mailman-3.3.4 is not getting started

by Mark Sapiro

On 6/23/21 12:24 AM, Shashikanth Komandoor wrote: > Hi team, > > I am trying to install mailman 3.3.4, the currently available > latest version at > https://docs.mailman3.org/en/latest/install/virtualenv.html on RHEL 7.5. > > As part of the installation, I am not creating any user with the > name *mailman* and instead going with the *root* user only. Along with that > I am using the directory */var/lib/mailman* as the root directory. It is a very bad idea to run Mailman as root. If there were some vulnerability that would enable an exploit to run arbitrary code, you wouldn't want that code to run as root. ... > Now, the issue is while I am trying to start the service, it > is showing the below error and the status looks like as following: > > # systemctl start mailman3 > Job for mailman3.service failed because a configured resource limit was > exceeded. See "systemctl status mailman3.service" and "journalctl -xe" for > details. > > # systemctl status mailman3 > ● mailman3.service - GNU Mailing List Manager > Loaded: loaded (/etc/systemd/system/mailman3.service; disabled; vendor > preset: disabled) > Active: failed (Result: resources) since Wed 2021-06-23 12:51:27 IST; > 1min 7s ago > Process: 16277 ExecStart=/var/lib/mailman/venv/bin/mailman start > (code=exited, status=0/SUCCESS) > > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: os.execl(*execl_args) > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: File > "/usr/lib64/python3.6/os.py", line 527, in execl > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: execv(file, args) > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: TypeError: expected str, > bytes or os.PathLike object, not NoneType > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: Starting Mailman's master > runner > Jun 23 12:51:27 psumm3.nic.in mailman[16277]: Generating MTA alias maps > Jun 23 12:51:27 psumm3.nic.in systemd[1]: PID file > /var/lib/mailman/var/master.pid not readable (yet?) after start. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: Failed to start GNU Mailing List > Manager. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: Unit mailman3.service entered > failed state. > Jun 23 12:51:27 psumm3.nic.in systemd[1]: mailman3.service failed. > > I can't understand where the issue might be. What's in Mailman's mailman.log? -- 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: django-allauth 0.59.0

by Jered Floyd

This is only required for the new "user sessions" app which doesn't appear to be exposed within Mailman. (I agree it should be added, though.) --Jered ----- On Dec 21, 2023, at 4:12 AM, Mark Sapiro mark(a)msapiro.net wrote: > On 12/20/23 7:27 PM, Jered Floyd wrote: >> >> >> FYI, django-allauth 0.59.0 was released on December 12 and incorporates the >> patches to work properly with Mailman again. > > django-allauth 0.59.0 requires django.contrib.humanize in > INSTALLED_APPS. You may need to add this in your Django settings when > upgrading django-allauth. > > > -- > 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/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to jered(a)convivian.com

2 years, 4 months

[MM3-users] Re: DMARC Mitigation Wrap

by Mark Sapiro

On 1/26/20 4:43 PM, Allan Hansen wrote: > > MM3 has the option to wrap the main message with a wrap_message. It appears, however, that MM3 is oblivious to all my attempts to include whitespace, in this case a <cr>. When the enclosed message is automatically unwrapped by the receiving client, this causes the wrap and enclosed message's From: header to butt up against each other, which is rather ugly. I tried many tricks, but none worked, such as, <cr>, SPACE+, TAB+, <BLANKLINE>, SHIFT-RETURN, two RETURNS, \r\n and UTF-8 codes. They all either got ignored or copied as entered to the output message. Here’s an example. I just want to put a divider after the wrap_message main text. > > The From address of this message has been replaced with the list > address, while the From name has 'via list' appended. Please be > careful when using 'via list' addresses later for new emails, as they > will be sent to the whole list.\r\n -------------------------- > ----------------------------------------------------------------------\r\n > From: Allan Hansen <allan_hansen(a)icloud.com <mailto:allan_hansen@icloud.com>> > Subject: [Testlist] wrap with divider and BLANKLINE > > Which coding option am I missing? I have searched for one online. I assume you are entering your text in Postorius in the DMARC wrapped message text box. There are a number of things going on here. Postorius is wrapping and filling the text and stripping trailing whitespace. If you want more whitespace, I suggest following your text with one or more empty lines and a single dot as in The From address of this message has been replaced with the list address, while the From name has 'via list' appended. Please be careful when using 'via list' addresses later for new emails, as they will be sent to the whole list. ------------------------------------------------------------------- . In the above, the blank lines before and after the line of dashes will be preserved as will the final dot which should be unobtrusive enough. More importantly, the rendering of the received message is up to your mail client. Your's apparently begins the wrapped message immediately after the wrapper's text, but many will not do that. Unless you actually view the received message in every mail client used by your user's, you won't know what they actually see. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 3 months

[MM3-users] Re: templates

by Mark Sapiro

On 5/5/23 17:04, Christian via Mailman-users wrote: >>From bounce.log > > May 05 07:59:00 2023 (765) Member juliankrauspolk(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 07:59:00 2023 (765) Member juliankrauspolk(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:01:00 2023 (765) Member baronchadg(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 08:01:00 2023 (765) Member baronchadg(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:11:01 2023 (765) Member vortexanthony(a)hotmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 1. > May 05 08:13:01 2023 (765) Member alaitz.aritza(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score = 5. > May 05 08:13:01 2023 (765) Member alaitz.aritza(a)gmail.com on list > degrowcali.lists.ccalternatives.org, bounce score 5 >= threshold 5, sending > probe. > May 05 08:15:01 2023 (765) Probe bounce received for member > juliankrauspolk(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:01 2023 (765) Disabling delivery for juliankrauspolk(a)gmail.com > on list degrowcali.lists.ccalternatives.org by bounce > May 05 08:15:02 2023 (765) Probe bounce received for member > alaitz.aritza(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:02 2023 (765) Disabling delivery for alaitz.aritza(a)gmail.com on > list degrowcali.lists.ccalternatives.org by bounce > May 05 08:15:02 2023 (765) Probe bounce received for member > baronchadg(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:15:02 2023 (765) Disabling delivery for baronchadg(a)gmail.com on > list degrowcali.lists.ccalternatives.org by bounce > May 05 08:17:02 2023 (765) Residual bounce received for member > juliankrauspolk(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:17:02 2023 (765) Residual bounce received for member > alaitz.aritza(a)gmail.com on list degrowcali.lists.ccalternatives.org. > May 05 08:17:02 2023 (765) Residual bounce received for member > baronchadg(a)gmail.com on list degrowcali.lists.ccalternatives.org. So some of your user's, but not 24, are bouncing. If your list's bounce processing settings have Notify owner on disable = Yes, the owner should receive a notice including the DSN. If Notify owner on bounce increment = Yes, the owner will also get notices when a user's score is incremented as for vortexanthony(a)hotmail.com above. This still doesn't answer the other users. Have you looked at the MTA logs? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years

[MM3-users] Re: import21 caused a few mails to be sent out

by Mark Sapiro

On 6/2/24 7:57 AM, Marc SCHAEFER wrote: > Hello, > > After importing a (big > 3000 subscribers) list with import21, I noticed the > following: > > 36 mails went out from LIST-NAME-bounces to subscribers, but they > apparently all bounced. > > Could those be subscribers that Mailman2 saw bouncing and added > the appropriate flag, and Mailman3 sent a probe after the import21? These are probably not probes. They are probably Bounce disable warnings. > I checked for one of the e-mail address and: > > Mailman2: > - that e-mail has the [X] R flag for "noncourriel" (no delivery) > > Mailman3: > - that e-mail is Delivery mode Regular, Bounces to 0 import21 will set an imported members delivery_status to the corresponding MM 2.1 delivery_status. If an imported member's 2.1 delivery status is nomail with reason unknown, by_user, by_moderator or by bounces (in French these are ?, U, A, R respectively), the MM 3 delivery_status will be set accordingly. This is not Delivery Mode, it is Delivery status which is not shown on the membership list, but only by clicking the user's email in the membership list. > NB: in MM2 and MM3, all users are in Hold for moderation, that's > normal. > > In addition, there are a few mails in /var/lib/mailman/messages > for example that same user: one file, showing a bounce from a remote > server. > > So my questions: > > 1) is this behaviour to "probe" already disabled addresses normal, and > not "port over" the "don't deliver"? No, if a MM 2.1 user's delivery was disabled, it will be imported as such. > 2) why are those messages held in messages/ ? Bounce DSNs are saved in the message store (/var/lib/mailman/messages) so they can be attached to admin notifications. > 3) should I then, before running import21, clean the MM2 installation > of all those users with [X] R flag? If yes, is there > a simple command? That should not be necessary. MM 2.1 users with nomail "R" (in French) should be imported with delivery_status = DeliveryStatus.by_bounces and they should not be sent mail except for the periodic Bounce disable warnings which is probably what you are seeing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

Search results for query "sapiro"