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

[MM3-users] Re: Mailman/Django-allauth integration with Yahoo

by Mark Sapiro

On 8/4/24 03:35, Дилян Палаузов wrote: > > Then I get a site, partially in English, partially localized. It is in my domain at address /mm3/accounts/confirm-email/ , and states: > > Messages: Confirmation of email address sent to ...(a)yahoo.com > Menu: Entrance \r\n New registration > > Confirm your email address: > > We have sent an email to you for verification. Follow the link provided to finalize the signup process. If you do not see the verification email in your main inbox, check your spam folder. Please contact us if you do not receive the verification email within a few minutes. I'm not certain, but it looks like you are signing in to a new account and django-allauth is creating the account with the address from yahoo and is asking you to confirm. > I have indeed received an email, which states: > New signin from … Hi, Your Yahoo account … was just used to sign in on …. If you did this, you’re all set. If not, please use this link to stop sharing, and create a new password. Have a great day! Thanks,Yahoo > > So, the /account/confirm-email states I have received an email for verification, but the email sent says no verification is needed, I am all set up. > > Any idea what can I improve? This appears to be a glitch in the new account verification process. In any case, it's a django-allauth issue, not a Mailman issue. Once you have gone through this dance, what happens the next time you sign in via Yahoo. > In addition https://gitlab.com/mailman/mailman-suite/-/blob/master/mailman-suite_projec… suggests adding in settings.py: > > SOCIALACCOUNT_PROVIDERS = {'openid': {'SERVERS': [dict(id='yahoo', name='Yahoo', openid_url='http://me.yahoo.com')]}} > > which I have not done. That is, I do not use the “openid” provider, but the “yahoo” provider. Do I have to use the OpenID provider when using Yahoo? I don't think it would matter. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 1 month

[MM3-users] Re: ModuleNotFoundError: No module named 'mailman_web'

by Mark Sapiro

