Forum OpenACS Development: Incoming Mail Handling

Collapse
Posted by Richard Hamilton on
A number of people have been talking about developing a facility whereby users can reply to notication emails (from the Project Manager, Workflow or Ticket Tracker) and have their replies automatically stored in the db and associated with the appropriate acs_object.

This seems to open up a number of potential security issues (which Malte, DaveB and I have discussed briefly) which really warrant wider debate and scrutiny.

Malte suggested that I kick this off in the Forum here, so to get it going:

EXAMPLE USE CASE
~~~~~~~~~~~~~~~~

A company deals with an agency. All mail goes to the
reception. The reception then forwards the incoming customer mails to the people concerned.

All mails recieved from a customer that are related to a project need to be stored along with the project as a comment or mail-tracking in the OpenACS system.

POTENTIAL ISSUES
~~~~~~~~~~~~~~~~

Personally I have grave reservations about allowing emails to get as far as the database!

It seems to me that if we do this we will be effectively using email as a way of triggering the execution of code on the webserver and also as a means of posting data via the webserver app to the database. This is almost like making email to the domain a valid db transaction. Sounds highly insecure to me. In the absence of checks and balances, is this not asking for problems with malicious emails and DoS attacks? Doesn't it completely circumvent the site session security?

Opening up a port for a mail transport agent on the computer running the webserver is something that I personally try to avoid for reasons of security, performance (exposure to high inbound email traffic loads that you cannot control) and bandwidth - for servers
on pay-per-byte backbone network hosting deals your exposure to email traffic once you open up an smtp server makes your bandwidth cost unquantifiable and uncontainable.

Sounds dangerous if to me, and ultimatelty offers nothing that a link in a notification email to the site won't accomplish! Initially I asked "why not communicate using the extensive facilities in the community system rather that have insecure, pstn emails flying around all over the place that then require another layer of admin to keep together?". The answer is that for a reception handling 100's of emails per day, keep having to login to the site to copy and paste the email text is cumbersome. I can understand this point of view.

Having used a system like this I understand its seductive convenience. I think that it would be a really good feature to have if we can figure out a secure(ish) way to do it.

Inviting input.........................

Richard

Collapse
2: Re: Incoming Mail Handling (response to 1)
Posted by Malte Sussdorff on
This issue has been extensively discussed as well at https://openacs.org/forums/message-view?message_id=316225
Collapse
3: Re: Incoming Mail Handling (response to 1)
Posted by Malte Sussdorff on
I think due to the fact that setting this up requires quite some work (you have to ammend Postfix to do anything useful and configure OpenACS correctly to listen to the incoming e-mails), I'd say whoever needs this functionality (sending an email to the system without authentication) is aware of the risks and we should not limit the toolkit to not allow arbitrarily incoming email into the system. Though this is a security risk, you have to conciously set it up that way, so I don't think we are facing a problem. There are a lot of ideas on how to improve the security, e.g. for the receptionist we will block emails from the outside of the company (so only mails from within the company can be send to the mailserver). Or you could say only people with a valid sender email (though this can be faked) will be allowed to send emails to the system, or you could rely on digitally signed messages or, or, or.
Collapse
4: Re: Incoming Mail Handling (response to 1)
Posted by Richard Hamilton on
OK, well I agree that as opening up the security hole is a conscious decision for the admin - and is therefore the admin's own lookout!

I also agree that limiting the toolkit based on some kind of arbitrary notion of what constitutes an acceptable level security policy is not a good idea (because everyone's needs are different). In fact we should probably have a general set of guiding principles for OpenACS security for just that purpose. But I really don't think that we should actively encourage poor security.

As I have said before - just because something appears convenient, it doesn't necessarily mean that it is a good idea! Also there is little that can be less convenient than a compromised or crippled service. 😊

My own feeling is that as this is a desireable feature, if we could only devise a more secure way of doing it and agree on that, we would enhance the toolkit whilst mitigating this unhappy tradeoff between utility and security.

I vote that we thrash out some solutions to the security issues and try to make this work in a more robust and more secure fashion.

Collapse
5: Re: Incoming Mail Handling (response to 1)
Posted by Jun Yamog on
Ask Mat Kovach, he implemented an outgoing and incoming email handler.