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

[MM3-users] Re: config incoming email in my domain cpanel

by Rafael Mora

El jue., 3 ago. 2017 a las 15:26, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 08/03/2017 01:22 PM, Rafael Mora wrote: > > El jue., 3 ago. 2017 a las 15:18, Mark Sapiro (<mark(a)msapiro.net>) > escribió: > >> > >> You need to forward port 25 for SMTP mail delivery and if you want the > >> web UI (Postorius and HyperKitty) accessible from the outside, port 80 > >> for http and/or port 443 for https > >> < > >> > https://www.iana.org/assignments/service-names-port-numbers/service-names-p… > >>> . > >> > > > > I mean for incoming mail redirected from my hostgator hosting, because > when > > I suscribe an email address MM3 sends a confirmation email, so I have to > > reply to be suscribed to the list. > > > As I said, for mail delivery you need to forward port 25 to the Mailman > server. > Ok so I'll redirect in my zentyal firewall the port 25 to my local centos7 with postfix and MM3 with IP 192.168.1.42. Thanks Mark. > > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

8 years, 6 months

[MM3-users] Re: Missing Base64 encoding from control message reply

by Mark Sapiro

On 9/23/23 02:54, Jana Berger wrote: > > I have multiple control messages, all received from my instance which > all contain the "Content-Transfer-Encoding: base64" marker, their > contents is plain text (Content-Type: text/plain; charset="utf-8"), but > they are still encoded using base64. It seems you are saying these messages are valid. I.e. they specify "Content-Transfer-Encoding: base64" and the body is in fact base64 encoded. This is as they should be. > Of course that is not proof, but an indication that it is either done by > the mail server itself or widely across MUAs. As you say, this suggests that some MTA in the path to your user or the user's MUA is responsible for decoding the base64 encoded body but leaving the "Content-Transfer-Encoding: base64" header as is. > Global "Preferred language" is "English (USA)", which is not overridden > by the list in question. I have not changed the default encoding. Is > there a surefire way to detect this? > > My mailman.cfg has no section pertaining to encoding, and all related > files also do not mention encoding. The Subject: and body of these messages should be ascii, not utf-8 unless you have something like ``` [language.en] charset: utf-8 ``` in your mailman.cfg -- 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: Single Click Unsubscribe

by Mark Sapiro

On 1/25/24 15:21, olebra(a)samfundet.no wrote: > > To me, "subscribed messages" in the above means the policy applies to > everyone sending over 5k emails daily, whether for marketing or not. > > All the best, > Ole > > [0]: https://support.google.com/a/answer/81126 > _______________________________________________ > 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/ > Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… You can always put something like the above "To unsubscribe ..." line in the lists footer as we do. Gmail's web UI renders that as a mailto: link. Further, at least in some cases, Gmail's web UI recognizes the List-Unsubscribe header in the message and provides it's own Unsubscribe buttons in the web UI. Granted, these aren't truly "one click" as they require confirmation, but that can be avoided by setting a list's unsubscribe_policy to `open`. Also granted that Gmail is the 900 pound gorilla here, but unsubscribe links that don't require confirmation are a bad idea. Even if the link contains some kind of encrypted data to ensure it can't be spoofed, there is still a danger if I forward list mail to a 3rd party and they click my unsubscribe link. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 1 month

[MM3-users] Re: mailqueue shows bounces for emails that are not on the mailing list

by Mark Sapiro

