how to prevent fake mails from being sent on my mail server? [closed]

Question

I use Zimbra as my office email server. Recently, an intern at my company showed that he could use my email id (without hacking into my account) to send emails to anyone in the company using the Zimbra mail server domain in place of localhost using this code http://www.tutorialspoint.com/jsp/jsp_sending_email.htm

I was surprised that a commercial mail server did not have a means to prevent this.

Given the easy availability of this code, I assume this problem is well known and mail servers would have rules to check for this.

Does SMTP allow this to happen and nothing can be done to stop it? Would i be able to write some code to constantly monitor the server for such packets which come from such emails? (Am assuming such mails would have a different kind of packet header) and i would be able to monitor it since it is local and probably does not go through the internet.

Anything the IT support dept would be able to do to stop such emails (technologically; not by threats)

Answer 1

Most MTA software (including Microsoft Exchange) will allow you to forge the From header in an email message. Also, SMTP itself is a protocol, like HTTP, so it would not be able to prevent it. Email spoofing is certainly nothing groundbreaking or new - I'd highly recommend the Wikipedia article on Email spoofing for more detail.

Forging the From header is how most "service" emails work - for example emails sent from [email protected] where the "system" user doesn't actually exist - the same goes for the commonly-used [email protected] address to send all "Reply" email into a black hole.

This is because, as Ericrobert alluded to, SMTP wasn't specifically designed with security in mind. If you're concerned about unauthorised access, you can turn on SMTP authentication so that each connection to your server needs to provide a username and password.

However, SMTP authentication does not prevent [email protected] authenticating and sending an email as [email protected], and would also need to be enabled carefully. Incoming email will need to be relayed unauthenticated.

A typical solution to this is to use port 25 as an unauthenticated closed relay (i.e. the server will only accept email for your domain) and port 587 for authenticated connections, however your intern would still be able to use their script on port 25.