1

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 [email protected] to [email protected] 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?

5
  • What is you question, exactly ?
    – Stephane
    Jan 19, 2016 at 10:11
  • Is this a security issue or not? Is this really still standard behaviour in 2016? I'm not sure If I should try to talk with other people to report that "issue" or if I should just accept it as it is and do not care about it further. Jan 19, 2016 at 10:17
  • Are you sitting "inside" the company? If so, it is quite common that the mailserver will trust all insiders to send mail without verification. And why it should be different? Even from outside, sender verification is hard to establish. You could be roaming with a laptop. You cannot easily determine if the sender is a "valid" client, except you completly forbid users to send their company mails from outside.
    – flohack
    Jan 19, 2016 at 10:31
  • No, I'm connecting from the internet. What I'm wondering about is why there is no kind of reverse dns resolution to check if the client connecting to the mail server is allowed to send mails from the domain it claims to belong to. Jan 19, 2016 at 10:35
  • 1
    The proper solution for that kind of issue is setting a correct SPF and having the mail gateway enforce it
    – Stephane
    Jan 19, 2016 at 11:12

1 Answer 1

1

The problem that you are describing is known as spoofing, where you are able to send a message from p[email protected], even though you are not [email protected].

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.

2
  • There is a spf record in their dns entry. They just do not seem to check it on their incoming mail, which then could be considered a security flaw. Jan 19, 2016 at 12:04
  • 1
    I agree with you that this should be considered a security concern. Spoofing can lead to more insidious things, like phishing attacks (en.wikipedia.org/wiki/Phishing). So, SPF verification and/or DKIM verification should be employed by the receiving MX to minimize the risk of these types of attacks.
    – mti2935
    Jan 19, 2016 at 12:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .