Search results for "Postorius" - Mailman-users

Re: makemigrations --merge error after Debian upgrade

by Mihai Moldovan

* On 4/16/25 01:04, Sam Darwin via Mailman-users wrote: > "Virtualenv Installation, recommended for Production" > > It's recommended for production. > > I've followed that method. If someone does this, they may never encounter > or bump into any files from the "distro packaging (specifically in Debian > and Ubuntu)" . True, and that's fine. :) > Which means they're missing out on this particular idea about the mailman > wrapper. The script is small enough it can be described in the docs. > > Let's try a grep inside mailman-suite-docs: > > grep -r -i wrapper * > > no relevant results. They are small scripts, but describing them in the documentation is problematic because they depend on user names and file system locations, which in turn are distro- or even system-dependent. (Just as an example, some distros use www-data as the web service user, which is needed for the hyperkitty and postorius integrations, while other distros use wwwrun and even others just plain www or something else entirely.) Providing such wrappers as part of venv or the upstream repository is hence not possible. This said, nobody prevents you from creating such wrappers for use with your venv installation tailored to your system either, just make sure that you write them up correctly. :) Also, as is often the way, the documentation could probably be also improved. For instance, the migration documentation says: > This, and in general all, mailman commands should be run as the Mailman > user and not as root. Running some of these commands as root can create > files owned by root that can’t be read by the Mailman user. But it doesn't explicitly tell you how to do this. Naturally, as a system administrator installing, maintaining and migrating mailman instances, you should probably know how to run a command as a specific user. su -s /bin/sh -c "mailman ..." $LIST_USER and su -s /bin/sh -c "$PYTHON_BINARY $PATH_TO_MANAGE_PY ..." $WWW_USER is probably what you want to execute commands either as the mailing list or as the web user, with all these variables being pseudo-variables that you want to fill in/hardcode to fit your system correctly. Putting that in the documentation and especially educating users to not use them in a copy-and-paste manner is difficult, though. Try that and you'll probably have an influx of requests along the lines of "I don't have a variable called $LIST_USER, the command fails to execute!" Mihai

1 year, 6 months

Re: Can "Pre Verified" set to yes by default?

by Stephen J. Turnbull

Hi Alan, It occurred to me that Django template widgets are very flexible. It may be possible to customize the template to accomplish this task. In that case, the customized template would be kept in a place that doesn't get overwritten in an upgrade, reducing the maintenance cost (unless either Postorius or Django changes the template in a way that seems unlikely to me). I'll try to take a look at that over the holiday break -- that has the advantage that I just document how we did it for you, and tell any future requests to RTFM and DIY. ;-) Alan So writes: > I can say that it is not purely a technical issue in an > organization that whether system admin should maintain a few minor > changes that are not in the main branch. Sure, we understand that. I'd be interested to hear from business users and university users if they would like this particular default to be configurable. It's very easy to do as a one-off, if there is substantial demand we *can* do it, and later say to people who want similar changes that it's on them to demonstrate they have enough demand on their side for another one-off, just as was done for this one. > Due to massive customization made to previous Mailman 2 > installation by some student helpers which made it very difficult > to be upgraded nearly 20 years ago, we tend not to repeat this > pattern when we upgrade to Mailman 3 a few years ago. I agree, you need to be disciplined about what changes you are willing to develop and maintain. This one seemed to me to be over that bar, especially since you can put it in and not suffer too greatly if it gets reverted in a upgrade and the maintainers don't notice. > After all, it is just one of the many suggestions that you > received. I respect the decision of the core team. If the core > team consider that this feature is low priority, it is fine not to > implement it. Unless I see a lot of demand, I think as a one-off I don't want to implement it in list_forms.py, but rather let occasional admins do it on their sites if they want it that bad. But GSoC is coming up again; maybe a student would be willing to take on a generic "pwn all the defaults" project next summer. Steve

3 years, 10 months

Re: Counter-intuitive header filter processing

by Mark Sapiro

