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

[MM3-users] Re: mailman import21 passwords

by Mark Sapiro

On 9/16/24 16:25, Sam Darwin via Mailman-users wrote: > > Why can't passwords be imported from mailman2 to mailman3? How difficult would it be to do? > (is there a link to where this is already explained? ) Mailman 3 users have a _password attribute which isn't actually used for anything. The importer used to set this from the MM 2.1 member's password, but this was dropped by <https://gitlab.com/mailman/mailman/-/merge_requests/565>. See <https://mail.python.org/archives/list/mailman-developers@python.org/thread/…> for a discussion of this. Also note that since member passwords were stored in plain text in MM 2.1 and periodically emailed, those passwords are inherently not secure and have possibly been exposed so setting that password, even though encrypted in MM 3, is not a good idea. As far as creating a Django user for an imported member, whether or not with the member's MM 2.1 password, it is at least as expensive as just encrypting the password and would result in poor performance. Further, and perhaps more importantly, Mailman 3 is modular. There is no guarantee that any Mailman Core installation into which a MM 2.1 list is imported actually also supports Django users for Postorius and/or HyperKitty. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

[MM3-users] Re: Settings | Alter Messages, Settings | DMARC Mitigations

by Mark Sapiro

On 9/22/25 11:53, Philip Bondi wrote: > Hello to all: > > I thought I should share. We have: > > Anonymous List: No > DMARC mitigation action: Wrap the message in an outer message From: the list. > > But our message weren't being wrapped. After I period of months, I experimented. Now I've realized that "DMARC wrapped message text" must contain some message. > > Now our messages are wrapped. I think what you observe is what's intended. If dmarc_wrapped_message_text is non-empty, the resultant message is the outer message From: the list and that message is Content-Type multipart/mixed with sub-parts text/plain containing the dmarc_wrapped_message_text and message/rfc822 containing the original message. If dmarc_wrapped_message_text is empty, the resultant message is the outer message From: the list with Content-Type message/rfc822 and that content is the original message. In either case there is an outer message From: the list with the original message in a message/rfc822 part. Whether you consider that wrapped or not is just a semantic issue, but the fact remains the the delivered message is a message From: the list which contains the original message in its entirety. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 3 weeks

[MM3-users] Re: Mail configuration

by Mark Sapiro

On 03/27/2018 03:43 PM, Stephen J. Turnbull wrote: > > My feeling is that you want to ask on Postfix channels, since I don't > see a good reason to involve Mailman itself in what is really a task > for the MTA. Mailman was deliberately designed to not know anything > about outgoing mail except a host and port to send to. Which brings up the point I've been meaning to post for days but it keeps slipping off the back burner and falling on the floor. I can think of a couple of ways to hack the code in Mailman 2.1 to select a different outgoing MTA by list. It can also be done in Mailman 3 by having separate MTA configs per list, but I can't give you a recipe off hand. But, the way I would do this is what you are presumably doing anyway. That is have separate Mailman installations on the old and new server. Then you can move the lists incrementally and gradually. Then all you need is a transport map in Postfix on the old server to route mail to the new server for the already moved lists, and then finally update DNS after all the lists are moved. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 8 months

[MM3-users] Re: duplicate dkim headers w/ AWS SES

by Mark Sapiro

On 6/2/20 9:44 AM, sunil soprey wrote: > Periodically, I've seen these errors from few senders, and wondering if community has a idea? Mailman - 3.3.1rc1 Tom Sawyer > > "554 Transaction failed: Duplicate header 'DKIM-Signature'" while sending AWS-SES as the MTA? > > Possible to strip from postfix? I've submitted a AWS ticket. It appears that AWS SES is intended only for delivery of locally generated mail and not mail that is received and resent by a mailing list or forwarding arrangement. This page <https://docs.aws.amazon.com/ses/latest/DeveloperGuide/header-fields.html> gives a list of a large number of headers that can appear only once in a message, among them are Delivered-To:, DKIM-Signature: and a few others that might legitimately appear more than once in messages from a mailing list. There are a couple of ways to remove incoming DKIM sigs. If you are signing with opendkim, there is a RemoveOldSignatures config setting which if true will remove existing signatures when signing. In Mailman itself you can put [mta] remove_dkim_headers: yes in mailman.cfg and Mailman will remove all DomainKey-Signature, DKIM-Signature and Authentication-Results headers from the message before delivery to the MTA. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

