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

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

by Mark Sapiro

On 11/14/25 15:36, Cathryn McGuire wrote: > Hi Mark, > > "It appears in your case that Gateway to news is Yes and Newsgroup > moderation is Moderated" > > I don't see any Gateway to mail or Gateway to news, but Newsgroup moderation was set to Moderated (as you said). I changed it to Not Moderated. That's good. As I've said, I don't know what the affinity UI looks like. If you send me (off list) a screen shot of the page where you see Newsgroup moderation, I can advise you further, but basically, anything to do with Newsgroups should be set to Off or No. > In the following case, they are cc'ing to the mailist, and To: is to a member. Sometimes they are not members. Sometimes they To: to the mailist and cc: to the member or non-member. > > Subject:Re: [Neighbours] Furnace problems > To:Bill McCreery <billmccreery1(a)gmail.com> > Cc:neighbours@mailist.dunbar-vancouver.org > Content-Type:multipart/alternative; boundary="000000000000f9e5900643322d20" > X-MailFrom:dunontime@gmail.com > X-Mailman-Rule-Hits:header-match-neighbours.mailist.dunbar-vancouver.org-0 > X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation My understanding is you want to hold for moderation any message with a Cc: unless it it To: the list with a Cc: to a member, and I said that with what's available to you in the list's settings, you can't distinguish between Cc: to a member and Cc: to a nonmember, so you have to hold any message with a Cc: > "If the reason was actually what is posted above with 'neighbors' > rather than 'cc:', that's a problem with EMWD's Mailman core." > > Does that mean that any cc: to neighbours or to a member or non-member should be blocked (held)? > Or, does that mean if the cc: is to neighbours, it should be allowed through? That quote was in response to your post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… wherein you said > The message is being held because: > > Header "neighbours > > <neighbours(a)mailist.dunbar-vancouver.org>" matched a > header rule I thought that was a typo and the real reason was Header "Cc: <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. If that was the case, it was expected and was due to your header filter on Cc: headers. My confusion was I couldn't see how the reason could have been Header "neighbours <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. And if it was, that was an EMWD issue. I think the header rule you have will hold any post with a Cc: to anywhere. If you want to not hold posts with a Cc: <neighbours(a)mailist.dunbar-vancouver.org> regardless of To:, you can do that by adjusting your header rules, but I don't think you want that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 1 week

[MM3-users] Re: Digests not working correctly

by Mark Sapiro

On 6/4/23 11:45, Joel Lord wrote: > So I seem to have problems with both periodic AND size-triggered > digests. Size first, this is simpler. Just got one sent out, clearly > triggered by a new email getting added to the queued up messages, but > the setting for the list is the default 30KB and the digest came out at > 23.2 KB. Is it measuring the accumulated queue as size on disk > including metadata and filesystem block sizes or something, rather than > the size of what the emailed digest will be? The threshold is determined by the size in bytes of the MMDF format mailbox file in which the the messages for the digest are saved. This does not include metadata and is not affected by block sizes. It contains the raw messages with all headers and 8 bytes of message separators per message and a 'From ' line per message. Once the digest is triggered, the messages are configured into a digest message with boilerplate, a TOC and possibly a header and/or footer added. The messages themselves may be added as separate MIME message/rfc822 parts to a mime format digest or added as text to a plain format digest. Many headers are removed as the messages are added. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.…> for what is kept. In addition any non text/plain parts in the message are not included in the plain format digest, but are replaced by notes that they have been removed. All this says that a MIME format may be larger or smaller than the threshold depending on the size of the removed headers vs. the added parts, and a plain text digest will probably be smaller if the messages have non text/plain parts, e.g. if content filtering doesn't collapse alternatives and leaves the text/html alternative part, this part will not be in a plain format digest. > Periodic is much more complicated, even to explain. I have the cron job > running nightly at 11:00 PM and it certainly seems to be working, except > for one really odd thing. The list also definitely has periodic digests > enabled in the web UI. This is a very bursty list, so it will go mad > with traffic for a few weeks and then will go mostly idle for a month or > so. The first digest of a burst is definitely size-triggered, but > pretty reliably it has the last few messages from the previous burst in > there. So the one I got today had three messages from today and one > message from May 4th. But that May 4th message should have gone out at > 11:00 PM on May 4th with the daily digest and then gotten flushed from > the pending digest queue, right? That's correct. Do you ever get periodic digests sent at 11:00 PM? If not, there is some issue either with configuration or something. If you get them sometimes, I don't know what could be wrong. -- 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: Issues with @gmail.com addresses

by Mohsen Masoudfar

