[clug] Linux email server that strips down attachments?

[Scott Ferguson]

Interesting problem.

On 02/07/17 21:06, Hugh Fisher via linux wrote:
> For a change of topic from the impending doom of CLUG…
> 
> Is there, or could there be, a Linux email server that strips all the
> code and interactivity from incoming attachments while leaving the
> content readable?

Yes.

Exim.

For those that fear the subset of HTML used in email you can use
acl_smtp_mime (formerly demime)

To process attachments - you can use antiword and pdf2text.

In both cases adjust your ACL rules to implement the conversions....
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; and because proper
implementation of malware scanning *and* secured client systems make the
processes redundant.

You *will* need considerably more resources for your email system if you
decide to go the path you propose.

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.

> 
> I'm now in my second job working with mostly non-technical folk, and
> I'm seeing a lot of attachments being emailed around, mostly DOCX
> (Microsoft Word) and PDFs. Now the first reaction of anyone who
> follows the regular stories about phishing and malware spread through
> email is "Nooo! Don't do that!" and trying to convince people to
> change their ways.

A major problem - and the most common cause of software projects failing
is failure to consult with end-users. The best intentions will not
result in a system policy/software project being used if the end-users
don't want or understand it...

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).

Apropos of nothing - it takes about 20 minutes of poking around to gain
remote access as a system admin on the "locked down" M$ Surface devices
designed/marketed as being "the defence" against that problem.

> 
> Which I've come to recognise won't work. A lot of people write emails
> in Word format because Word is their usual writing tool, just a a lot
> of hackers read and write email within Emacs.

*cough* Vi
:p

> And PDFs are usually the
> best way to send around reports, design proposals, anything where the
> appearance needs to be evaluated. Banning attachments is not
> realistic.
> 
> However, these documents are not being emailed around for editing.
> Office 365, Google Docs, Dropbox, whatever, are well established for
> collaborative work. 

Each have their failings e.g. security, privacy, integration with local
tools/applications.

> 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.

> 
> So, I imagine that these organisations would be considerably more
> secure with an email server that examined and stripped down all
> incoming attachments. 

That might be true if it were only text that was important (and we
ignore proof of the author e.g. PGP, as opposed to the oft-neglected
proof of the sender e.g. DKIM etc).

> Use the Libre Office code to take apart the
> DOCXs and PDFs. Strip out every macro and embedded font, every
> fragment of Javascript or Visual Basic, even hyperlinks. Re-assemble
> as a pure read-only document and send it on.

A (properly?) implemented client system 'should' prevent any of those
things from being a concern - instead of transferring responsibility for
security from the unrestricted ability of the end recipient to shoot
foot to solely being the responsibility of the email server (like
passing laws against sharp corners on furniture to protect the clumsy)
(??) As you undoubtedly discovered - that's an issue that's rarely
addressed, and failure to do so just exacerbates the existing problem.

> 
> Doable?
> 
> 

Yes but - to be effective you would need to implement and enforce
organisation wide publishing policy, and spend considerable time and
resources doing system analysis to try and prevent unforeseen problems.
There are also legislative issues with removing accessibility aids -
aids that are not possible to add to plain text without reducing the
content itself to "dumb text".

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. :(


Kind regards


-- 
    A: Because we read from top to bottom, left to right.
    Q: Why should I start my reply below the quoted text?

    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?

    A: The lost context.
    Q: What makes top-posted replies harder to read than bottom-posted?

    A: Yes.
    Q: Should I trim down the quoted part of an email to which I'm reply

http://www.idallen.com/topposting.html