Full Disclosure mailing list archives
RE: FD should block attachments
From: "Sean Crawford" <sean01 () accnet com au>
Date: Sun, 4 Apr 2004 01:18:33 +1000
Hi list first up.. Now again my 2 bits worth.. This is a forum called 'Full Disclosure'.. That's what it is.....not filtered. People can share what ever the hell they want be that a virus.. Semantics on filtering has no place here as that's your own security issue as this is a non-moderated forum.... Your a troll in the full sense...maximum bight's for little effort. If your mail server is so secure why would you care?............... If you want to host files for download....good on you!... Waste of bandwidth.................well what a joke to even mention that.... Those that host this list could say the whole hosting procedure is a waste no matter the content... Gawd post's like yours piss me off................go drown Troll... This whole thread is a waste. Sorry........... but this stuff pisses me off.............. I subscribe to this list for it's content..........not for it's filtering value.. Thankyou,.... Sean..\\PS...I so hope FD don't be come some lame arse filtered list....Thankyou hoster's -----Original Message----- From: full-disclosure-admin () lists netsys com [mailto:full-disclosure-admin () lists netsys com]On Behalf Of Michael Gale Sent: Saturday, 3 April 2004 9:29 AM To: full-disclosure () lists netsys com Subject: Re: [Full-disclosure] FD should block attachments Hello, As I have read all the replies below I feel I should respond. First of all I host my own domain which includes my own web, mail and ftp servers. At the moment my mail server is a postfix server with amavisd-new, clamAV and bogofilter. So all attachments get filtered - so client side filtering is NOT a problem or issue. The point -- this list is supposed to be for security professionals and not another bugtrag one. As security professionals, we should be setting examples. SMTP was not designed to transfer files, and think of the wasted bandwidth. I am lucky and pay for bandwidth at a flat rate and since my server is only my network my client downloads the message at 10MB second. The point -- how many people are on this list ? Lets say 10,000 -- some one sends a e-mail to the list containing a 1MB attachment. We just wasted / costs lists.netsys.com 10GB of transfer. Now lets those 10,000 list subscribers, 50% do not care about the attachment and delete it, but the other 5,000 each response with their 1MB attachment. Now think about where you work -- we have a internal exchange server and every day are trying to convienence people to post links to files on the Intranet instead of attaching them --- why ? because why send 100 people the same attachment which they will all most likely save forever in the mailbox. (Now I know Exchange is supposed to try and do single message store) Look at all the bandwidth we wast, the money we cost other people and the examples we set. Posting a link to a file is much better way -- only those who want to see the attachment will download it. IRC servers have this type of setup I believe -- maybe the FD could setup a HTTP server where list subscribers could post files -- have a cron to auto delete any file older then 30 days or less. Michael. On Mon, 29 Mar 2004 02:40:00 -0700 Michael Gale <michael.gale () bluesuperman com> wrote:
Hello, Being a member of this I do not mind the carrying on of list members. I usually enjoy reading the banter and I do not care about the"noise" ratio. What is annoying is the amount of viruses or waste of my bandwidth attachments that come from this list. I think FD should change their policy and block all attachments, except maybe plain text file's. Most people on this list are smart enough that exe's, zip and pif attachments do not need to be send, I am tired of the excuses: I had a virus I did not know what the file was ... ... FD should block attachments except for plain text. People can post links to web pages or what ever that way only people who want to see the attachment would get it, plus it would save on your bandwidth. Michael. -- Hand over the Slackware CD's and back AWAY from the computer, your geek rights have been revoked !!! Michael Gale Slackware user :) Bluesuperman.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
-- Hand over the Slackware CD's and back AWAY from the computer, your geek rights have been revoked !!! Michael Gale Slackware user :) Bluesuperman.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Server. part000.txt - is OK http://www.nod32.com __________ NOD32 1.701 (20040401) Information __________ This message was checked by NOD32 antivirus system. http://www.nod32.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: FD should block attachments, (continued)
- Re: FD should block attachments Michael Cecil (Apr 02)
- Re: FD should block attachments Paul Schmehl (Apr 02)
- RE: FD should block attachments Poof (Apr 02)
- Re: FD should block attachments Niek Baakman (Apr 03)
- Re: FD should block attachments petard (Apr 02)
- FD should block attachments Michael Gale (Apr 02)
- Re: [FD] FD should block attachments Andrew J Caines (Apr 02)
- Re: Re: [FD] FD should block attachments morning_wood (Apr 02)
- Re: Re: [FD] FD should block attachments Luke Norman (Apr 02)
- Re: [FD] FD should block attachments Andrew J Caines (Apr 02)
- Re: FD should block attachments Michael Gale (Apr 03)
- RE: FD should block attachments Sean Crawford (Apr 03)
- Re: FD should block attachments Michael Gale (Apr 03)
- Re: FD should block attachments Michael Gale (Apr 03)
- Re: FD should block attachments Troy (Apr 03)
- Re: FD should block attachments Nick FitzGerald (Apr 04)
- Re: FD should block attachments fd (Apr 04)