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

[MM3-users] Re: Mailman 3 stops delivering to a domain after too many bounces

by Mark Sapiro

On 7/12/22 12:34 AM, Julian Kippels wrote: > Hi, > > We have recently upgraded from Mailman 2 to Mailman 3. Since then I > have observed many user reports that mails to mailing lists don't reach > all members. My suspicion is that there are too many "dead" members on > those lists. This was not a problem on Mailman 2, but has become a > problem on Mailman 3. It seems to me that for example Mailman 3 sends > mails to the first 5 existing member addresses from domain A, then > encounters several (20 or so seems to be the threshold) "dead" member > addresses from domain A that generate a bounce and then does not even > attempt to reach the remaining 800 member adresses from domain A and > only sends to members on domain B and domain C. > > Is there a way to globaly ignore bounces and send out mails to all > members of a list, no matter what? Mailman's outgoing runner should not be quitting because of bounces at SMTP time. It seems like there may by some issue causing Mailman's outgoing runner to die. What's in Mailman's var/queue/shunt/ and Mailman's var/logs/mailman.log. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 2 months

[MM3-users] Re: About to Install MM3 -- Seeking clarification

by Mark Sapiro

On 1/2/23 03:54, Onyeibo Oku wrote: > > I pulled the plugs on uwsgi and installed Gunicorn. Gunicorn gave more > mileage but something is still not right. When I visit the mailmanweb > home with a browser, I see the following: > > "Server Error. An error occurred while processing your request." > > Mailmanweb and mailman3 services are running. I perused the log file > at /opt/mailman/web/logs/mailmanweb.log and found the following: > > > raise MailmanConnectionError( > mailmanclient.restbase.connection.MailmanConnectionError: ('Could not > connect to Mailman API: ', > 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'localhost\', > port=8001): Max retries exceeded with url: > /3.1/lists?advertised=true&count=0&page=1 (Caused by > NewConnectionError(\'<urllib3.connection.HTTPConnection object at > 0x7f7f4b128c40>: Failed to establish a new connection: [Errno 111] > 0x7f7f4b128c40>Connection refused\'))"))') Postorius is unable to connect to Mailman core's REST API. Are your settings for accessing Mailman's REST API correct? E.g., does MAILMAN_REST_API_URL = 'http://localhost:8001' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = 'restpass' match $ mailman info ... REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass Note the 3.1/ in REST root url is not included in MAILMAN_REST_API_URL. What do you get from, e.g. curl -urestadmin:restpass http://localhost:8001/3.1/lists It should return JSON with information about your lists. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 8 months

[MM3-users] Re: redirecting -bounces replies

by Mark Sapiro

On 6/25/25 10:53, Hirayama, Pat wrote: > Thanks, Mark. > > I (finally) started working on this ... and in trying to implement your suggestion — ran into a problem, I think. > > The current postfix_vmap has entries like: > > list-bounces(a)lists.domain.info lmtp:[mailman-core]:24 This looks very strange. It should be something like ``` list-bounces(a)lists.domain.info list-bounces(a)alias.domain ``` where alias.domain is the configured alias domain for the mail host lists.domain.info. > So, when I try adding entries to a separate vmap file, like: > > list-bounces(a)lists.domain.info lmtp:[mailman-core]:24, user(a)gmail.com > > It only goes through normal bounce processing. > > If I do: > > list-bounces(a)lists.domain.info user(a)gmail.com, lmtp:[mailman-core]:24 > > Then it goes to the gmail address, and no bounce processing happens. The issue here is the value `lmtp:[mailman-core]:24` is completely wrong. It should be an email address with a syntactically valid domain name. The domain name isn't a real domain. It is only a name exposed to Postorius in the postfix_vmap and postfix_lmtp files. What do you have configured for the alias domain for the lists.domain.info domain? See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… If you have this properly configured, adding user(a)gmail.com in either order in postfix_vmap should work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 2 weeks

[MM3-users] Re: Turn off social logins?

by Mark Sapiro

On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > Torge Riedel writes: > > > - there is a way to do this now via settings_local.py, but feels > > a little bit risky if default configuration changes on update of > > mailman > > This should not be true. If it is, we need to fix that. Will check. It is more or less true. The issue is that unlike mm_cfg.py and Defaults.py in Mailman 2.1, the recommended way to set up Django in Mailman 3 is to point Django at settings.py for the default config, and the last thing in settings.py is try: from settings_local import * except ImportError: pass Thus,the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py. The way around this is to remove the import of settings_local from settings.py and then put from settings import * at the beginning of settings_local.py and then point Django at settings_local rather than settings. Then you can do things like try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 7 months

[MM3-users] Re: Is there a way of recording bounce messages?

by Mark Sapiro

On 9/26/23 11:29, Mohsen Masoudfar wrote: > > I'm dealing with the same issue. Upon reviewing the logs, I've noticed a significant number of bounced emails for a particular mailing list. Gmail users have reported not receiving emails. > I haven't been able to locate the "munge from" information. My current setup is using Mailman 3.1.1. I read it has been introduced in 3.2. DMARC mitigations were introduced in Mailman 3.1.0. They should be available in 3.1.1. They were first exposed in Postorius 1.1.0. Where are you looking for DMARC mitigations? > The Question is what to do with Mailman 3.1.1, if the upgrade is not an option. > > I get in the logs messages like below with several Queue-ids: > > Sep 25 09:03:55 localhost postfix/smtpd[26692]: 147583E927: client=a14-93.smtp-out.amazonses.com[54.240.14.93] > Sep 25 09:03:55 localhost postfix/cleanup[26696]: 147583E927: message-id=<0100018acb94b326-fdf39193-144e-4fdc-8faf-0d3df54eb4ee-000000(a)email.amazonses.com> > Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: from=<>, size=24934, nrcpt=1 (queue active) > Sep 25 09:03:55 localhost postfix/lmtp[26697]: 147583E927: to=<listname-bounces@servername>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.03, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok) > Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: removed This only says that some Amazon MTA has relayed a bounce to Mailman. It says nothing about why the message bounced. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: Handling of (un)subscribe mails for already (un)subscribed users

by Mark Sapiro

On 12/10/20 2:04 PM, Andreas Barth wrote: > * Mark Sapiro (mark(a)msapiro.net) [201210 22:51]: >> On 12/10/20 11:51 AM, Andreas Barth wrote: >>> Hi, >>> >>> I noticed that a mail to -subscribe for an already subscribed user >>> doesn't get any response (about line 225 in >>> mailman/src/mailman/app/subscriptions.py). Same but different for >>> unsubscribe for users not on the list. >> >> >> I tested and I see this, so there is a bug, but I don't know what the >> issue is. > > Ok, if you consider this a bug it makes sense to fix it upstream and > not just locally. > > > >> The code you point to should raise AlreadySubscribedError and >> <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m…> >> should catch it and report, but this doesn't seem to be happening.. > > Actually I don't see where it should send the mail in the code you > refered to, but I'm pretty new to mm3-code and the involved coding > guidelines. Ther code pointed to adds the error to `results` and returns ContinueProcessing.yes. The return is to mailman/runners/command.py which is ultimately responsible for returning `results` to the user in a `results of your email commands` message. The issue is the code at <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/subscripti…> appears to not be executed as in my test at least, the workflow continued. > I would tend to add something along > msg = UserNotification( > self.mlist.owner_address, self.mlist.owner_address, > subject, text, self.mlist.preferred_language) > msg.send(self.mlist) > (with appropriate subject, ...) before > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/app/subscripti… > but of course that could be the wrong approach (but as > subscriptions.py is sending out mail at other places, that's my first > idea). Aside from the fact that this wouldn't work if that code isn't executed, sending that message at that point would not be appropriate if the subscription request originated from something other than an email command. I.e., if it's a web subscribe, the error should be reported in the web response, not in an email to the user who may not even be the one originating the request. -- 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: Issues with @gmail.com addresses

