Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 If I telnet 25 I can successfully send a message to another user without authentication:

HELO local
SUBJECT: Whatever this is spam
Spam spam spam

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

share|improve this question

closed as not a real question by Ward, growse, HopelessN00b, mdpc, Brent Pabst Nov 8 '12 at 18:18

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

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? –  Sane Nov 8 '12 at 2:59
You limit who may send email through the SMTP server, and for whom the server will accept mail. Google "open relay." –  Bart Silverstrim Nov 8 '12 at 3:10
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 8 '12 at 3:15
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 8 '12 at 3:18
See Also:… –  voretaq7 Nov 8 '12 at 4:16

2 Answers 2

up vote 7 down vote accepted

If the mail server you are telnetting into is the authoritative server for the domain you specified in the RCPT TO: address ( 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.

share|improve this answer
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 8 '12 at 3: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 8 '12 at 5:15
Please feel free to be as detailed as possible ;) –  josten Nov 8 '12 at 6:31

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.


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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.