How can I block outside mail FROM [email protected]?

Question

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 [email protected] sender?

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

Answer 1

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.

Answer 2

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}

Answer 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.

Answer 4

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