On 09/18/2018 01:04 PM, Jonas Meurer wrote: > > Maybe then the description for chain "accept" in postorius needs to be > adjusted. Currently it says "Accept immediately (bypass other rules)". > This gives the impression, that it will overrule the default action. Yes, I agree it's confusing. > A related followup question: what configuration is recommended for an > announcement list where only specific senders (e.g. sender(a)example.org) > should be allowed to post and mail from all (other) subscribers should > be rejected? > > The only way I see to achieve this currently is: > > * Set default action for member posts to "Default processing" > * Add a header filter to accept "sender(a)example.org" > * Add a header filter to reject ".*" > > In my eyes, that's very counter-intuitive and cumbersome to configure. > But maybe I just missed a more obvious and elegant solution to achieve > the same? The way to do that is to set the default action for member posts to Reject and set Member Options -> Administration options -> Moderation for the authorized posters to Accept or Default processing as desired. However, this allows anyone to post by spoofing an authorized address. To avoid that, leave everyone's Moderation setting at List default and post using "pre-approval" (see <https://mailman.readthedocs.io/en/latest/src/mailman/rules/docs/approved.ht…>. The downside of this is it requires the poster to send a cleartext password in a header or body line of the post. It will be removed from the post delivered to list members, but sending it in cleartext in an email may be an issue. We will eventually do something with PGP signatures instead, but that isn't here yet. > And one more comment: if I make the list an "anonymous list" (i.e. "hide > the sender of a message, replacing it with the list address"), then > header filters for the "from" header don't work any longer. That's kind > of unexpected as well. I would have expected mailman to process the > header filters at reading the incoming mail, not after rewriting headers > of the outgoing mail? Your expectation is correct. All the applicable rules are applied to the incoming message before any message alterations such as anonymizing are applied. Possibly you were confused because some other rule's action took precedence over your header rule. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 1 month

Re: MM2 to MM3 on debian 10

by Gelpi Andrea

Il 27/04/20 18:59, Mark Sapiro ha scritto: > On 4/27/20 8:26 AM, Gelpi Andrea wrote: >> Hi, on a debian 10 with MM3 I'm trying to migrate form some old MM2 >> mailing lists. I know that not all can work. >> >> In my old lists I have email and regular expressions in >> reject_these_nonmembers and discard_these_nonmembers >> >> After importing the list all these email are in non member list. >> >> All these email have Delivery status enabled. > > > Delivery status is not relevant for non-members and only has to do with > receiving list posts in any case. > > What version of Mailman core is this? There have been changes in > `mailman import21` that may affect this, but an address in > `reject_these_nonmembers` should be imported as a non-member with a > moderation action of `reject` and similarly for `discard`. > > Note that regexps in *_these_nonmembers should be imported into the MM 3 > legacy *_these_nonmembers attributes. Some older versions of import21 > also imported non-regexp addresses here, but that was wrong. > Mailman V 3.2.1 Python V 3.7.3 Postorius V 1.3.2 Hiperkitty V 1.2.2 Yes reject_these_nonmembers has a moderation action of 'reject' and the some for discard. > >> Does this mean that all of them will receive any message sent to the list? >> The moderation rule is correct, but if I understood correct Delivery >> status should be disabled. > > > Delivery status is irrelevant for non-members. Only members are > candidates for delivery. > Ok, but will non-members receive the list posts or only members will? > >> For migration I followed this link >> https://docs.mailman3.org/en/latest/migration.html >> >> To migrate archives it states to run >> >> python manage.py hyperkitty ... >> >> I cant' find a manage.py on debian 10 > > > manage.py is a Django generic term for the Django admin command. You > probably want something called django-admin or similar. > Yes in debain 10 exists django-admin. Now I need to understand how to use it. It asks me to load a configuration. > >> A search shows the only /usr/share/mailman3-web/manage.py exists. >> >> Is there any documentation specific for debian? > > That would be up to Debian. > -- Gelpi ing. Andrea -------------------------------------------------------------- It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here. --------------------------------------------------------------

6 years, 6 months

Re: How to delete non-users

by Mark Sapiro

