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

[MM3-users] Re: Mailing list resends same email multiple times

by Mark Sapiro

On 3/9/23 04:18, 朱超 wrote: > Hello, I need your help. There have question about Scenes: > > Add mailbox a and mailbox b to mailing lists c and mailing lists d, and send mail to mailing list c and mailing list d through mailbox b , among which a has received many mails sent by b, check the log and find: The file about path:/opt/mailman /var/queue/bounces has the content of retrying mail, but I turned off process bounces. > > Mailing list sends mail via exim, logs found in exim： 023-03-09 00:54:47 1pa4YR-001xk5-0y <= <> R=1pa4YM-001xje-1F U=exim P=local S=7672 T="Mail delivery failed: returning message to sender" from <> I need more information. Even though the list isn't brocessing bounces, bounces will still be returned to the -bounces address and queued in /opt/mailman/var/queue/bounces. If they remain there, the bounce runner is not processing them. If the list's bounce processing is turned off, the bounce runner should just dequeue the message and discard it. If multiple messages go to the list, something is returning them to the list posting address instead of the list-bounces address. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 6 months

[MM3-users] Re: Mailman3 on FreeBSD

by Mark Sapiro

On 08/12/2017 04:51 PM, Barry Warsaw wrote: > On Aug 10, 2017, at 16:32, John Poltorak <karotlopj(a)gmail.com> wrote: >> >> On FreeBSD they ought to be in /usr/local/etc/mailman.cfg however I don't >> see any indication as to what I should put in this file and if it was in >> /usr/local/etc/mailman.cfg then how would mailman find it? > > It wouldn’t by default. Right now Mailman does not search for /usr/local/etc/mailman.cfg, but that wouldn’t be a difficult change to add. I’m not sure whether that would makes sense as a general default or not. I’m not up on the FreeBSD conventions and standards here; can you explain why /usr/local/etc is preferred over /etc on that distro? I was hoping Abhilash would chime in here, because I think John is using the docker image and there's probably a specific path for mailman.cfg. As far as what goes in it, it could even be empty if you want to accept all the defaults, but you probably want at least [mailman] site_owner: real_person(a)example.com I expect if you do find -name mailman.cfg in your installation, you'll find at least examples. -- 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

[MM3-users] Re: mailman3 admin from mailman2 & File location questions

by Mark Sapiro

On 11/3/21 1:38 PM, bob B wrote: > Question1 > We use help users with list settings, so we would log into mailman2 with the master password. So what is the best way to duplicate this for mailman3. I assume I can just use the admin account and share that password with my other admins. But I see the domain owners, but is that working? I added someone as a domain owner, and they do not see private email lists and it looks like that can not edit any list settings? There was a post that this had not yet been implemented? Any other options? Domain owners should be able to manage lists in their domains, but currently they can't. You can go to the Django admin interface and give any user superuser status, and then they will be 'admins'. You don't have to share passwords. > Question2 > Where are all the emails/archives stored? are they in /opt/mailman/...., or are they in the database? It depends on the archiver. For the prototype archiver they are in the archives/prototype/ directory in Mailman's var directory. For HyperKitty they are in the database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: Deleting messages from HyperKitty archive

by Mark Sapiro

On 3/25/24 12:42, Mark wrote: > Hi, > > I'm running Mailman 3.3.9 with HyperKitty version 1.3.8 (venv installed > as per the docs). > > As superuser (listmaster) I can "Delete message/thread" and "Delete > archive". > > These options aren't there for the list owners. > > The docs (link below) say that in the newer HyperKitty version 1.3.9, > list owners can delete messages/threads > > Is there a patch I can implement on HyperKitty version 1.3.8 (so list > owners can delete messages), or is it possible to update HyperKitty to > version 1.3.9 without bringing everything crashing down? > > *** > https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html > 1.3.9 (2024-02-27) > List owners can now delete messages and threads and reattach threads. > (Fixes #261) > *** The patch is at <https://gitlab.com/mailman/hyperkitty/-/merge_requests/584/diffs>. Upgrading HyperKitty can be done in your venv by something like ``` pip install hyperkitty==1.3.9 ``` however, there may be things that also depend on later versions of django-mailman3, mailmanclient, mailman-web or even mailman core, thus it is best to upgrade everything. For the recommended virtualenv install, see <https://docs.mailman3.org/en/latest/upgrade-guide.html#virtualenv-install> -- 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: Data too long for column 'data' in workflowstate

by Mark Sapiro

On 12/14/20 9:46 AM, Morris Jones wrote: > I ran into this error attempting to add a user to a mailing list: > > (pymysql.err.DataError) (1406, "Data too long for column 'data' at row 1") > [SQL: INSERT INTO workflowstate (token, step, data) VALUES (%(token)s, > %(step)s, %(data)s)] > [parameters: {'token': '7394fbf654b3faffc6a65eb95e0616eea6651b9e', > 'step': 'do_confirm_verify', 'data': '{"pre_approved": false, > "pre_confirmed": false, "pre_verified": false, "invitation": false, > "address_key": "dorothyxxxxxxxx(a)gmail.com", "subscriber_key": 1, > "user_key": "00201c01dcc443c3a0d8f6d1ea42e230", "token_owner_key": 1, > "send_welcome_message": null}'}] > > In MySQL I see that column 'data' in workflowstate is VARCHAR(255), and > the data in the query is 259 characters. > > If I have a moment I'll write a bug or patch ... but I'm not really > current on schema migrations. This is <https://gitlab.com/mailman/mailman/-/issues/793> fixed by <https://gitlab.com/mailman/mailman/-/merge_requests/730> You may be able to apply the fix from the merge request, but that depends on your install's latest Alembic Revision ID being 9735f5e5dbdb. Alternatively, I think it may be sufficient to just ALTER TABLE workflowstate MODIFY `data` VARCHAR(510); -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[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

11 months, 4 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, 5 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, 3 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, 3 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

1 month, 4 weeks

Search results for query "sapiro"