Attachments being scrubbed even for lists where 'archive' is set to No
This is Mailman 2.14, but the bug was also present in ancient releases.
We have a list configured like this: archive=No archive_private=Yes
The global settings are: DEFAULT_ARCHIVE=On DEFAULT_ARCHIVE_PRIVATE=0 ARCHIVE_TO_MBOX=2 PRIVATE_EXTERNAL_ARCHIVER=No
Even though no html archives are being generated, Mailman still creates the attachments directory for this list, and saves all attachments in it.
I've traced the code responsible for this to ArchiverMailbox.__init__(), invoked by HyperArchive.processUnixMailbox(). I couldn't find where Mailman uses the perl-list 'archive' flag. Only the global DEFAULT_ARCHIVE seems to be considered.
-- Bernie Innocenti Systems Administrator, Free Software Foundation
Bernie Innocenti wrote:
This is Mailman 2.14, but the bug was also present in ancient releases.
We have a list configured like this: archive=No archive_private=Yes
The global settings are: DEFAULT_ARCHIVE=On DEFAULT_ARCHIVE_PRIVATE=0 ARCHIVE_TO_MBOX=2 PRIVATE_EXTERNAL_ARCHIVER=No
Even though no html archives are being generated, Mailman still creates the attachments directory for this list, and saves all attachments in it.
I've traced the code responsible for this to ArchiverMailbox.__init__(), invoked by HyperArchive.processUnixMailbox(). I couldn't find where Mailman uses the perl-list 'archive' flag. Only the global DEFAULT_ARCHIVE seems to be considered.
The list's 'archive' flag is tested in the ToArchive.py handler and if False, the message is never queued for archiving and the HyperArchive.processUnixMailbox() process is never invoked.
Scrubbing is not only done in archiving. See my comment in your bug report at <https://bugs.launchpad.net/mailman/+bug/767335/comments/1>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Bernie Innocenti
-
Mark Sapiro