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

[MM3-users] Re: Huge performance issue: Mailman doesn't (seem to) receive any mails.

by Mark Sapiro

On 9/20/19 1:54 AM, Henrik Rasmussen wrote: > Mark Sapiro wrote: >> What other log entries relate to attempts to send to 172.19.199.2:8024? >> You may have to go back to when this first started to see them. > > Docker deleted it's log when restaring, as the container is deleted and removed, but the starte of the current log says: > ``` > Sep 18 13:28:57 postfix rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="20" x-info="http://www.rsyslog.com"] start > Sep 18 13:29:00 postfix postfix/postfix-script[94]: starting the Postfix mail system > Sep 18 13:29:00 postfix postfix/master[96]: daemon started -- version 2.10.1, configuration /etc/postfix > Sep 18 13:29:02 postfix postfix/smtpd[102]: connect from incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:04 postfix postfix/smtpd[102]: EFF017E9D65AE: client=incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:04 postfix postfix/cleanup[106]: EFF017E9D65AE: message-id=<2E40950170CA0A4A8D0F0C0CF1C0630601B8B9F412(a)P1KITMBX03WC02.unicph.domain> > Sep 18 13:29:04 postfix opendkim[19]: EFF017E9D65AE: incoming.gateway.example.com [192.168.111.222] not internal > Sep 18 13:29:04 postfix opendkim[19]: EFF017E9D65AE: not authenticated > Sep 18 13:29:04 postfix postfix/smtpd[102]: disconnect from incoming.gateway.example.com[192.168.111.222] > Sep 18 13:29:18 postfix postfix/qmgr[98]: 0E53F7E9D7D8D: from=<>, size=212010, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: C51DE7E9920B8: from=<>, size=212004, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 2923A7E99B41F: from=<>, size=212040, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: D0A1E7E981E26: from=<quarantine(a)messaging.microsoft.com>, size=14542, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 95FA77E9815A5: from=<>, size=211977, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 208777E993635: from=<sender(a)example.com>, size=9826184, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 757C27E9BD45C: from=<>, size=211997, nrcpt=1 (queue active) > Sep 18 13:29:18 postfix postfix/qmgr[98]: 738C87E9B94BE: from=<>, size=212141, nrcpt=1 (queue active) > [SLIP] > Sep 18 13:32:24 postfix postfix/anvil[103]: statistics: max cache size 1 at Sep 18 13:29:02 > Sep 18 13:43:48 postfix postfix/smtpd[992]: connect from gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/smtpd[992]: 9E0D37E9D65AF: client=gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/cleanup[996]: 9E0D37E9D65AF: message-id=<3e08121bcdf5b0ebeb779a26ab2fe6ef(a)mailing.einnews.com> > Sep 18 13:43:48 postfix opendkim[19]: 9E0D37E9D65AF: DKIM-Signature field added (s=default, d=sendergateway.example.com) > Sep 18 13:43:48 postfix postfix/smtpd[992]: disconnect from gateway[172.19.199.1] > Sep 18 13:43:48 postfix postfix/qmgr[98]: 9E0D37E9D65AF: from=<sender(a)example.com>, size=59393, nrcpt=1 (queue active) > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: mail for [172.19.199.2]:8024 is using up 7863 of 7863 active queue entries > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to reduce lmtp connect and helo timeouts > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: so that Postfix quickly skips unavailable hosts > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to increase the main.cf minimal_backoff_time and maximal_backoff_time > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: so that Postfix wastes less time on undeliverable mail > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: you may need to increase the master.cf lmtp process limit > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: please avoid flushing the whole queue when you have > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: lots of deferred mail, that is bad for performance > Sep 18 13:43:48 postfix postfix/qmgr[98]: warning: to turn off these warnings specify: qmgr_clog_warn_time = 0 So we see that Postfix is trying to send 9E0D37E9D65AF, but the subsequent log entries are only the "warning: mail for [172.19.199.2]:8024 is using up 7863 of 7863 active queue entries" ones. If this happens again, look in the log before restarting the container for connection refused, lost or timed out types of entries. You verified that Postfix could connect and receive the greeting from Mailman's LMTP runner, but that was after the queue was full. Maybe when it started and the queue filled up, this wasn't the case, but then if Postfix can connect, the queue should eventually drain. -- 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: Migration failure (2.1.29 to 3.3.8 on Debian testing)