by Mark Sapiro

On 9/5/23 12:59, Mohsen Masoudfar wrote: > Hi, > > since 8/1/2023 I get complains from users with @gmail.com addresses, that they are not getting any emails. > I checked the logs and I see that the emails are going out: > > to=<xxxx(a)gmail.com>, relay=email-smtp.us-east-1.amazonaws.com[35.169.171.20]:587, delay=0.46, delays=0.03/0.06/0.13/0.24, dsn=2.0.0, status=sent (250 Ok xxx ) > > But it seems the users are getting email delivered to them. > I’ve advised them to check their spam, promotions, and social folders and to add the list address to their email safe-senders lists, but still no success. > Is there any way to help this list members? Even though gmail publishes a DMARC policy of none, it has recently started enforcing a stricter policy for mail From: the gmail.com domain. You need to apply DMARC mitigations to mail From: the gmail.com domain. There are two ways to do this. One way is to set DMARC Mitigations -> DMARC Mitigate unconditionally to Yes (and set DMARC mitigation action appropriately) The other way requires upgrading Postorius and Mailman core to the heads of the GitLab branches (core=3.3.9b1, postorius=1.3.9b1). Doing this enables a DMARC Addresses setting which can be set to `^.*(a)gmail\.com$` to apply DMARC mitigatations to mail From: the gmail.com domain regardless of it's published policy. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years

