Search results for "Postorius" - Mailman-users

Re: Implicit destination

by David Krantz

On Mon, Aug 27, 2018 at 2:50 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > That is not the issue. Sending the held message notice to a spammer, if > it reaches the spammer, is probably inconsequential. The issue is that > virtually always in spam the sender address is either undeliverable or > is the address of an innocent 3rd party. Sending these notices to > innocent 3rd parties is called backscatter and is a bad thing. > > To avoid this backscatter, you can set the list's > respond_to_post_requests attribute to False. There are two problems > here. One is this setting is not currently exposed in Postorius, and the > other is this will also stop desired held message notices such as those > from list members. Aha. That was a simple solution although with a bad consequence. Will it stop moderation mails to the moderator as well? I'll try. Otherwise it will not be a problem in my case. The lists where I have this problem are more of function addresses for a number of persons (like a board or workgroup) so they accept posts from non-members. I use mailman as a simple forward gets legit mail caught in the receivers spam filters and might cause more black-list problems. You are of course entirely correct in that backscatter is the real problem, I should have thought of that. The thing in the spam I've received lately is somewhat sophisticated: the senders have correct (albeit strange) domains and correct SPF records so they try to seem legit although the senders are located in unexpected parts of the world. I just checked one example, in that case the MX pointed to the sender IP, the SPF was very sloppy (~all) and everything looked correct except for the fact that we usually do not receive mail from Ukraine and the cryptocurrency scam in the body. It almost got caught in the spam filter, but not quite. cheers // David

7 years, 11 months

Re: New releases

by Mark Sapiro

On 6/9/20 1:05 AM, Danil Smirnov wrote: > On Tue, 9 Jun 2020 at 00:05, Mark Sapiro <mark(a)msapiro.net> wrote: > >> After you upgraded did you run these django-admin commands? >> ``` >> django-admin collectstatic --clear --noinput --verbosity 0 >> django-admin compress >> django-admin compilemessages >> django-admin migrate >> ``` >> These 4 commands should be run after every update to Postorius, >> HyperKitty or django_mainlman3. >> > > Hm, interesting... Could you point me to some related docs please? The documentation is weak and should be updated, but see <https://docs.mailman3.org/en/latest/upgrade-3.2.html#migration-steps> > To upgrade, I've just bumped app versions in my Dockerfiles, built and > restarted... > Mailman-core worked right away with no issues. > Mailman-web (Hyperkitty) failed with the error: > > ---------- > ERROR 2020-06-08 19:46:41,942 14 django.request Internal Server Error: > /hyperkitty/ > Traceback (most recent call last): > File "/usr/lib/python3.6/site-packages/compressor/base.py", line 282, in > precompile > mod = import_module(mod_name) > File "/usr/lib/python3.6/importlib/__init__.py", line 126, in > import_module > return _bootstrap._gcd_import(name[level:], package, level) > File "<frozen importlib._bootstrap>", line 994, in _gcd_import > File "<frozen importlib._bootstrap>", line 971, in _find_and_load > File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked > ModuleNotFoundError: No module named 'sassc -t compressed {infile} > {outfile}' ... > I've fixed the error by removing the older file which is > /opt/mailman-web-data/static/hyperkitty/libs/bootstrap/stylesheets/_bootstrap.scss > > After that everything seems to be working fine. I'm not sure about the above error. 'sassc -t compressed {infile} {outfile}' is defined in `settings` COMPRESS_PRECOMPILERS, but it is a command to be run as part of `django-admin compress`, not a module to be imported. Possibly running `django-admin compress` before starting Hyperkitty would have avoided this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 2 months

Re: Re-send subscription response and file permission error in queue

by Mark Sapiro

