Security implications of a limited function server

Question

I want to collect certain information from people/devices via email. These emails will never be delivered to anybody, but simply processed on the server. Received emails will be processed - some simply dropped, most stored (in a database), attachments may or may not be stored (but never executed) depending on certain conditions.

I have investigated using existing MTA software for this, and have come to the conclusion that it would be overkill and create complexity far above what is necessary for this purpose.

If I were to write my own MTA software I would need to implement a fairly limited subset of features - literally enough to receive emails, no sending whatsoever. I would keep the actual MTA software as thin as possible to minimize the amount of maintenance. So after the MTA software has received an email it would pass it (in its entirety) to a second piece of software which would perform the processing.

The emails are simply stored, to be retrieved in a web UI by the sender and anybody else they specifically allow only. Certain attachments will be stored, but never executed on the server and again only accessible by the sender of the original email and others they nominate.

I know very little about the world of network security - with such a limited server am I opening up a potential way in? I guess the answer to that question is always yes - but am I any less secure that with a well maintained, secure but full featured MTA software (like Postfix)?

If I haven't been specific or clear enough please let me know, thanks!

(The server will be Linux, likely Ubuntu. Software most likely written in C# under Mono, possibly Python or a mix (C# server, Python processing))

@ S. Lott I've spent the past 3 days exploring the option of using existing software and it seems my that my best solution would be Postfix > Procmail > my own processing. Postfix is a complete MTA solution which took a lot of configuration to get close to what I want - the complexity is largely an issue of configuration and getting 3rd party software to work together do do my bidding. I'm sure somebody well versed in configuring mail servers and administering nix servers in general would have a much easier time, but as I see it a custom solution wouldn't be a huge project - my only real concern was security.

Also with regards to overkill - I need a very limited subset of what Postfix does, and most of the configuration I was looking at was trying to disable certain behaviour. In many respects I would prefer to use mature, stable Postfix over my own solution, but I feel that the time already invested could have been used much more productively writing something specifically for the task.

Answer 1

I don't see too much of an issue. I would put the MTA inside a DMZ which is strictly firewalled. The database would be outside the DMZ on another box for example.

This use of a DMZ is good practice whether you are using a commercial mail server, or a custom built one. If custom built is the more practical choice then you're headed in the right path

Answer 2

Unless you have experience writing server software, I would simply use Postfix as the MTA, and process the messages using whatever interfaces it offers (rather than let it forward mail to your application via SMTP.

I would avoid writing a new custom MTA, that is simply another layer that you have to implement and secure.

Don't underestimate:

1- The complexity of security, especially if you are not experienced with attacks in that area.

2- The possible longevity of your system. It might not seem worth attacking now, but what if it were left on for 10 years...?

Answer 3

If I can assume the data you're collecting is not sensitive, so encryption/privacy is therefore unnecessary, I see very little risk in writing your own server, particularly if you follow PaulG's recommendation to place the server in a firewalled DMZ.

Based on your description, I'm not thinking of your server as an MTA; rather, it's a file-transfer server that happens to speak SMTP. Let's look at a hypothetical session and discuss some issues:

[Client connects to your server]
< 220 Welcome message from your.server.com
> HELO someclient.com
< 250 your.server.com
> MAIL From: [email protected]
< 250 OK
> RCPT To: another_address@also_ignored.com
< 250 OK
> DATA
< 254 End data with <CR><LF>.<CR><LF>
> client sends data here
> .
< 250 OK
> QUIT
< 221 Bye
[Close connection]

Things to think about:

• Is security an issue at all? (Do you need to guard against spam? Do you need to verify the client, sender, or recipient?) If the answer is "no," you can ignore everything that follows HELO, MAIL, and RCPT and send a 250 response unconditionally.

• You can dump everything between DATA and the . into a file for processing. You'll probably want to limit the size, and the processing will be easier if the data is in plaintext: not MIME- or Base64-encoded, with no attachments.

• Your server will need exception handling: it should respond gracefully to timeouts, protocol errors, and premature disconnection.

• If you control the message content, you can perform simple authentication and validation by placing your data between some sort of BEGIN and END lines and appending a salted hash. When you process the date, ignore everything outside the BEGIN/END lines and verify the hash.

• Finally, I'd go so far as to say that postfix may actually introduce more security issues than it solves. With all of its features and flexibility you really do need to understand how to configure it properly, and mis-configuration can turn your server into a relay for spam.

Good luck - please let us know which solution you choose!