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

[MM3-users] Re: psycopg2 error?

by Odhiambo Washington

On Fri, Oct 27, 2023 at 8:21 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 10/27/23 09:16, Odhiambo Washington wrote: > > (venv) mailman@debian12:~$ pip cache remove psycopg2-binary > > WARNING: No matching packages for pattern "psycopg2-binary" > > Files removed: 0 > > This was intended to prevent the following 'Using cached'. > > > > (venv) mailman@debian12:~$ pip install psycopg2-binary > > Collecting psycopg2-binary > > Using cached > > > psycopg2_binary-2.9.9-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl > > (3.0 MB) > > > However, you now have a different issue. > > > > raise DistributionNotFound(req, requirers) > > pkg_resources.DistributionNotFound: The 'flufl.lock>=5.1' distribution > was > > not found and is required by mailman > > See https://gitlab.com/mailman/mailman/-/issues/1085 Thank you. That solves the problem for sure! But this was detected 4 months ago. When is the permanent solution coming? (venv) mailman@debian12:~$ vi venv/lib/python3.11/site-packages/mailman-3.3.9.egg-info/requires.txt # flufl.xxx to flufl-xxx (venv) mailman@debian12:~$ mailman info GNU Mailman 3.3.9 (Tom Sawyer) Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] config file: /etc/mailman3/mailman.cfg db url: postgresql://mailman:XXXXXXX@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass (venv) mailman@debian12:~$ exit logout root@debian12:/home/wash# systemctl start mailman3 root@debian12:/home/wash# systemctl status mailman3 ● mailman3.service - GNU Mailing List Manager Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; preset: enabled) Active: active (running) since Sat 2023-10-28 01:22:56 EAT; 7s ago Process: 15590 ExecStart=/opt/mailman/venv/bin/mailman start (code=exited, status=0/SUCCESS) Main PID: 15592 (python3) Tasks: 17 (limit: 4547) Memory: 980.8M CPU: 27.774s CGroup: /system.slice/mailman3.service ├─15592 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/master -C /etc/mailman3/mailman.cfg ├─15598 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=archive:0:1 ├─15599 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=bounces:0:1 ├─15600 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=command:0:1 ├─15601 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=in:0:1 ├─15602 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=lmtp:0:1 ├─15603 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=nntp:0:1 ├─15604 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=out:0:1 ├─15605 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=pipeline:0:1 ├─15606 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 ├─15607 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=retry:0:1 ├─15608 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=task:0:1 ├─15609 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=virgin:0:1 ├─15610 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=digest:0:1 ├─15648 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 └─15649 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 Oct 28 01:22:54 debian12.wash.lan systemd[1]: Starting mailman3.service - GNU Mailing List Manager... Oct 28 01:22:55 debian12.wash.lan mailman[15590]: Starting Mailman's master runner Oct 28 01:22:55 debian12.wash.lan mailman[15590]: Generating MTA alias maps Oct 28 01:22:56 debian12.wash.lan systemd[1]: mailman3.service: Can't open PID file /opt/mailman/mm/var/master.pid (yet?) after start: No such file or directory Oct 28 01:22:56 debian12.wash.lan systemd[1]: Started mailman3.service - GNU Mailing List Manager. root@debian12:/home/wash# -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

2 years, 6 months

[MM3-users] Re: Different Mail Domain Cause Key Error

by Brian Carpenter