I created a new list with this setting. This new created list can send to Gmail addresses, this is very strange, because I have changed the problem list (The list that cannot send to @gmail addresses) settings to match the new one, but still the issue is there. The only difference is that the problem list has been imported from mailman2. Question: is there a command line that displays all the settings of a list? I think it might be some hidden settings that are not visible in the UI? Thanks Mohsen ________________________________ From: Mohsen Masoudfar <mmasoudf(a)aaas.org> Sent: Wednesday, September 6, 2023 1:32 PM To: Mark Sapiro <mark(a)msapiro.net>; mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: Re: [MM3-users] Re: Issues with @gmail.com addresses Thank you Mark for your response as always! I checked the lists having the issue of sending emails to @gmail.com subscribers. They had already these settings (so no changes): DMARC Mitigate unconditionally : yes DMARC mitigation action: Replace From: with list address DMARC rejection notice: empty DMARC wrapped message text: empty I wonder three points: * What would be the next action to fix the issue? * This issue started around the beginning of August. Could it be due to some changes google made recently? * Give the number of Gmail users, this should annoy a bigger community, are you seeing that many upset people? Thanks, Mohsen ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Tuesday, September 5, 2023 4:17 PM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Issues with @gmail.com addresses [EXTERNAL EMAIL] 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 _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> This message sent to mmasoudf(a)aaas.org

2 years, 5 months

[MM3-users] Re: Clearing webserver cache - Nginx

by Mark Sapiro

On 9/29/24 00:59, Odhiambo Washington via Mailman-users wrote: > > Could you allow me to revisit this issue since I haven't solved it? First, > I bypassed CloudFlare DNS proxying just to ensure I have nothing is coming > in between my browser and the web server. > That did not help with the issue of the "missing" CSS files. Then you have som other issue in your configuration. > Ideally, I should not be creating these symlinks, right? On my old server > the symlinks weren't necessary. That is correct. > I have created some symlinks and that appears to help with Apache. I will > test with Nginx and see how it goes. > ``` > root@eu:/opt/mailman/mm/static/CACHE/css# ls -al > total 196 > drwxr-xr-x 2 mailman mailman 4096 Sep 29 10:40 . > drwxr-xr-x 4 mailman mailman 4096 Mar 21 2024 .. > lrwxrwxrwx 1 mailman mailman 23 Sep 29 10:40 output.ac23d5f5127c.css -> > output.d29798365ddb.css > lrwxrwxrwx 1 mailman mailman 23 Sep 29 10:31 output.bacec526ec98.css -> > output.e69dbb26da3b.css > -rw-r--r-- 1 mailman mailman 1209 Mar 21 2024 output.d29798365ddb.css > -rw-r--r-- 1 mailman mailman 569 Mar 21 2024 output.e68c4908b3de.css > -rw-r--r-- 1 mailman mailman 180904 Mar 21 2024 output.e69dbb26da3b.css > root@eu:/opt/mailman/mm/static/CACHE/css# > ``` > My question though: What is the source of truth for the files that should > be in /opt/mailman/mm/static/CACHE/css/ ?? When you run `django-admin collectstatic --clear ...` it removes all the old files from the static/ directory and installs new ones. At this point static/CACHE/ contains no files. Then when you run `django-admin compress` it creates three output.*.css files in static/CACHE/css and one output.*.js file in static/CACHE/js and creates a static/CACHE/manifest.json file that points to those four files and which is what Django uses for the paths to put in the relevant <script ...> and <link rel="stylesheet" ...> tags in the pages it serves. I.e. static/CACHE/manifest.json is the source of truth. > Maybe that is what I need to focus on. If need be, then I should *fix* the > contents of that file so that it doesn't contain the nonexistent files, no? I very much doubt that it does contain the nonexistent files since it is built by the same `django-admin compress` that creates the output* files. > Lastly, why is it that my https://mm3-lists.kictanet.or.ke/archives/ does > not display content similar to what https://lists.mailman3.org/archives/ > does? > What change should I make in which settings.py? This is a clue. I presume you actually have archived lists. There is something very wrong in your configuration if HyperKitty is not finding those lists. Possibly you have more than one WSGI server running and you aren't always proxying to the correct one. That seems far fetched to me, but without seeing all your web server, WSGI server and Django configurations, I have no idea what the issue could be. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 4 months

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

by Mark Sapiro

