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

[MM3-users] Re: Attack on Mailman Server?

by Mark Sapiro

On 3/9/23 12:34, Eggert Ehmke via Mailman-users wrote: > In the log file there are several entries like this: > > > ERROR 2023-03-09 13:09:34,066 53357 django.request Internal Server Error: /accounts/ > signup/ > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/exception.py", > line 47, in inner > response = get_response(request) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/core/handlers/base.py", line > 181, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/views/generic/base.py", line > 70, in view > return self.dispatch(request, *args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/utils/decorators.py", line 43, in > _wrapper > return bound_method(*args, **kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/decorators.py", line 18, in > wrap > resp = ratelimit.consume_or_429(request, action=action, **rl_kwargs) > File "/opt/mailman/venv/lib/python3.9/site-packages/allauth/ratelimit.py", line 77, in > consume_or_429 > return render(request, "429." + app_settings.TEMPLATE_EXTENSION, status=429) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/shortcuts.py", line 19, in > render > content = loader.render_to_string(template_name, context, request, using=using) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/template/loader.py", line 61, in > render_to_string > template = get_template(template_name, using=using) > File "/opt/mailman/venv/lib/python3.9/site-packages/django/template/loader.py", line 19, in > get_template > raise TemplateDoesNotExist(template_name, chain=chain) > django.template.exceptions.TemplateDoesNotExist: 429.html > > So what is special about this 429.html? Django allauth is returning a 429 status because it is rate limiting due to too many requests in a short time (a bot accessing the signup page multiple times per second.) Allauth is telling Django to render a status=429 response using a 429.html template and Django can't find one. This would appear to be a django-allauth issue. -- 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

[MM3-users] Re: Phantom Email Address in Nonmember List

by Mark Sapiro

On 9/18/24 09:35, Steve Brown via Mailman-users wrote: > > Yes, that is what is happening, but only for messages from the steve@stevebrown address. I can send a screenshot and a .txt of the headers (of the message after sent back to me from MM3 and long!) but didn't see a way to do that on the archive page. Do I need to post from my gmail address? The usual behavior of most MUAs (mail clients) is to set the envelope sender to the same address as From:. In that case, you won't see an issue like this. In your case, when you send via tmdhosting servers, they set that odd bounce+... address as the envelope sender, presumably so they can do something in processing DSNs returned to that address. If you post the full headers of such a message from the list, either inline or as a .txt attachment, I'll look and say what I can. As far as getting headers from HyperKitty is concerned, if you click on a thread containing the message, there is a Download button which will produce a gzipped mbox containing the message(s) in that thread, but the headers are very minimal - only From:, To:, Subject:, Date:, Message-ID:, MIME-Version: and Content-Type:. There is also a From_ separator, but it contains the From: address, not the true envelope sender. > One clue I hadn't spotted before was a bodyhash_mismatch warning in the headers. No idea where that came from. Doesn't appear in emails from me to other addresses. Is that in Authentication-Results:? It is probably saying an original DKIM signature fails to verify because of a body mismatch which is expected if Mailman has filtered any MIME parts or added a message header or footer. -- 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: Problem upgrading from 2.1 to 3, dockerized

by Mark Sapiro

On 8/8/25 11:43, jesper.holck--- via Mailman-users wrote: > I recently followed the instructions here https://github.com/g4rf/dockerized-mailcow-mailman, and was able to create a new Mailman 3, Debian-based installation. I then followed the instructions here https://docs.mailman3.org/en/latest/migration.html in order to migrate from my old, Centos-based installation, to the new, Debian-based installation. It seemed to work well, but unfortunately a problem showed up. > > Whenever someone posted to one of the lists on the new installation, the messages were rejected by Postfix: > > postfix-mailcow-1 | Aug 5 20:55:48 ef2b760c2e61 postfix/cleanup[8681]: B7B856099EC: message-id=<A8946B8E-2A47-4701-9548-4544981FAC5E(a)gmail.com> > postfix-mailcow-1 | Aug 5 20:55:49 ef2b760c2e61 postfix/cleanup[8681]: B7B856099EC: milter-reject: END-OF-MESSAGE from unknown[172.22.1.1]: 5.7.1 This message does not meet our delivery requirements; from=<mylist-bounces(a)myserver.dk> to=<mylistuser1(a)gmail.com> proto=ESMTP helo=<[172.19.199.4]> > postfix-mailcow-1 | Aug 5 20:55:50 ef2b760c2e61 postfix/cleanup[8681]: 216D36099EC: message-id=<A8946B8E-2A47-4701-9548-4544981FAC5E(a)gmail.com> > postfix-mailcow-1 | Aug 5 20:55:50 ef2b760c2e61 postfix/cleanup[8681]: 216D36099EC: milter-reject: END-OF-MESSAGE from unknown[172.22.1.1]: 5.7.1 This message does not meet our delivery requirements; from=<mylist-bounces(a)myserver.dk> to=<mylistuser2(a)mail.dk> proto=ESMTP helo=<[172.19.199.4]> The above messages are not messages normally seen from Postfix. They apparently come from some mailcow milter. > So, for each of the existing lists, I had to delete the old list and create a new one - with the same name and the same users. After this, everything seems to work as expected. I can think of nothing that `mailman import21` would do that would be different from creating a list, configuring it and adding members. Since you are following a third party how-to, please see https://wiki.list.org/x/12812344 - perhaps reporting this at https://github.com/g4rf/dockerized-mailcow-mailman/issues would be appropriate. -- 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: Mailman rewrite the Cc header incorrectly

by Mark Sapiro

On 5/26/20 9:10 PM, Alan So wrote: > Thanks again for the work and just notice that the issue has been closed already. Looks like unfolding the header line is a logical way but it seems that >=3.3 email package unfold the header before parsing the header according to the following python issue: > > https://bugs.python.org/issue11050 Yes, the issue is closed because the fix has been merged and will be in Mailman Core 3.3.2. I agree that it appears that there would have been no issue if Mailman created messages using the `SMTP` policy and retrieved the addresses using the `addresses` attribute of the headers. However, for historical reasons, Mailman Core still uses the `compat32` policy (Python 3.2 compatibility) and uses `email.utils.getaddresses()` to get the addresses from the header value, so the "fix" for <https://bugs.python.org/issue11050> doesn't apply. Changing Mailman Core to use email.EmailMessage() objects rather than the legacy email.Message() objects is a worthwhile goal, but would require extensive changes to fix all the things that broke as a result. Anyway, I really appreciate your diligence in following through repeatedly on this issue. Were it not for that, I wouldn't have been motivated to fix it. For a look at why even a trivial change is not trivial, see the commits at <https://gitlab.com/mailman/mailman/-/merge_requests/652/commits>. The first of these is developing good tests for the issue and then fixing the code so the tests pass, and the second, unanticipated one was due to the fact that Python 3.5 didn't maintain the original ordering of the addresses in Cc: so I couldn't compare against a fixed result. This is due to the fact that the underlying code uses dictionaries, and prior to Python 3.6 dictionaries didn't preserve order. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

[MM3-users] Re: Improve logging?

by Mark Sapiro

On 1/31/23 00:40, Odhiambo Washington wrote: > Some entries in the log files can be very scary, while in actual sense they > are harmless. > Such inconsequential, but scary entiess can mess up the well-being of a > SysAdmin. > I humbly request for the logs related to posts by non-members to a MM3 list > to be improved a little bit :-) > Here is the example in mailman.log: > > <cut> > Jan 31 10:03:54 2023 (92481) DISCARD: < > 2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The message > is not from a list member'] > [31/Jan/2023:10:04:48 +0300] "GET > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f HTTP/1.1" 200 253 "-" "GNU > Mailman REST client v3.3.5" > [31/Jan/2023:10:04:48 +0300] "GET > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f/addresses HTTP/1.1" 200 473 "-" > "GNU Mailman REST client v3.3.5" > Jan 31 10:18:09 2023 (92343) deque: do_confirm_verify > Traceback (most recent call last): > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/workflow.py", > line 69, in __next__ > return step() > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/subscriptions.py", > line 476, in _step_send_confirmation > raise StopIteration > StopIteration > </cut> > > Is there a possibility to change the logging engine to just *fold* the last > 7 lines into "The message is not from a list member. It was discarded", or > something close? No. This entry Jan 31 10:03:54 2023 (92481) DISCARD: <2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The message is not from a list member'] is a single entry about a discarded message. The next two are logging requests via the REST API that have nothing to do with the discard and are logged by a different module. The last entry with a traceback is yet another separate event. That one could probably be suppressed because raising StopIteration is a normal occurrence in workflow processing. -- 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: Reset bounce count in MM3