On 4/21/20 4:04 PM, Mark Sapiro wrote: > This is not the error. The KeyError ... 'file' exception is a Django > logging exception. It is not the underlying error. There should be more > in the log indicating what the real problem is. Ok. The first thing however is did I miss a step? Here is the complete error that is sent to me via email as superuser: Internal Server Error:/mailman3/lists/ KeyError at/mailman3/lists/ 'file' Traceback: File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/exception.py" in inner 34. response = get_response(request) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/base.py" in _get_response 115. response = self.process_exception_by_middleware(e, request) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/base.py" in _get_response 113. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/views/list.py" in list_index 755. paginator_class=MailmanPaginator) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django_mailman3/lib/paginator.py" in paginate 71. objects = paginator.page(page_num) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django_mailman3/lib/paginator.py" in page 46. number = self.validate_number(number) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/paginator.py" in validate_number 48. if number > self.num_pages: File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/utils/functional.py" in __get__ 80. res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/paginator.py" in num_pages 97. if self.count == 0 and not self.allow_empty_first_page: File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/utils/functional.py" in __get__ 80. res = instance.__dict__[self.name] = self.func(instance) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django_mailman3/lib/paginator.py" in count 56. return self.function(count=0, page=1).total_size File "/opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/views/list.py" in _get_list_page 751. advertised=advertised, mail_host=mail_host, count=count, page=page) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/client.py" in get_list_page 181. return Page(self._connection, url, MailingList, count, page) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/page.py" in __init__ 37. self._create_page() File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/page.py" in _create_page 62. response, content = self._connection.call(self._build_url()) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailmanclient/restbase/connection.py" in call 112. error_msg, response, None) *During handling of the above exception (HTTP Error 404: {"title": "404 Not Found"}), another exception occurred:* File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/exception.py" in inner 34. response = get_response(request) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/postorius/middleware.py" in __call__ 42. return self.get_response(request) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/exception.py" in inner 36. response = response_for_exception(request, exc) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/core/handlers/exception.py" in response_for_exception 95. exc_info=sys.exc_info(), File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/utils/log.py" in log_response 228. exc_info=exc_info, File "/usr/lib/python3.7/logging/__init__.py" in error 1412. self._log(ERROR, msg, args, **kwargs) File "/usr/lib/python3.7/logging/__init__.py" in _log 1519. self.handle(record) File "/usr/lib/python3.7/logging/__init__.py" in handle 1529. self.callHandlers(record) File "/usr/lib/python3.7/logging/__init__.py" in callHandlers 1591. hdlr.handle(record) File "/usr/lib/python3.7/logging/__init__.py" in handle 905. self.emit(record) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/utils/log.py" in emit 119. reporter = ExceptionReporter(request, is_email=True, *exc_info) File "/opt/mailman/mm/venv/lib/python3.7/site-packages/django/views/debug.py" in __init__ 254. self.template_info = getattr(self.exc_value, 'template_debug', None) File "/usr/lib/python3.7/tempfile.py" in __getattr__ 614. file = self.__dict__['file'] Exception Type: KeyError at/mailman3/lists/ Exception Value: 'file' Request information: USER: AnonymousUser -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

6 years

[MM3-users] [SOLVED] Re: Re: Newbie question 2: Rewriting issue for bounced emails

by William Oliver

On Mon, 2021-12-27 at 14:36 -0800, Mark Sapiro wrote: > > It appears that the MX for billoblog.com is not accepting mail from > your > server. Can you send non-mailman mail from this server to this address? > If not, you need to contact billoblog.com to fin wht they are blocking > your mail. > > > I tried changing the smtp port in mailman.cfg to 587, but that didn't > > change anything. > > because the issue is not in delivery from Mailman to Postfix. It is in > delivery from Postfix to billoblog.com. First, thanks so much for talking me through this. I could never have done it on my own. If you ever decide to go to the Smoky Mountain National Park or Knoxville, TN, send me an email, and I'll buy you a drink (I live in the hills between Knoxville and Gatlinburg, TN). In any case, I did some wandering around the intertubes and it appears this is an uncommon but well-known problem when using dovecot and postfix. It has to do with the setting of smtpd_recipient_restrictions in master.cf. It's not clear *which* "reject" command is triggered, but if I set it to just: -o smtpd_recipient_restrictions=permit_sasl_authenticated then it can get through. Er, to the next error, anyway. Sigh. I have *no* idea why it only shows up with mailman, but not with regular mail. I got some learnin' to do about that line. I don't know what the default reject criteria are. I have this horrible suspicion that I've opened myself up to zillions of evil emails, but I'll investigate that later. So, this took care of the Access Denied issue. That opened up the next error, which was "relay access denied". Again, regular mail worked just fine. Here's the syslog when I sent email to testlist from fp145(a)libertyfp.org: Here's the rejection to billo(a)billoblog.com: Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: connect from mail.libertyfp.org[2.56.57.28] Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: NOQUEUE: reject: RCPT from mail.libertyfp.org[2.56.57.28]: 454 4.7.1 <billo(a)billoblog.com>: Relay access denied; from=<testlist-bounces+billo=billoblog.com(a)libertyfp.org> to=<billo(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org> Dec 27 18:31:52 libertyfp postfix/submission/smtpd[471207]: disconnect from mail.libertyfp.org[2.56.57.28] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 But it accepts the email to fp145(a)libertyfp.org Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: connect from mail.libertyfp.org[2.56.57.28] Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: 4FCDD420F5: client=mail.libertyfp.org[2.56.57.28] Dec 27 18:31:53 libertyfp postfix/cleanup[471223]: 4FCDD420F5: message- id=<8d3bf47c5dcd86983e8c01f8baece4e3ac43a1a1.camel(a)libertyfp.org> Dec 27 18:31:53 libertyfp postfix/cleanup[471223]: 4FCDD420F5: warning: header Subject: [Testlist] bbbbb from mail.libertyfp.org[2.56.57.28]; from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org> to=<fp145(a)libertyfp.org> proto=ESMTP helo=<mail.libertyfp.org> Dec 27 18:31:53 libertyfp postfix/qmgr[468573]: 4FCDD420F5: from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>, size=1870, nrcpt=1 (queue active) Dec 27 18:31:53 libertyfp postfix/submission/smtpd[471207]: disconnect from mail.libertyfp.org[2.56.57.28] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Direct mail from fp145(a)libertyfp.org to billo(a)billoblog.com worked fine also. Again, a quick DuckDuckGo search reveals that this has come up a couple of times. It required that I modify /etc/postfix/main.cf to add the non-localhost ip4 address of the box to the mynetworks line: mynetworks = 127.0.0.0/8 10.0.0.0/24 to mynetworks = 127.0.0.0/8 10.0.0.0/24 2.56.57.28 I assume that means that postfix uses localhost for regular mail, but mailman3 uses the 2.56.57.28 address. In any case, it now works fine. I am happily receiving the six million test messages that were queued awaiting delivery to billo(a)billoblog.com. Once again, thanks. I owe you. billo

