[clug] Linux email server that strips down attachments?

Brenton Ross rossb at fwi.net.au
Fri Jul 7 05:55:32 UTC 2017


Perhaps it might be better to assume that some things are going to get
through your defences.

How about putting the email client (and enough stuff to read and answer
the emails) in a sandbox that was isolated from the users' other files
and programs. Any time a file needed to be moved to or from the email
sandbox it would be subject to stringent examination.
(This might also make it a bit more difficult for users to email
sensitive information out of the organisation.)

Brenton

On Fri, 2017-07-07 at 12:57 +1000, Hugh Fisher via linux wrote:

> On Thu, Jul 6, 2017 at 5:52 PM, Scott Ferguson via linux
> <linux at lists.samba.org> wrote:
> > however I'd strongly suggest *not* doing these things because: the
> > results are inconsistent; it presupposes that every email recipient does
> > not have visual handicaps; it overlooks the positive features of marked
> > up documents (images, links, character formatting; accessibility tags;
> > versioning controls; inline MIME digital signatures;
> 
> I'm well aware of these, which is why I very carefully wrote that I
> wanted to *preserve* formatting and markup, reassembling the content
> as valid DOCX/PDF, not convert everything to plain text. While I am at
> times nostalgic for USENET, I'm not trying to impose plain ASCII or
> UTF-8 on everyone.
> 
> > and because proper
> > implementation of malware scanning *and* secured client systems make the
> > processes redundant.
> 
> Which is what we, the IT industry, have been trying to do for at least
> the past decade. Malware scanners aren't new or rare, they just don't
> work. If malware scanners were going to prevent phishing and malware
> attacks, they would have by now.
> 
> (I know that scanners can pick up attacks IF we already know about
> them. Surprise surprise, evil minded individuals keep coming up with
> new attacks.)
> 
> > IMO the source of the problem is where the malware has an effect - on
> > the client systems. If people do, um, bad things as the result what the
> > postie delivers I'd rather the problem is solved by educating the
> > recipients and limiting their ability to shoot foot, than *trust* and
> > task Australia Post with scanning and modifying the mail.
> 
> Again, educating users is what we've been trying and failing to do for
> over a decade. If education worked, phishing attacks would have died
> out long ago.
> 
> People, myself included, will click on the wrong link or whatever
> because the majority of humanity are neither James Bond nor Dungeons &
> Dragons adventurers. We don't assume that everyone we come in contact
> with might be an enemy agent, and we don't constantly check for traps.
> Even skilled people get tired or distracted.
> 
> The people on this list are presumably more technical minded than
> most. Hands up if you check PDF documents for embedded JavaScript
> before you open them?
> 
> As for responsibility of the mail delivery system rather than
> individuals, a thought experiment. Put 500 grams of some radioactive
> substance in a box, address it to the workplace office/cubicle of
> someone you know at the Australian Taxation Office or Northrop
> Grumman, and drop it in a postbox. Do you think it's going to arrive
> on their desk? (Or if it does, that there won't be some serious
> conversations with the security and mailroom staff?)
> 
> Organisations impose all kinds of security practices on their
> employees. Stripping toxic crap out of email attachments is something
> malware scanners already do. I just want to extend it to whitelisting
> rather than blacklisting.
> 
> > I feel your pain (seriously) - but my experience is that it's very
> > difficult (even in high security environments) to trample on employees
> > rights to treat their employers systems and equipment as their own
> > personal playground - even when nothing in their job description or
> > qualifications gives them the ability to assess the risks of their
> > actions (no need to explain the problem where a user with
> > non-administrative rights can trigger malware with elevated system rights).
> 
> Nothing I'm suggesting takes away capabilities from end user desktops.
> If Jane in Auditing wants to write a Visual Basic macro or whatever
> that extracts email addresses from the organisation directory and
> sends out a form letter, I don't want to stop her. But there's
> absolutely no reason why that kind of program can be emailed to
> everyone from anywhere in the world. Even internally Jane should not
> be able to do so: she can drop it on the shared file server and email
> everyone where to look instead.
> 
> >> At least 95% of the time the recipient just needs
> >> to read them, nothing else.
> >
> > That varies considerably from one organisation to another, and within
> > organisations.
> 
> And I said this was for organisations, not everyone. If your company
> or whatever really needs people to receive and execute random bits of
> code in email, I imagine you won't be interested.
> 
> > Consider that only a small percentage of people that "use" email - use
> > it effectively (most use it like postcards instead of conversation), and
> > fewer still can "write" (communicate effectively). Very, very few
> > understand or use proven identification systems - which makes much
> > content redundant/dangerous regardless of the format it's delivered in. :(
> 
> Which is why I think this would be easier to get implemented and used
> than you think. The number of people who actually want to send macros
> and JavaScript and whatnot is microscopic. Nobody else will notice.
> 
> Oh, and and I didn't make it clear first time around that this would
> of course be a Linux system. "Your email has been checked by Linux
> Steam Cleaner" would make a nice tag at the end of incoming emails,
> and might even get a few people thinking what else Linux might be good
> for.
> 
> -- 
> 
>         cheers,
>         Hugh Fisher
> 




More information about the linux mailing list