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

[MM3-users] Re: users leaking across virtual hosts

by Mark Sapiro

On 3/25/22 12:49, Stanisław Findeisen via Mailman-users wrote: > Hi > > We are hosting several virtual hosts (mail host : web host is a 1:1 mapping with identical names), works fine, but it looks user accounts are somehow global, i.e. registering a new user in a new virtual host doesn't work if the user name or e-mail address are already in use in another virtual host. This happens on the Hyperkitty sign-up page: /accounts/signup/ , with the errors being "A user is already registered with this e-mail address." and "A user with that username already exists.". I am assuming this is a well-known limitation, which would require a serious internal redesign to fix; correct? These user registrations and logins are Django things so yes, they are global within the Django instance. > I was able to successfully login in the browser to a vhost using my user credentials from the original vhost (the one where the account was created) (the password was not auto-filled, of course, because of a different domain name). But how safe is this? How about subscribing to lists, posting etc.? Is this going to mess things up somehow? I don't think it's a problem. The user is a Django user for the web UI. The fact that there is or isn't a Django user with a particular email address has nothing to do with whether that address can post to a list. The user can subscribe to lists or not. The user can manage her subscriptions for lists to which she is subscribed and can subscribe to lists or not as controlled by list settings. Basically, registering as a user allows you to authenticate as that user for the web UI only. If you wanted to separate these user registrations by vhost, you'd need to run separate Django instances for each vhost, but I don't see a need to do that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: Errors while importing mm2 list archives - SOLVED

by Mark Sapiro

On 12/20/22 22:25, Odhiambo Washington wrote: > > In my case, running `mailman` without any arguments just makes it grok :) > > (venv) [mailman@gw ~/mm]$ mailman info ... > *config file: /opt/mailman/mm/mailman.cfg* That's because it first looks in the current directory for `mailman.cfg` and only if it doesn't find it there does it look in /etc/mailman3. >> Ultimately, when I did the import, there was only one email from the >>> archives that failed to be imported - which I honestly don't mind, but >>> maybe there is a solution for this >>> "'utf-8' codec can't encode character '\udcae' in position 331: >> surrogates >>> not allowed" ?? >> >> >> If you provide a copy of that message from the mbox, either on the list >> or to me directly, I'll investigate. >> > > A mbox file containing that email and the associated thread can be > downloaded from here: > https://webmail.kictanet.or.ke/~wash/chunk_7.txt.gz The offending message is multipart with an attached message/rfc822 part and that part has a preamble which in bytes is b'This document is a Single File Web Page, also known as a Web Archive file. If you are seeing this message, your browser or editor doesn't support Web Archive files. Please download a browser that supports Web Archive, such as Windows\xae Internet Explorer\xae.' The '\xae' is an iso-8859-1 encoding for '®', but no charset is specified for this preamble so email message parsing ends up decoding those as surrogates '\udcae' which throws the exception when hyperkitty.lib.incoming.add_to_list() in trying to save the attachment does `att.set_content(content)`. Normally, when messages to be archived arrive from core via mailman_hyperkitty, the surrogates are replaced by email.utils._sanitize(), but this doesn't happen with messages from hyperkitty_import. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

[MM3-users] Re: integrating mm3 with postfix / lmtp

by Mark Sapiro