by Mark Sapiro

On 3/8/26 20:57, iMark wrote: > =========== > > My thinking was that to reset that member's bounce_count from 4 to 0, I > could just delete the records (resulting from the query) in the > "bounceevent". > > But as the query result only shows 2 bounces, I'm looking for where the > Admin web UI is getting "4" from (ie. the processed bounce events older > than 24 hours). The list member's bounce score is the bounce_score column in the member table, but finding the correct row is dificult because you need the list_id which you'd look up in the mailinglist table and either the address_id from the address table or the user_id from the user table. It's much easier to use mailman shell as in ``` $ mailman shell -l list(a)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(a)example.com mailing list >>> mbr = m.members.get_member('user(a)example.com') >>> mbr.bounce_score = 0 >>> commit() ``` But what is the point of doing this? If the member is bouncing, the score will continue to increment, and if not the bounces will become stale and a future bounce will set the score to 1. You mentioned reset_bounce.py, but that doesn't reset scores. It sets delivery enabled for users whose delivery is disabled by bounce, but you can do that, albiet one by one, in Postorius just by clicking the user in the membership list and setting Delivery Status to Enabled. In Postorius <=1.3.13, Delivery Status doesn't show in the membership list, but it will in the next release. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 1 week

[MM3-users] Re: Disabled by bounce

