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
  • 79,345
  • 17
  • 128
  • 213
  • What kind of SMTP server are you running? Is there a firewall in front of the server? Do you have control over the SMTP server? – Winter Faulk Nov 08 '12 at 02:59
  • Can you limit what IP address are allowed to have access to SMTP on the server? – Winter Faulk Nov 08 '12 at 03:01
  • 1
    You limit who may send email through the SMTP server, and for whom the server will accept mail. Google "open relay." – Bart Silverstrim Nov 08 '12 at 03:10
  • @Sane - That's not correct. Email servers send and receive email via SMTP. Email clients on the other hand, send via SMTP and receive via POP. – joeqwerty Nov 08 '12 at 03:10
  • @BartSilverstrim - The OP isn't describing an open relay, he's describing sending a message via telnet to a user whose email domain the server is authoritative for, which is exactly how SMTP works. – joeqwerty Nov 08 '12 at 03:12
  • Yes, you're right, but if he's wondering how to secure from spoofed messages, that's what you'd harden against. Usually the people that panic over this think it's how spammers are sending mails, but only if your server were an open relay accepting mail from anyone for anyone. Or some combination thereof... – Bart Silverstrim Nov 08 '12 at 03:13
  • 1
    Oh, and you can also configure your mail server to require authentication to send mail out. There are other layers you can add (SPF records, reverse lookups, etc.) to make it harder to send spoofed mail. All of which are server specific. – Bart Silverstrim Nov 08 '12 at 03:15
  • But @joeqwerty is right in that what you're doing with telnet is how any SMTP transfer works. You're using telnet as if it were a slow mail client or other SMTP server relaying email, and if you're connected as an authorized user from an authorized IP/domain to someone in that domain that the server accepts mail for or sending to a server that is authorized to take the message, it'll work just fine. – Bart Silverstrim Nov 08 '12 at 03:17
  • @sane no, SMTP servers accept mail from other SMTP servers. It's transferring messages as the protocol name says. – Bart Silverstrim Nov 08 '12 at 03:18
  • 1
    Mail server A talks to mail server B using SMTP. You *retrieve mail from your end-point mailbox* with POP/IMAP/Exchange. Mail servers talk to each other in SMTP or a variant of it. – Bart Silverstrim Nov 08 '12 at 03:18
  • @Sane ...um...how do you think two mail servers talk to each other? They don't use POP to retrieve mail between sites. – Bart Silverstrim Nov 08 '12 at 03:23
  • @Sane if I send mail to my SMTP server on mydomain.com, how do you think it *gets* to your server at yourdomain.com where you retrieve it? – Bart Silverstrim Nov 08 '12 at 03:24
  • Although if the OP wants he can also connect to the POP port and try retrieving mail from his mailbox using RFC commands for POP, if the server isn't using security to prevent it. – Bart Silverstrim Nov 08 '12 at 03:26
  • @BartSilverstrim and others, I thought I new SMTP inside and out but I was wrong and you are right, sorry. – Winter Faulk Nov 08 '12 at 03:29
  • 1
    See Also: http://serverfault.com/questions/419407/fighting-spam-what-can-i-do-as-an-email-administrator-domain-owner-or-user – voretaq7 Nov 08 '12 at 04:16

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
  • 1
  • 3
  • Good answer. I didn't want to go too far in my answer regarding relaying because I thought it might confuse the issue for the OP and relaying wasn't the underlying issue/question, but I'm glad you addressed it in your answer. – joeqwerty Nov 08 '12 at 03:58
  • Thanks @joeqwerty. I appreciate the vote of confidence. I think your answer is definitely more concise, but thought that some people might want more background information at the risk of being verbose. Hard to tell who the audience is. – jpgeek Nov 08 '12 at 05:15
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
  • 108,377
  • 6
  • 80
  • 171