[MM3-users] Re: New Mailman 3 installation issues

by Mark Sapiro

On 5/19/21 11:50 AM, Sarah H wrote: > Hi Mark, > > I wanted to make another note on the documentation, the migration documents (https://docs.mailman3.org/en/latest/migration.html#fn2) reference using > > 'python manage.py hyperkitty_import' > > it should be > > 'mailman-web hyperkitty_import' That is a can of worms. It all depends on how you installed Mailman 3. If you follow the doc at https://docs.mailman3.org/en/latest/install/virtualenv.html, the django management command will be `mailman-web`, but installation in other ways can result in its being `manage.py` or `django-admin` or almost anything. For example, https://docs.mailman3.org/en/latest/pre-installation-guide.html#what-do-i-n… refers to a typical Django project in which the management command is `manage.py`. https://docs.mailman3.org/en/latest/config-web.html is inconsistent in itself in that it uses `mailman-web` in most places except the note about qcluster at https://docs.mailman3.org/en/latest/config-web.html#running-the-task-queue which also links to http://hyperkitty.readthedocs.io/en/latest/install.html#asynchronous-tasks which uses `django-admin`. I'm thinking that we should put a note about this near the top of https://docs.mailman3.org/en/latest/ and let it go at that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Block members from sending cc's and bcc's

by Mark Sapiro

On 7/18/25 5:37 PM, Cathryn McGuire wrote: > > The .* pattern did not do the job of blocking cc's and bcc's in the Header Filters of Affinity. It lets them go through, even as hold for moderation has been chosen. First, you can't filter on Bcc because Bcc is removed from the message before being sent. That's the whole point of Bcc. In otherwords, if I mail To: the list with Bcc: to others, the list never sees that Bcc: header and can't filter on it. As far as Cc is concerned, if in Header filters you have a rule with 'cc' in the header box and '.*' in the pattern box, the action box action should be applied to any message with a Cc: header. > I've asked EMWD to advise me because I think Affinity is very new, even though Brian Carpenter was developing it in 2020, is that correct? Affinity is not new, but it is a proprietary product of EMWD. If you have set the header filter as above and it is not working, only EMWD can help with that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months, 3 weeks

[MM3-users] Re: Mailman3 equivalent of list_owners binary

by Mark Sapiro

On 10/2/25 08:38, l.reilly(a)ucl.ac.uk wrote: > > I've tried using the command 'mailman members --role administrator LISTSPEC' whilst looping through each list from the output of 'mailman lists'. It almost does the job, but in cases where an owner has a display name set the sync fails as it cannot parse these lines. > > e.g. Cannot parse as valid email address (skipping): Smith, John <john.smith(a)example.com> The issue here is when the display name contains a comma or other special character, it should be quoted as in "Smith, John" <john.smith(a)example.com> to be parsed as an email address/display name. The absence of quotes in the output of `mailman members` is not really a bug as that output is intended only for humans, but you could apply this patch to provide them. ``` --- a/src/mailman/commands/cli_members.py +++ b/src/mailman/commands/cli_members.py @@ -112,7 +112,7 @@ if email_only or not dn: print(address.original_email, file=outfp) else: - print(f'{dn} <{address.original_email}>', + print(f'"{dn}" <{address.original_email}>', file=outfp) ``` Otherwise, you could supply the -e/--email-only option to `mailman members` to not include the display names in the output. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 1 week

[MM3-users] Re: "Something went wrong | Mailman REST API not available. Please restart Mailman core.

by Mark Sapiro

On 10/29/25 14:31, Hirayama, Pat wrote: > > The weird thing is that it is not all lists. Most of them seem to be fine. Which suggests to me that the issue is with a few lists, but not systemwide, so I think my settings in mailman.cfg, settings.py, settings_local.py are likely correct. So Postorius can connect to Mailman core's API on behalf of some, but not all lists. This is very strange. > For the problem lists, I see this in the log: > > ERROR 2025-10-29 18:38:56,784 7 postorius Mailman REST API not available > ERROR 2025-10-29 18:38:56,790 7 django.request Service Unavailable: /postorius/lists/obfuscated.name.lists.fhcrc.org/ > ERROR 2025-10-29 18:38:56,790 7 django.request Service Unavailable: /postorius/lists/obfuscated.name.lists.fhcrc.org/ > > So, Postorius can't communicate with the API, I guess? These are the normal messages when the REST API is not available. But it apparently is available for at least some API endpoints. What is the traceback from the ERROR 2025-10-29 18:38:56,784 7 postorius Mailman REST API not available error and what is in the web server logs? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 month, 2 weeks

[MM3-users] Re: old usernames appearing in mailman.log

by Mark Sapiro

On 6/26/23 10:12 PM, Ken Alker wrote: > --On Monday, June 26, 2023 5:03 PM -0700 Mark Sapiro <mark(a)msapiro.net> > wrote: >> >> Your urls.py file probably contains in its urlpatterns list >> ``` >> re_path(r'^mailman3/', include('postorius.urls')), >> re_path(r'^archives/', include('hyperkitty.urls')), >> ``` >> The simplest fix is to add >> ``` >> re_path(r'^postorius/', include('postorius.urls')), >> re_path(r'^hyperkitty/', include('hyperkitty.urls')), >> ``` >> to that list. > > I see many ursl.py files all over the system, but none that appear to be > where I'd expect them to be for processing by any executables. Is this > a file I should have copied over and edited, or created from scratch and > somehow missed? I don't see anything about it in the instructions at > <https://docs.mailman3.org/en/latest/install/virtualenv.html> (although > I do see a post from last July from someone stating it got missed in the > instructions back then). In your case, it is the one in /opt/mailman/venv/lib/python3.x/site-packages/mailman_web/, but it is not a good idea to change that as changes will be overwritten when mailman_web is updated. It's OK to not change it. Just do the following. >> Another way to fix this is in your mailman-hyperkitty.cfg, you have >> ``` >> base_url: https://lists.netlojix.com/hyperkitty >> ``` >> Change that to >> ``` >> base_url: https://lists.netlojix.com/archives >> ``` > > Done, and restarted both services, but I'm not seeing a difference when > I go to <https://lists.netlojix.com/hyperkitty/api/> (I was getting a > "Page not found", and still get that). That's because going to the 'hyperkitty' url won't work, but nothing should be doing that so it's OK if it doesn't work. Fixing mailman-hyperkitty.cfg will tell mailman-hyperkitty to use the 'archives' url, so now it should be working. The next post after you fixed it should archive OK and all the messages in /opt/mailman/mm/var/archives/hyperkitty/spool/ should also be archived and the files removed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 5 months

[MM3-users] Re: Is it possible to add non-members in regex format in Mailman 3 ?

by Mark Sapiro

On 6/16/20 7:09 AM, Shashikanth Komandoor wrote: > > But in mailman 3, I am not allowed to add the non members in > the regex format. Of course it is allowing me to add individual mail ids > and give permissions. But I want to add a non-member which may be something > like the entire cisco.com domain on which I want to set the rule. You cannot add a non-member with a regexp email, but the legacy *_these_nonmembers list attributes still exist in Mailman core and accept regexps. These settings are exposed in Postorius 1.3.3+ under Settings -> Message Acceptance. With older Postorius, you ned to set these directly in core, e.g. with `mailman shell` as in $ bin/mailman shell -l list.example.com 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. The variable 'm' is the list.example.com mailing list >>> m.accept_these_nonmembers [] >>> m.accept_these_nonmembers = ['^.*[.(a)]good\.domain$'] >>> m.accept_these_nonmembers ['^.*[.(a)]good\\.domain$'] >>> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

Search results for query "sapiro"