by Mark Sapiro

On 2/17/23 13:39, denise.mcgeachy--- via Mailman-users wrote: > Hi all - new to this forum but am trying to work out a similar issue raised by a list member's IT department. I'm a bit out of my depth here and hoping you all can help. > > They have recommended: > > - When the mailing list relay an email from a member of the list to other members, the email from address should be the mailing list and not the user sending the original email. For example: list-name(a)mydomain.ca (on behalf of Sally Brown) > - The mailing list should not modify the original email and thus breaking the DKIM signature > > I have clicked the DMARC mitigation unconditionally option which seems to solve the second point but haven't managed to have it sent by the list name but not as suggested in the first point. I either get "my email via list(a)mylist.ca" or list(a)mylist.ca" > Is anyone aware of a setting to do this? Those two points are contradictory. You can't do both. Not modifying the message in ways that break DKIM requires no content filtering, no addition of list headers or footers and no munging of From: or Reply-To: headers. Normally the list will make some modification that will break DKIM signatures. If you set DMARC mitigation action to Replace From: with list address, and set DMARC Mitigate unconditionally, that should address the first point and individual messages from the list will be From the list and that's all you should need. For example, the message to which I'm replying is From: denise.mcgeachy--- via Mailman-users <mailman-users(a)mailman3.org> While this is not identical to the format you quote, the address is the list's address which is the important thing. -- 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: list footer questions

by Mark Sapiro

On 5/14/20 2:49 PM, Mohsen Masoudfar wrote: > > It is on Ubuntu18.04 and has been installed with Ubuntu package Mailman-full. There is no update available yet. So it looks like I cannot use the easy way of modifying the templates. > Question: Is there a way to achieve the same by updating the code? You don't have to modify code. You can set a footer in Mailman's file hierarchy. There is a var/templates directory, maybe somewhere like /var/lib/mailman/templates in the Ubuntu package. This directory can contain subdirectories lists, domains and site. These may or may not existb but the layout is the site directory contains subdirectories for language codes, i.e. 'en', 'fr', 'de', etc. The domains directory contains subdirectories for domains like 'example.com', example.net, etc. and those contain the language subdirectories. The lists directory contains subdirectories for lists like list.example.com and those contain the language subdirectories. Now when mailman is looking for a template, it looks in this hierarchy first, e.g. when looking for an English language footer for the list(a)example.com list for regular members it will look in this order: templates/lists/list.example.com/en/list:member:regular:footer.txt templates/domains/example.com/en/list:member:regular:footer.txt templates/site/en/list:member:regular:footer.txt before falling back to a default. The name for a digest footer is list:member:digest:footer.txt, or there can be a list:member:generic:footer.txt file which is for both regular and digest deliveries. There is documentation at <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>, but it can be difficult to follow. <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…> describes the various templates and the substitutions available. Note that the name of a file in the above hierarchy is the template name with `.txt` appended. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 5 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

Ok, I'll install whoosh on env2 Thanks El vie., 21 jul. 2017 a las 16:32, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/21/2017 02:27 PM, Rafael Mora wrote: > > > > it says it needs whoosh > > > > How do I install that? on env2 with python2 or env with python3 ??? > > > In env2 do 'pip install whoosh' > > -- > 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

9 years, 2 months

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

I've created https://gitlab.com/mailman/mailman/-/issues/735 for this and I've also done an experiment and found what I think is a workaround. If you set ``` [webservice] hostname: greyarea-post.cam.ivimey.org ``` or maybe just `greyarea-post` would do, and then add to `/etc/hosts` on `greyarea-post` ``` 0.0.0.0 greyarea-post.cam.ivimey.org ``` or whatever name you used for `hostname` this will get gunicorn to bind to the public interface and will include the proper hostname in the `self_link` responses.

6 years, 3 months

Search results for query "sapiro"