On 9/11/20 2:18 PM, Mark Sapiro wrote: > On 9/8/20 10:56 PM, accounts-mailman(a)holbrook.no wrote: >> A user sent subscription request to the `..-join@` address of a list. Email domain wasn't set up properly, so response got rejected. Now, if the user tries to send another request, no reponse comes back. In the log I find a python stack trace saying subscription already pending. >> >> ``` >> Sep 08 10:32:44 2020 (19918) Traceback (most recent call last): >> File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 171, in _one_iteration >> self._process_one_file(msg, msgdata) >> File "/usr/lib/python3/dist-packages/mailman/core/runner.py", line 264, in _process_one_file >> keepqueued = self._dispose(mlist, msg, msgdata) >> File "/usr/lib/python3/dist-packages/mailman/runners/command.py", line 196, in _dispose >> mlist, msg, msgdata, parts, results) >> File "/usr/lib/python3/dist-packages/mailman/commands/eml_membership.py", line 104, in process >> ISubscriptionManager(mlist).register(subscriber) >> File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 520, in register >> list(workflow) >> File "/usr/lib/python3/dist-packages/mailman/app/workflow.py", line 69, in __next__ >> return step() >> File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 227, in _step_sanity_checks >> raise SubscriptionPendingError(self.mlist, self.address.email) >> mailman.interfaces.subscriptions.SubscriptionPendingError >> ``` > > > I'll look at this when I get some time. I'm still catching up after > being off line for 12 days. This exception should also send a response to the user's email saying "User <user(a)example.com has a pending subscription for list(a)example.net" Was this sent? To fix, >> How can I remove the pending subscription, or re-send the response email? > > In Postorius, pull down Subscription Requests and select Pending > Confirmation and delete the request. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

request to held messages yields set of email addresses

by Thomas Krichel