On 10/25/2017 05:41 PM, Fabian A. Santiago wrote: > > No to the domains part and I think virtual alias maps is needed: > > mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx in BOTH virtual_mailbox_domains and relay_domains > Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx in BOTH virtual_mailbox_domains and relay_domains > Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE: reject: RCPT from pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1 <test123@xxx>: Recipient address rejected: User unknown in virtual mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP helo=<[10.0.0.29]> (above slightly sanitized for return to the list) The issue here is your list domain cannot be a virtual_mailbox_domain or a virtual_alias_domain. I have the same issue on mail.python.org where we have both Mailman 2 and Mailman 3 lists @python.org. and python.org is a virtual_alias_domain. I have a group of MRs for a branch that implements "alias_domains" to deal with this. Basically it works by creating another (virtual_alias_maps) postfix_vmap mapping to map list addresses @python.org to addresses @x.python.org. Then the postfix_domains and postfix_lmtp maps have the x.python.org domain and there is a patch to mailman/runners/lmtp.py to map the x.python.org domain back to python.org. The various MRs are <https://gitlab.com/mailman/mailman/merge_requests/202> for the core, <https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the REST bindings used by Postorius and <https://gitlab.com/mailman/postorius/merge_requests/186> to be able to set an alias_domain via Postorius. That's not all implemented at mail.python.org. What's there is the basic Postfix config, a bash script the generate the new mappings from the old and a simple patch to mailman/runners/lmtp.py. So, the bottom line is it can be done and it's in process, but it won't really be supported until Mailman 3.2. In the mean time, you just need to have a separate domain for your lists that isn't a virtual_*_domain. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years

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

by Mark Sapiro

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

5 years, 4 months

[MM3-users] Re: All addresses in a bounced list posting seem to be considered as bouncing

by Mark Sapiro

On 9/30/22 12:41, Andy Smith wrote: > > This just happened again. As a refresher, the issue I'm seeing is > that Mailman registers a bounce against addresses that aren't > subscribed, including addresses for the list itself and for the > -leave address that is in some footer text. > > Here's the bounce.log: > > Sep 30 17:12:25 2022 (8428) Member [elided1](a)[elided1].force9.co.uk on list users.mailman.bitfolk.com, bounce score = 1. > Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email users(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com > Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email mailto:[elided2]@gmail.com is not a subcriber of users.mailman.bitfolk.com > Sep 30 17:12:25 2022 (8428) Member [elided2](a)gmail.com on list users.mailman.bitfolk.com, bounce score = 1. > Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email users-leave(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com > Sep 30 17:12:25 2022 (8428) Member [elided3](a)[elided3].org.uk on list users.mailman.bitfolk.com, bounce score = 1. > > I have elided parts of the email addresses of real subscribers. > > Attached is the actual non-delivery report from the MTA that > triggered this. In it I have done my best to elide the names and > addresses of real people, but nothing else. They match the same > elisions from the bounce log. What is your version of flufl.bounce? I made one change to your attached DSN. In the message/selivery-status part, I changed Final-Recipient: rfc822;[elided1](a)[elided1].force9.co.uk to Final-Recipient: rfc822;elided1(a)elided1.force9.co.uk and processed the message with flufl.bounce.scan_message() which returned the single address elided1(a)elided1.force9.co.uk. I suspect this is https://gitlab.com/warsaw/flufl.bounce/-/issues/12 which was fixed in flufl.bounce 4.0 and upgrading to 4.0 will fix this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 1 month

[MM3-users] Re: import21 detailed usage instructions in 2024

by Mark Sapiro

On 6/2/24 4:28 PM, Keith Christian wrote: > 1 Soon, I will be executing the first test imports from > Mailman2.1 to Mailman3.9. > > 2 Planning to copy over the entire production Mailman2.1 to a new > directory structure on the Mailman 3.9 machine. > > 3 Expecting that all .mbox and .pkl files will be present and no > special work has to be done to bring them over will a "full" > mailman2.1 copy. That's correct. > 4 Can the import21 program find the mailman2.1 .mbox and .pkl > files on its own and process them? No. `mailman import21` needs to be given the path to the config.pck to import and hyperkitty_import needs to be given the path to the .mbox. > 5 Other than the mailman2.1 instance being shut down, any other > prep that needs to be done? Ideally there are no held messages or other moderator requests for the MM 2.1 list, i.e. deal with these before shutting down the list. If there is a MM 2.1 digest.mbox it needs to be moved and converted for MM 3 I have attached a bash script I use on mail.python.org to migrate lists. Paths and some other things are specific to that installation, but you may find it useful. It calls a move_digest script which I've also attached > 6 Any special command line parameters to be aware of for import21? Usage: mailman import21 [OPTIONS] LISTSPEC PICKLE_FILE Import Mailman 2.1 list data. Requires the fully-qualified name of the list to import and the path to the Mailman 2.1 pickle file. Options: -c, --charset TEXT Specify the encoding of strings in PICKLE_FILE if not utf-8 or a subset thereof. This will normally be the Mailman 2.1 charset of the list's preferred_language. -h, --help Show this message and exit. > 7 Is there a list of troubleshooting steps for commonly > encountered migration issues? Not that I'm aware of. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

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

