Looking for an email client without sending features

reddy

reddy

For security reasons, we are looking to give employees receive-only email addresses.

In this context, I am looking for an email client allowing - and ideally only permitting - to read emails via IMAP without setting up SMTP. Thunderbird allows doing so but this is clearly not the intended usage, the user interface emphasizes sending too much (and the application has too many features to my liking). I am looking for a simple program in the Unix spirit whose sole role is to fetch emails for the account provided in its configuration file (no interactive configuration needed).

This can even be a terminal-based tool, however it must be easy enough to use for a non-power user (training can be provided but this cannot involve remembering dozens of keyboard bindings). Also, opening attachments should be easy enough.

Does anyone has any idea?

Thanks!
 
Claws email client is highly modular GUI pkg. Alpine is a good CLI too. In addition to disabling/blocking ports 25, 465, 587, you create email accounts or aliases (in admins e g. PostfixAdmin) that can only receive but with no sending capabilities as long as the (sub-)domain is not fully configured for SPF, DKIM etc.
 
For security reasons
Click to expand...

you can not use the words "email" and "security" in the same sentance .. It's simply impossible.

the only secure way to do what your asking is to recieve it on another computer, print it and hand it to the person (punchcards may also work to)

the problem is that email is a plain text service that only requires a response.. so you can send email via any method that will allow you to echo text to a waiting conenction.

some examples,
bluetooth to your phone
usb wifi to another network
any access to a shell or terminal
any access to a programming language or application
any open computer port, internal and external
any connection type including cdroms, ltp, serial usb bluetooth firewire etc
a mechanical device including a powersupply, soundcards or other vibrational devices
a laser of any type
any mua can be abused
mod'ed cables

skys the limit..

so the real question is .. whats a reasonable response .. trying to find a mua with no compose button is not a reasonable approach.

things that can actually help:
block new message compose urls such as https://mail.google.com/mail/u/0/#inbox?
dont block ports, block traffic ..
use an ids device like bro
remove all unused kernel modules like sound support, ltp/bluetooth
remove all applications including telnet, netcat etc
ensure you use protocol based firewalls like pf and create reg'es to look for required email headers like helo and mail from
configure domain mail boxes to deny all mail except
create mail redirection rules to clone or forward mail to a specific place
use a specific mail appliance such as an iron port, or a mail inspection device like fire eyes
configure firewalls to specifically drop all traffic from the client (doenst really work as you can relay mail on any port, including 80)
specifically hardcode dns entries
 
vigole said:
Block the ports -- 465/587/25?-- (RFC 8314) by firewall (IPFW)
Click to expand...
It doesn't have to be IPFW, but that's the "correct" advice. Trying to enforce a policy in a client software doesn't sound like a good plan…

But then, what exactly is the usecase of email if you can't reply? Maybe you're looking for something entirely different, like e.g. moderated newsgroups?
 
  • Like
Reactions: a6h
Zirias said:
It doesn't have to be IPFW, but that's the "correct" advice. Trying to enforce a policy in a client software doesn't sound like a good plan…
Click to expand...
I've worked around this in the past by forwarding ports over SSH. I worked for a smart company once that blocked SSH, too. I configured my SSH server to listen on port 443.

Edit: Go ahead and block port 443. I triple-dog dare you.
 
Jose said:
Edit: Go ahead and block port 443. I triple-dog dare you.
Click to expand...
I have my (open)sshd reachable on tcp:443, as well as my openvpn. net/sslh does the trick. Still, I can't use that to connect from work – DPI won't be fooled by just picking another port. It's still useful of course, any firewall operating on "layer 3-4" only will (have to) pass this traffic.
 
If they need to receive email but never to reply, it means email is only used to transmit simple orders that require no further explanation and no reporting.

In such a situation, a human being has no added value, a machine would certainly do a better job in a totally secure way (email-wise).
The conclusion is obvious: develop an application to do the work and fire the people. ;)

