1

I have noticed that it's possible to telnet into a mailserver that I own and send spoofed messages to other clients. This only works for the domain that the mail server is regarding; I cannot do it for other domains.

For example; lets say that I own example.com. If I telnet example.com 25 I can successfully send a message to another user without authentication:

HELO local
MAIL FROM: someuser@example.com
RCPT TO: someuser@example.com
DATA
SUBJECT: Whatever this is spam
Spam spam spam
.

I consider this a big problem; how do I secure this?

voretaq7
  • 80,749

2 Answers2

6

If the mail server you are telnetting into is the authoritative server for the domain you specified in the RCPT TO: address (example.com in the example above), it is likely nothing to be concerned about. That simply means that your mail server is accepting mail for addresses in the domain you have set it up for. As @joeqwerty points out, this is how SMTP works. Try it with an email address in a domain that is NOT being managed by this mail server.

However, if this is a different domain, it means that your server is relaying which is probably a bad thing. I say "probably" because there are a few other things to check.

SMTP servers decide whether or not to forward email in a variety of ways. Usually they will accept all mail which is destined for that server (as mentioned above). After this, they might do one of the following depending on how they are set up: 1. Relay all email from a specified IP address/ range. This is common for ISPs so that they relay email only from their own customers. They sometimes (in Japan anyway) also filter this by the from address of the customer to verify the customer is using only the address within the ISPs domain.

  1. POP before SMTP. Basically, it watches for a POP login which requires a password (unlike SMTP). If there is a successful login, it figures that the user at that IP address is probably authorized to send mail as well, and it relays all SMTP messages as well for a set period of time. POP before SMTP

  2. SMTP-AUTH mechanism of ESMTP. This is an extension which allows you to enter authorization credentials when sending mail.

There are others and also are many different anti-spam filters which can operate at different stages of the sending process (in the SMTP dialogue, before queuing, before sending, etc) which can also muddy the waters. I think that this covers the main ones though.

In your case, if

  1. Your server is not authoritative for the domain name you are sending to, AND
  2. You are not using POP before SMTP / have not authenticated from your IP address with POP (eg with your mail client by checking mail), AND
  3. You have not set your IP address as a trusted IP address to allow relaying on the server

Then you probably have a problem, and should look into how to limit relaying for your mail server. These settings are server-specific though, so you would have to check the documentation for whichever one you are using.

jpgeek
  • 271
4

Yes, because that's how SMTP works. Sending an email to a user for whose email domain the SMTP server is authoritative isn't spoofing the server. That's how SMTP servers send emails to other SMTP servers.

Functionally there's no difference between you sending an email via telnet (unauthenticated) to a user whose email domain the server is authoritative for and any other SMTP server sending a message to the same user.

I've had several people over the years "bring this issue to my attention" and it points out their lack of understanding of how SMTP actually works. What they get confused with is:

Sending a message via telnet (unauthenticated) to a user whose email domain the server IS authoritative for. This is how SMTP works.

AND

Sending a message via telnet (unauthenticated) to a user whose email domain the server IS NOT authoritative for. This is using the SMTP server as a relay and is generally not desired.

joeqwerty
  • 111,849