On 11/8/23 14:47, gordon(a)dickens.com wrote: > > Basically, it does not appear that mailman nor the runners are active and rebooting does not help. "/opt/mailman/venv/bin/mailman start" generates errors as follows: > >> Traceback (most recent call last): >> File "/opt/mailman/venv/bin/mailman", line 6, in <module> >> from pkg_resources import load_entry_point >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3248, in <module> >> @_call_aside >> ^^^^^^^^^^^ >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3223, in _call_aside >> f(*args, **kwargs) >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 3261, in _initialize_master_working_set >> working_set = WorkingSet._build_master() >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 617, in _build_master >> ws.require(__requires__) >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 956, in require >> needed = self.resolve(parse_requirements(requirements)) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 815, in resolve >> dist = self._resolve_dist( >> ^^^^^^^^^^^^^^^^^^^ >> File "/opt/mailman/venv/lib/python3.11/site-packages/pkg_resources/__init__.py", line 856, in _resolve_dist >> raise DistributionNotFound(req, requirers) >> pkg_resources.DistributionNotFound: The 'mailman==3.3.5' distribution was not found and is required by the application First of all, when running /opt/mailman/venv/bin/mailman you need to specify the -C option with the path to mailman.cfg, i.e. ``` /opt/mailman/venv/bin/mailman -C /etc/mailman3/mailman.cfg start ``` Can you run the mailman command without a subcommand. I.e. ``` /opt/mailman/venv/bin/mailman -C /etc/mailman3/mailman.cfg ``` should just produce a list of subcommands. Does it do that or produce the same error as above? I don't understand the above error. I think the content of /opt/mailman/venv/bin/mailman should be ``` #!/opt/mailman/venv/bin/python # -*- coding: utf-8 -*- import re import sys from mailman.bin.mailman import main if __name__ == '__main__': sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) sys.exit(main()) ``` Which doesn't correlate with the above traceback. What is yours? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 10 months

[MM3-users] Re: upgrading in FreeBSD 13.1-p7: problem with aiosmtpd and lmtp runner

by Mark Sapiro

Guillermo Hernandez (Oldno7) wrote: > I thought I said it: I reboot this server everyday at 06:40 CEST time. > That's why I'm sure it's not an undetected problem for weeks. The lists > in this last upgraded server are with daily traffic. I'm suscribed to all. I've looked at this a bit further. Prior to Mailman core 3.3.4 we required aiosmtpd>=1.1. In 3.3.4 we required aiosmtpd>=1.4.1 and now we require aiosmtpd>=1.4.3. The code in aiosmtpd that triggers the issue in the socket module was added in aiosmtpd==1.3.1. So it is likely that your prior Mailman core version was <3.3.4 and your aiosmtpd dependency was <1.3.1, so the Mailman upgrade would also have upgraded aiosmtpd to a version which triggered the socket issue.

2 years, 5 months

[MM3-users] Re: Mailman3 Setup

by George R. Kasica

Mark: These all reference the virtual environment setup, which is fine if I need to go with that. I’ve already installed the components etc. As a “standard installation. Do you know of a good doc that would help me set up in a non-container environment – just the native OS – Ubuntu 20.04 LTS. If I need to go with a virtual environment, do I need to uninstall what I have out there and what’s the best way to get all the added bits out? --- George R. Kasica Phone: +1 414 732 8503 Fax: +1 206 374 6482 Owner Netwrx Consulting Jackson, WI USA gkasica(a)netwrx1.com http://www.netwrx1.com<http://www.netwrx1.com/> From: George R. Kasica <gkasica(a)netwrx1.com> Sent: Sunday, June 5, 2022 10:32 To: mailman-users(a)mailman3.org; Mark Sapiro <mark(a)msapiro.net> Subject: Re: [MM3-users] Re: Mailman3 Setup Thank you! Will take a look. — ===[George Kasica]=== 🇺🇦 On Jun 5, 2022, 10:29 -0500, Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>>, wrote: On 6/5/22 06:26, George R. Kasica wrote: Hello: I'm in the process of setting up Mailman3 on Ubuntu 20.04. I have the following Environment, and please ask if I left something needed out: Postfix Apache2 MySQL Mailman3 (all 3 bits mailman3, mailman3-web, python-mailman-hyperkitty) The install SEEMS to have worked, but I'm looking for a guide for setup now. I used to run 2.1 about 18 months ago, but the server failed, and I never reinstalled it. I figured now, with a newish Ubuntu 20.04LTS Server, I'd go the mailman3 route...I've seen MANY posts of issues getting MM3 working with 20.04. Should I go back to 2.1, or what is the best way to get mailman-3 configured? You should definitely go with Mailman 3. The docs are at https://docs.list.org/ (redirects to https://docs.mailman3.org/en/latest/) I suggest you start by looking at https://docs.mailman3.org/en/latest/install/virtualenv.html -- Mark Sapiro <mark(a)msapiro.net<mailto:mark@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<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

3 years, 3 months

[MM3-users] Re: Message is received but is not sent out. Another, similar message, is processed fine.

by Mark Sapiro

On 6/26/23 11:00 PM, Allan Hansen wrote: > > I also see this in queue/shunt: > > mailman@list:~/var/queue/shunt$ ls -ltr > total 88 > -rw-rw---- 1 mailman mailman 7168 Feb 17 23:03 1676703781.903885+fdcba88c680f50a0799c672cd0abe82e4bfe19b3.pck > -rw-rw---- 1 mailman mailman 19821 Apr 2 07:08 1680444501.0831451+e110b8c5c20ba3f87c1cea1c5f38e74a6cf8f1c5.pck > -rw-rw---- 1 mailman mailman 19489 Jun 18 11:52 1687114364.41209+1684717da96ff76d1ce773a0cf39c5f8b63e9078.pck > -rw-rw---- 1 mailman mailman 20274 Jun 18 19:01 1687140067.64057+7f77c1ebca490831f58ef9cfde06109081a4e7d6.pck > -rw-rw---- 1 mailman mailman 20085 Jun 26 17:18 1687825091.8457294+478565324778f2eb6f0fecaeccbd29596edaef53.pck > > The three last entries coincide with the captured messages. I suggest you examine those with `mailman qfile` and remove any irrelevant or duplicate messages. If you have mailman.log from Feb or Apr, you could find the error that caused the shunting and maybe fix it. > Finally, in the captured message source (the last which was Cc'd to me) I do see this: > > Content-Type: text/plain; charset="iso-8859-8-i" > > Which matches the complaint in the mailman log. If you want to fix and unshunt any of these, you could do, e.g., in `mailman shell` (watch out for wrapped lines) ``` >>> import pickle >>> file = '1687114364.41209+1684717da96ff76d1ce773a0cf39c5f8b63e9078.pck' >>> with open(file, 'rb') as fp: ... msg = pickle.load(fp) ... msgdata = pickle.load(fp) ... >>> msg.replace_header('Content-Type', 'text/plain; charset="iso-8859-8"') >>> with open('/path/to/.pck/file', 'wb') as fp: ... pickle.dump(msg, fp) ... pickle.dump(msgdata, fp) ... >>> ``` > Another difference: > The posted message shows > Content-Transfer-Encoding: base64 > The shunted message shows > Content-Transfer-Encoding: quoted-printable That's not important. > My question thus changes to: > > a. Should she be doing something special when sending to the lists? Get her mail client to send utf-8 or iso-8859-8 encoded messages, not iso-8859-8-i. > b. If not, is my setup in need of change? See Steve's reply. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 2 months

[MM3-users] Re: Sort Lists in Postorious

by Simon Coggins

A feature request to this for me would be to search the lists. We have over 200 lists and it's hard to find the one you need to work on as an admin :) Sent from my iPhone On 1 Dec 2021, at 08:45, Mark Sapiro <mark(a)msapiro.net> wrote: On 11/30/21 1:26 PM, Jonathan Wright via Mailman-users wrote: > Is there a way to sort the lists displayed on the main page of Postorious? They are sorted alphabetically by list name. There's not an option for another sequence. -- 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/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>

3 years, 9 months

[MM3-users] Re: Member Issue Discovered

by Mark Sapiro

On 10/19/20 12:03 PM, Brian Carpenter wrote: > Hi Everyone, > > If I subscribed to a MM3 list with barn(a)emwd.com with the name of Barn > Quilter. It shows up in the member roster. So far, so good. I then > unsubscribe barn(a)emwd.com. It no longer shows up in the member roster. > So far so good. I then resubscribe barn(a)emwd.com with either no name or > Barn User and it shows up in the member roster as barn(a)emwd.com with the > name of Barn Quilter. Is this a known bug and has been fixed with the > latest release? I suppose it could be considered a bug, but what's happening is your initial subscribe created a user and and address and set the user's preferred address to the created address. It also set the display_name of the address and it subscribed the user to the list or possibly the address to the list depending on what actually did the subscribe. When the user/address was unsubscribed, it is removed from the list's membership and the list was removed from the user's memberships, but the user and address still existed. Then when you resubscribed, the existing user/address was made a member of the list, but not updated so the "new" display_name was ignored. I think this is also the case if the original address had no display_name. You could say this is a bug and the display_name associated with this new subscription should replace the prior one, but what if that address was subscribed to other lists and didn't want the display_name changed on those lists. Ideally (perhaps) there could be multiple address records with the same email address and different display_names, but address records are keyed by email address, so this can't be. One workaround would be for a user who wanted to have an address with different display_names for different lists to have multiple addresses like address+list1(a)example.com, address+list2(a)example.com, etc. Is this really an issue that should be fixed or just a curiosity? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: Implicit Destination Meaning

by Mark Sapiro

On 2/8/21 6:41 PM, Brian Carpenter wrote: > I just migrated a MM2 list to MM3. The client had no problem sending > posts to his list with MM2. However when he posted to his MM3 list, it > showed up in the moderation queue: > > ============ > Your mail to 'dogs(a)lists.redacted.org' with the subject > > mailing list changes > > Is being held until the list moderator can review it for approval. > > The message is being held because: > > Message has implicit destination > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. > =========== > > Is there a List Setting somewhere that needs to be adjusted to allow > this sender to post without moderation? There are a few things going on here. First, the list setting is require_explicit_destination. This is in Postorius under Settings -> Message Acceptance. If this is False or No, the implicit destination rule will never hit, but clearly it is Yes/True and should have been imported from the 2.1 list so it was probably True there too. When True, it means the list posting address or an acceptable alias must be explicitly addressed (in To:, Cc:, Resent-To: or Resent-Cc: of the post. An acceptable alias is a literal address or pattern matching addresses. These are also in Settings -> Message Acceptance and should have been imported from MM 2.1. For example, if the list's posting address is list(a)example.com, but you can also post to list(a)lists.example.com, list(a)lists.example.com should be in acceptable aliases. The most likely explanation here is that the post is being sent to a subdomain which is not the list's canonical posting address or vice versa. The reason this worked in MM 2.1 but not in MM 3 is in MM 2.1 if the list name matched, the check passed even if the domains didn't, but that is not the case in MM 3. The solution is to add the 'other' addresses to Acceptable aliases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: Only held_messages for 1 (of 3) list has "Mailman REST API not available" message.

by Mark Sapiro

On 1/7/22 4:51 AM, Duane Raymond wrote: > Thanks Mark. > > This sounds like a database problem. What's in Mailman >> core's var/logs/mailman.log ? > > > In the var/logs/mailman.log there was a permission error for the messages/ > store folders. I noticed that some of the mm file and directories were > owned by root vs 'mailman' user (what Brian uses when he set up the mm3 > server). So after resetting all to mailman (I believe others use 'list') `list` is used by the Debian/Ubuntu packages. We recommend `mailman`. These ownership issues are often caused by running Mailman core as `root`. This causes certain things to be created/owned by `root` and when Mailman core is later run as `mailman`, it can't access these things. To guard against this, Mailman core >=3.3.5 will refuse to run Mailman as `root` unless a `--run_as_root` option is specified. > Now I get the error below with the error from mailman.log. ... > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman/rest/post_moderation.py", > line 77, in _make_resource > resource['msg'] = msg.as_string() > AttributeError: 'NoneType' object has no attribute 'as_string' This is https://gitlab.com/mailman/mailman/-/issues/856, fixed in Mailman 3.3.5 by https://gitlab.com/mailman/mailman/-/merge_requests/819. You can apply this patch to avoid the issue. ``` --- a/src/mailman/rest/post_moderation.py +++ b/src/mailman/rest/post_moderation.py @@ -74,7 +74,15 @@ class _HeldMessageBase(_ModerationBase): # resource. XXX See LP: #967954 key = resource.pop('key') msg = getUtility(IMessageStore).get_message_by_id(key) - resource['msg'] = msg.as_string() + if msg is None: + resource['msg'] = """\ +Subject: Message content lost +Message-ID: {} + +This held message has been lost. +""".format(key) + else: + resource['msg'] = msg.as_string() # Some of the _mod_* keys we want to rename and place into the JSON # resource. Others we can drop. Since we're mutating the dictionary, # we need to make a copy of the keys. When you port this to Python 3, ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Mark Sapiro

On 1/30/22 08:22, Jacob Sievert via Mailman-users wrote: >> Yes they should. This is >> https://gitlab.com/mailman/mailman/-/issues/257 fixed in Mailman core >> 3.3.5. Also in Mailman 3.3.5 is a new Task runner that runs periodic >> tasks, one of which is to remove orphaned pendings. > Hmm our running system right now already was on 3.3.5 since a few days > after release. > But maybe all of those were still from before. Task runner cleans some things, but not all. ...>> # Prior to Mailman 3.3.5, some tokens for user confirmations were >> pended with >> # too long a lifetime. This script removes those pendings based on >> when they >> # were pended and the configured pending_request_life rather than their >> # expiration. > With the script we went down to around 16k entries in pendedkeyvalue > removed were the following: > expunged 6932 orphaned pended held messages When a message is held, two tokens are pended; one for the moderator and one for the user. Notification to the user doesn't currently include the user's token or instructions on removing the held post; that needs to be done, but the token is pended anyway. Prior to 3.3.5, when a held message was handled, the moderator's token was removed, but not the user's. That's what these are. > expunged 254 expired held messages > expunged 21 expired (un)subscription confirmations Prior to 3.3.5, some things were pended with excessively long lifetimes. The script expires these based on 3 days for user confirmations and 180 days for moderator actions. The above were older than that. > This shows that there were a lot of things in an unfinished state to my > understanding in our system. > For a time this system was running with less RAM than it should have > had. So maybe some of the problems came from there. These were all problems with pre 3.3.5 Mailman, not specific to your system. -- 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

Search results for query "sapiro"