Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm testing a postfix installation. I noticed that if I try to send mail from a fictitious account on another domain that isn't mine (, to one of my local users (, the email still gets delivered to my user.



I'm not sure if this is normal behaviour or if it can cause problems. For example, I'm worried that users could use the server to send spoofed emails that aren't really originating from the email accounts they claim to be originating from.

P.S. I'm still in the early stages of learning postfix, so not sure if my question makes sense.

As per @DerfK's comment, I tested for an open relay (where both MAIL FROM and RCPT TO aren't hosted on this server), and this is what I get. For some reason it accepts the RCPT TO, then says goodbye AFTER I type the subject. So is this good or bad?

250 mail
250 2.1.0 Ok
250 2.1.5 Ok
Subject: testing for open relay
221 2.7.0 Error: I can break rules, too. Goodbye.
Connection closed by foreign host.
share|improve this question
I'm worried that users could use the server to send spoofed emails that aren't really originating from the email accounts they claim to be originating from. If you want to run a mail server, you have to be prepared to police its use. If you aren't willing to do that, then you shouldn't be running a mail server and should instead let your ISP do it. – David Schwartz Aug 14 '12 at 23:26
@David Schwartz, But isn't this why I'm asking questions? – sameold Aug 14 '12 at 23:55
Yes, it is. I'm just saying you may wish to reconsider your decision to run your own mail server. It's not "set and forget". It has to be policed. – David Schwartz Aug 15 '12 at 0:40
@David Schwartz, Actually, I'm not planning to run my own mail server, but I have to learn it. – sameold Aug 15 '12 at 1:15
You're not sending the message from a machine on the same subnet are you? Usually by default postfix will accept and attempt to deliver those. – 84104 Aug 15 '12 at 5:21

That is normal behaviour. Other SMTP servers connect to yours as SMTP clients to deliver mail to your domain.

To work around this spoofing problem, there are SPF and DKIM. You should check them out.

share|improve this answer
Definitely normal. Now, you should worry when you can send mail from not-your-domain, to not-your-domain. In that case you have an open relay. – DerfK Aug 14 '12 at 22:51
@DerfK, I tested this. See my update for what I got. Is this output good or bad? – sameold Aug 14 '12 at 23:06
@sameold you're getting kicked off because you're speaking SMTP wrong. Try DATA after RCPT TO: then if it's going to accept the email, it will tell you to write it one line at a time, then finish with a line starting with .. This is where you'd put Subject: and other header/body content. Once you get to the . if it says OK, then you have a real problem. See the example on wikipedia – DerfK Aug 14 '12 at 23:21

Concerning your first situation: it's normal for SMTP server to accept mail for accounts it is responsible for and basically that is how it's going to work, just setup spam checking software like SpamAssassin (most widely used free solution, supports SPF/DKIM check).

As far as your question likely appeared on early stage of mail server setup, here are some tips related to dealing with fictitious mail.

Normal users won't try to spoof their emails in most cases. More often this is behavior of spammer that is why you can filter such mail based on its content. More complex setup can include:

  1. RBL/DNSBL/RHSBL checking (may give many false rejects because many of even valid mail senders break some of RFCs).
  2. Sender address verification (see Address verification readme for Postfix). This also might reject some of valid mail (basically again because of misconfiguration, e.g. disallowing mail with empty MAIL FROM: <>).
  3. Greylisting. As for my personal experience this fights up to 90% of spam mails because of spammers impatience. But this slows delivery of valid mail a bit however this is not a problem in most cases.
  4. SPF/DKIM verification (although not mandatory to support it).
  5. Various custom content checking (including already mentioned spamcheckers).

If we talk about postfix it gives rather flexible abilities to restrict which mail is acceptable.

Concerning your update: the error message postfix gives you just states that you break SMTP specs (there is no Subject: SMTP command, see SMTP RFC but Subject header you've likely meant is part of message body which must be supplied after DATA SMTP command). From the transcript you've provided I can't reliably tell whether your postfix functions as open relay because there is no information about client who had that SMTP session.

With basic setup postfix, as far as I recall, allows relay of mail (meaning you can specify any email address, not only in domain which postfix is responsible for) from:

  • localhost
  • trusted networks (set via mynetworks)

So if you've telneted postfix from the server it runs on that might be ok. If from anywhere in Internet then things are bad.

Also you might want to read carefully SMTPD Relay and access control to deepen the knowledge exactly on topic of postfix relay access.

Hope this helps.

share|improve this answer

You forgot Data! I had exactly this problem. You have to have command data, then subject. So it resolves your problems. Look like this:


250 mail


250 2.1.0 Ok


250 2.1.5 Ok


354 End data with <CR><LF>.<CR><LF>

subject: hello

i love you, oh my god! Why do i forget data


250 2.0.0 Ok: queued as E10601E09B1

share|improve this answer
Thanks! You just saved me from a major headache. Was already prepared to bang my head against the wall. ;-) – afrischke Apr 27 '14 at 22:48

Postfix must accept mail from domains it is not responsible for. Otherwise you would have only local email.

An open relay accepts mail from domains it is not responsible for to addresses it is not responsible for. In the following table: Local represents domains the sever is responsible for; Remote represents domains the server is not responsible for; and None represents an empty sender:

Source   Destination   Accepted
======   ===========   ========
Local    Local         Yes
Local    Remote        Yes
Remote   Local         Yes
Remote   Remote        NO
None     Local         Yes
None     Remote        NO

There are many ways to verify the Remote domain including: Callouts, SPF, DMARC, Whitelists and Blacklists. These all depend on DNS. Greylisting is a technique to ensure a real mail server is sending the mail rather than a spambot. Spamfilters such a Spamassassin use a combination of techniques to validate the mail which usually includes scoring the above tests as well as content and headers.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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