[MM3-users] Re: Handling of Mail from non-subscribers

by Mark Sapiro

On 5/8/20 5:32 PM, Peter Adebahr via Mailman-users wrote: > > May 09 01:22:38 2020 (1235) SHUNTING: 1588980158.3151...... > > But immediately before I find the "module 'time' has no attribute > 'clock'" which I remember from a thread a couple of days ago, though I > cannot remember a solution when mm3 has not been installed from source > but via apt-get. > > My core is V 3.2.2, core python 3.8.2, by the way. That is exactly the issue. Mailman 3.2.2 is not compatible with Python 3.8. This is a Debian/Ubuntu packaging bug. What has happened is the post encountered the exception shown in the Traceback that preceded the SHUNTING message and the message that triggered the exception was placed in the shunt queue. The thread you remember is <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> The fix is to patch your Mailman installation with the changes at <https://gitlab.com/mailman/mailman/-/merge_requests/552/diffs?commit_id=ea0…>. Or, at the very least change x = random.random() + right_now % 1.0 + time.clock() % 1.0 to x = random.random() + right_now % 1.0 + time.process_time() % 1.0 in mailman/utilities/uid.py. After doing that and restarting Mailman core you can do `mailman unshunt` to reprocess the message or if you prefer, `mailman unshunt --discard` (or just remove it from the shunt queue) to discard it. -- 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: Moderation not working?

by Mark Sapiro

On 11/24/20 12:30 PM, peter(a)chubb.wattle.id.au wrote: > > Hi Folks, > Running a shiny new instance of mailman3, as per the Debian package > (version 3.2.2) but the moderation doesn't seem to work. WE got > hit by a heap of spammers overnight, even though the 'hold for > moderation' bit is set for non-members (and now for members too). If the action for member posts was accept ot default processing at the time, perhaps the spam spoofed a member address in one of From:, Reply-To:, Sender: or the envelope sender, > Emails seem just to get straight through. Even now with both member and non-member actions set to hold? > Any advice on how to debug this? Would upgrading to a later version > using pip help? An upgrade probably won't help. This should work in your version. For one of the mail's, check all 4 addresses, From:, Reply-To:, Sender: and the envelope sender (available in the MTA logs). Note that Reply-To: and/or Sender: may have been modified by the list. Then see if any of those addresses matches a member or a non-member and what the specific moderation action is for that address. Also check the list's accept_these_nonmembers which is probably not exposed in your version of Postorius but which you can see via `mailman shell`. -- 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: Header Filter madness

by Brian Carpenter

On 1/13/21 3:05 PM, Mark Sapiro wrote: > On 1/12/21 9:57 PM, Mark Sapiro wrote: >> On 1/11/21 6:14 PM, Brian Carpenter wrote: >>> On 1/11/21 8:48 PM, Mark Sapiro wrote: >>>> On January 11, 2021 5:50:04 PM MST, Brian Carpenter >>>> <brian_carpenter(a)emwd.com> wrote: >>>>> I have a client whose header filters seemed to have stop working. No >>>>> matter what I try, it seems none of their header filters are being >>>>> applied. Other lists on the same server that use header filters, are >>>>> working fine. This particular header is the subject header. I can >>>>> duplicate their problem but only with their list. If I create the exact >>>>> same header on a test list using the exact same subject line, the >>>>> header >>>>> filter does its job (moderate). Just not with this one list. >> >> What's in the X-Mailman-Rule-* headers of the post that should be but >> isn't held? >> >> Are there other header filter rules besides the one that doesn't work? > Also, on your test list, did you copy/paste the regexp or retype it. If > the latter, there is possibly trailing whitespace that breaks it. Thanks Mark. I am currently waiting for feedback from my client. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 8 months

Search results for query "sapiro"