Hi all - I am running Mailman 2.1.5 (still!).
I was wondering what it is that determines if a message has "scrubbed attachments". For instance, a couple of days ago, I sent a simple message to one of my lists - just a sentence or two of text, and it created a directory under /archives/private/listname/attachments for it. I looked in there and displayed the HTML file it created, and all it had in it was my text and a few <BR>s.
I used the same mailer today and sent out another simple text message, and no directory was created under attachments this time.
And then I compare my list (not-archived, digestible, no digest members) to another identical list with plenty of posts sent to it (according to /logs/post), and there is no attachment directory at all. I just assumed it was the mailer I am using that determines if part of it should be scrubbed, but if that were so, why would there be inconsistencies between the message I posted just now and the one I posted 2 days ago?
Thanks in advance.
- jim -
Savoy, Jim writes:
I was wondering what it is that determines if a message has "scrubbed attachments".
The options you have set for filtering and the MIME structure of the message does. One possible explanation of your observation is that for some reason the first message had only a text/html part, and Mailman scrubbed it, while the second had both text/plain and text/html parts, so that the text/plain part was retained as is and the text/html discarded entirely.
why would there be inconsistencies between the message I posted just now and the one I posted 2 days ago?
Most likely, because the structures of the messages created by your MUA were different.
To determine for sure what's going on we'd need to know the exact settings of your content filtering options, and see the raw messages including all headers from the mailman/archives/private/LIST.mbox/LIST.mbox file.
Thanks Stephen.
I was wrong - an attachment directory was indeed created for my second message as well. In looking at the creation dates for that list, they always seem to be created sometime the next day after 3:00 am. Since the only cron job I run at that time for Mailman is senddigests, I guess that is what creates it.
So I guess the difference between my message being scrubbed, and a message on another list not being scrubbed, is the MUA (as the content-filtering is the same on all of our lists (ie never touched from the original defaults)). And because filter_content is set to NO on all lists, I don't imagine we're doing any filtering anyway.
As for the listname.mbox file, there isn't one. That directory has always been empty. The attachments dfirectory is very large though.
- jim -
On Wed, May 5, 2010 at 7:44 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
Savoy, Jim wrote:
Yes, The message contains a non-text/plain part or a text/plain part other that the default body with an unspecified character set and this part is scrubbed for the plain format digest.
You'll get more information from the digest itself.
[...]
As for the listname.mbox file, there isn't one. That directory has always been empty.
So either the lists are set to not archive or ARCHIVE_TO_MBOX is set to something other than 1 or 2 in mm_cfg.py.
The attachments dfirectory is very large though.
Because of all the parts scrubbed from the plain digest. Note that this will be done as long as the list is digestable even if no one is subscribed to the plain digest.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Savoy, Jim writes:
I was wondering what it is that determines if a message has "scrubbed attachments".
The options you have set for filtering and the MIME structure of the message does. One possible explanation of your observation is that for some reason the first message had only a text/html part, and Mailman scrubbed it, while the second had both text/plain and text/html parts, so that the text/plain part was retained as is and the text/html discarded entirely.
why would there be inconsistencies between the message I posted just now and the one I posted 2 days ago?
Most likely, because the structures of the messages created by your MUA were different.
To determine for sure what's going on we'd need to know the exact settings of your content filtering options, and see the raw messages including all headers from the mailman/archives/private/LIST.mbox/LIST.mbox file.
Thanks Stephen.
I was wrong - an attachment directory was indeed created for my second message as well. In looking at the creation dates for that list, they always seem to be created sometime the next day after 3:00 am. Since the only cron job I run at that time for Mailman is senddigests, I guess that is what creates it.
So I guess the difference between my message being scrubbed, and a message on another list not being scrubbed, is the MUA (as the content-filtering is the same on all of our lists (ie never touched from the original defaults)). And because filter_content is set to NO on all lists, I don't imagine we're doing any filtering anyway.
As for the listname.mbox file, there isn't one. That directory has always been empty. The attachments dfirectory is very large though.
- jim -
On Wed, May 5, 2010 at 7:44 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
Savoy, Jim wrote:
Yes, The message contains a non-text/plain part or a text/plain part other that the default body with an unspecified character set and this part is scrubbed for the plain format digest.
You'll get more information from the digest itself.
[...]
As for the listname.mbox file, there isn't one. That directory has always been empty.
So either the lists are set to not archive or ARCHIVE_TO_MBOX is set to something other than 1 or 2 in mm_cfg.py.
The attachments dfirectory is very large though.
Because of all the parts scrubbed from the plain digest. Note that this will be done as long as the list is digestable even if no one is subscribed to the plain digest.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro -
Savoy, Jim -
Stephen J. Turnbull