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

[MM3-users] Re: Mailing Lists

by Mark Sapiro

On 12/23/21 3:09 PM, John McDonald via Mailman-users wrote: > I am responsible for the mailing list of a local church. Recently the church was moved to using Mailman for this. When a simple message is created and sent to the mailing list most email addresses received it correctly but those with an Outlook or Hotmail account received attachments and not the message. There are three attachments and one of them has to be opened to view the message. > > Am I missing some setting? First question. Is this Mailman 2.1 or Mailman 3? This list is for Mailman 3. The corresponding list for Mailman 2.1 is https://mail.python.org/mailman3/lists/mailman-users.python.org/ That said, your issue is because the list is adding a message footer (or possibly header or both) to the delivered message. This is discussed in the FAQ at https://wiki.list.org/x/4030707 That FAQ says there are Mailman configuration things you can do. Exactly what you do depends on the requirements of your list and whether this is Mailman 2.1 or Mailman 3. If you don't require that HTML or other non plain text parts be delivered, you can adjust content filtering to remove them and create a simple plain text message which won't have this problem. Or you can ensure that no message header/footer is added. How you do these things depends on your Mailman version. -- 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: Mailing list welcome message won't update

by Mark Sapiro

On 1/16/25 15:14, via Mailman-users wrote: > "Does your empty list:member:generic:footer.txt work to not add any footer to list messages? If so, I can't think of any reason why your list:user:notice:welcome.txt wouldn't be used." > > Sorry, I am not sure how to chekc this. > Can I use a mailman command? > Where does that footer get added if it was not empty? > > Thanks. > > Frances > _______________________________________________ > 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 mark(a)msapiro.net In the above message received from the list, the footer (which is custom) is everything from the horizontal line below your name to the end of the message (and will be added again below my sig). A default footer for this list would be just ``` _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org ``` If the message is a single text/plain part, the footer is added to the body inline. If it is a MIME multipart message, the footer is attached as a separate MIME part. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[MM3-users] Re: Remove login from list subscription page

by Mark Sapiro

On 3/1/22 12:23, bob B via Mailman-users wrote: > Is there any way to easily remove the login button for the List subscription page? 99% of our list do not use archiving, and log-in just confuses users so We would like for them just to be able to sign up to be on the list. You would need to patch postorius/templates/postorius/lists/summary.html Something like this would do what I think you want. ``` --- a/src/postorius/templates/postorius/lists/summary.html +++ b/src/postorius/templates/postorius/lists/summary.html @@ -101,20 +101,9 @@ {% endif %} {% else %} <div> - <h2>{% trans 'Subscription / Unsubscription' %}</h2> - <p>{% blocktrans %} - To subscribe or unsubscribe from this list, please log in first. - If you have not previously logged in, you may need to set up an account - with the appropriate email address. - {% endblocktrans %}</p> - <p><a href="{% url LOGIN_URL %}?next={{ next|default:request.path|urlencode }}" class="btn btn-primary">{% trans 'Log In' %}</a></p> - </div> - <hr /> - <div> - <p> + <h2>{% trans 'Subscription' %}</h2> {% blocktrans %} - You can also subscribe without creating an account. - If you wish to do so, please use the form below. + To subscribe to this list, please use the form below. {% endblocktrans%} </p> <form action="{% url 'list_anonymous_subscribe' list.list_id %}" ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

[MM3-users] Re: Migration from old server to new server failed

by Helio Loureiro

Hi, This is running on the latest mailman3. Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro On Sun, 25 Feb 2024 at 02:52, Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/23/24 09:28, Mark Sapiro wrote: > > On 2/22/24 21:51, Stephen J. Turnbull wrote: > >> If I'm correct, I think you'll > >> find the offending message in $var_dir/archive/hyperkitty or some > >> subdirectory, it's a regular queuefile, and you can read it with the > >> showqfile utility to see if it's spam. Otherwise you need to edit the > >> [] out of the message ID. > > > > The directory is $var_dir/archive/hyperkitty/spool/ and the command to > > view the queue entry is `mailman qfile path/to/file`. > > > BTW, the issue with bogus [] delimited Message-IDs is "fixed" (actually > worked around) in Mailman 3.3.9 by > https://gitlab.com/mailman/mailman/-/merge_requests/1099/ > > -- > 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 helio(a)loureiro.eng.br >

2 years, 7 months

[MM3-users] Re: Discrepancy in date time of archived message

by Mark Sapiro

On 9/25/25 14:35, Mark wrote: > > I have a message posted to a list on 25 September at 20:57 UTC. > > The server is set to UTC and the date command shows it has the correct > date and time. > > And I received the message ---- 25 September at 20:57 UTC > > But the message is shown (incorrectly) in the archive as having been > posted on 26 September at 8:57 a.m. (out by +12 hours) > > It should be shown as 25 September 8:57 p.m. Where are you seeing this time? Is it the time displayed in the thread or message view or the time displayed as the Sender's time when you hover over the time in the thread or message view? If it's the former of these, you probably have set `TIME_ZONE` in your Django settings to other than `UTC`. This should be `UTC` because times from Mailman core are naive times in `UTC`. See https://docs.djangoproject.com/en/5.2/topics/i18n/timezones/ for some info. If it is the Sender's time, that is whatever time is in the message's Date: header with the offset ignored. E.g., a time in the Date: header of `26 Sep 2025 08:57:00 +1200` will show as `Sender's time: Sept 26, 2025 8:57 am`, ignoring the 12 hour offset. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

[MM3-users] Re: Problem creating list members using REST API

