6

A security firm has been testing my mail server and claims my Postfix daemon is an open relay. The evidence is as follows (valid public IP for mail.mydomain.com has been changed to 10.1.1.1 for security):

Relay User: postmaster Relay Domain: 10.1.1.1
Transaction Log: EHLO elk_scan_137 250-mail.mydomain.com 250-PIPELINING
250-SIZE 20480000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME
250 DSN
MAIL FROM: postmaster@[10.1.1.1]
250 2.1.0 Ok
RCPT TO: postmaster@[10.1.1.1]
250 2.1.5 Ok

I've already blocked mail to root, but clearly I should not block postmaster. I feel that the ability to send mail from a server to itself does not make an open relay. But how can I safely block a spoofed postmaster@mail.mydomain.com sender?

[N.B. I've scanned myself using mxtoolbox.com and they say it is secure and not an open relay]

sventechie
  • 119
  • 1
  • 9
  • I've already blocked outside mail from root@mail.mydomain.com using this trick: http://serverfault.com/questions/412638/block-outgoing-mail-to-specific-address-using-postfix – sventechie Sep 13 '13 at 14:21
  • 2
    Do an open relay test online: http://mxtoolbox.com/diagnostic.aspx - but really an "open relay" is sending email through your server to another address externally. What they've done is more likely to just send email to a junk mail folder/fllter in your postmaster mailbox. – TheCleaner Sep 13 '13 at 14:40
  • 4
    What they've done is to send an email using domain literals. I'm pretty sure the relevant RFC's require an email server to accept domain literals but I know that many email servers don't allow it, such as Exchange Server 2007 and 2010. I don't understand how that's considered being an open relay but hopefully someone else here will enlighten us. – joeqwerty Sep 13 '13 at 15:02

4 Answers4

23

The fact that someone can send you mail addressed to your own mail server's IP address has absolutely no bearing on whether the mail server is an open relay.

Open relays accept mail for any and all systems outside their administrative domain and forward them onward. This clearly is not what's demonstrated here.

Ask the security firm to share whatever it is they've been smoking, since clearly it's really good stuff.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 1
    Assuming that not accepting domain literals will flag an email test as having a misconfigured server because the acceptance of domain literals is an RFC requirement, I don't understand why accepting domain literals would be flagged as being an open relay. Do you know why this might be? I've seen this pop up before but I've never understood why. – joeqwerty Sep 13 '13 at 17:19
  • 1
    You're ahead of me, then. I've never heard of anyone competent even suggesting such a thing. – Michael Hampton Sep 13 '13 at 17:22
  • Since I should not be receiving mail from my own postmaster account, is there a way to block just mail purporting to originate from my own box? – sventechie Sep 16 '13 at 13:29
  • 2
    @sventech What you need to do is fire the fake "security" firm. – Michael Hampton Sep 16 '13 at 14:22
  • @MichaelHampton alas, they have a stranglehold on my industry and we must have their certification to thrive. – sventechie Sep 18 '13 at 20:55
  • 1
    OK, in that case, **who are they** and what is this certification? – Michael Hampton Sep 18 '13 at 21:18
  • I'm betting he's after a PCI compliance certification, and the companies that do them are frequently incompentent crooks charging outrageous amounts of money for unqualified 'techs' to run a script against the target machine and parrot back a report that they do not understand in the least. [Source: I worked at an MSP for a few years and had to deal with PCI jackholes almost daily] – Sammitch Sep 19 '13 at 22:38
  • 1
    @Sammitch I've never seen a PCI compliance audit care a bit about email, but then again I would never run an email server on an in-scope machine in the first place. – Michael Hampton Sep 19 '13 at 22:42
6

Since nobody else has mentioned it yet, this is one of the problems SPF was designed to fix. If you publish a correct SPF record in your DNS and have your server check SPF records, it would know that outside servers are not allowed to send e-mail with "From: *@yourdomain.com". As a bonus, this not only fixes your immediate problem but will also block spam, and help the rest of us block spam as well!

For more information on SPF and fixing E-Mail/SPAM issues in general please read through:

Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User?

As Michael pointed out, this is not an "open relay" problem. You should seriously consider firing your auditors if they think this is the case. This stuff ain't that hard, and they're completely wrong with regard to the terminology and severity of the problem

Chris S
  • 77,337
  • 11
  • 120
  • 212
3

I think you need to use smtpd restrictions.

Snippet of my configuration:

smtpd_helo_restrictions         =
    permit_mynetworks,
    reject_unauth_pipelining,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_hostname,
    reject_rbl_client zombie.dnsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net
smtpd_recipient_restrictions    =
    permit_mynetworks,
    reject_unauth_pipelining,
    reject_non_fqdn_recipient,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:[127.0.0.1]:2501,
    permit
smtpd_sender_restrictions       =
    permit_mynetworks,
    reject_unauth_pipelining,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit_sasl_authenticated,
    permit_tls_clientcerts,
    check_sender_access regexp:$config_directory/tag_as_foreign.re,
    permit
smtpd_data_restrictions =
    reject_unauth_pipelining,
    reject_multi_recipient_bounce,
    permit

There is a wide range of checks you can do depending on your configuration. There is a restriction set for each phase of SMTP workflow. Check more at http://www.postfix.org/postconf.5.html.

You should define restrictions for all phases, that is smtpd_helo_restrictions, smtpd_data_restrictions, smtpd_sender_restrictions, smtpd_recipient_restrictions and smtpd_client_restrictions. In Postfix 2.10+ there is a new smtpd_relay_restrictions option that may be perfectly suited for you.

Note that if you want your own mail to be relayed through your SMTP server, you need to be identifiable somehow - e.g. be in $mynetworks, you use authentication.

Mine configuration also use blackhost lists, greylisting and authentication.

Basically, your SMTP restrictions should allow:

  1. your networks (localhost, intranet etc.; see permit_mynetworks),
  2. authenticated users (users logged in using SMTP login, you can relay mail for them to outside servers; see permit_sasl_authenticated),
  3. e-mails that are delivered to you (= you are "final destination" for them; see reject_unauth_destination).
  4. optionally all other e-mail domains you are relaying e-mails for; e.g. when your server is not the final destination for some domain but is e.g. front-end proxy, you should check the recipient against a whitelist and transport it to nexthop destination.

All other e-mail, that is sent by unauthorized user from anywhere to outside servers, means open relay.

Aleš Krajník
  • 2,481
  • 1
  • 15
  • 11
1

Disable VRFY and EXPN, because this parameters can be used by spammers http://cr.yp.to/smtp/vrfy.html

c4f4t0r
  • 5,149
  • 3
  • 28
  • 41