issues with BSD/OS 4.0 and mailman 1.0b8
The web site says that Python 1.5 or newer is required. It seems to be that 1.5.1 or newer is required, as the "getpass" module does not exist in 1.5.
Also, under BSD/OS unix (and most BSD in general) the group setgid bit is not necessary on directories -- the default bahavior is to use the directory's group when creating new files. Having the setgid bit causes annoying security alerts, but is otherwise harmless.
The INSTALL document says that the default list for --with-mail-gid is 'other daemon'. However, the wrapper on my system was build to be setgid mailman.
I'm building Python 1.5.1 now, so when I get it going, I may report more... ;-)
v.
Is there a way to reject postings with attachments? This is starting to get to be a problem. I know I can limit message size, this isn't really the problem as much as people including non-text items like pictures and word files.
The best solution, would be to replace attachments with links to the web server. Thus, if a person attached three items, a picture, a word file, and a visio document, Those items would be stored in the archive, and a link to the items would be placed in the e-mail.
Thanks again!
Best,
Clark
At 04:22 PM 2/22/99 , Clark Evans wrote:
Is there a way to reject postings with attachments?
I put the following in the area labelled "Hold posts with header value
matching a specified regexp.":
content-type: .*(multipart/|/enriched|coded|html)
This doesn't reject them but does hold them for approval. At least thats
one way around it for now. This is similar to what I did when I ran SmartList (actually I still do.. until I transition all my lists).
Sanjay
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Sanjay Parekh | | sanjay.parekh@arris-i.com | | Systems Engineer - Cornerstone | | Arris Interactive | | Atlanta, GA | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- PGP Key ID: 0xE1FD2FBA PGP Fingerprint: 547F 95C0 9E32 E936 D51F 6CA7 EB14 A33A E1FD 2FBA
"CE" == Clark Evans clark.evans@manhattanproject.com writes:
CE> Is there a way to reject postings with attachments?
CE> This is starting to get to be a problem. I know
CE> I can limit message size, this isn't really the
CE> problem as much as people including non-text
CE> items like pictures and word files.
Sanjay posted his approach, which is probably the best you can do for now without hacking the code. An idea we threw around last year was to have configurable filters the message could pass through. One such filter could either strip or reject attachments, similar to what you describe.
-Barry
CE> Is there a way to reject postings with attachments? CE> This is starting to get to be a problem. I know CE> I can limit message size, this isn't really the CE> problem as much as people including non-text CE> items like pictures and word files.Sanjay posted his approach, which is probably the best you can do for now without hacking the code. An idea we threw around last year was to have configurable filters the message could pass through. One such filter could either strip or reject attachments, similar to what you describe.
Another option for the time being involves wrapping your aliases with a filter like procmail. This is what I do for my majordomo lists or any place that I need extra filtering (note the majordomo slant of these recipes, but I've converted stuff enough here so that it should apply to Mailman...) And yes, it's a hack. :)
listname :"|/usr/bin/procmail -m LIST='listname' EXTRA='' /etc/mail/procmailrc.lists" listname-admin :"|/home/staff/mailman/mail/wrapper mailowner listname" listname-request :"|/home/staff/mailman/mail/wrapper mailcmd listname" owner-listname :listname-admin listname-owner :listname-admin
/etc/mail/procmailrc.lists looks like this:
PATH=/usr/bin:/usr/local/bin:/bin HOME=/etc/mail
# if EXTRA isn't set to an archiver or something, set to devnull # so that we have another address to hide the -outgoing address # in the Received: headers -- another ugly majordomo-required # hack :0
- EXTRA ?? ^^^^
{ EXTRA="devnull" }
# check against message-id database to make sure that this isn't # a duplicate post :0 Wh: $HOME/list-cache/${LIST}.lock | formail -D 8192 $HOME/list-cache/${LIST}.cache
# mail people to let them know that I don't like attachments # on the list :0
- ^(Content-Type: multipart/mixed;|X-MS-Attachment: WINMAIL.DAT)
- ! ^FROM_DAEMON
- ! $ ^X-Listname: ${LIST}@mallorn.com
{
:0 hc
| (formail -r -A"Precedence: bulk"
-A"X-Listname: ${LIST}@mallorn.com"
-A"From: owner-${LIST}@mallorn.com" ;
cat "/usr/lib/mail/reply.mime" | sed s/LISTNAME/${LIST}/) | $SENDMAIL -t -f owner-${LIST}@mallorn.com
}
:0 | /home/staff/mailman/mail/wrapper post $LIST,$EXTRA
Chris
"VK" == Vivek Khera khera@kciLink.com writes:
VK> The web site says that Python 1.5 or newer is required. It
VK> seems to be that 1.5.1 or newer is required, as the "getpass"
VK> module does not exist in 1.5.
I missed an import in bin/newlist. See patch below.
VK> Also, under BSD/OS unix (and most BSD in general) the group
VK> setgid bit is not necessary on directories -- the default
VK> bahavior is to use the directory's group when creating new
VK> files. Having the setgid bit causes annoying security alerts,
VK> but is otherwise harmless.
What kind of security alerts? I think it's probably more common (Solaris for sure, Linux??) to require the g+s bit on dirs.
VK> The INSTALL document says that the default list for
VK> --with-mail-gid is 'other daemon'. However, the wrapper on my
VK> system was build to be setgid mailman.
Do you mean that it was built with mail-gid `mailman' by default? This setting anyway is highly dependent on MTA.
-Barry
Index: newlist
RCS file: /projects/cvsroot/mailman/bin/newlist,v retrieving revision 1.23 retrieving revision 1.24 diff -c -r1.23 -r1.24 *** newlist 1999/02/10 23:15:53 1.23 --- newlist 1999/02/27 18:05:43 1.24
*** 31,37 ****
import sys, os, string import time ! import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils --- 31,41 ----
import sys, os, string import time ! try: ! import getpass ! except ImportError: ! # we must be in Python 1.5, which didn't have the getpass module ! from Mailman.pythonlib import getpass import paths # path hacking from Mailman import MailList from Mailman import Utils
"BAW" == Barry A Warsaw bwarsaw@cnri.reston.va.us writes:
VK> Also, under BSD/OS unix (and most BSD in general) the group VK> setgid bit is not necessary on directories -- the default VK> bahavior is to use the directory's group when creating new VK> files. Having the setgid bit causes annoying security alerts, VK> but is otherwise harmless.
BAW> What kind of security alerts? I think it's probably more common BAW> (Solaris for sure, Linux??) to require the g+s bit on dirs.
BSD generally does a nightly scan for setuid file changes. Setgid directories also come up on the scan when they change, which happens a lot with mailing list archives.
I just manually un-setgid them... but I have to temporarily setgid the root directory again when I re-install the software.
It would be nice if configure had an option with --no-setgid-dirs to turn off this "feature".
VK> The INSTALL document says that the default list for VK> --with-mail-gid is 'other daemon'. However, the wrapper on my VK> system was build to be setgid mailman.
BAW> Do you mean that it was built with mail-gid `mailman' by default? BAW> This setting anyway is highly dependent on MTA.
I was confused when I installed it. I thought the program would be setgid the group it needed to be run as, rather than checking that it was being run from the proper group and begin setgid mailman.
It turns out that under Postfix, the program is run under GID "daemon", but the program was checking for group "mail". So I hard-coded it according to the instructions in the error message.
v.
"VK" == Vivek Khera khera@kcilink.com writes:
"BAW" == Barry A Warsaw bwarsaw@cnri.reston.va.us writes:
VK> BSD generally does a nightly scan for setuid file changes.
VK> Setgid directories also come up on the scan when they change,
VK> which happens a lot with mailing list archives.
VK> I just manually un-setgid them... but I have to temporarily
VK> setgid the root directory again when I re-install the
VK> software.
VK> It would be nice if configure had an option with
VK> --no-setgid-dirs to turn off this "feature".
Would it be enough if you could just skip the chmod g+s on the installation of all the subdirs? I could paramaterize that step in the Makefile, so that you could do the following:
% make DIRSETGID=: install
-Barry
"BAW" == Barry A Warsaw bwarsaw@cnri.reston.va.us writes:
VK> It would be nice if configure had an option with VK> --no-setgid-dirs to turn off this "feature".
BAW> Would it be enough if you could just skip the chmod g+s on the BAW> installation of all the subdirs? I could paramaterize that step in BAW> the Makefile, so that you could do the following:
That would be sufficient. I can live with a top-level setgid directory since it won't change often enough to show up on the security reports.
v.
participants (5)
-
Barry A. Warsaw -
Christopher Lindsey -
Clark Evans -
Sanjay Parekh -
Vivek Khera