by Mark Sapiro

On 6/7/23 11:58, {16/7} wrote: > > I have both the mailman and mailman3-full packages installed on my machine and I'm following the migration guide located here: https://docs.mailman3.org/en/latest/migration.html Which is the source of at least one of your issues. The Debian packages are behind and are missing multiple bug fixes and enhancements. > Running the command { mailman import21 mylist(a)mysite.com /var/lib/mailman/lists/mylist/config.pck } completes once I create the list but states that it cannot convert the msg_footer and digest_footer mailing list attributes. (I might also point out that the { mailman create mylist(a)mysite.com } command isn't actually documented on that webpage.) import21 tries to make Mailman 3 compatible versions of your Mailman 2.1 msg_footer and digest_footer. It will put these in Mailman's var/templates/lists/<list-id>/<lc>/ directory as list:member:regular:footer.txt and list:member:digest:footer.txt respectively. You need to examine those files as they probably contain Mailman 2.1 style replacements that haven't been converted. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… for the Mailman 3 replacements which are encoded as dollar strings, e.g. $listname gets replaced with the list's posting address. > I can't seem to find the manage.py script in my $PATH and after searching, I find it as part of the mailman3-web package. As you report in a followup, in the Debian package it's called mailman-web > Next, I changed the file's group back to list and decided to try running the manage.py script as the www-data user. This results in "/usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and timeout are misconfigured." and "System check identified some issues:" followed by a list of "Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'" warnings for a number of Django tables. Recent mailman installed following https://docs.mailman3.org/en/latest/install/virtualenv.html will include ``` DEFAULT_AUTO_FIELD = 'django.db.models.AutoField' ``` in Django's settings which will avoid that warning with Django>=3.2 > > My questions are: > > 1. How do I undo any damage (if any) my efforts may have caused? You probably didn't do any damage as the commands failed before doing anything. > 2. What's the correct way to run manage.py? I see from your follow up that you figured this out. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

[MM3-users] Re: re-injecting emails that were not archived

by Mark Sapiro

On 6/25/23 11:47 AM, Ken Alker wrote: > > I noticed when I came onto the project last week that there were 140 > messages stuck in the "shunt" queue for the two lists hosted by this > server (I have no idea why and the old logs were not available and I > don't recall the results of "mailman qfile", assuming that had shed some > light on the reason why they were shunted). In any event, I unshunted > these messages and they flowed out to the subscriber's email addresses > successfully. What I was not expecting is that the system did not > inject any of these emails into the archive. AFAICT, the messages are > no longer anywhere on the system (but I could be mistaken). Here are my > questions: > > 1) Why would these emails not have been injected into the archive? The message may have been shunted from by the `out` runner, in which case unshunting would only cause them to be processed again by the 'out' runner. Archiving is a separate queue and process. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/archi… for an overview of the message handling process. The bottom line here is if a message was shunted by the 'out' runner only, it should have been archived at the original post time. Were these messages already archived? If not, depending on list settings there may be HyperKitty archiving iossues in which case they may by queued in Mailman's var/archives/hyperkitty/spool/. directory, but if they are, there would be errors in mailman.log from regular attempts to process them. Also they may be found in var/archives/prototype/<list>/new/ directory. > 2) Is there some way for me to re-inject these messages into the two > lists? The only place I (THINK I) have them is in my own personal IMAP > box since I'm a subscriber to the lists. You can inject them into the archive queue with `mailman inject`. See `mailman inject --help`. Before doing this, be sure it's necessary, i.e. they're not already archived, although HyperKitty won't accept a message whose Message-ID: is already in the archive. > 3) Can this be done without the emails being re-delivered to subscribers? As long as you inject them into the `archive` queue queue only, they won't be resent to the list members. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: Reason for Shunting (SOLVED)

by Brian Carpenter