4 years, 4 months

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Andrew Hodgson

Stephen J. Turnbull wrote: >Ruth Ivimey-Cook writes: > > On 21/06/2020 04:52, Mark Sapiro wrote: > > > Change that to greyarea-post > > Problem is, if I do that (which I did in the beginning), the core rest > service listens on localhost / 127.0.0.1 >I don't understand. I'm not in a position to test with Mailman itself right now, but the standalone gunicorn[1] does the right thing (takes an IP address and binds to the corresponding interface, or takes a domain name, resolves it to >the IP address, and binds that to the corresponding interface). It does not substitute localhost. Sorry not to reply to ruth on this before, my main experience of this issue was running in a Kubernetes cluster using Docker, using https://github.com/maxking/docker-mailman as the basis for the images. What follows is my own research on this issue and it may be completely wrong. Taking the default Mailman Core setting: [webservice] hostname: localhost This makes Mailman-Core listen on the loopback address (via name lookup) on the configured port for incoming REST requests. When it responds to these requests, it sends out in the response a self_link address which matches the [webservice] hostname Parameter. Connecting clients (such as Postorius) need to connect to Mailman-Core on the given hostname (eg http://localhost in the default case where Mailman Core and Web components are installed to the same machine. However if the [webservice] hostname: parameter is set to something like 0.0.0.0, then although you can direct Postorius (via DNS lookup or IP address) at the Mailman Core instance, it fails to work properly because the resulting response sent back from Mailman Core will include self_links pointing at 0.0.0.0 which will not be usable as a URL by the REST client. A fix for this issue is to set the [webservice] hostname parameter to a FQDN or IP address which can be resolved by the machine running the Web components, and as long as the base URL that Postorius tries to use for the Mailman Core access is the same as in the [webservice] hostname parameter, you are good to go. It appears that when specifying a FQDN in the [webservice] hostname parameter, that the system will look up the IP address for that host using the systems name resolution function. This has the side affect of potentially listening on the wrong interface (localhost) if the system hosts file is set such that the machine's FQDN points to 127.0.0.1. In my case my containers were behind CoreDNS and this wasn't an issue for me, but had I tried this for example on a Debian system I would have come against the same issue that Ruth has as it will automatically set the FQDN of the system to resolve to 127.0.0.1 by way of the Hosts file. Adding the network IP address of the system with the FQDN in the hosts file should fix this issue. > > IMO, the hostname parameter needs to be split up into a "what address > should the rest of the world use to address me" and separately "what > address(es) should I listen on". Multiple listen addresses enable > multihomed >hosts to get the right connectivity, too. >I'm not clear on what you're saying. An address is a rendezvous point; if you're not listening on the address that others are using, you won't meet. What good does it do to split them up? I agree with this, we need a setting for which interface for Gunicorn to listen on, and what Mailman Core sends out in the self_link attribute when responding to REST requests. Thanks. Andrew.

