[Mailman-Users] Mailman Munging MIME Content Headers
scott.armstrong at nvl.army.mil
Sat Dec 8 10:09:29 CET 2001
That's about as descriptive as I can get regarding my problem.
The scenario is this -
I've replaced pipermail with the updated hypermail package and I've done this by subscribing a special user to each list and setting
By leaving the "archive_to_mbox" turned on, it allows me to retain a backup of the archived messages and to reconstruct the html using some scripts I've written that interface with hypermail. I hope to soon add the capability for list owners to edit the archives via IMAP and reconstruct the html versons that their users see.
To retain Mailman's authentication of private archive membership, I've left the ~mailman/archives/private tree intact and placed the html archives in the subdirectories by list name under this location. With the exception of some occasional problems with relative URL referencing (sometimes the "/" isn't appended to the archive name), everything works great. I even have indexing and searching set up using swish-e.
My problem occurs when a user requests a MIME document from the archives. It looks as if the content type is being stripped off before the document is being sent or it's just not being inserted from the .meta files. If a user requests an MS Word document, it is pulled up in binary format within the browser. If I replicate the same tree to another location, losing the Mailman authentication :( , everything works perfectly and the content type is sent along with the document.
I'm running Mailman 2.0.8 under SPARC Solaris 8, Apache 1.3.22 w/ mod_ssl, Python 2.1.1, and I'm utilizing cern_meta_module and the hooks in Hypermail 2.1.3 to create the .meta directory and the .meta files.
Would someone please help me track this down and fix it? I would very much hate to lose the Mailman authentication.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mailman-Users