I've worked at a bank and everyone had the same email client. Some employees could send email on the internet, others couldn't, but all could send internal emails. Email was also used for calendar management. They also had an email filtering system scanning messages for keywords and attachments. Suspicious emails were quarantined an reported. Legitimate messages could be released upon n+1 approval, though.

Now, if you work at a company with a serious concern about security, I imagine employees are not allowed in with a smartphone, right?

Because it makes no sense to block outgoing email if anyone can use a streaming app to broadcast the company's secrets live on the web...

reddy said:
For security reasons, we are looking to give employees receive-only email addresses.
Click to expand...
 
You don't need to receve mail in that context.
Only sync Maildir from a file server.
If the goal is only read mails, a sync every x minutes drom a server in only one way could be sufficient.
 
That's why I said PostfixAdmin & a few changes here & there (pf and Postfix conf) can play a huge role in getting this going. They should then think of the UI. Of course, a custom UI and app might just worth it.
 
Thank you all for your contributions and ideas, I really appreciate it. When I said "security", I didn't have data exflitration and this kind of risk model in mind. Sure not having sending capabilities helps mitigate this risk (in an incomplete manner as a number of people have highlighted), but in our case the main problem being solved with this is one of corporate communications quality management + legal liability reduction.

We have certain quality standards for our communications and interactions with the outside world. The way many people email in the business world is awful, so every outbound com must be duly justified and go through the corporate coms department, who is the only one to have outbound capabililities. They send emails on behalf of people.

We do not want everyone to have the ability to send emails on behalf of the company, this is an aspect too many companies overlook nowadays yet if someone screws up, the whole company is liable (thus the legal risk mitigation side of the story). This approach also allows us to avoid "parallel diplomacy" (employees using our brand equity to conduct their private business, or look official - meaningful risk model in our business). So in a gist, as far as this particular receive-only aspect is concerned, the risk model is a non-technological one.

Our operations model is similar to what 20-100-2fe described, the receive-only email addresses are only a small part of our corporate communications framework. Internal business communications are done on internal message boards. The receive-only email adresses are actually for something that no one has mentioned so far: the many software systems and cloud applications that send automated emails to users ;) this is the main reason these receive-only adresses exist.

Workstations have a very restricted internet access, wikipedia + essential resources for specific teams (whitelist approach, company-wide + per team whitelist). For the few people who truly need unrestricted internet access occasionally, this can be done in dedicated secured rooms. Smartphones are not allowed in the office, you have to leave them at the entrance.

It is in this context that I am looking for an email client having the best possible user interface for our use case. Mutt looks like a very promising compromise, but before going down that road I will take a close look to Claws email to see to which extent we can customize the UX to remove the compose and reply buttons. I never heard of Claws before.

The receive-only adresses are created on a dedicated subdomain, they are non-readable and look like: ae34pp25rgh24frh@receiveonly.mail.mydomain.com. appropriate sending policies are enforced at the SMTP server level, we do not rely on the UX for security. This is the reason my only concern is to put together the best possible UX since all other aspects are already taken care of.
 
If it is for filtering logs from cloud, you can take a look at Mblaze.
It is a set of cli tools to get data from a maildir.
Not that friendly to read mail, but can be used to make some data analyse or automatic task.
 
What I miss, is a simple document management system for dealing with emails, with configurable workflow capabilities. Some could for example read only, other write also internal notices, other answer. Mails could be put in different queues. In some sense request tracker is that, but not simple. I gave up testing it.
 
blocking a port, or making upstream fire wall rules will not save you! the meer fact someone has access to a shell makes it impossible to secure that terminal upstream.

If you want do it properly you will need an endpoint on the machine.. the best solution for your use case is a bro sensor..
apparenty its called https://zeek.org/ now .. its open source and is already quielty built into several commercial products that offer communication between firewalls and endpoints.

this will allow you to transparently create and enforce policy at the workstation level.
 
Can you perhaps set up a web based email client (roundcube?) and just set up imap (leaving smtp unconfigured) and for aesthetics, hack the html interface to remove any reference to "sending".
 
You must log in or register to reply here.
Back
Top