5 years, 10 months

[MM3-users] Re: Help with some 'withlist' configuration changes

by David Partain

Hi! Thank you, Mark, for giving me something to go on! I'll dig further. Cheers, David On Wed, 2021-06-23 at 06:59 -0700, Mark Sapiro wrote: On 6/23/21 6:30 AM, David Partain via Mailman-users wrote: Hi, Firstly, a repeat that I have a relatively broken (and soon to be fixed, I hope) installation of mailman3 based on Ubuntu 18.04 distrib packages (3.1.1-9) that stumbles along by me dealing with a bunch of things by hand that I hope'll go away once I'm up to the current version. In this set-up, I get a fair number of items shunted. Since I have this wonky version where stuff isn't always exposed in the web interface, I have to fix these things by hand. An example is that something gets shunted because of too many recipients, where I do: sudo -u list mailman withlist somemailmanlist m.max_num_recipients = 0 commit() sudo -u list mailman unshunt I've managed to find a number of these, such as m.max_message_size, m.require_explicit_destination, and m.administrivia. There is some other issue here as these things should only cause a message to be held, not shunted. Some exception is being thrown in the process of holding the messgage, and thaty is the real issue. What are the tracebacks in Mailman's mailman.log for these shunts? My questions are undoubtedly foolish, but here goes: 1. Is there any way to print the entire 'm' structure? If so, I'd perhaps be able to figure out the answers to my other questions. dir(m) or maybe you want >>> for x in dir(m): ... if not x.startswith('_'): ... print(f'{x}: {m.__getattribute__(x)}') ... 2. Is there a way for me to correct the following shunt-ing issues with 'withlist'? I've been unable to figure out how... a. 'moderation_reasons': [ 'Message has no subject'] / 'rule_hits': ['no-subject'] b. Some things get caught as 'rule_hits': ['nonmember-moderation']. However, if I look in the (web-based) config, it shows that non-members should be accepted but the messages are shunted nonetheless. I don't know what to look for in 'm' or how I might clear these messages. As I note above, these things are reasons to hold the message. The shunting occurs because something is going wrong in the holding process. Find the errors and tracebacks in Mailman's mailman.log to see what the real issue might be. 3. I have no idea what these are telling me to do about digest messages. Suggestions? This is the entire info I get from 'mailman qfile': ------------------------------------------------------snip snip---------------------------------------------- [----- start pickle -----] <----- start object 1 -----> <----- start object 2 -----> { '_parsemsg': False, 'digest_number': 457, 'digest_path': '/var/lib/mailman3/lists/somelist/digest.31.457.mmdf', 'lang': 'en', 'listid': 'somelistid', 'version': 3, 'volume': 31, 'whichq': 'digest'} [----- end pickle -----] ------------------------------------------------------snip snip---------------------------------------------- That is telling you there was in issue in sending the digest, the mailbox for which is /var/lib/mailman3/lists/somelist/digest.31.457.mmdf. Unshunting that will retry sending that digest. 4. I have some that have 'rule_hits': [] (it's empty) but are shunted nonetheless. I can't see anything weird other than one of the messages has a utf-8 subject. Any ideas? 5. Some messages that were sent to -request addresses (e.g., subscribe messages, confirm, approve messages) are being shunted. What should I do with these? You need to find the errors in the log and figure out what the underlying issue is. I'm guessing it's a permissions issue, possibly because of having at one time rum `mailman start` as root causing files to be created and owned by root and not be readable/writable by the Mailman user.

4 years, 10 months

[MM3-users] Re: mailman3 does not send to the members of the lists

by Stephen J. Turnbull

Mark Sapiro writes: > I say you have to understand what you want Postfix to do and configure > it appropriately. I would recommend going to a Postfix list as Mark suggested. Postfix configuration is complex, and they're more likely to know the best way to do exactly what you say you want to do. I myself can't help with Postfix details, I'm an Exim user. But my list of "need to know" stuff is generic, just the answers would be very different with Exim or Sendmail or qmail! > I would need much more information in order to know how your Postfix > should be configured, In particular, whoever answers your questions will need to know: 1. Why are you using virtual domains for email? This doesn't need to have great detail. Mostly: - are you supporting multiple organizations with their own domains, OR - is this for some purpose of your own, OR - did you just copy the virtual domain lines from some example configuration? In the last case, you might try not even mentioning that you're using virtual domains. (That's only if you treat this as a "new install". If you're going to send them your current configs, they'll see your virtual domain stuff and want to know "why?" You may as well tell them.) They may tell you that you can do everything you want without them! Or they may tell you that virtual domains are the best way to do that, and you can be confident about it. In the last case you could also try just deleting and seeing if your system works, as you suggested to Mark earlier. But that could also break everything related to mail on that host. 2. Who is receiving mail via Dovecot, and via what domain(s)? The "who" is generic (eg, "users and web applications using IMAP clients"), but the domains should be specific. If not inconvenient, it is easiest if you give real names for the domains. If there are privacy, security, or intellectual property concerns with the domain names, you'll need to find out the conventions used by the Postfix community for dealing with that. If you do redact your domain names in your explanation in the initial contact, make sure you explain exactly how you did that, or you will confuse everybody and have an unpleasant experience. 3. What domain does Mailman use to receive mail? Is Mailman the only thing that receives mail on that domain? What else, if anything, needs to received mail addressed to that domain? 4. What domains other than those handled by Mailman and Dovecot, if any, are processed by your Postfix MTA? 5. What other things, if any, besides Mailman and Dovecot directly receive mail processed by your Postfix MTA? Anything downstream from Mailman and Dovecot doesn't need to be mentioned. If there are still problems with downstream recipients once Mailman and Dovecot are receiving mail correctly, direct those issues to us and to Dovecot, as appropriate. You should check the channel FAQ to see whether they want your configuration in your first contact, or not. Even if they do, you might be better off to treat this as a "new install" rather than "it's broken, help me fix it". In contacting the Postfix channel, explain "I want to ..." based on the answers to those questions. Then your question is "how do I configure mail so that Dovecot domains and users get mail, Mailman domains, lists, and administrators get mail, and any other mail handled by Postfix goes to the right place (as defined by questions 4 and 5)?" Steve

