[Esa-l] Files to poison: Hybris

[Mark Luntzel]

So I'm trying to figure out how to get it to sanitize outgoing email. 
I'm just absolutely 100% sure its in the procmail documentation but my 
search abilities are not coming up with the right answers. I tried the 
sendmail.cf thing thats in the faq but after I put that in, it seemed to 
ignore the /etc/procmailrc altogether. So, if someone could kindly take 
a few seconds and point me in the right direction I'll buy you a 
beverage in Los Angeles.

hows that for an offer!

rcooper wrote:

> On Thursday 14 December 2000 06:21, you wrote:
> 
>> At 20:11 13/12/00 -0800, John wrote:
>> 
>>> If it's not business related, my answer is "tough."
>> 
>> Mine too.  I get flack from the lower levels of my userbase because of the
>> poisoned file I use (to summarize the diffs against the 'default' list:
>> *.asf, *.avi, *.bat, *.cmd, *.com, *.exe, *.mov, *.mp[g|eg?]?,
>> *.qt[m|vr?]?, *.scm, *.scr, prolly some others I've missed)  Quite
>> draconian, I think you'll agree, but in the business we are in
>> (recruitment) there is no reason for members of staff to *regularly*
>> receive files of these types.
>> 
> 
> I take the same draconian approach here.  Especially with *.exe and *.com.
> Our email system is small with only about 100 users or so.  Still we manage 
> to average about 2 gigs a month in email.  Since the majority of email is 
> amongst ourselves the risk is smaller than with the email that comes from the 
> outside.  We pretty much dont allow anything but .doc,.xls,.jpg,.gif.  
> Everthing else sent to /dev/null. 
> 
>>> We don't need a zillion copies of frog-in-a-blender or elf bowling
>>> coming in through our mail system at work. If it's business related,
>>> they make arrangements to upload it to our FTP site (all of our
>>> clients have accounts).
>> 
>> I can but agree.  If only I had the gumption to make internal mail go
>> through the sanitizer as well to stop the trade in .EXEs inside of the
>> company I'd have a shed-load of disk space returned to the servers.
>> 
>> I don't *yet* have the FTP option (I'm working on it though...), so I get
>> clients to send things through me (as the postmaster) if it's on the
>> poisoned list.
>> 
>>> Your boss should back you up if you let him know that business-related
>>> .EXEs are coming in at about one per year.
>>> 
>>> BTW, my users call me the Email Nazi. :)
>> 
>> I remind the higher-ups about Mellisa and ILOVEYOU when I start getting
>> flack and it all dies down very quickly.  They have the sense to see why
>> the approach I take with the sanitizer is, in the long-term, the best
>> approach.
>> 
>> I don't want to know what my userbase calls me :-)  No doubt it involves a
>> few expletives.
> 
> 
> 
> I santize all internal and external mail.  The File mangling was a problem at 
> first.  I had a meeting to address this isssue with the end users.  I 
> educated them as to why the filename was mangled and not launchable from 
> their email client.  I showed them examples of what can happen if they launch 
> an attachment that is infested and the effects it would have on their work.  
> Once they saw I was looking out for their best interests and not trying to 
> exert authority over them and make things harder, they gave me 100 % support. 
>  So naturally, the next step was to stop all the little cute .exe files that 
> offices share amongst themselves.  Again, communication and education was key 
> in getting user support.  I allowed the users to take an active role in the 
> policy.  For example sometimes a vendor will call complaining they cannot 
> send a certain filetype to our email systems. My users automatically say 
> tough.  We dont accept those file types!  By making the users part of the 
> process they will not feel alienated and will actually help the process.  
> Perhaps this approach may not work well for really large groups but I have 
> found a little bit of human engineering can go a long ways towards making the 
> things work a lot smoother. 
> 
> 
> Cheers,
> 
> Ron
> 
> 
> 
> 
> 
>> Kind regards
>> 
>> Murray Crane
>> SYSADMIN
>> Longbridge International Plc
>> 
>> _______________________________________________
>> E-mail Security Announce list mailing list
>> E-mail Security Announce list at spconnect.com
>> http://www.spconnect.com/mailman/listinfo/esa-l
> 
> _______________________________________________
> E-mail Security Announce list mailing list
> E-mail Security Announce list at spconnect.com
> http://www.spconnect.com/mailman/listinfo/esa-l