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

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

3 weeks, 2 days

[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/ >

5 years, 3 months

[MM3-users] Re: Active archivers and archiving and thread question.

by Mark Sapiro

On 3/30/22 11:21, bob B via Mailman-users wrote: > Digging into the mailman3 world, and want to check my logic... > > We normally don't use archives, so I have "archive policy" set to "Do not archive this list" for our lists. However, the "archives" button is still there on the list info page, and if users go into it, they don't see anything, But they can click "start a new thread" which sends a message to the list, but since archiving is turned off, that message does not show up there. > Am I understanding that correctly? > > if I have "Active archivers" disabled, that hides that area from the users, correct? You need to have hyperkitty unchecked in Active archivers to prevent the Archive button from appearing on the info page. Archive policy = Do not archive this list will prevent HyperKitty from creating an archive for that list. If there is one at, e.g., https://example.com/archives/list/list@example.com/ you can delete it and Archive policy = Do not archive this list will keep it from being recreated. > Any reason why these are separated? why have an active archiver, if archiving is turned off -OR- archives are turned on, but no active archiver? They probably shouldn't be completely independent. If Archive policy = Do not archive this list, that should probably deactivate any Active archivers for the list, but arguably, one might want to temporarily stop archiving and then restart it without having to remember which archivers were active. At a minimum, setting Archive policy = Do not archive this list should probably remove the Archive button from the info page. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

[MM3-users] Re: Emails about moderation are sent to list owners, want them sent to moderators instead

by Mark Sapiro

On 7/2/22 1:56 AM, Elias Rudberg wrote: > Hello, > > This is about GNU Mailman 3.3.3 (Tom Sawyer). > > For each list there are both "owners" and "moderators". As I understand > it, the idea is that owners have the power to change configuration for > the list, while moderators have more limited power, they can only > moderate but not change configuration. Correct. > When an email is sent from a non-member to a list that requires > moderation in such a case, an email with subject like "[listname] post > from [sender] requires approval" is sent to the list owners. I would > like those emails to be sent to moderators instead. Such notices are actually sent to the LISTNAME-owner@... address, received by Mailman and resent to all the owners and moderators. Both owners and moderators should receive the message. > The reason why I want it to work that way is that list owners sometimes > want to delegate the work of moderating to the moderators. List owners > then want to keep the power to change list configuration, but they do > not want to be bothered by individual moderation emails. > > Is there a way to configure mailman3 to make it send moderation emails > to moderators instead of owners? As I said, the notices are sent to both owners and moderators. There is no simple configuration to change this. Change would require modifying mailman/handlers/owner_recipients.py or possibly defining a sub-class of mailman.pipelines.OwnerPipeline which overrides the _default_handlers method and arranging for that to be used. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 2 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

4 years, 10 months

[MM3-users] Re: Filter who can send on mailman3 list?

by Mark Sapiro

On 4/5/21 6:43 AM, marcus.granath(a)gmail.com wrote: > > So what I basically try do achieve is to have only the following addresses to be allowed to send announcements (e-mails) on the mailman3 list, and all others that are member of the mailman3 list will just receive the e-mails. The usual "announcements" are sent out as the "no-reply" address (that actually are not really part of the mailman3 list) ;-) > > no-reply(a)abc.com ("fake address" that actually are not really part of the mailing-list) > peter(a)abc.com > david(a)abc.com > marcus(a)abc.com > > How to achieve this kind of filter with mailman3? Header filters is not the way to do this. First set both "Default action to take when a non-member posts to thelist" and "Default action to take when a member posts to the list" to either Hold for moderation or Discard (no notification). Reject is not recommended because of backscatter from spam posts with spoofed From: addresses. Then ensure all members Moderation Action is set to None or List Default (two names for the same thing). Now, no one can post. To allow your set of users to post, you have choices. The easy way but not secure against spoofing is to set the Maderation Action for the three allowed members to List Default and toi create a non-member for no-reply(a)abc.com and set it's moderation action to List Default. The more secure way is to leave everyone moderated, set a moderator password for the list and post with an Approved: header or pseudo header. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/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, 5 months

