I have Scrubber enabled on my Mailman 2.1.5 configuration. It works fine stripping the attachments, except, why does it change a Microsoft Word extension ".doc" to a ".bin"? This makes it difficult to open the attachment, because you have to either save it to your hard drive and associate the file to open in the correct program, or choose which program to open it with. Why doesn't Scrubber just leave it at .doc and then when you click on the stripped attachment link, wouldn't it know to bring up the correct application and display the file? Or would it thing the content type is HTML? Any solutions or work around. Please respond this is critical that I know if there is something I can do.
At 10:50 AM -0600 2004-09-24, Kory Wheatley wrote:
I have Scrubber enabled on my Mailman 2.1.5 configuration. It works fine stripping the attachments, except, why does it change a Microsoft Word extension ".doc" to a ".bin"?
Because leaving it as a ".doc" file is dangerous.
Any solutions or work around. Please respond this is critical that I know if there is something I can do.
Keep in mind that this is a volunteer open source project. If
you've got anything that is critical, you need to consider support issues as part of your decision as to what to use.
On Friday, Sep 24, 2004, at 16:43 US/Eastern, Brad Knowles wrote:
At 10:50 AM -0600 2004-09-24, Kory Wheatley wrote:
I have Scrubber enabled on my Mailman 2.1.5 configuration. It works fine stripping the attachments, except, why does it change a Microsoft Word extension ".doc" to a ".bin"?
Because leaving it as a ".doc" file is dangerous.
Get real. It changes the extension not because .doc files are dangerous but because the sender simply failed to use Mailman's idea of the proper MIME type for a .doc file. You can of course get Mailman to leave a .doc file as a .doc file by sending it in with a content-type of application/msword. This just turns out to be unlikely in practice because MUAs have limited knowledge of proper MIME types.
--Robby
Robby Griffin wrote:
Get real. It changes the extension not because .doc files are dangerous but because the sender simply failed to use Mailman's idea of the proper MIME type for a .doc file. You can of course get Mailman to leave a .doc file as a .doc file by sending it in with a content-type of application/msword. This just turns out to be unlikely in practice because MUAs have limited knowledge of proper MIME types.
So Mailman should dumb itself down to the level of these MUAs?
Even Popcorn, my Windows client of choice, which is a fully self contained (except for a small initialization file) compressed executable 118KB in size, knows the proper MIME content-type for most common file types.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Friday, Sep 24, 2004, at 18:27 US/Eastern, Mark Sapiro wrote:
Robby Griffin wrote:
Get real. It changes the extension not because .doc files are dangerous but because the sender simply failed to use Mailman's idea of the proper MIME type for a .doc file. You can of course get Mailman to leave a .doc file as a .doc file by sending it in with a content-type of application/msword. This just turns out to be unlikely in practice because MUAs have limited knowledge of proper MIME types.
So Mailman should dumb itself down to the level of these MUAs?
Even Popcorn, my Windows client of choice, which is a fully self contained (except for a small initialization file) compressed executable 118KB in size, knows the proper MIME content-type for most common file types.
Well, whether it's common isn't really the issue. I meant that in general Alice's MUA does not have knowledge of what MIME types Bob's Mailman will accept (meaning, handle gracefully in archives) for a .foo file. I'd rather Mailman be liberal, not dumb, but it seems to amount to the same thing here.
Suppose that all MIME types used by all software are standardized and developed along a single timeline. If Mailman gets ahead of an MUA in terms of the set of MIME types it accepts, then senders won't be using the proper types yet and confusion will result if anyone sends attachments using the old types (in particular, their MUA's default type for unrecognized extensions). If Mailman lags behind an MUA then users may send using the new types that Mailman doesn't yet accept and confusion will result.
And of course if there are multiple timelines of development or nonstandard MIME types in some software, then confusion will result from the differing sets of MIME types known to each piece of software at any given time.
I'm not convinced this is a feature, it just seems so fragile.
--Robby
At 6:04 PM -0400 2004-09-24, Robby Griffin wrote:
Because leaving it as a ".doc" file is dangerous.
Get real. It changes the extension not because .doc files are dangerous but because the sender simply failed to use Mailman's idea of the proper MIME type for a .doc file.
Leaving it as a ".doc" file when the MIME bodypart type does not
match the claimed extension *is* dangerous.
On Friday, Sep 24, 2004, at 19:07 US/Eastern, Brad Knowles wrote:
Leaving it as a ".doc" file when the MIME bodypart type does not match the claimed extension *is* dangerous.
In mail, yes (and what does Mailman normally do to sanitize extensions / MIME types in the messages it redistributes?). But on the web? I'm curious, what's the threat model?
--Robby
Kory Wheatley wrote:
I have Scrubber enabled on my Mailman 2.1.5 configuration. It works fine stripping the attachments, except, why does it change a Microsoft Word extension ".doc" to a ".bin"? This makes it difficult to open the attachment, because you have to either save it to your hard drive and associate the file to open in the correct program, or choose which program to open it with. Why doesn't Scrubber just leave it at .doc and then when you click on the stripped attachment link, wouldn't it know to bring up the correct application and display the file? Or would it thing the content type is HTML?
That depends on what content-type your web server associates with .doc extensions.
Any solutions or work around. Please respond this is critical that I know if there is something I can do.
You might try putting a .htaccess file in archives/private/listname or in archives/private/listname/attachments with a
AddType application/msword bin
directive in it. Depending on your web server and browser, this may work, but if it does it will then try to open any .bin attachment with msword which will be a problem if you have any non-msword attachments that get saved with "bin" extensions.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Friday, Sep 24, 2004, at 16:55 US/Eastern, Mark Sapiro wrote:
You might try putting a .htaccess file in archives/private/listname or in archives/private/listname/attachments with a
AddType application/msword bin
directive in it. Depending on your web server and browser, this may work, but if it does it will then try to open any .bin attachment with msword which will be a problem if you have any non-msword attachments that get saved with "bin" extensions.
This is pretty lame. I run Mailman in an environment where most of the users use Lotus Notes on Macs, and in our case Mailman converted the vast majority of their attachments to .bin or .obj because Notes sent most things as application/octet-stream. PDF file? .bin. Excel file? .bin. Word doc? .bin. Argh. Users can NOT figure out how to open these files (or even what application they were supposed to have been openable in) after getting them from the archives. Most of them had Stuffit Expander launch automatically (on the .bin file, duhr) and were generally confused.
I operate under the assumption that Apache knows more about MIME types and extension mappings than Mailman does, so I hacked my Scrubber.py to avoid ever altering the extensions of attachments. Note that if you do this you have to be careful not to let the webserver do any server-side processing on any files in the archiver attachment area. It's also useful to make the default type for files of unrecognized extension be application/octet-stream so that they don't display in the browser -- this is done in .htaccess for public archives and in private.py for private archives.
I'll come up with a patch if anyone wants it, but seriously, YMMV, a lot.
--Robby
Robby Griffin wrote:
This is pretty lame. I run Mailman in an environment where most of the users use Lotus Notes on Macs, and in our case Mailman converted the vast majority of their attachments to .bin or .obj because Notes sent most things as application/octet-stream. PDF file? .bin. Excel file? ..bin. Word doc? .bin. Argh. Users can NOT figure out how to open these files (or even what application they were supposed to have been openable in) after getting them from the archives. Most of them had Stuffit Expander launch automatically (on the .bin file, duhr) and were generally confused.
I agree, but why is Lotus Notes sending PDFs, etc. as application/octet-stream instead of application/pdf, etc?
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi all,
Robby Griffin wrote:
I'll come up with a patch if anyone wants it, but seriously, YMMV, a lot.
I think I should commit one of my unpublishd patch on SourceForge CVS.
@@ -356,8 +396,16 @@ # e.g. image/jpg (should be image/jpeg). For now we just store such # things as application/octet-streams since that seems the safest. ctype = msg.get_content_type()
- fnext = os.path.splitext(msg.get_filename(''))[1]
- ext = guess_extension(ctype, fnext)
- # i18n file name is encoded
- lcset = Utils.GetCharSet(mlist.preferred_language)
- filename = Utils.oneline(msg.get_filename(''), lcset)
- fnext = os.path.splitext(filename)[1]
- # For safety, we should confirm this is valid ext for content-type
- # but we can use fnext if we introduce fnext filtering
- if mm_cfg.SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION:
ext = fnext- else:
ext = guess_extension(ctype, fnext) if not ext: # We don't know what it is, so assume it's just a shapeless # application/octet-stream, unless the Content-Type: is
With this patch, site manager can set SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in mm_cfg.py to use attachment filename extension as is specified by the original attachment. I also want to merge patch id 1027882 so that really dangerous files can be trapped by MimeDel.py.
"Tokio" == Tokio Kikuchi tkikuchi@is.kochi-u.ac.jp writes:
Tokio> I think I should commit one of my unpublishd patch on
Tokio> SourceForge CVS.
[...]
Tokio> With this patch, site manager can set
Tokio> SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in
Tokio> mm_cfg.py to use attachment filename extension as is
Tokio> specified by the original attachment.
Arrgh. A couple of my lists share a host with people who would probably like to have that option = True, but I definitely want False. Can this be made to be a "site manager permits, list manager enables" double opt-in option, pretty please?
BTW, don't serious webservers support some kind of ./.htmime.types facility? If so, then the archiver could inform the webserver of the MIME type it observed for the file, and pretty much wash its hands of the issue. (You'd still like to tell the webserver that the file came from a poorly authenticated source, but I think for directories containing list archives you can normally just assume that. ;-)
Hi,
Stephen J. Turnbull wrote:
Arrgh. A couple of my lists share a host with people who would probably like to have that option = True, but I definitely want False. Can this be made to be a "site manager permits, list manager enables" double opt-in option, pretty please?
Please submit an item in SourceForge feature request (RFE) tracker. I have no time to work on this now but may be able to tackle near future. http://sourceforge.net/tracker/?group_id=103&atid=350103
I think I should commit one of my unpublishd patch on SourceForge CVS.
(snip)
With this patch, site manager can set SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in mm_cfg.py to use attachment filename extension as is specified by the original attachment. I also want to merge patch id 1027882 so that really dangerous files can be trapped by MimeDel.py.
I've committed these patches in the cvs.
You can download the latest source from the cvs by:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mailman co
-r Release_2_1-maint mailman
Cheers,
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
participants (6)
-
Brad Knowles -
Kory Wheatley -
Mark Sapiro -
Robby Griffin -
Stephen J. Turnbull -
Tokio Kikuchi