On 2/9/21 6:37 PM, Mark Sapiro wrote: > On 2/9/21 2:57 PM, Brian Carpenter wrote: >> On 2/9/21 5:25 PM, Mark Sapiro wrote: >>> On 2/9/21 2:03 PM, Brian Carpenter wrote: >>>> Is there a way to determine why a message keeps ending up in the shunt >>>> queue? >>>> >>> Look in mailman.log for the `SHUNTING` message and the traceback that >>> immediately preceeds it. >> >> Thanks Mark. The reason was: >> >> Feb 09 16:40:11 2021 (2614) Uncaught runner exception: Multiple rows >> were found for one_or_none() >> >> sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for >> one_or_none() >> >> Feb 09 16:40:11 2021 (2614) SHUNTING: >> 1612906811.2642436+cd8e97a66b6d0c2b73c2adde71a4914108c3e673 >> >> I have no idea what that means. > > See > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> > and <https://gitlab.com/mailman/mailman/-/issues/657> > Thanks Mark, that fixed it. In my case the list had duplicate entries for all 4 archivers in the Mailman database. -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 8 months

[MM3-users] Re: ValueError: The ADMINS setting must be a list of 2-tuples.

by David Partain

Hi Mark, Helpful, as always. Thank you. And do I feel silly. That was pretty darned obvious. In any case, it's fixed. Cheers, David ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Thursday, March 21, 2024 01:46 To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: ValueError: The ADMINS setting must be a list of 2-tuples. On 3/20/24 13:23, David Partain via Mailman-users wrote: > raise ValueError("The ADMINS setting must be a list of 2-tuples.") > ValueError: The ADMINS setting must be a list of 2-tuples. > > Our ADMINS setting in /etc/mailman3/settings.py has > > ADMINS = ( > ('Mailman Suite Admin', 'someone(a)our.domain', 'someoneelse(a)our.domain'), > ) > > Can someone point me in a direction to correct this? 2-tuples, not triples. E.g. ADMINS = ( ('Mailman Suite Admin1', 'someone(a)our.domain'), ('Mailman Suite Admin2', 'someoneelse(a)our.domain'), ) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[MM3-users] Re: serving /static-content within /mailman3-web-Folder - change in recent mm release

by Stefan Bauer

thank you Mark, that did the trick :) Am Do., 29. Sept. 2022 um 18:33 Uhr schrieb Mark Sapiro <mark(a)msapiro.net>: > On 9/29/22 06:50, Stefan Bauer wrote: > > Hi Folks, > > > > during our migration to latest MM we noticed, that nowadays, the static > > content is not served from within mailmans base directory, but from > outside. > > > > old MM3: > > > > domain.tld/mailman3/static/django-mailman3/js/main.js > > > > new MM3: > > > > domain.tld/static/django-mailman3/js/main.js > > > > Is there a chance to change it to the old behavior? > > > See the Django settings STATIC_ROOT and STATIC_URL. > > > -- > 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/ >

4 years

[MM3-users] Re: Replies

by Mark Sapiro

On 3/17/22 20:47, Matthew R via Mailman-users wrote: > Hi everyone, we're going to be using a Mailman3 list for the purpose of > providing email support. So: > > * Anyone can post to the list > * Agents will reply to the poster to receive support, and the reply > must go back to the original poster (the client) and the mailing list for > other agents to see > * The poster's replies will be sent to the mailing list (so other > agents can see) as well as to the agent who initially replied to the initial > posting > > > > Is there any way to accomplish this? Right now, if the agent replies to the > client's email correctly but the client doesn't hit "Reply All" the email is > only sent to the agent that initially took the "case" and the other agents > aren't aware that there was a response. This is an intractable problem. Ideally, you would be able to configure the list to ensure all mail is sent with a Reply-To: that includes the original From: and the list address, but there is no list configuration that guarantees that. It wouldn't be difficult to patch mailman to do it for a particular list. You could almost get there if all the posts to the list included a Reply-To: In this case setting Reply goes to list to the list and First strip reply to to No, but you can't even hope that all incoming posts include a reply to. But, even if they don't, this may work. I.e., setting Reply goes to list to the list will set a Reply-To: with the list address in all delivered posts. The agent can do Reply-All: and hopefully, this goes to the From: and to the Reply-To. Then the client gets the reply with a Reply-To: to the list and hopefully, the client's reply goes back to the list. I say `hopefully` twice above because if there's a Reply-To; it is not a guarantee with all MUAs that Reply-All will include the From:, and at the client's end, even with a Reply-To: to the list, there's no guarantee the client's MUA will honor that. I say it's an intractable problem because what ever the list does, it relies on the user's MUA to do the right thing, and unfortunately, not all do. -- 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: Mailman-web showing "An error occurred while processing your request."

