Mail server security: Mails to internal receivers with faked sender address

Question

I noticed that I am able to send emails from my company's mail server to internal receivers from faked inhouse sender addresses without problem and I'm wondering if this should be supposed a security issue or not.

I wrote a little python script to connect to the server and send a mail from personA@company.com to personB@company.com and that mail was delivered without any problems. Sometimes it was marked as spam, sometimes not. After a few e-mails, the sending server got blocked because of poor reputation. So my question is: Is this really expected behaviour?

I would expect that such a setup is ideal for sending phishing or spamming mails to employees of that particular organization. Of course, I do understand that you should be able to connect to an smtp server from outside to send mails to local receivers, otherwise no mails could be delivered. But is it really common that there is no kind of verification of the sender address or that it is so weak?

A member of the IT-Department didn't seem suprised when I talked to him about that issue and told me that this was quite normal behaviour. This post suggests that he is right: Issues with using a mail server that doesn't support authentication to send mail?. So I checked if I could do the same with my (security-aware) mail-provider: The client got blocked before it could even send the mail, and client and receiver address, both my regular mail addresses, were rejected. That's what I would expect from a correctly configured server. Am I wrong here? Is it really negligible?

Answer 1

The problem that you are describing is known as spoofing, where you are able to send a message from personA@company.com, even though you are not personA@company.com.

Because the SMTP protocol dates back to the early 1980's, when the internet was in its early stages and used only by a relatively small number of users, the engineers of the SMTP protocol did not foresee the problem of spoofing. Because of this, users can easily send messages appearing to have been sent from any sender that they choose.

To counter the problem of spoofing, message authentication methods have emerged. These methods are used to determine whether the sender's address appearing on a message is likely to be legitimate, or whether it is likely to have been spoofed. By authenticating whether or not a message was likely to have been sent from the sender that it purports to have been sent from, spam filters can more accurately determine whether or not a message is likely to be spam. Two standards that have become widely used for message authentication are Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).

SPF is a way of publishing the IP addresses of mail servers that outbound mail for a domain is authorized to be sent from. This enables spam filters to determine if a message was likely spoofed. If the message was sent from a mail server whose IP address is not listed in the SPF record for the domain of the purported sender, then the message is likely to have been spoofed. SPF records are published as TXT records in the DNS for a domain.

DKIM is another method for authenticating messages. It's an outgrowth of an earlier standard, known as DomainKeys, and is based on public key cryptography and digital signatures. Using DKIM, the message is digitally signed by an entity - which can be either the sender themselves, or a third party. The signer's public key, which is used for verifying the signature, is published in the DNS for their domain. When a message is signed, the DKIM signature is placed in the header of the message. Upon receipt of the message, the signature is verified using the signer's public key. If the signature is valid, then this indicates that the signer has vouched for the authenticity of the message. UltraSMTP can DKIM-sign your messages on your behalf using our keys, or messages can be signed by UltraSMTP using your keys.

Your company's domain should have SPF or DKIM information published in its DNS. If you configure your incoming MX to check that incoming messages appearing to have been sent from users in your company's domain have been sent from an SMTP server included in your company's SPF record, or contain a valid DKIM signature, then it can use this to flag these spoofed messages.