Hi gang, I probably have already developed an uneviable reputation of being able to produce the finest of mess. I stay true to form here. In my 3.12 installation when my admin clicks to view the held messages, he gets an internal server error. The error comes from postorius, where the log entry is 2026-04-15 12:45:25 [FALCON] [ERROR] GET /3.1/lists/bibnez(a)folks.email/held => Traceback (most recent call last): File "falcon/app.py", line 440, in falcon.app.App.__call__ File "/usr/local/mailman/venv/lib/python3.12/site-packages/mailman/rest/post_moderation.py", line 194, in on_get resource = self._make_collection(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/mailman/venv/lib/python3.12/site-packages/mailman/rest/helpers.py", line 189, in _make_collection [etag(resource) for resource in entries] ^^^^^^^^^^^^^^ File "/usr/local/mailman/venv/lib/python3.12/site-packages/mailman/rest/helpers.py", line 104, in etag return json.dumps(resource, cls=ExtendedEncoder, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/json/__init__.py", line 238, in dumps **kw).encode(obj) ^^^^^^^^^^^ File "/usr/lib/python3.12/json/encoder.py", line 200, in encode chunks = self.iterencode(o, _one_shot=True) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/json/encoder.py", line 258, in iterencode return _iterencode(o, 0) ^^^^^^^^^^^^^^^^^ File "/usr/local/mailman/venv/lib/python3.12/site-packages/mailman/rest/helpers.py", line 68, in default return super().default(obj) ^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.12/json/encoder.py", line 180, in default raise TypeError(f'Object of type {o.__class__.__name__} ' TypeError: Object of type set is not JSON serializable Checking the actual set that is returned, by converting the set into a string and writing it to a file (by enhancing helpers.py), I discover that what is returned is as set of 53 email addresses, not of 24 messages as the web interface suggests. Intrestingly, my admin reports that the he is correctly informed about the held messages via email. The then forwards those that need posting to the list. I suspect that to get to the bottom of this problem, I need to use the low-level postorious functions that actually access the parse the held message data. -- Written by Thomas Krichel http://openlib.org/home/krichel on his 22230th day.

3 months, 3 weeks

Registration mail is not sent

by Stephen J. Turnbull

Christian H. Kuhn via Mailman-users writes: > i got mailman-web up and runnung. Is this a system package, or did you use the "Virtualenv install" (https://docs.mailman3.org/en/latest/install/virtualenv.html)? > Wanted to registrate the main user. Got an error ("Bei der > Verarbeitung Ihrer Anfrage ist ein Fehler aufgetreten."). Google says that means "An error occurred while processing your request." That's not a Postfix-like error message. Rather, that looks like a webserver. Did you try to register the "main user" in Postorius? Or in some web interface to your mail server? What do you mean by "main user"? The site administrator, also called the superuser? I don't think you can register "the" superuser through the web.[1] You need to use sudo -u mailman mailmanweb createsuperuser or similar. (If you are using a system package manager rather than pip, it would usually prompt you to do this.) > In the logs of postfix, i could see the connection from mailman to > postfix, but no mail was transmitted to postfix. It's always helpful to post the full log message. If you're concerned about security/privacy, you can redact hostnames and mailaddresses (but say what was redacted, and be prepared to answer questions about the redacted text). Did you send mail through a list? If not, why were you looking in the Postfix logs? It seems possible that some Mailman process raised an exception (a backtrace should be logged in error.log, mailmanweb.log or mailman.log), and tried to report to the site owner by email, but the address was unknown to Postfix. Without more information it's hard to way what you need to do. Regards, Steve Footnotes: [1] Once you have a superuser, it is possible to create additional superusers. But it is not possible to do that for the first one. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

4 months, 2 weeks

Re: Getting connection refused on postfix trying to connect to mailman-core:lmtp

by Abhilash Raj

On Thu, Oct 5, 2017, at 05:36 PM, Dmitry Makovey wrote: > On 10/05/2017 03:20 PM, Abhilash Raj wrote: > > On Thu, Oct 5, 2017, at 03:08 PM, Dmitry Makovey wrote: > >> > >> I've got a setup where postfix runs inside one VM(container) and mailman > >> runs inside another one (maxking containers). I've wired everything > >> according to docs yet I'm getting: > >> > >> postfix/lmtp[266]: 66A72800A87: to=<somelist(a)lists.here.stanford.edu>, > >> relay=none, delay=0.5, delays=0.48/0.01/0/0, dsn=4.4.1, status=deferred > >> (connect to mailman-01.stanford.edu[1.2.3.4]:8024: Connection refused) I found this in your settings: [mta] lmtp_host: mailman-01.stanford.edu [mta] lmtp_port: 8024 And the log message above. I believe that the LMTP runner died because it wasn't able to bind to `mailman-01.stanford.edu`, which I am assuming is the hostname assigned to the host running these containers. `MM_HOSTNAME` env variable in the docker containers should be something that the process inside mailman-core container can bind to and can be reached by postfix (which can run either on host or on another container). (Now that I read it myself, I agree that the name of the variable sounds not-so-intuitive.) The default configuration (and docker-compose.yaml) sets this value to the IP Address of the container (172.19.199.2), which is reachable from the host. If you set this value to whatever IP the mailman-core is assigned and re-create the containers (or just re-start and run `mailman aliases` in mailman-core to re-generate transport_maps), it would work out. Also, I see your docker-compose.yaml configuration (`MAILMAN_CORE_IP: 172.19.199.2`) is not consistent with your output of `mailman conf`([webservice] hostname: 172.19.199.5`). I am not sure how that happened though, just wanted to point it out. This *might* cause the rest runner to die to and thus Postorius/HK wouldn't work. Hope that was helpful! -- Abhilash Raj maxking(a)asynchronous.in

8 years, 10 months

Re: Issues with migrating from Mailman2 to Mailman 3

by Mark Sapiro

On 9/22/19 10:29 AM, Uwe Grasshoff wrote: > Hello all, > > I'm currently trying to convert a Debian based mailman2 installation to > a docker based mailman3 installation. > I successfully running the mailman-web and mailman-core containers > together with the database container but I'm struggling with the import > of the old mailing lists. In the core container I'm running this two > commands for every mailing list: > > mailman create mailman(a)example.com > mailman import21 mailman(a)example.com > /oldmailman/lists/mailman/config.pck > > Then I'm switching over to the mailman-web container and running this > two commands: > > python3.6 manage.py hyperkitty_import -l mailman(a)example.com > /oldmailman/archives/private/mailman.mbox/mailman.mbox > python3.6 manage.py update_index_one_list mailman(a)example.com > > I'm getting no errors or something else which could indicate a problem. > After that I'm looking into the web interface > http://example.com/postorius/lists/ > There I can only see the public mailing list and the private ones are > not shown there (as expected). Everything up to this point is expected behavior. > When I then try to login with the List > Manager credentials of the lists (from mailman2) I can't login in. So I > thought maybe I have to "register" myself again to than get access to > the list management. > So I tried that but when I filled out the form and click "Register" I'm > presented with an error page which titles "Serverfehler" (Server error > in german) and the message "An error occurred while processing your > request." I'm not sure about the error, but the import21 process registered you so what you need to do is go to the Login page, click "Forgot Password?" and then request a password reset. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 10 months

Re: Upgrade-path from Ubuntu18LTS to recent mailman release

by Stephen J. Turnbull

Stefan Bauer writes: > thanks alot. That looks promising. Can we just copy the current > mailman3-database and take the configurations or is there a specific > migration path we have to follow? Much of the documentation on mailman.readthedocs.io discusses migrations and upgrades. You should read those for general hints. The distro Mailman to venv Mailman case is more discussed here on the mailing list than in those documents. I don't have pointers to those threads or the time to look offhand, maybe over the next few weeks as I work on our GSoC project. If you do find any, and would post them here, I'll make sure they get into the docs. The main thing is to backup Mailman configs (probably in /etc/mailman or /etc/mailman3) and the backend database (core, Postorius, possibly HyperKitty depending on configuration, and the django-mailman auth stuff) before trying to migrate. (For the backend database I would just dump the RDBMS unless non-Mailman content is really huge.) The nature of the virtualenv install is such that it *will not* overwrite any of the distro files at all (as long as you put it in /usr/local or /opt). However, you want to preserve the configs and database and reuse them, so those *must* be backed up. > We are currently running 3.1.1-9 (Ubuntu 18). Ubuntu 18 is probably old enough that you need to be careful about MySQL and its derivatives. The specific problems are (1) you need to specify the right UTF-8 variant for the coding system, and (2) more recent versions of Mailman tend to make certain records overflow. If you're using PostgreSQL these caveats *do not* apply. If you're using sqlite3 (I doubt it, but just for completeness) you should change to PostgreSQL or MySQL. If you're using something else (same caveat), I can't really say. Probably somebody out there is using Oracle or whatever, but we don't know about that. :-) Steve

4 years, 3 months

Re: Digests not working correctly

by Mark Sapiro

On 6/4/23 18:35, Joel Lord wrote: > > The periodic digests do seem to be coming out. I also now have > confirmation that the one message in this morning's digest that was from > May 4th was also included in the last digest back on May 4th, so it > seems that the one message was left behind in the digest queue when the > periodic digest was sent. I don't see how that can happen. The process that sends a digest renames the var/lists/<list-id>/digest.mmdf mailbox file in which the messages are accumulated to var/lists/<list-id>/digest.<volume>.<issue>.mmdf, where <volume> and <issue> are the volume and issue numbers of that digest, and then queues a message in the `digest` queue to tell the digest runner to create the digest from the messages in that mbox and send it. Thus, it leaves no var/lists/<list-id>/digest.mmdf mailbox file behind and that is created anew when the next post arrives. Further, if there is a non-empty digest.mmdf file, its messages should be sent no later than the next 11 PM `cron digests`. > There was one earlier message to the list > back on May 4th, before the one that got duplicated, but I can't tell if > that triggered a size-based digest to be sent: the logs aren't clear > enough on that detail for me to tell. OK > Just to inform things: > > (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep mailman > django-mailman3==1.3.9 > mailman==3.3.8 > mailman-hyperkitty==1.2.1 > mailman-web==0.0.6 > mailmanclient==3.3.5 > (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep hyper > mailman-hyperkitty==1.2.1 Actually, it's HyperKitty, not hyperkitty, but I assume HyperKitty is up to date as are the others. > (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep post > postorius==1.3.8 > > -- 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

Re: Mailman 3 - Header Filter

by Henrik Rasmussen

Mark Sapiro wrote: > On 4/22/19 2:34 PM, Thomas Lehker wrote: > > I am a Mailman neophyte and need help with filtering posts based on the subject field. We have a few list owners that want 'Out of Office' replies discarded. When using the below syntax in Postorius/Header filter the post is not discarded but ends up in 'Held Messages'. Is there any syntax I am missing or a setting in the lists that needs to be disabled/enabled to get these posts dropped? Any help is much appreciated. > The issue may be that in Mailman core's 'builtin' chain, the checking of > header_matches occurs after the check for member moderation so if the > member moderation check results in the message being held, the > header_matches aren't checked. There may me a newer thread about this, but I haven't found it. In my case I would be more interested in holding or discarding mails with subject 'Out of Office' if the mail would otherewise be send the to the list members due to a non-moderated list. I would emagine that the order of "check for member moderation" and header_matches would not be significant if holding or discarding the mail due to header_matches, am I right? 🤞🏻 If so, I would think that Header "subject:" or "subject" with Pattern "^(?i)(.*)autosvar(.*)" - without the double quotes - and Function "Hold for moderation" or "Discard" should either hold or discard any message with "Autosvar" (danish word for "Out of Office reply") somewhere in the subject, but that doesn't happen. What is the correct syntax? I know that filtering out Out of Office replies is just as hard as spam filtering, since it varies, but at least there is some kind of consistency in the wording, so I would give it a try. *) In a prevous mail I was told that ^ would tell Mailman that it is a regex. -- Henrik Rasmussen her(a)adm.ku.dk Copenhagen, Denmark

2 years, 10 months

Mailman-users search results for query "Postorius"