5 years, 9 months

[MM3-users] Re: Problems with New MM3 Installation

by Abhilash Raj

On Tue, May 11, 2021, at 8:43 PM, Mark Sapiro wrote: > On 5/11/21 7:46 PM, Jeff wrote: > > > > I really appreciate your assistance. New messages are now being archived as expected, but I still have a few small remaining issues to work out with my MM3 installation: > > > > 1) some emails that arrived before I got the archive working are still sitting in: > > > > /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain]/new > > > > Strangely this includes at least one email that was archived. Should this directly be cleared as messages are archived? Is there a way to force it to be cleared? > > /usr/local/mailman3/mm/var/archives/prototype/[listname]@[domain] is a > collection of messages in maildir format. This is how the prototype > archiver stores messages. This has nothing to do with HyperKitty. It is > a separate archiver. If you don't want messages to be stored there, you > can disable the prototype archiver for the list by unchecking prototype > in Postorius -> Settings -> Archiving -> Active archivers or disable it > entirely for the installation by setting > ``` > [archiver.prototype] > enable: no > ``` > in mailman.cfg > > > 2) Some messages that arrived while I was having other problems with the setup have been stored in: > > > > /usr/local/mailman3/mm/var/queue/shunt > > > > What should I do to get these messages processed? > > > Assuming the issues that caused them to be shunted have been fixed, just > run the command > ``` > mailman unshunt > ``` > > > 3) Similar to above, some messages are in: > > > > /usr/local/mailman3/mm/var/queue/bad > > > > How can I get these messages processed? > > > First examine the messages with > ``` > mailman qfile /usr/local/mailman3/mm/var/queue/bad/<file> > ``` > To be sure you want them. Also examine mailman.log for the times they > were stored in the `bad` queue. You are looking for 'Skipping and > preserving unparseable message: <file>' and/or 'SHUNTING FAILED, > preserving original entry: <file> messages and you want to determine > which runner preserved the message. There may be a 'whichq' entry in the > message's metadata in which case, that's the answer. > > Once you have determined the queue, you can just move the .psv file from > the bad queue to the appropriate queue, renaming it from .psv to .pck in > the process. > > > > 4 Modified the template for “list:admin:action:post” through Postorious and emails that arrived after that were put in the “shunt” queue. I traced this problem to POSTORIUS_TEMPLATE_BASE_URL. By default, it is set to "http://localhost:8000 <http://localhost:8000/>” which is where uwsgi is listening. However, uwsigi is listening for uwsgi:/ not http://. Should I change POSTORIUS_TEMPLATE_BASE_URL to “uwsgi://localhost:8000 <uwsgi://localhost:8000>” or keep http but make it something else? > > > I know little about uwsgi. setting it to `uwsgi://localhost:8000` might > work. You could also set it to the base URL that a user would use to > access the web UI, e.g. `https://example.com` and that would presumably > be proxied to uwsgi. For example, on the server for this list we have > ``` > POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org' > ``` > which gets proxied to gunicorn, but the idea is the same. Using the full external URL should work. Core doesn’t speak uwsgi protocol so the uwsgi:// URL won’t actually work. I am starting to think it was a very bad idea to use uwsgi in the official docs :( -- thanks, Abhilash Raj (maxking)

