Blocking Common Webmail Addresses (Postfix)

carlosinfl · 09-22-2008, 02:26 PM

I would like to know if its possible to have Postfix reject all in and out SMTP traffic for 'Yahoo!, Hotmail/MSN, Gmail, AOL, etc etc etc. I work for a company that would like to restrict SMTP traffic since we deal with sensitive material and DoD contractors. Anyone know if this is a simply done from Postfix config or how tricky this gets?

trickykid · 09-22-2008, 03:27 PM

You can do this with header_checks to filter the email. Try searching the postfix documentation and or this site to find some examples, a quick search found plenty to start from.

Mr. C. · 09-24-2008, 01:18 AM

You probably want to be checking against envelope sender and recipients. Create sender and recipient restriction access maps that take place before permitting your networks to access:

Code:

main.cf:
   smtpd_sender_restrictions =
       ...
       check_sender_access pcre:/etc/postfix/forbidden_domain_checks
       permit

   smtpd_recipient_restrictions =
       ...
       check_recipient_access pcre:/etc/postfix/forbidden_domain_checks

       permit_mynetworks
       reject_unauth_destination
       ...
       permit

forbidden_domain_checks:
    # never put OK here, or your server can be used as an open relay
    # see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger

   /@hotmail\.com$/   REJECT We do not accept mail from hotmail.com
   /@gmail\.com$/     REJECT We do not accept mail from gmail.com

You can create two tables if you'd like, which is necessary if you have different lists based on envelope sender or recipient.

If you have a limited list of domains you allow, it might be easier to configure an acceptable access list rather than a long denied list.

carlosinfl · 09-24-2008, 07:47 AM

I am guessing after I create the file "forbidden_domain_checks", I would then have to run a 'postmap' against it to build the db?

Code:

mail:/etc/postfix# postmap forbidden_domain_checks 
mail:/etc/postfix# ls -l
total 104
-rw-r--r-- 1 root root   377 2008-09-24 08:40 forbidden_domain_checks
-rw-r--r-- 1 root root 12288 2008-09-24 08:48 forbidden_domain_checks.db

Also in my main.cf, I only have the following entry:

Code:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unlisted_recipient,
        reject_unlisted_sender,
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client safe.dnsbl.sorbs.net,
        reject_invalid_hostname,
        reject_non_fqdn_hostname

Do I have stuff in the wrong order above? Should I move anything around and or replace anything and where would the 'check_sender_access pcre:/etc/postfix/forbidden_domain_checks' fit in?

Mr. C. · 09-24-2008, 11:56 AM

Correct, you create the file forbidden_domain_checks. However, I've used a pcre table in the example above, which is not an indexed (eg. database) table, so it is not postmap'd. Remove the .db file if you use pcre/regexp. If you want to use a database type such as hash, you will need to change the contents of forbidden_domain_checks to suit the table type, and then postmap the indexed file.

Your check_sender_access table would be in an smtpd_sender_restrictions as mentioned above.

For your smtpd_recipient_restrictions, I move cheap checks (no additional DNS lookups, no RBL queries, etc.) up front:

Code:

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,

All of my systems use FQDN recipients

Code:

        reject_non_fqdn_sender,

If I can't bounce a message, I don't want it.

Code:

        reject_unlisted_recipient,

I only accept mail for listed recipients
...

Code:

        permit_mynetworks,
        permit_sasl_authenticated,

Consider moving SASL authentication to a separate submission port (see submission, port 587, in master.cf)

Code:

        reject_unauth_destination,
        reject_unlisted_sender,

Where is this list of sender's coming from?
sender address verification (SAV) only if sender's systems allow it.

Code:

        reject_unknown_sender_domain

Rejects when there is no MX or A record, or malformed MX for sender's address.

Code:

        check_helo_access pcre:/etc/postfix/helo_checks.pcre

Create a helo_checks tables that rejects obvious forgery helos. There are lots of examples on the postfix mailing list. I've posted one or two examples in these forums.

Code:

        reject_invalid_hostname,

I don't use this because I capture these in my helo_checks table above

Code:

        reject_non_fqdn_hostname,

This is ok, but will reject mail from local clients such as Outlook that by default are not
configured to use FQDN.

Code:

        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client safe.dnsbl.sorbs.net,

Monitor for any false positives on the latter two

Code:

        reject_invalid_hostname,
        reject_non_fqdn_hostname

These are duplicated above - remove.

carlosinfl · 09-24-2008, 01:15 PM

So you recommend my section to look like this?

Code:

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unlisted_recipient,			   	   
	permit_mynetworks,
        permit_sasl_authenticated,
	reject_unauth_destination,
        reject_unlisted_sender,
	reject_unknown_sender_domain,
	check_helo_access pcre:/etc/postfix/helo_checks.pcre,
	reject_non_fqdn_hostname,
	reject_rbl_client zen.spamhaus.org

Do I need the trailing 'permit' under the final "reject_rbl..."?

Mr. C. · 09-24-2008, 06:52 PM

It's really a personal call. You have to basically build your rulesets over time, as you gain experience. You can add warn_if_reject in front of restrictions you are unsure about. This way, you get a warning message in the log "warn:" and you can see the affects.

The reject_unlisted_sender - do you have a valid sender list (in other words, not breaking recipient validation via wildcards)?

You'll find you may want to move some rules around, as you see which ones are more effective.

permit is the default action, so it's not necessary. It is a self-documenting rule that helps you remember, so you can add it or leave it out.