Issues with cross posted emails after upgrading to mailman 3.3.6
Since upgrading from 3.3.4 to 3.3.6 we are seeing a high instance of emails that are sent to 2 lists (EG 2 campuses). One campus will get the email and the other campus will get an email that just contains "The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.” Is this something new in 3.3.6? I’m trying to work out what’s going on and why it would be lost. Both lists need the email as the membership list is different so the people on the second list get a useless email.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
Sorry that should be we went from 3.3.4 -> 3.3.5. I’m just reading the code now but my quick reading of it seems to say that if someone sees to 2 lists and they are both moderated, if one list moderator releases it, the email is deleted from the store and then when the second person releases it it’s now a dummy message that has no contents? That doesn’t sounds right.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
On 4 Nov 2021, at 12:50 pm, Simon Coggins <s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>> wrote:
Since upgrading from 3.3.4 to 3.3.6 we are seeing a high instance of emails that are sent to 2 lists (EG 2 campuses). One campus will get the email and the other campus will get an email that just contains "The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.” Is this something new in 3.3.6? I’m trying to work out what’s going on and why it would be lost. Both lists need the email as the membership list is different so the people on the second list get a useless email.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
Ok so after pulling it all apart this appears to have been a major problem in mailman3 from conception maybe? So here’s what happening as I understand it.
If an email comes in and it is address to 2+ lists and 2 or more of those lists hold the email for moderation. The email is stored in the database using the message-id-hash (or something based on the message-id). Then if one list moderator approve/discards the email then that action deletes the message from the database. But there are still 1+ other lists that the message was addressed to that have pending actions, but that email is now gone. Before 3.3.5 these approves were silently dropped and no email was sent to the list, but in 3.3.5 new code was added to send a dummy email that contains "The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.”
We have multiple campuses in the same city and it’s not uncommon for people to send the same email to the multiple lists in the same city. This is where we’ve started to see the content was lost emails. I’m amazed we haven’t had people report missing emails before this.
My very ugly hack that I’m sure is not even close to the right way of fixing this was to set exim to use max_rcpt = 1 when talking to the mailman LMTP server. Then I made the following changes to runners/lmtp.py
*** lmtp.py.orig 2021-11-04 17:46:03.428874115 +1000 --- /opt/mailman/venv/lib/python3.6/site-packages/mailman/runners/lmtp.py 2021-11-04 17:37:59.911514738 +1000
*** 37,42 **** --- 37,43 ---- import email import asyncio import logging
import hashlib
from aiosmtpd.controller import Controller from aiosmtpd.lmtp import LMTP
*** 155,160 **** --- 156,171 ---- if msg.defects: return ERR_501 msg.original_size = len(envelope.content) +
# Modify the messageID so tha it's unique for each list. This requies# the MTA to be configured to only send one RCPT per connection# In exim this is max_rcpt = 1# SIMON HACKdel msg['Message-ID']msg['Message-ID'] = "{}{}".format(hashlib.sha512(envelope.rcpt_tos[0].encode('utf8')).hexdigest()[:24], message_id.strip("<>"))message_id = msg['Message-ID']# END SIMON HACKadd_message_hash(msg) msg['X-MailFrom'] = envelope.mail_from # RFC 2033 requires us to return a status code for every recipient.
All I’m doing is literally appending a subset of a hash of the mailing list rcpt address to the front of the message-id, so that if it gets moderated, each instance of the email has a different message-id and each moderation action has it’s own copy of the email to operate on. This seems to have gotten us out of the immediate issues. But I’m eager to find a better solution that might be more permanent.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
On 4 Nov 2021, at 1:11 pm, Simon Coggins <s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>> wrote:
Sorry that should be we went from 3.3.4 -> 3.3.5. I’m just reading the code now but my quick reading of it seems to say that if someone sees to 2 lists and they are both moderated, if one list moderator releases it, the email is deleted from the store and then when the second person releases it it’s now a dummy message that has no contents? That doesn’t sounds right.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
On 4 Nov 2021, at 12:50 pm, Simon Coggins <s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>> wrote:
Since upgrading from 3.3.4 to 3.3.6 we are seeing a high instance of emails that are sent to 2 lists (EG 2 campuses). One campus will get the email and the other campus will get an email that just contains "The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.” Is this something new in 3.3.6? I’m trying to work out what’s going on and why it would be lost. Both lists need the email as the membership list is different so the people on the second list get a useless email.
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
On 11/4/21 1:02 AM, Simon Coggins wrote:
All I’m doing is literally appending a subset of a hash of the mailing list rcpt address to the front of the message-id, so that if it gets moderated, each instance of the email has a different message-id and each moderation action has it’s own copy of the email to operate on. This seems to have gotten us out of the immediate issues. But I’m eager to find a better solution that might be more permanent.
As you have seen, this is new in 3.3.5. I recognize this is a problem. Previously, attempts to accept the message on the second and subsequent lists would throw an uncaught exception - see https://gitlab.com/mailman/mailman/-/issues/914 and this was a fix for that.
Please file an issue for this at https://gitlab.com/mailman/mailman/-/issues and I will try to find a better solution. Your approach of munging Message-IDs will create other issues. Consider a post to a list with direct CC to userx. userx replies-all to the message received directly. the In-Reply-To of this reply is the unmunged Message-ID which will affect threading in the archives and other recipient's MUAs. I realize this is preferable to losing the message, but I hope we can do better.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 4 Nov 2021, at 11:57 pm, Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> wrote:
On 11/4/21 1:02 AM, Simon Coggins wrote:
All I’m doing is literally appending a subset of a hash of the mailing list rcpt address to the front of the message-id, so that if it gets moderated, each instance of the email has a different message-id and each moderation action has it’s own copy of the email to operate on. This seems to have gotten us out of the immediate issues. But I’m eager to find a better solution that might be more permanent.
As you have seen, this is new in 3.3.5. I recognize this is a problem. Previously, attempts to accept the message on the second and subsequent lists would throw an uncaught exception - see https://gitlab.com/mailman/mailman/-/issues/914<https://gitlab.com/mailman/mailman/-/issues/914> and this was a fix for that.
Yeah I’m seriously amazed we’ve not had complaints in the year we’ve been running mailman3 that people have lost emails to multiple lists. Only now that you fixed the exception have people seen missing emails :)
Please file an issue for this at https://gitlab.com/mailman/mailman/-/issues<https://gitlab.com/mailman/mailman/-/issues> and I will try to find a better solution. Your approach of munging Message-IDs will create other issues. Consider a post to a list with direct CC to userx. userx replies-all to the message received directly. the In-Reply-To of this reply is the unmunged Message-ID which will affect threading in the archives and other recipient's MUAs. I realize this is preferable to losing the message, but I hope we can do better.
Yeah it’s not a great solution but it’s the quickest I could come up with that works “for us”. 99% of our lists are announcement lists only with minimal replies so while this will break some. I’m hoping it will give us enough time to wait out a proper fix. I’ve created a new issue #955 with as much detail as I think you’ll need. Let me know if you need any more.
-- Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
Mailman's content filtering has removed the following MIME parts from this message.
Content-Type: image/png Name: attachment.png
Content-Type: image/png Name: attachment.png
Replaced multipart/alternative part with first alternative.
On 11/4/21 12:58 PM, Simon Coggins wrote:
Please file an issue for this at https://gitlab.com/mailman/mailman/-/issues<https://gitlab.com/mailman/mailman/-/issues> and I will try to find a better solution. Your approach of munging Message-IDs will create other issues. Consider a post to a list with direct CC to userx. userx replies-all to the message received directly. the In-Reply-To of this reply is the unmunged Message-ID which will affect threading in the archives and other recipient's MUAs. I realize this is preferable to losing the message, but I hope we can do better.
Yeah it’s not a great solution but it’s the quickest I could come up with that works “for us”. 99% of our lists are announcement lists only with minimal replies so while this will break some. I’m hoping it will give us enough time to wait out a proper fix. I’ve created a new issue #955 with as much detail as I think you’ll need. Let me know if you need any more.
Thanks for filing the issue. I'll work on a solution. My current
thinking is to add a count column to the message table, set the count
to 1 when initially adding a message-id, increment the count when adding
an existing message-id, decrement the count when deleting a message-id
and only delete the entry and message when the count reaches 0.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 5 Nov 2021, at 6:30 am, Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> wrote:
Yeah it’s not a great solution but it’s the quickest I could come up with that works “for us”. 99% of our lists are announcement lists only with minimal replies so while this will break some. I’m hoping it will give us enough time to wait out a proper fix. I’ve created a new issue #955 with as much detail as I think you’ll need. Let me know if you need any more.
Thanks for filing the issue. I'll work on a solution. My current
thinking is to add a count column to the message table, set the count
to 1 when initially adding a message-id, increment the count when adding
an existing message-id, decrement the count when deleting a message-id
and only delete the entry and message when the count reaches 0.
That should work well. I’m happy to do some testing of any patches you create in our test environment if you need extra testing.
-- Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>
—Simon
Mark Sapiro writes:
Thanks for filing the issue. I'll work on a solution. My current thinking is to add a
countcolumn to the message table, set the count to 1 when initially adding a message-id, increment the count when adding an existing message-id, decrement the count when deleting a message-id and only delete the entry and message when the count reaches 0.
Are we guaranteed to get a separate LMTP delivery for each list? That is, if the MTA receives 2 RCPT TOs to lists for one transaction, won't it do the same in LMTP when it sends forwards the message to Mailman?
Steve
On 11/5/21 2:07 AM, Stephen J. Turnbull wrote:
Are we guaranteed to get a separate LMTP delivery for each list? That is, if the MTA receives 2 RCPT TOs to lists for one transaction, won't it do the same in LMTP when it sends forwards the message to Mailman?
It doesn't matter. The LMTP runner makes a separate in queue entry for
each recipient list, thus these are processed as separate messages
regardless of how they arrived.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 11/4/21 1:30 PM, Mark Sapiro wrote:
Thanks for filing the issue. I'll work on a solution. My current thinking is to add a
countcolumn to the message table, set the count to 1 when initially adding a message-id, increment the count when adding an existing message-id, decrement the count when deleting a message-id and only delete the entry and message when the count reaches 0.
I wound up taking a different approach. I check for other references to the message in the message store and only delete the message if there are none. The fix is at https://gitlab.com/mailman/mailman/-/merge_requests/932/diffs
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 7 Nov 2021, at 10:54 am, Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> wrote:
I wound up taking a different approach. I check for other references to the message in the message store and only delete the message if there are none. The fix is at https://gitlab.com/mailman/mailman/-/merge_requests/932/diffs<https://gitlab.com/mailman/mailman/-/merge_requests/932/diffs>
Oh nice. That seems like a sensible solution. Thanks for tackling so quickly. I’ll do some testing today and roll it out once testing is complete.
-- Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
Mailman's content filtering has removed the following MIME parts from this message.
Content-Type: image/png Name: attachment.png
Content-Type: image/png Name: attachment.png
Replaced multipart/alternative part with first alternative.
Simon Coggins wrote:
On 7 Nov 2021, at 10:54 am, Mark Sapiro <mark@msapiro.netmailto:mark@msapiro.net> wrote: I wound up taking a different approach. I check for other references to the message in the message store and only delete the message if there are none. The fix is at https://gitlab.com/mailman/mailman/-/merge_requests/932/diffshttps://gitlab.... Oh nice. That seems like a sensible solution. Thanks for tackling so quickly. I’ll do some testing today and roll it out once testing is complete.
I made a small change to defend against 'impossible' situations. See https://gitlab.com/mailman/mailman/-/merge_requests/933/diffs
On 8 Nov 2021, at 11:11 am, Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> wrote:
Simon Coggins wrote:
On 7 Nov 2021, at 10:54 am, Mark Sapiro <mark@msapiro.netmailto<mailto:mark@msapiro.netmailto>:mark@msapiro.net<mailto:mark@msapiro.net>> wrote: I wound up taking a different approach. I check for other references to the message in the message store and only delete the message if there are none. The fix is at https://gitlab.com/mailman/mailman/-/merge_requests/932/diffshttps://gitlab.com/mailman/mailman/-/merge_requests/932/diffs<https://gitlab.com/mailman/mailman/-/merge_requests/932/diffshttps://gitlab.com/mailman/mailman/-/merge_requests/932/diffs> Oh nice. That seems like a sensible solution. Thanks for tackling so quickly. I’ll do some testing today and roll it out once testing is complete.
I made a small change to defend against 'impossible' situations. See https://gitlab.com/mailman/mailman/-/merge_requests/933/diffs<https://gitlab.com/mailman/mailman/-/merge_requests/933/diffs>
Thanks for the heads up. I did a bunch of testing with the original patch and was happy with it so we’re running that in prod now. How far off is 3.3.6? Just working out if I apply this slight change or wait for the full release.
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
Mailman's content filtering has removed the following MIME parts from this message.
Content-Type: image/png Name: attachment.png
Content-Type: image/png Name: attachment.png
Replaced multipart/alternative part with first alternative.
On 11/7/21 5:19 PM, Simon Coggins wrote:
On 8 Nov 2021, at 11:11 am, Mark Sapiro <mark@msapiro.net<mailto:mark@msapiro.net>> wrote:
I made a small change to defend against 'impossible' situations. See https://gitlab.com/mailman/mailman/-/merge_requests/933/diffs<https://gitlab.com/mailman/mailman/-/merge_requests/933/diffs>
Thanks for the heads up. I did a bunch of testing with the original patch and was happy with it so we’re running that in prod now. How far off is 3.3.6? Just working out if I apply this slight change or wait for the full release.
We don't have a specific release schedule. I think it could be several months before a 3.3.6 release. I don't think this change is critical. I was just considering 'what ifs' that actually shouldn't occur, but I suggest going ahead and applying the change.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
We're also getting bit by this due to messages being replaced with the notice below.
"The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list".
I'm looking to apply the patch above.
I got one of these yesterday as well.
On 11/9/2021 7:06 PM, dancab@caltech.edu wrote:
We're also getting bit by this due to messages being replaced with the notice below.
"The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list".
I'm looking to apply the patch above.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Joel Lord
Don’t use the code I posted, use the new patches from Mark if you want to apply them. The patches are
https://gitlab.com/mailman/mailman/-/merge_requests/932 https://gitlab.com/mailman/mailman/-/merge_requests/933
I’ve applied both of them to my prod box now and they are working well. The only catch is 932 will include an update to NEWS.rst that won’t apply because the contents are different. Thats fine it doesn’t impact the patch.
All I did was download both patches using the plain diff option when you click on the download icon at the end of the line “Request to merge msapiro:clean into master”.
Then on my mailman server (I did it in my test environment first) applied the patch in order (your paths, locations, install may differ from mine, this works for me):
$ cd /opt/mailman/venv/lib/python3.6/site-packages/mailman $ patch -p3 < /tmp/932.diff $ patch -p3 < /tmp/933.diff
And then restart mailman. This also assumes you are running
-Simon
Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins@cqu.edu.au<mailto:s.coggins@cqu.edu.au>
[https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939
On 10 Nov 2021, at 10:16 am, Joel Lord <jpl@ilk.org<mailto:jpl@ilk.org>> wrote:
I got one of these yesterday as well.
On 11/9/2021 7:06 PM, dancab@caltech.edu<mailto:dancab@caltech.edu> wrote:
We're also getting bit by this due to messages being replaced with the notice below.
"The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list".
I'm looking to apply the patch above.
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org>
-- Joel Lord
Mailman-users mailing list -- mailman-users@mailman3.org<mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave@mailman3.org<mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
Thanks Simon for the additional info about the patch procedure. I've updated my Dockerfile and done some basic tests. I'll push to production soon.
participants (5)
-
dancab＠caltech.edu -
Joel Lord -
Mark Sapiro -
Simon Coggins -
Stephen J. Turnbull