[clug] Linux email server that strips down attachments?

Hugh Fisher hugo.fisher at gmail.com
Fri Jul 7 02:57:12 UTC 2017

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


        Hugh Fisher

More information about the linux mailing list