On 10/19/25 14:28, Cathryn McGuire wrote: > Hi Mark, > > 1. Since this post in July, I've been trying to work with EMWD to get the cc's blocked. I've tried every rule configuration in the Header Filter to no avail. EMWD can't seem to help. The setting options are as follows: > > Acceptable aliases > > This is a list, one per line, of addresses and regexps matching addresses that are acceptable in To: or Cc: in lieu of the list posting address when 'require_explicit_destination' is enabled. Entries are either email addresses or regexps matching email addresses.Regexps are entries beginning with '^ and are matched against every recipient address in the message. The matching is performed with Python's re.match () function, meaning they are anchored to the start of the string. What is the content of this? Probably should be empty. > 2. Require Explicit Destination (this is a checked box. Could it be interfering with the Header filters?) No, it doesn't interfere with header checks. > This checks to ensure that the list posting address or an acceptable alias explicitly appears in a To: or Cc: header in the post. > > 3. Default action to take when a member posts to the list > > Accept immediately (bypass other rules) > Default action to take when a member posts to the list. > Hold: This holds the message for approval by the list moderators. > Reject: this automatically rejects the message by sending a bounce notice to the post's author. The text of the bounce notice can be configured by you. > Discard: this simply discards the message, with no notice sent to the post's author. > Accept: accepts any postings without any further checks. > Default Processing: run additional checks and accept the message. NOTE - when set here, all members are blocked. What does Blocked mean? If you mean held for moderation, what is the reason they are held? > 4. We also have the problem of large image file sizes being let through no matter what setting we have. We have it set to 500KB, but everything is accepted. > > Maximum message size > 500 > The maximum allowed message size in KB. This can be used to prevent emails with large attachments. A size of 0 disables the check. > > Perhaps some settings are over-riding others? If you have Default action to take when a member posts to the list set to Accept, that bypasses this check and many others. > What do you think? What do you have in your header filter rules? More importantly, what are you trying to accomplish? I.e. what do you want to happen in the following cases? 1. Message To: the list, no Cc: 2. Message To: the list, Cc: to other address 3. Message To: somewhere else, Cc: to the list 4. Message To: elsewhere, Bcc: to the list (require explicit destination will hold this one) Maybe others? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 months

[MM3-users] Re: Emergency moderation and clearing out a lot of held messages

by Stephen J. Turnbull

Hi, Mark, Dan I'm no database expert, but is it possible that there's some index that's missing? (Just a WAG, feel free to ignore if you know more about databases than "adding indicies solves all problems" ;-) Mark Sapiro writes: > On 11/16/22 15:52, Dan Caballero wrote: > > Thanks Mark! > > > > We're using GNU Mailman 3.3.5 (Tom Sawyer). The tests I did via the Docker container used a database dump from our production MySQL server. > > > > We have 2050 lists. The address table in the database has 95028 rows. > > > For what it's worth, mail.python.org has 188 Mailman 3 lists and 85852 > rows in the address table, and handling a message waiting moderation > takes only a second or two. Thus, whatever the scaling issue is, it's > likely related to the number of lists as opposed to the number of list > members. > > -- > 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 > 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… > > This message sent to turnbull.stephen.fw(a)u.tsukuba.ac.jp > >

3 years, 3 months

[MM3-users] Re: Issues with a DMARC record leading to message being shunted

by Mark Sapiro