by Mark Sapiro

On 1/18/22 2:11 PM, Stephen Daniel wrote: > The REST API documentation is a bit informal. As someone who is not > familiar with mailman, and who doesn't know python, they are a bit of a > slog. Agreed. I guess we sort of assume that people dealing directly with the REST API are familiar with both. > It might be worth seeing if the code can be enhanced to allow the boolean > values to be sent in using JSON booleans as well as JSON strings. I think here we only have to deal with the REST API because other uses of as_boolean are all on strings that come from config files. We can't modify as_boolean directly, as it is part of a third party dependency and is intended to be used with config files, not JSON objects, but I think something like this will do it. ``` --- a/src/mailman/rest/helpers.py +++ b/src/mailman/rest/helpers.py @@ -249,6 +249,8 @@ class GetterSetter: """ if self.decoder is None: return value + if self.decoder is as_boolean and isinstance(value, bool): + return value return self.decoder(value) ``` Perhaps you could try to test that. I just created https://gitlab.com/mailman/mailman/-/issues/970 for this. It would help me in fixing this if you could provide a small piece of your code that throws the error. -- 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: Detectors and Bounces

by Mark Sapiro

On 8/5/22 14:03, summersan(a)nclack.k12.or.us wrote: > > Previously, there were `34775` files in the `/opt/mailman/mm/var/queue/bounces` directory, ranging from June 7 to August 4. For background, there's typically a time in the summer where many user accounts are purposely disabled (generally near July-August, I think). From the bounce file dates, I wonder if this bounce-related issue has been happening for longer than I first realized. The issue is that sometimes the bounce runner dies. This can be from an OOM error or some other reason, but I have observed it even on systems I admin. The master SHOULD restart it, but it doesn't. See https://gitlab.com/mailman/mailman/-/issues/898. Anyway, it appears your bounce runner died sometime on or before June 7 (if you have syslog from then it might have a clue), and you didn't stop and start Mailman core until August 4 when the bounce runner started again and began chugging through it's queue. I.e., I think everything in your installation is OK and the excessive load was just due to processing the 34775 queued bounces that should have been processed gradually over the previous 2 months. Although 500 bounces per day seems like a lot, but if you have a lot of lists, and bouncing users aren't being disabled because bounce runner isn't running, this may be normal. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

[MM3-users] Re: Mailman rewrite the Cc header incorrectly

by Mark Sapiro

On 5/26/20 12:33 AM, Alan So wrote: > Thanks. Just filed an issue: > https://gitlab.com/mailman/mailman/-/issues/725 Thank you for your "well formed" issue. I have started to work on this, but I have run into a snag. The patch at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> doesn't work. The problem is msg.get_all(header, []) does not parse the header and return a list of addresses. It just returns a list, the items of which are the raw values if the header instances in msg. I.e., if there is only one Cc: header, msg.get_all('cc', []) returns a list of one string which is the raw value of that header. If there were two Cc: headers in the message it would return a list of two strings with the two raw values. Thus, we would need to parse the strings returned into the individual email addresses. The simple minded way to do that is addrs = [] for hdr in msg.get_all(header, []): for addr in hdr.split(','): addrs.append(parseaddr(re.sub('[\r\n]', '', addr))) but that will fail if the header contains a quoted display name containing a comma such as "last, first" <user(a)example.com> So, I need to go back to using getaddresses, but do the unfolding first. Watch the issue for the final fix. -- 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: List in list, mutiple reply-to addresses

by Mark Sapiro

On 11/25/21 11:00 PM, Stefan Bauer wrote: > Mother: > Anonymous list: No > First strip reply to: No > Reply goes to list: No Munging > DMARC mitigation action: Replace From: with list address > DMARC mitigate unconditionally: Yes > > > > Daughter: > Anonymous list: No > First strip reply to: Yes > Reply goes to list: No Munging > DMARC mitigation action: Replace From: with list address > DMARC mitigate unconditionally: Yes > Because of DMARC mitigation, you can't do what you want. With the settings you have the mother list puts the original From: in Reply-To: and it's own address in From:. Then regardless of what the daughter does with the incoming Reply-To:, it will add the incoming From: to Reply-To: so the Reply-To: of a message from the daughter will always contain the address of the mother. The best you can do, unless you are willing to set DMARC mitigation action: to No DMARC mitigations is what you started with which is First strip reply to: No on the daughter which will at least put the original From: to the mother in Reply-To: from the daughter along with the mother's address, but you can't remove the mother's address from the daughter's Reply-To: because DMARC mitigation will always put it there. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

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

by Mark Sapiro

On 4/28/22 10:59, bob B via Mailman-users wrote: > We had an issue where a program went rogue and sent out 30k email alerts to one of our lists, so now I have a few questions. > > When the issue happened I turned on emergency moderation and we have resolved the issue so.. > > 1. How do I easily delete 30k of held messages? It looks like the GUI only allows me to do 200 at a time? is there a way to flush all held messages easily? See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… and the thread containing it. > 2. When I enabled Emergency moderation, I expected it to stop notifying the admin on every held message, but it appears that is not the case? Also, does it reply to the sender of every held message when Emergency moderation is on? > > it seems like the steps are: > turn on "Emergency moderation" > turn OFF "Notify users of held messages" > turn OFF "Admin immed notify" MM 2.1 didn't notify the admins of emergency holds. This is not the case in MM 3. It probably should be, but isn't. Senders are or aren't notified per "Notify users of held messages". So the steps above are correct. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

Search results for query "sapiro"