On 9/16/22 16:40, Allan Hansen wrote: > Hi Mark, > > Thank you for looking into it. > > We are very strict about memberships, which we are because of spam, bots and malicious contributors and because we don't want anyone to think that our lists are used for spam: > > When a user applies, the server sends a message to the moderator. > The moderator communicates with the potential member and accepts or does not accept the application. So Subscription policy is Moderate or Confirm, then moderate. > At this point, if the user has not been accepted, but tried to send a message to the list, a non-member membership is created. Yes. This is expected. > When he/she logs in to list his/her account, the list to which he/she holds non-memberships will be listed and the user will think that he/she has been properly subscribed (why else are the lists listed). I'm guessing you are talking about the https://www.example.com/mailman3/accounts/subscriptions/ page. On that page, all membership roles (owner, moderator, member, nonmember) are listed. Note that if the user goes instead to info page for the list, appropriate pronoun will be presented with a subscribe form. > Noone notices the column that shows the role as 'nonmember.' So he/she thinks that the subscription request has been accepted, but nothing is working. That's why the 'non-member' record is an issue. I also don't see why non-members are automatically added, filling up the database with junk (at least from our point of view, with all respect). That's the way Mailman 3 is designed. Changing it would be a major undertaking. Consider the case where default nonmember action is hold rather than discard. Then when handling a nonmember post, the moderator can set the nonmember's moderation to default processing to essentially accept future posts from that nonmember if the nonmember has a legitimate reason to post, or to discard if the nonmember is a spammer. If you think it would help, you might consider colorizing the roles on that page so perhaps nonmember could be in red. This should be a simple patch to Postorius. > But our lists don't accept messages from non-members. Such messages are quietly discarded, as most are spam, as mentioned above. > So now the user is neither getting emails from the lists nor is unable to send messages to the list. > The next step for the user is to complain to me. ☹ Why didn't you (or the moderator) accept the held subscription at the beginning? > I have looked for a template that could be used to warn someone when he/she is added as a non-member, but did not find one. It's also not clear that I'd want one, as most of these non-subscriptions are by spammers and I prefer not to reply to spammers. __ > > I tried your suggestion below, Mark. > Here's my transcript: > > ********** > 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. > >>>> lm = getUtility(IListManager) >>>> for l in lm: > ... for nm in l.nonmembers.members: > ... nm.unsubscribe() > ... >>>> > ********** > I did this twice, once with commit() and once typing ctrl/d (ctrl/D) just gave me a beep. > Calling commit() did not return to the ... as in your example, but showed the >>> prompt, so I tried ctrl/D (beep) and then ctrl/d (exit). My example did not show a `...` in response to commit(). Commit() was followed by three backticks which is markup for the end if the literal text. The >>> following commit() is expected. Either calling commit() explicitly or exiting with ctrl-D should commit the changes. > I then went to the Postorius page for one of the lists and found that all the non-members were still present. I don't know why this would be. I tested that script and it worked for me. My original point is the presence of a nonmember role should not prevent the user from subscribing. If there is an issue with subscribing it is probably because of the outstanding subscription request waiting moderator approval. I understand that you would like the nonmember role to disappear, but that isn't going to happen in the distribution, and I can't undertake the extensive effort required to figure out how you can do it for your site. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

Re: Archive Policy not reflecting in Hyperkitty

by Abhilash Raj

On Fri, May 3, 2019, at 8:38 AM, Nathan Dixon wrote: > So the issue I am seeing is that when I set a lists archive policy to > prviate, it isn't reflecting that in Hyperkitty. > > I am running the docker installation of Mailman, postorius and hyperkitty. > So I go into the docker instance of mailman-core and run this: > > python3 manage.py shell from hyperkitty.models.mailinglist import > MailingList MailingList.objects.all().values_list('name', 'archive_policy') > > And all my lists are showing '2', regardless of how I set the mailing list > archive policy. > > This might be a duplicate of > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > Am I missing something in my install? Or is this a bug? It can take upto an hour for this change to reflect in Hyperkitty. Did you wait for that long? This happens because Hyperkitty stores it's own data, and queries Mailman Core periodically to fetch updates every hour. In future, we might be able to do this in more realtime fashion by using an event based pub/sub model. But, we are not there yet. > > Many thanks for your attention, > > -- > > *Nathan Dixon* MEng > Senior Software Architect > m: +44 (0)7402 690311 > > t: +44 (0)20 81231252 > e: nathan.dixon(a)evadon.com > w: www.evadon.com > > This e-mail and any attachments are confidential and may be protected by > legal, professional or other privilege. If you are not the intended > recipient you should not store it, copy it, re-transmit it, use it or > disclose its contents, but should return it to the sender immediately and > delete your copy from your system. The views expressed are those of the > sender and not necessarily those of Evadon. Please note that whilst we scan > all e-mails for viruses we cannot guarantee that any e-mail is virus-free. > Please be advised that we expressly reserve the right to monitor email > content for the purposes of ensuring compliance with legal requirements and > company policies and your sending to, or receiving from, us of any email > constitutes your agreement to these terms. > > > Evadon Dynamics Limited, registered in England No. 09494097. Registered > Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, > S1 2BJ > _______________________________________________ > 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)

7 years, 6 months

Re: Migrating Mailman 3 lists

by Andrew Hodgson