4 years, 11 months

[MM3-users] Re: How To Install Mailman 3 on Debian 10 (Complete Guide)

by Brian Carpenter

On 2/26/21 10:00 PM, Stephen J. Turnbull wrote: > Thank you for going to the trouble of making your guide easily > available to and usable by the community. You're welcome Steve. > Yes, and we try to document them all, written by different people at > different times. I don't think that's an unreasonable approach given > the wide variety of situations of our site admins, but I'm sure a lot > of "greenfield" installations will appreciate your thorough, "from > parts manifest to assembled working system", approach. I agree. I just know there are probably a lot of folks who just want a working and current Mailman 3 server and are not picky over the actual server environment. Mailman 3 is really dependent upon being connected to a number of services: web server, database server and MTA for instance. Then you add in all of the required Python modules, and you have a really complicated system that has a lot of moving parts. I intend to explore other OS for installing MM3 and to document that process as well. I will not document the process of using package managers (apt/yum) etc to install Mailman 3 itself because I think it is very problematic having older versions of Mailman 3 set up. Mark Sapiro put it very well when he said: > Mailman 3 is still relatively young and there are many important > features and fixes in the current releases that aren't in the > Debian/Ubuntu packages. I hoping a guide such as mine will move folks away from using a Debian repo for Mailman installations. > Yes, it has been a problem. At this point I'm pretty sure :^þ that > mailman.readthedocs.io is the official guide, but that hasn't been > well-known in the past and there are a lot of mirrors and unofficial > guides like yours (but not as thorough). And there's a lot of stuff > on the Wiki that requires effort to integrate because it was > originally written in reply to a particular user's questions. See that is something I am very interested in fixing and cleaning up but I need help in knowing how to work with something like Readthedocs.io. > Sphinx is pretty much the gold standard for Python documentation. It > looks nice. The markup is reStructuredText, which is a powerful, > Markup-like language with a few features that Markup didn't have last > I looked, and it's extensible by Python programmers. It's also used > in marking up Python docstrings. So you can see why we'd choose it. > But if you're *not* an experienced Python programmer, none of those > are advantages. Exactly! > > > I am just trying to understand how can we lower the barrier for > > > community members to help contribute to existing docs instead of > > > them having to create new ones. Specifically around installation, > > > since that tends to get stale often when depedent packages change > > > or a new dependency is added that breaks the installation. > > @Abhilash: For non-Python programmers, it's not *that* hard, but there > is a hurdle at the beginning. So lift me up and throw me over that hurdle. > I think the best thing to do is to advertise that we're always looking > for doc contributions, and that if somebody's not familiar with reST, > they shouldn't let that stop them. Of course we'll help them with > markup, and if necessary we'll do it. "Raises hand here" -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 2 months

[MM3-users] Re: Default values for lists in Mailman 3

by Markus Grandpré