by Mark Sapiro

On 6/22/20 12:21 PM, Ruth Ivimey-Cook wrote: > > The localhost address is coming in via the hosts file, which is a > relatively standard practice IMO. I could change it, but then perhaps > other things would not work. I would prefer to be able to specify what I > need. There are also things like systemd-resolvd which will do the > localhost-substitution for you even if /etc/hosts doesn't. I have done further testing. See my comment at <https://gitlab.com/mailman/mailman/-/issues/735#note_366074014>. You need to set hostname: in mailman.cfg to the actual external IP address of the Mailman host machine or to a name which resolves to that IP both internally and externally, and also set that host name/IP in the MAILMAN_REST_API_URL setting on the Postorius machine. > I did try with the gunicorn patch Mark mentioned (host = "0.0.0.0") and > changing the cfg file hostname back to the full name of the host, and > that now works!! -- in that the problem I showed earlier is gone. Remove that patch and do the above. > However I then get another issue. From the mailman.log file I now see in > the last few lines. For clarity I've numbered them like this "{1}": > > {1} [22/Jun/2020:00:58:24 +0000] "GET /3.1/domains HTTP/1.1" 200 320 "-" > "GNU Mailman REST client v3.3.1" > {2} [22/Jun/2020:00:58:24 +0000] "GET /3.1/domains/ch-bc.org.uk > HTTP/1.1" 200 215 "-" "GNU Mailman REST client v3.3.1" > {3} [22/Jun/2020:00:58:24 +0000] "GET > /3.1/domains/greyarea-web1.cam.ivimey.org/lists?advertised=true&count=0&page=1 > HTTP/1.1" 404 26 "-" "GNU Mailman REST client v3.3.1" > > At this point the browser screen reports "Something went wrong" and the > message "HTTP Error 404: {"title": "404 Not Found"}" Make the above changes and see if that solves this. If not, let us know and we'll try to help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

[MM3-users] Re: Hyperkitty 403 Forbidden Error

by Mark Sapiro

On 1/23/22 07:41, Josef Dietl wrote: >> >> The issue here is accessing the hyperkitty API. The base URL for these >> accesses is configured in mailman-hyperkitty.cfg. From what I see here, >> that is something like `http(s)://host.example.com/hyperkitty/` If you >> append `api/` to that base URL and go there in a web browser do you get >> a page of documentation of the HyperKitty API? If so, then figure out >> why it works from a web browser and not when Mailman core does it. If >> you get the 403, figure out why. This is probably an nginx issue. > > Seems like an nginx issue indeed. However, I'm an apache guy, trying to re-educate myself on nginx. > OK, here's the result of changing mailman-hyperkitty.cfg from `http(s)://host.example.com/hyperkitty/` to `http(s)://host.example.com/hyperkitty/api/` Do not make this change in mailman-hyperkitty.cfg. That will produce 404's for sure. This was only a suggestion to try from a browser. > Yes, if I open things from the web browser, I do get the HyperKitty API doc. OK. That means you can access HyperKitty's API from a browser at `http(s)://host.example.com/hyperkitty/api/`. This is the same thing Mailman core is doing if `base_url` is set to `http(s)://host.example.com/hyperkitty/`, so what's the difference between Mailman core's access via mailman-hyperkitty and your's via the web browser. For further diagnosis, you might try `wget -O- http(s)://host.example.com/hyperkitty/api/` on the Mailman server. > With what follows below, I guess it's a timeout: Processing a message takes longer than rendering a HTML document. > > Jan 22 20:26:27 2022 (149435) ACCEPT: > <AM0PR04MB4785365CA1BB735884E149CEC25C9(a)AM0PR04MB4785.eurprd04.prod.outlook.com> > Jan 22 20:26:28 2022 (149439) HyperKitty failure on https://[FQDN]/hyperkitty/api/api/mailman/urls: Do not include the api/ in base_url. That was just for testing with a web browser or wget/curl. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 9 months

