So then removing attachments is just snakeoil: viruses are application/octet-stream.
As for size restriction: it is again snakeoil with the proposed limits: Klez is 120K. On the other hand, I see people happily sending 300+K attachments (eps files, say, with no compression) regularly on the users list. On the devel list people are sending core files as attachments (2.5M)! The largest file on the devel list is 3.5M (a diff.gz file). The largest file on the users list is 1.5M---a pdf file. People behind a modem will agonize over these. Email is certainly not a file distribution medium, and most people do not care about these enormous attachments. Also note that a 1M message sent to the users list means 465M on my server---since there are 465 subscribers there. One solution would be to ask people to post big files somewhere on their server, and then send only the URL to the list. But some people may not be able to do this (as was indicated on the users list). So I could set up a "bigfile" list, and people would send their too big messages there. Or I can imagine to set up an address so that it would automatically post the body on the web, and send the URL back to sender. This would mean though sending big files inline mail -s"big.eps" [EMAIL PROTECTED] < big.eps Perhaps I could handle attachments, if I find a suitable mime-slicer. But I do not see virus or spam decreasing from these measures. Mate On Tue, Apr 30, 2002 at 11:42:18PM +0200, Lars Gullik Bjønnes wrote: > > As you can see from this bounced message, the rules are now to harsh. [...] > Content-Type: multipart/mixed; boundary="=-=-=" > Mate Wierdl <[EMAIL PROTECTED]> writes: > > | I just set up all lists so that the following MIME types are > | removed, and if a message contains nothing else, it will be rejected: > > | application/octet-stream > > Isn't this often used for sending files containg non-ascii characters? > Or just files that does not have a recognized extension. > > > > | application/x-cpio > > should be allowed > > | application/x-csh > > ditto > > | image/tiff > > ditto > > | image/x-portable-anymap > | image/x-portable-bitmap > | image/x-portable-graymap > | image/x-portable-pixmap > > and these > > | image/x-xbitmap > | image/x-xpixmap > | image/x-xwindowdump > > and these > > | There is also a possibility that a message containing these kinds of > | attachments are simply rejected. Which option is better (I think the > | latter). > > > | Also, I think it is a good idea to pose an upper limit on message size. > | What should it be? Is 30,000 bytes good on all lists, but 300,000 on > | the devel list? > > 30k is not much..., perhaps double it? > > and the devel list will perhaps be ok with 300k, but I guess that the > subscribers will get a mail telling that the message is oversized? We > can enlarge the limit if it is needed. > > -- > Lgb