Abhilash Raj wrote: >On Mon, Apr 27, 2020, at 9:05 AM, Andrew Hodgson wrote: [Moving Mailman to new server] >> I did this the other week, the difference I think we've got here is >> that I migrated the whole instance (Mailman Core's var files plus >> complete Postgresql database) over to the new server rather than >> trying to add the lists to an existing setup, which I couldn't work >> out either which is what prompted me to complete the server migration >> before adding more lists. >> The only issue I ran into was not copying the Mailman Core var files >> to the new server, this actually gave me a bit of trouble later on as >> firstly Mailman doesn't create the lists directory which is what I was >> checking with Exim for list existence, and also I had an issue where I >> was missing a moderated message from the messages directory which >> stopped the admin interface from displaying for that list. >var/ directory does store some state for Mailman, specifically queued messages. Optionally, also templates. Directory structure is something that could be fixed with this issue[1], but given that the messages are still stored on the >filesystem instead of database, you'd need to move var/ directory too. I would say that the var directory structure is essential to keep if possible between servers. I don't really want to fix the issue where I couldn't access a list because of old pending messages that were no longer available. I fixed it in the end by creating pickles with the same name, and then just deleting the messages from the web interface. The problem was happening because Postorius was trying to get the list of held messages to show on the admin interface, this caused Mailman REST interface to throw an exception. I was going to post on here but figured it out in the end. Another issue though stemming from this is that when I was moving the data across I had several messages in the var/messages directory structure and my incorrect assumption was that they were old held messages which weren't deleted. There were around 60 messages in that folder structure and I actually only needed to recover 2 of them to get the list on track, I forgot to check that the user had cleared their held messages. Even now when I deleted the fake messages I put there in the web interface, the files are still now on the server in that structure. Andrew.

6 years, 6 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Stephen J. Turnbull

Abhilash Raj writes: > The is definitely a bug, caused due to the fact that "Delivery Status" field > only has two options, "Enabled" and "Disabled". Internally, this field can > have 4 values, "enabled", "by_user" (maps to "Disabled" in Postorius), > "by_admin" (means disabled by admin) and "by_bounces" (means > disabled due to bounces). So, when the value of the field is among > the last two options, it appears as "unset" with no options selected, > which unfortunately is also how it looks by default since all options > are "unset" from start. > > The "fix" for this issue would be simply adding a new choice to the > delivery_status field with a caveat that it is only a Readonly option to I don't see why most users would care (there will always be somebody who cares "just because", of course). For those who don't care, I expect it will be confusing. I think it's better just to treat all of the disabled settings as just "disabled" in the UI for members. > We could also go a step further and show it on the List's info page > when their delivery is disabled due to excessive bounce and allow > the them to re-enable it themselves without admin intervention. This is probably a good idea, but in a situation where we know the problem is excessive bouncing we should caution them that there is almost certainly a probably with delivery *to their specific address* and that Mailman and the admins *can do nothing about that*, so if that isn't fixed they'll just get disabled again. I suppose it would be good to add that frequently these are due to occasional problems like disk full that "management" at their site normally takes care of, so there's little if any harm to just reenabling. > to the list's info page, but I guess that is the first place you'd go to > debug when you get an email that your delivery was disabled? Surely we can help them go directly there? > https://gitlab.com/mailman/postorius/-/issues/470 > > I don't know if there are any downsides to letting users re-enable > their delivery on their own. I don't see any myself. Maybe if the list is planning a surprise party for them? ;-) There is a specific downside, which is that if you only allow them to reenable if they disabled it themselves, you have to show them the other cases.

5 years, 8 months

Re: Python is updated

by Duane Raymond

Hi Lars, I did the same thing this weekend (upgraded mailman to latest and python from 3.7 to 3.11) as part of a process to do some work I've promised Mark :-) Here are my notes (to I can repeat it next time). I'm on Debian 10. My mailman install is based on Brian Carpenters install notes: https://wiki.list.org/DOC/Howto_Install_Mailman3_On_Debian10 0) IF UPGRADING: copy /static folder, /venv folder and base config files to new backup folder (e.g. config_bak) 1) Install desired python e.g 3.11 (from source if necessary) and be sure to include: apt install libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev 2) IF UPGRADING: Stop the mailman related services: systemctl stop mailman qcluster gunicorn 3) Create local venv at: python3.11 -m venv /opt/mailman/mm/venv (backup old one first to backup folder) 4) Set ownership of venv folder and subfolders/files: chown -R mailman.mailman venv 5) Switch to owner: su mailman 6) Activate venv: source /opt/mailman/mm/venv/bin/activate 7) Check pip uses the intended python version: pip -V 8) Upgrade PIP if necessary: pip install --upgrade pip 9) Install mailman3 basics: pip install --upgrade mailman hyperkitty postorius 10) Install additional if missing: pip install --upgrade django-mailman3 mailmanclient mailman-hyperkitty 11) Install DB connector: pip install pylibmc psycopg2 python3-psycopg2 python3-pil python3-psycopg2 whoosh python3-whoosh python3-httplib2 12) Update /opt/mailman/mm/urls.py with desired paths (django) 13) IF UPGRADING RUN: bin/django-admin migrate PLUS: bin/mailman-post-update (or individually below) bin/django-admin collectstatic --clear --noinput --verbosity 0 bin/django-admin compress bin/django-admin compilemessages 13) Exit venv environment: deactivate and Exit mailman user: exit 14) Start mailman: systemctl start mailman (check status: systemctl status mailman.service) 15) Start qrunner: systemctl start qcluster (check status: systemctl status qcluster.service) 16) Start gunicorn: systemctl start gunicorn (check status: systemctl status gunicorn.service) Note: 1. /django-admin is the same as /mailman-web in some installation notes. 2. The bin/mailman-post-update script Brian used does everything except the "migrate" step 3. I don't know if all the pip psycopg2/whoosh modules are needed - I didn't take the chance. 4. My system now uses django 4.1.8 so I didn't need to worry about the psycopg2-binary install (I don't think I did - it seems to all work) 5. The 3.8 release notes contain a breaking change with the postgresql connection command. I changed that before upgrading. (assuming you are using postgresql!) 6. What I haven't covered here is checking the autostart, service settings and crons are working as that is in the documentation and may already/still be running on your server. Hope that helps :-) Cheers, Duane