[MM3-users] Re: Pd CRON mailman gatenews

by Mark Sapiro

On 3/15/23 23:31, Pierre Malard via Mailman-users wrote: > File "/usr/lib/python3/dist-packages/flufl/lock/_lockfile.py", line 502, in _read > with open(self._lockfile) as fp: > PermissionError: [Errno 13] Permission denied: '/var/lib/mailman3/locks/dbcreate.lck' > —————————————————————————————————————————————————— > > CRON content: > —————————————————————————————————————————————————— ... > # Every 15 minutes, gate messages from usenet to those lists which have the gateway configured > */15 * * * * list if [ -x /usr/bin/mailman ]; then /usr/bin/mailman gatenews; fi Do you have any list's for which Gateway to mail is set to yes or for which there is a Linked Newsgroup?. If not, running gatenews is superfluous. > I thought, given the last line, a problem of rights. It is not the case ! The directory and the files contained in /var/lib/mailman3/locks belong to the user "list". > When I run "/usr/bin/mailman gatenews" by hand everything is correct. Can you do `sudo -u list cat /var/lib/mailman3/locks/dbcreate.lck`. If that succeeds, this may be a SELinux or other security manager issue. > The questions I have are these: > We have 8000 files "dbcreate.lck..." in the directory "/var/lib/mailman3/locks". > What are they for? > Can we delete them? They are probably all orphaned lock files due the the gatenews failure. To be certain that none are current you could stop Mailman core. Then with Mailman core stopped, any files in /var/lib/mailman3/locks are orphaned and should be removed. > We have 2 files "master.lck..." dated from the day after tomorrow ! > What is this date? > Aren't these files the problem? Those files are normal. They are the master lock that prevents Mailman core from being started when it's already running. The future date is the way flufl.lock handles lock lifetimes. Locks when set have a lifetime, after which they can be broken. This is implemented in flufl.lock by setting the file's date that far into the future. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by Mark Sapiro

On 3/2/21 12:33 PM, David Partain via Mailman-users wrote: > On Tue, 2021-03-02 at 20:07 +0000, David Partain via Mailman-users > wrote: >> On Tue, 2021-03-02 at 19:56 +0000, David Partain via Mailman-users >> wrote: >> >> I assume this is because /usr/share/mailman3-web/manage.py, which >> has: >> >> '#!/usr/bin/env python' >> >> resolves to Python 2.7.17. >> >> Should I could try changing that to '#!/usr/bin/env python3' and see >> what happens? :) I could also uninstall python2 but that becomes >> more of a nail-biter... NO! Do not do that. >> I can report that the above doesn't help. Neither does just making >> /usr/bin/python link to /usr/bin/python3.6 >> >> I still get errors in mailman-web.log pointing to 2.7 as shown in my >> previous mail. > > If I force the issue by linking /usr/bin/python to /usr/bin/python3.6, > I start seeing: > > ModuleNotFoundError: No module named 'hyperkitty > > in mailman-web.log. > > I know next to nothing about python. Is > > pip install hyperkitty > > the right answer? No. > I have the following installed now: > > # dpkg -l | grep hyperkitty > python-django-hyperkitty 1.1.4-4 > python3-mailman-hyperkitty 1.1.0-4 > > but this version of Ubuntu has no python3-django-hyperkitty or I'd just > try installing that... This is all because you are using the Ubuntu 18.04 package which is about 4 years out of date and is from the era where HyperKitty, Postorius and django_mailman3 still ran under Python 2.1.7. Unless you want to remove the Ubuntu package and install everything with pip, you need to just stick with what you have that at least partly works and we'll try to determine how to fix the utf8mb4 issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

Search results for query "sapiro"