Dear Mark, dear list, in Menu "Mass Operations / Mass Subscription" I have set the default value for checkbox "Invitation" in file </usr/lib/python3/dist-packages/postorius/forms/list_forms.py> (on Debian 12) as you had suggested: invitation = forms.BooleanField( label=_('Invitation'), initial=True, required=False, help_text=_( 'If checked, the other checkboxes are ignored and the users will ' 'be sent an invitation to join the list and will be subscribed ' 'upon acceptance thereof.' ), widget=forms.CheckboxInput(), ) However, administrators of mailing lists on our Mailman3 demo system report that the invitation is still sent, even if they have deactivated the sending of the invitation via the “Invitation” checkbox. What have I done wrong? Best regards, Markus Am 20.09.24 um 09:05 schrieb Markus Grandpré: > Thank you very much for your answer. > > Best regards, > Markus > > Am 19.09.24 um 22:03 schrieb Mark Sapiro: >> On 9/19/24 05:46, Markus Grandpré wrote: >>> Dear list, >>> >>> I would like to activate the invitation setting for all lists as >>> default. In Mailman 2.1 I have done this in the file </etc/mailman/ >>> mm_cfg.py>: >>> >>> >>> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >>> >>> >>> How can I do this in Mailman 3? >> >> There is a draft merge request at https://gitlab.com/mailman/ >> postorius/-/merge_requests/930 which implements a framework for >> setting Postorius defaults and creates a setting to set the default >> for pre- verified on the mass subscription page. Once merged, this can >> easily be extended to provide a default for Invitation. >> >> In the mean time, you can only do this by patching src/postorius/ >> forms/ list_forms.py like >> ``` >> --- a/src/postorius/forms/list_forms.py >> +++ b/src/postorius/forms/list_forms.py >> @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): >> >> invitation = forms.BooleanField( >> label=_('Invitation'), >> - initial=False, >> + initial=True, >> required=False, >> help_text=_( >> 'If checked, the other checkboxes are ignored and the >> users will ' >> ``` >>> Can I also transfer other default values like: >>> >>> ... >>> DEFAULT_SERVER_LANGUAGE = 'en' >>> DEFAULT_SEND_REMINDERS = 1 >>> DEFAULT_SUBSCRIBE_OR_INVITE = Yes >>> DEFAULT_PRIVATE_ROSTER = 2 >>> DEFAULT_ARCHIVE = Off >>> DEFAULT_ARCHIVE_PRIVATE = 1 >>> ... >>> >>> from the very same configuration file to Mailman 3? Is there a >>> documentation of the default values for lists in Mailman 3? >> >> This is done by creating a list style with the desired defaults. See >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/ >> styles/ docs/styles.html for documentation of styles and see https:// >> gitlab.com/ mailman/example-mailman-plugin for an example of creating >> a plugin in Mailman core to make a persistent style. >> >> There is no specific doc for the list settings. You need to look at >> https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/ >> base.py for the various settings and https://gitlab.com/mailman/ >> mailman/-/blob/master/src/mailman/styles/default.py to see which >> default classes are applied for various styles. >> > > > _______________________________________________ > 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 markus.grandpre(a)uni-konstanz.de -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

1 year, 7 months

[MM3-users] Re: Fwd: Re: Removing a mail addresses and users

by Abhilash Raj