by Mark Sapiro

On 2/8/23 08:34, C. Souza wrote: > I'm trying to manage 2 held messages in a specific list and I'm getting > this error below when I click on /held_messages. It never happened before. ... > ==> mailmanweb.log <== > ERROR 2023-02-08 16:01:30,149 1516 django.request Internal Server Error: > /mailman3/lists/mylist.domain.com/held_messages > Traceback (most recent call last): ... > File > "/opt/mailman/venv/lib64/python3.6/site-packages/django/utils/dateparse.py", > line 107, in parse_datetime > match = datetime_re.match(value) > TypeError: expected string or bytes-like object I'm not certain, but it looks like one of the held messages has a bad or possibly missing Date: header. Working around this is tricky. You can do the following in mailman shell. ``` $ mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list >>> requests = IListRequests(m) >>> msgstor = getUtility(IMessageStore) >>> for request in requests.held_requests: ... key, data = requests.get_request(request.id) ... if data['_request_type'] == 'held_message': ... print(f'request ID = {request.id}Message-ID = {key}\n ' ... f'message = {msgstor.get_message_by_id(key)}') ... This will print for each held message output like request ID = nnn Message-ID = <the message id> message = the message content You can then handle these messages with >>> from mailman.app.moderator import handle_message >>> handle_message(m, nnn, action) where nnn is the request ID and action is either Action.discard to discard the message or Action.accept to accept it. And finally >>> commit() ``` If you decide you want to edit the message content before accepting it, you could find the message in the file system. One of the headers in the displayed message is something like Message-ID-Hash: IWL2EUW3FT7IIUA3QYTZEX4W4JBZ26HL the message is saved as a python pickle in the file system in Mailman's var/messages/ directory. This has subdirectories of the first two characters of the Message-ID-Hash value and those have subdirectories of the second two characters of the Message-ID-Hash value, so if the above were the actual Message-ID-Hash the pickle would be at var/messages/IW/L2/IWL2EUW3FT7IIUA3QYTZEX4W4JBZ26HL. You would need to pickle the new message content and save that over the existing file. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

Ok, should I install the SASL authentication daemon saslauthd and start it? El mar., 25 jul. 2017 a las 15:40, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/25/2017 01:19 PM, Rafael Mora wrote: > > What should I do to tell Postfix to use my domain?? for example send > emails > > using the email account mailing(a)labbrands.com > > > If what you're asking is how to configure Postfix to relay all outbound > mail via some other email server, that is a Postfix configuration question. > > If I thought I could give you a simple answer and that would be the end > of it, I'd try, but in your case every answer leads to another question, > so I suggest you start here to learn about configuring Postfix > <http://www.postfix.org/documentation.html>. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

9 years, 2 months

[MM3-users] Re: Upgrade

by Darren Smith

And as usual, Mark to the rescue. Works like a charm...thank you! By the way, whose idea was it to use Rush songs for the release names? I whole-heartedly approve. -Darren On Mon, Apr 16, 2018 at 11:52 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 04/16/2018 10:26 AM, Darren Smith wrote: > > Nice...spoke too soon. > > > > Mailman info works, but when attempting to start mailman I'm now getting > > this: > ... > > RuntimeError: Click will abort further execution because Python 3 was > > configured to use ASCII as encoding for the environment. Consult > > http://click.pocoo.org/python3/for mitigation steps. > > > Are you starting Mailman from an init script. If so, add > > export LANG=en_US.UTF-8 > > to the script. See > <http://mailman.readthedocs.io/en/latest/src/mailman/docs/ > install.html#running-mailman-3> > > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

8 years, 6 months

Search results for query "sapiro"