On 12/23/23 1:57 AM, Ralf Hildebrandt via Mailman-users wrote: > Hi! > > Recently a mail was not being distributed via our MM3 instance; I searched the logs and found: > > Dec 22 04:54:27 2023 (24) ACCEPT: <1d431542-b386-467b-8bf2-305f19ee7eb4(a)somenet.org> > Dec 22 04:54:28 2023 (28) Uncaught runner exception: list index out of range > Dec 22 04:54:28 2023 (28) Traceback (most recent call last): > File "/usr/lib/python3.10/site-packages/mailman/core/runner.py", line 179, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/lib/python3.10/site-packages/mailman/core/runner.py", line 272, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3.10/site-packages/mailman/runners/pipeline.py", line 37, in _dispose process(mlist, msg, msgdata, pipeline) > File "/usr/lib/python3.10/site-packages/mailman/core/pipelines.py", line 53, in process > handler.process(mlist, msg, msgdata) > File "/usr/lib/python3.10/site-packages/mailman/handlers/validate_authenticity.py", line 125, in process > authenticate(msg, msgdata) > File "/usr/lib/python3.10/site-packages/mailman/utilities/retry.py", line 44, in f_retry > return f(*args, **kwargs) > File "/usr/lib/python3.10/site-packages/mailman/handlers/validate_authenticity.py", line 93, in authenticate > auth_result = authenticate_message( > File "/usr/lib/python3.10/site-packages/authheaders/__init__.py", line 395, in authenticate_message > dmarc_result = check_dmarc(msg, spf_result, dkim_result, dnsfunc=dnsfunc, psddmarc=psddmarc) > File "/usr/lib/python3.10/site-packages/authheaders/__init__.py", line 343, in check_dmarc > result, result_comment, from_domain, policy = dmarc_per_from(from_domain, spf_result, dkim_result, dnsfunc, psddmarc) > File "/usr/lib/python3.10/site-packages/authheaders/__init__.py", line 90, in dmarc_per_from > record, orgdomain = receiver_record(from_domain) > File "/usr/lib/python3.10/site-packages/authheaders/dmarc_lookup.py", line 117, in receiver_record > retval = lookup_receiver_record(hostSansDmarc, dnsfunc) > File "/usr/lib/python3.10/site-packages/authheaders/dmarc_lookup.py", line 92, in lookup_receiver_record > tags = answer_to_dict(str(result)) > File "/usr/lib/python3.10/site-packages/authheaders/dmarc_lookup.py", line 42, in answer_to_dict > retval = {t[0].strip().lower(): t[1].strip().lower() for t in rawTags} > File "/usr/lib/python3.10/site-packages/authheaders/dmarc_lookup.py", line 42, in <dictcomp> > retval = {t[0].strip().lower(): t[1].strip().lower() for t in rawTags} > IndexError: list index out of range > > Dec 22 04:54:28 2023 (28) SHUNTING: 1703220868.1418982+b27f5db154375fcd2c418d467172e4aad0d3d57a > > So the message has been shunted, due to this error. Something with > DMARC and tags. So I checked the DMARC record for the sending domain > somenet.org. It is "v=DMARC1;p=none;pct=100;rua=mailto:postmaster@somenet.org;mailto:postmaster@somenet.org;ri=3600;fo=1;" > which is syntactically incorrect. The extra ";mailto:postmaster@somenet.org" is wrong, I guess the tag "ruf=" is missing here! > > It should probably read "v=DMARC1;p=none;pct=100;rua=mailto:postmaster@somenet.org;ruf=mailto:postmaster@somenet.org;ri=3600;fo=1;" > > So, should mm3 somehow "catch" this error somehow? Perhaps we should catch it. We already have other issues involving authheaders.authenticate_message. There's an invalid From: issue at https://gitlab.com/mailman/mailman/-/issues/1100 reported at https://github.com/ValiMail/authentication-headers/issues/25 and a different invalid DMARC issue at https://gitlab.com/mailman/mailman/-/issues/1109 reported at https://github.com/ValiMail/authentication-headers/issues/26. For now, I reported this at https://github.com/ValiMail/authentication-headers/issues/27 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 2 months

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

by Rafael Mora

El jue., 3 ago. 2017 a las 15:18, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 08/03/2017 12:58 PM, Rafael Mora wrote: > > > > Does the rDNS PTR record should be placed in my Centos7 server? > > You can't do this. Hostgator or whoever manages the network (Telmex > Colombia S.A. ?) has to do this. > > > > I've created the DNS A record for lists.labbrands.com with the IP but I > > don't know the port that it uses so I can make a port redirect to my > local > > ip address wich is 192.168.1.42, do you know the port????? > > > 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. > > -- > 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: Walk-thru for Ubuntu Bionic Mailman 3 Full setup

by Tim Cutts

Yup. I noticed that when I went through this two days ago. I hadn’t got around to mentioning it yet. :-) > On 8 Jul 2022, at 18:01, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 7/8/22 9:16 AM, kisner(a)live.com wrote: >> Just out of curiosity and to try to improve the doc I can do this a little later. But I can tell you for sure the pip install psycopg2-binary<2.9 command failed for me on Ubuntu 22.04 and Debian 11.3. I'm not saying it's *not* me, and I don't know when the last time that doc was updated but I couldn't get it to work on a few different distros. > > > The issue is when you do > ``` > pip install psycopg2-binary<2.9 > ``` > your shell (sh, bash, zsh or whatever) interprets `<2.9` as an input redirection and probably says something like `2.9: No such file or directory`. You need to do something like > ``` > pip install psycopg2-binary\<2.9 > ``` > or > ``` > pip install 'psycopg2-binary<2.9' > ``` > I'll update the doc. > > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

3 years, 7 months

[MM3-users] Re: How to prevent members to attach executables (exe, bat, ...) to the emails sent to list

by Mohsen Masoudfar

Good morning Mark, You were right, the parameter m.filter_content was set to False, I believe the default. I changed it to True and it worked as expected. Thanks again. Mohsen -----Original Message----- From: Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> Sent: Friday, October 2, 2020 2:54 AM To: Mark Sapiro <mark(a)msapiro.net> Cc: mailman-users(a)mailman3.org Subject: [MM3-users] Re: How to prevent members to attach executables (exe, bat, ...) to the emails sent to list [EXTERNAL EMAIL] Mark Sapiro writes: > Filtering by extension only works on message parts that have an > associated file name. Thus, while you can add things like 'exe', 'bat', > 'cmd', 'com', 'pif', 'scr', 'vbs' and 'cpl' to filter_extensions, it > won't be completely effective. > > A better approach is to use MIME types[1] and only allow those you want. > For a discussion list, a reasonable set is what this list uses: I wouldn't say "better" if you're concerned about the executables being malware. There's long history of concealing malware by giving it a MIME type different from what the extension implies, and there was at least one Windows exploit that used this technique to achieve automatic execution of malware simply by displaying the message. _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mai…

5 years, 4 months

Search results for query "sapiro"