On Wed, Jun 10, 2020, at 3:33 PM, Allan Hansen wrote: > All, > > This disconnect between Mailman Core and Django and Postorius is, by > far, the weakest and, for subscribers, most confusing aspect of MM3 > (once it has been installed, which is extremely hard and confusing). The disconnect was intentional to make sure that we are fully able to leverage the power of Django's ability to run multiple dis-connected applications in a single Site and Account system. And Mailman Core was intentionally designed to not be an account management system so it can be kept simple. The disconnect however has caused more confusion than has helped, which we acknowledge. But this disconnect doesn't exist all that much right now, barring any bugs. We synchronize most of the state from Postorius down to Mailman Core including, any additional addresses that you add, primary address etc. Display Names don't trigger an update in Core, but it isn't that hard to do if you open a ticket. > > In a true account-centric system, you set up a web account and from > there manage your emails and, for each email, your subscriptions. > Subscription options would be hierarchical: account/email/list, with > lower levels inheriting/overriding settings from/the level above. You are able to sign in via web and manage your email and subscriptions. The preferences also work exactly how you described above where the lower level override the default and/or upper level settings. > > That’s really what I had expected when I pushed for us to move our 50 > email lists to MM3 and I was very excited about the prospect, > as it would solve a lot of system/subscriber management issues I had > managing MM2. > > Alas, I was very surprised that that’s not how MM3 works. Some things > got harder, even, such as the inability to change subscription > addresses, which should have been a showstopper from the start! > I still hope that MMxx OOTB will get there, but I guess it’ll be along > haul. Would we be talking about MM4 to be released 20 years from now? As a Subscriber, you are able to do switch emails in subscriptions from your options page. The URL to which is displayed in the List's Summary page when you are logged in. Yes, it requires an approval if the list's settings are set to moderate but that is going to be fixed, see this issue[1]. It is quite simple IMO to fix this one, if someone wants to take this up. [1]: https://gitlab.com/mailman/postorius/-/issues/425 Are you asking about switching emails as an administrator for your subscribers? > Some dedicated and skilled developers are currently investing heavily > in a replacement for Postorius, but I really believe that any work is > better spent transforming Mailman Core etc. into a true account-based > system. Then, and only then, will it make sense to build new and better > interfaces on top, as, without a healthy core, such interface will > currently may have to inherit the confusion and disconnect that > currently is so aggravating. I don't know if we want to add account management to Core, but User management is missing from Postorius, that is true. We punted on it and delegated that part to Django's admin interface. Long long time ago, I remember seeing that there was a User's tab for managing users, but that has since changed I think. If you and some others on this list would like to propose an RFC here[2], it would be a great help for me. What I am basically looking for is what kind of "User management" are administrators looking for. It doesn't have to be too detailed but a single line example would be: - As a Admin, I would like to delete a User completely from my system, including all their addresses and subscription - Also, it would be good to delete their account but retain their subscriptions - As a Admin, I would like to update User's attributes in the system like: - Manually verify their email address - Manually update their Name - As a User, I would like to delete my own account and all the subscriptions. Maybe this could be a starting point, but something like this can be added to Postorius. [2]: https://gitlab.com/mailman/postorius/-/issues/new As for the question in this thread, you are able to delete the User from Django's admin page and that would delete all the related EmailAddress for them. Deleting an Email address doesn't delete the User, since the relationship exists that User owns Emails. There is currently no way to delete all the subscriptions for a User though. > The above is not meant to aggravate the MM3 development team, for which > I have utmost respect and gratitude, and which I admire for their > tireless support given over decades to the community of admins. > Software development is devilishly hard and time consuming. And thank you for posting what you think is an important enhancement to Postorius. We don't have a very strict process to choose what new features to work on, so email like this do help us prioritize. Other users could also help by upvoting or just adding "+1" to the bugs/feature enhancements that affects them the most so we can fix them sooner rather than later. I would be more than happy if more people participated in just being able to prioritize features, all the work really happens in the open on Gitlab. As administrators of some 'open source' lists, the needs of us as admins are somewhat different from what would be in a closed organization and ability to kick someone completely out of the system is something never I had to do since folks are supposed to manage their own subscriptions. We do ban people from sending emails if they've been spamming, but that is a different thing, they are still able to login into Postorius AFAIK. > Yours, > > Allan Hansen > hansen(a)rc.org > > > > > > Begin forwarded message: > > > > From: Mark Sapiro <mark(a)msapiro.net> > > Subject: [MM3-users] Re: Removing a mail addresses and users > > Date: June 10, 2020 at 12:46:01 PDT > > To: mailman-users(a)mailman3.org > > > > On 6/10/20 10:23 AM, Abhijith PA via Mailman-users wrote: > >> Hello. > >> > >> I tried to remove random email address signing ups (which I signed up > >> while testing) via admin panel. After removing I tried to sign up again, > >> but I am getting, > >> > >> 'A user is already registered with this e-mail address' > > > > You removed the user's subscription from the list, but you didn't remove > > the user from the system. > > > > Mailman3 has a concept of `user` which didn't exist in Mailman 2.1. > > User's have addresses and a user or one of the user's addresses can > > belong to a list with one or more roles (non-member, member, moderator > > or owner) > > > > > >> Combing through the database, I found auth_user table in mailman3web db > >> still contain those mail address. How to wipe email address entirely > >> from the db so I can signup again without the 'forget password' method > > > > There are a couple of things. If you log in to the web UI as a django > > superuser, you can go to the django admin UI -> Users section and delete > > the User, but I think that will only delete the web user and not delete > > the user from Mailman core. > > > > You can also log in to the web UI as the user and go to > > <https://lists.mailman3.org/user-profile/delete>, but that again only > > deletes the web user, and if you could do that, you could just subscribe > > once you're logged in, so I assume that's what you want to avoid. > > > > I don't think there is a way for a user as opposed to a site admin to > > delete her user record from Mailman core and even for a site admin, > > there's no way in Postorius to delete a user from core. It has to be > > done via REST > > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…> > > or `mailman shell`. > > > > -- > > 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/ > > _______________________________________________ > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 10 months

Search results for query "sapiro"