3 years, 6 months

Re: Mailman archive issues (Hyperkitty)

by Kimmo L

Hi! I'm very grateful for your help :) Okay, sorry about that. I will try to give more information now. We use https://gitlab.com/mailman/mailman-suite to set up mailman with postorius and hyperkitty. Additional we use NGINX web server and postgresql database. Settings.py configuration are basically same with this - https://gitlab.com/mailman/mailman-suite/-/blob/master/mailman-suite_projec… The only differences are: *In database section we use postgresql configuration *Social accounts configuration is disabled *Haystack connections we use xapian_backend.XapianEngine engine Here is also our mailman.cfg: [database] class: mailman.database.postgresql.PostgreSQLDatabase url: postgres://mailman:xxxxxx@localhost/mailman [paths.custom] bin_dir: /usr/local/bin var_dir: /var/lib/mailman queue_dir: /var/spool/mailman log_dir: /var/log/mailman lock_dir: /var/lock/mailman etc_dir: /etc ext_dir: /etc/mailman.d pid_file: /var/run/mailman/master.pid [mailman] layout: custom site_owner: xxxx anonymous_list_keep_headers: [mta] ***** [loggin.archiver] path: archiver.log level: debug [archiver.hyperkitty] class: mailman_hyperkitty.Archiver enable: yes configuration: /etc/hyperkitty.cfg clobber_date: maybe clobber_skew: 1d Here is our uwsgi.ini: # /etc/uwsgi.ini [uwsgi] uid = uwsgi gid = uwsgi pidfile = /run/uwsgi/uwsgi.pid emperor = /etc/uwsgi.d stats = /run/uwsgi/stats.sock chmod-socket = 660 emperor-tyrant = true cap = setgid,setuid buffer-size = 32000 # process limits limit-as = 512 # Mailman settings plugins = python36,logfile master = true process = 2 threads = 2 chdir = /opt/mailman-suite/mailman-suite_project/ wsgi-file = wsgi.py uwsgi-socket = 0.0.0.0:8000 attach-daemon = ./manage.py qcluster # Logging req-logger = file:/var/log/uwsgi/uwsgi.log logger = cron file:/var/log/uwsgi/uwsgi-cron.log log-route = cron uwsgi-cron logger = qcluster file:/var/log/uwsgi/uwsgi-qcluster.log log-route = qcluster uwsgi-daemons logger = file:/var/log/uwsgi/uwsgi-error.log It seems that we have some perfomance issues on webUI, if we try to check archived messages. Some lists, that contains low number of archives is not a problem but lists, that contains several thousand messages and grows faster are issue. Sometimes it loads so long, that i get "504 Gateway Time-Out" I was also monitoring server perfomance and i didnt see any issues on that side. It seems that there might be some issues to read archived messages from database. But this is just my one opinion. I also debugged log files and found some error messages: 1) mailmansuite.log -> django.db.utils.DatabaseError: out of memory for query result # it happens when i try to open a lists in webui, to check archived messages. nginx-error.log -> upstream timed out (110: Connection timed out) while reading response header from upstream # also happens when i try to open list in hyperkitty and it takes long time to open If any information is more needed then let me know. My one thought was also, that maybe i need to try rebuild_indexes.

5 years, 4 months

Mailman-users search results for query "Postorius"