[MM3-users] Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/27/22 01:23, Odhiambo Washington wrote: > > I have actually deactivated mine, and life is still good with my MM3. > > And just so that my mind is in the clear, there are three ways of getting > the full MM3 functionality, viz: > 1. Mailman core, Django's cluster, and Gunicorn > 2. Mailman core, Django's cluster, and uWSGI > 3. Mailman core, Django's cluster, and mod_wsgi Yes, and possibly there are other WSGI interfaces, but offhand I don't know. > And something that has not been quite clear to me: What is the purpose of > Django's cluster in all this? django_q <https://django-q.readthedocs.io/en/latest/> is an app for Django that can process tasks asynchronously in the background so they don't block the foreground. qcluster manages those tasks. > I am asking because on my FreeBSD server, I usually see not less than 30 > PIDs for: > > /opt/mailman/mm/venv/bin/python3 /opt/mailman/mm/venv/bin/django-admin > qcluster --pythonpath /opt/mailman/mm/ --settings settings (python3.9) > > And there is a time I found it having 240 PIDs. > Would there be a problem if I limit the number of workers to "8"? Some of those may be orphaned. On servers I manage, I regularly stop all mailman3 services to install updates and on one of these servers (only mail.python.org) where there are resource issues, when the services are stopped, there are still orphaned qcluster processes. I have this ``` #! /bin/bash if status qcluster | grep -q 'running' ; then echo qcluster is running exit fi ps -fwwu mailman|grep '[a]dmin qcluster'|awk '{print $2}'|xargs kill ``` to get rid of the orphans -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

[MM3-users] Re: GDPR - save subscriptions confirmation emails

by Mark Sapiro

On 06/03/2018 12:34 PM, contact(a)maadix.net wrote: > Thanks Selva for you answer. > > In my Mailman 3 installation there is no /var/log/mailman/subscribe Correct. Mailman 2.1 had a subscribe log. Mailman 3 does not. Many things are logged in the 'mailman' log, but subscription confirmations are not. > I have logs about confirmations emails in > mailman/var/logs/smtp.log > > the format is the following: > > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) handling connection > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'LHLO > mails.example.com' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'MAIL > FROM:<contact(a)maadix.net>' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) sender: > contact(a)example.net > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'RCPT > TO:<prueba-confirm+7c010b0d89513b26d72cb4642e80447a2280ac86(a)list.example.org>' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) recip: > prueba-confirm+7c010b0d89513b26d72cb4642e80447a2280ac86(a)list.example.org > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'DATA' > Jun 03 13:45:27 2018 (20764) ('127.0.0.1', 40145) Data: b'QUIT' > > So, one solution that comes to my mind is to grep this log file. > > This is not a perfect solution and the full confirmation email is still > missing. > > I am not sure if this would be GDPR compliant. Also, while I don't think it is currently possible to confirm a subscription via REST, not to mention Postorius, it may be in the future and this would bypass email all together. I think the best thing is to implement logging. Of course, you might be able to get your MTA to save all mail to the LIST-confirm address to a separate mailbox in addition to delivering it to Mailman. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 3 months

[MM3-users] Re: What to backup?

by Mark Sapiro

On 5/26/19 12:17 PM, Alain Kohli wrote: > Thanks for the great explanation, that helped a lot! I'll try to work on > that issue if I find some time. In the meantime it would be neat to try > to clean up the old messages right before the backup. How can you > distinguish messages that have been moderated already? I couldn't really > find that in the database or the models. You could run the following in `mailman shell` $ /path/to/mailman shell Welcome to the GNU Mailman shell >>> lm = getUtility(IListManager) >>> ms = getUtility(IMessageStore) >>> for mlist in lm.mailing_lists: ... requestdb = IListRequests(mlist) ... for rq in requestdb.held_requests: ... key, msgdata = requestdb.get_request(rq.id) ... if msgdata['_request_type'] != 'held_message': ... continue ... msg = ms.get_message_by_id(key) ... print(msg['Message-ID-Hash']) ... U6QVO2GXMEQ5ZDQR2XCLDOH2FXPKJTWX 32HA6GKYE5FOVORLER7YAC3264BHG264 JM4NP3JRXBKKAL7UMM5XEXX644DQBAFJ L7FX6XKOOBP3YFFXUHA6EEJCQXX5BCHX DOJX55MRY6OYPZ4XFFTAQDD4I5MWJ3AD >>> What that prints is the names of all the files in the var/messages/ hierarchy which are currently held messages. Presumably the others are ones already handled. You could modify the above to write the list to a file and then wrap the whole thing in a shell script which would make the list and then do something like for f in `find var/messages -type f`;do n=`cut -d / -f5 <<<$f` for keep in `cat list` ;do k=0 if [ $n == $keep ] ;then k=1 break fi done if [ $k -eq 0 ]; then rm $f fi done in the above, list is the list of names to keep bade by the first script and -f5 in the cut command assumes the list from find is lines of the form var/messages/TJ/YF/TJYF5FETCRLOQZJ2H6Y4PMZP6M7GNLES. i.e. two subdirectories between messages/ and the file. -- 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

Search results for query "sapiro"