On 11/3/25 04:18, Stephen J. Turnbull wrote: > Paul via Mailman-users writes: > > > Iam getting alot of such from my mail server mail queue lately > > 4d08rT4xMHzMCD6S 2393 Mon Nov 3 01:43:21 > > list-bounces+makeupbymichelle=aol.com(a)lists.mydomain > > (host mx-aol.mail.gm0.yahoodns.net[67.195.228.84] said: > > 421 4.7.0 [TSS04] Messages from my-mail-server-IP temporarily > > deferred due to unexpected volume or user complaints - 4.16.55.1 > > If "my-mail-server-IP" is in fact your mail server's IP, then you may > have a problem: spammers may be using your server as a relay for > spoofed emails. It is also possible, or even likely that these are the result of bad actors maliciously requesting subscriptions for 3rd parties. Since this is a 421 status, these mails should remain queued in your mail server for a while and can be examined[1]. If this is the case, you may be able to mitigate this by setting SHOW_ANONYMOUS_SUBSCRIBE_FORM = False in your Django settings. See https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-9 [1] For example if your MTA is Postfix postcat /var/spool/deferred/4/4d08rT4xMHzMCD6S and if that shows a subscription or email verification request postsuper -d 4d08rT4xMHzMCD6S to delete it so it isn't retried. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 3 weeks

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

by Mark Sapiro

On 1/24/22 15:06, Mark Sapiro wrote: > On 1/18/22 06:24, Stephan Krinetzki wrote: >> Hello, >> >> We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is >> installed in a venv and deployed using Apache and uwsgi. This works >> quite well so far, only withheld messages cause us a problem: If we >> try to approve them via Postorius, the message is delivered to the >> list immediately, but the success message in Postorius takes a long >> time - on average the process hangs for three minutes until the >> message is no longer displayed. We have already adjusted the timeout >> in gunicorn.cfg, but this does not improve the situation. Are there >> any tips on how we can speed up the REST API? Or is it even a >> configuration error? > > > There are two steps in handling the POST for a held message. The first > step is accepting, rejecting or discarding the message. This is > happening immediately. > > The second step is handling the poster's moderation action based on the > choice from the Set member moderation dropdown in the view of the held > message. This is processed by the code at > <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…>. > If no selection has been made, the default value POSTed for > moderation_choice is `no-action` and that code is skipped. If it is one > of the choices `Hold for moderation`, `Reject (with notification)`, > `Discard (no notification)`, `Accept immediately (bypass other rules)` > or `Default processing` that is processed. So presumably a selection has > been made and processing is stuck on getting the member or setting the > member's moderation action. > > Possibly the logs of your database manager will have information. > Some additional info. By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If you are using gunicorn as a wsgi server, that is separate from the gunicorn serving the REST API and its config doesn't affect the REST API. The relevant config is mailman/config/gunicorn.cfg?. Also, I doubt the issue is with the REST API per se, but rather it is in Mailman core's processing of the particular endpoint and if that is slow, it is most likely some kind of database 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, 1 month

[MM3-users] Re: Scheduled tasks

by Mark Sapiro

On 6/7/18 9:59 AM, Darren Smith wrote: > All, > > I am looking more through the documentation of the Mailman Suite here: > > https://media.readthedocs.org/pdf/gnu-mailman/latest/gnu-mailman.pdf > > In section 3.2.5 it talks about the scheduled tasks that need to be run to > do "specific routine functions" in hyperkitty. > > I installed through the easy install script found here: > > https://github.com/iomarmochtar/mailman3_ei/ > > However, I can't find anything in THAT documentation that talks about these > cron jobs, and in fact the Mailman Suite isn't installed through that > script. That is a third party project. If you have issues with it, you should take them up with @iomarmochtar. > Can someone point me to any other documentation about the tasks that need > to be run on a continual basis? The section 3.2.5 you refer to tells you what needs to be set up in cron. For a list of the jobs tat are run, use django-admin runjobs --list . Our hyperkitty installation seems to be > bogging down more and more, and I am hoping that it will be as simple as > just running some jobs that haven't been on our radar. what do you mean by 'bogging down'? If you aren't doing so, setting up qcluster as in section 3.2.3 may help. -- 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: 500 Internal Server Error on specific list pages

by Mark Sapiro

On 7/29/20 9:55 PM, Johnny Cison wrote: > I have a new Mailman 3 server set up and am having a strange issue with > just one particular list. > > Accessing the list's Info page URL or it's Archiving Settings page URL > returns a 500 Internal Server Error, but its other pages work correctly. > Also, the Info and Archiving pages on the other lists are working correctly. > > When I access the info page for the problem list, I get these errors in the > log: > > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line > 41, in inner > response = get_response(request) ...> line 103, in call > raise HTTPError(url, response.status, content, response, None) > HTTPError: HTTP Error 500: A server error occurred. Please contact the > administrator. > > > When I access the Archiving page in Settings, I get these: > > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line > 41, in inner ... > line 103, in call > raise HTTPError(url, response.status, content, response, None) > HTTPError: HTTP Error 500: A server error occurred. Please contact the > administrator. These messages are from Django's log. What's in Mailman's mailman.log? -- 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: postfix malformed address with confirm replies

by Mark Sapiro

On 2/26/21 3:34 PM, Stephen Willey Mats Mats wrote: > > I’m getting bounces back from postfix (553 5.1.3 Error: malformed address) for my confirm replies. ... > I’m pretty sure I have all of the mailman settings in postix: > " > # Support the default VERP delimiter. > recipient_delimiter = + Yes, this is the relevant one and is correct. ... >> The mail system >> >> <matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu>: >> host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address >> (in reply to RCPT TO command) >> Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal >> X-Postfix-Queue-ID: E144B8BC3C5 >> X-Postfix-Sender: rfc822; stephen.s.w.matsmats(a)gmail.com >> Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST) >> >> Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu >> Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu >> Action: failed >> Status: 5.1.3 >> Remote-MTA: dns; 172.19.199.2 >> Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address I have no idea why Postfix is saying `matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu` is a malformed address, but this is a Postfix issue, not Mailman. Can you successfully post to `matsmats-mm3-test1 @mm3.aca-aws.s.uw.edu` how about a `help` command to `matsmats-mm3-test1-request(a)mm3.aca-aws.s.uw.edu` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: problems installing mailman3 under gentoo and upgrading mailman2 to mailman3

by Mark Sapiro

On 3/13/21 7:08 PM, John Covici wrote: > On Sat, 13 Mar 2021 16:22:59 -0500, > Abhilash Raj wrote: >> >> My guess is that you updated the database (perhaps, by invoking the mailman >> command form 3.3.3) and then tried to start 3.3.2. In this case, Mailman comes >> up and sees a new revision for the database migration added from 3.3.3 but >> can’t find the same migration in its source (because it is 3.3.2). > > That is sort of what happened, except in the opposite direction, it > was from 3.3.3 to 3.3.2. My question is therefore, do I have to > update this alembic_version when I upgrade mailman to a newer version? > That is what I was getting at. Abhilash's conjecture is that the error was due to a Mailman version accessing a database that had been previously accessed by a newer version so that the version_num in the alembic_version table didn't exist in mailman/database/alembic/versions/. This normally would not occur on an upgrade of Mailman, but if you went from a gentoo Mailman core to a version obtained by pip, it's possible that the gentoo Mailman had an alembic version that wasn't known to the pip Mailman even though the pip Mailman was newer. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: sending messages in response to posts from non-members

by Mark Sapiro

On 2/26/22 04:26, David Bremner wrote: > > I'd like to turn off the "bounce messages" sent by mailman to > non-members. My reasoning is that most such posts are spammers, and > often use forged return-paths / From's, so I end of sending steady > stream of backscatter to amazon.com etc... > > Is this configurable (without postorius) somehow? What exactly do you want? Do you want to discard without notice any nonmember posts or do you want to hold them but not send a notice of the hold to the poster? For the former, you want to set the list's default_nonmember_action to discard. For the latter you want to set the list's respond_to_post_requests to False. To make either of these settings the default for new lists, you'd need to patch mailman/styles/base.py. To set them for all lists you could do the following in `mailman shell` ``` $ bin/mailman shell 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. >>> for mlist in getUtility(IListManager).mailing_lists: ... # Pick the appropriate one of the following. ... mlist.default_nonmember_action = Action.discard ... mlist.respond_to_post_requests = False ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

Search results for query "sapiro"