More Postfix setup notes

| No TrackBacks

Well, I learn a little more about Postfix every day, and most recently it was to pay attention to the order you run your restrictions in... I had an odd problem that wasn't getting fixed like I intended, and had to run to the experts on the Postfix mailing list for help, and was set straight in short order. Read along for notes and my latest config...

One of these days, I need to put together a full tutorial on setting up Postfix and then just keep that updated, but for now, here's where I'm at.

First, the proper order of restrictions. If you get this wrong, you'll make mistakes and never know why things aren't working right. I was under the impression that the HELO restrictions happened first (since HELO happens first in SMTP), but that isn't how Postfix handles things. So, here's the actual order for restrictions:

smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions


Did you score 100%? Good for you if you did. ;) My problem was that I was trying to filter a spammer that was proclaiming himself to be sending mail from a mail server with my own DNS name. As if! The blocks I put in place weren't working (it was hitting my other spam filters first and getting bounced), so that's where I started digging.

It turns out that Postfix Enabler, which I run to help manage Postfix on my Mac, set up its own smtpd_client_restrictions with the rbl filters and some other things, and in my other settings I didn't set up my own list of restrictions for that block figuring that PE had it under control, and thinking my HELO restrictions would happen first. So, once I was straightened out on that, I decided to rework my set of restrictions to make things flow a bit better.

One thing that I will eventually go in and change is the access restrictions, and create separate lists for recipient, client, and sender restrictions. Postfix Enabler manages the one list called 'access' and rebuilds it every time I update (using the postmap command in the background, I'm assuming), and for now I'd rather not have to do that manually, but if my lists grow much more I may need to separate them to avoid filter errors.

So, here's my current config, with a few notes:


###Start PostfixEnabler###
alias_maps=hash:/etc/postfix/aliases
alias_database=hash:/etc/postfix/aliases
smtpd_sender_restrictions=hash:/etc/postfix/access
inet_interfaces=all
mynetworks_style=subnet
message_size_limit=10240000
mydomain=wrightthisway.com
myhostname=wrightthisway.com
smtpd_recipient_restrictions=permit_mynetworks,check_recipient_access hash:/etc/postfix/filtered_domains
unknown_local_recipient_reject_code=550
###End PostfixEnabler###

As indicated, this is what Postfix Enabler puts in on its own, most of those settings I'm not overwriting, but the restrictions definitely get changed. Also, I removed all the rbl listings from Postfix Enabler, so it now no longer creates its own client restrictions setting.


###Start Custom Config###
disable_vrfy_command = yes
default_process_limit = 10
smtpd_error_sleep_time = 30

strict_rfc821_envelopes = yes
smtpd_helo_required = yes

Same as what I've had before here, being strict with the protocols, setting some values to better manage bad servers, etc.


smtpd_helo_restrictions=
check_recipient_maps,
check_helo_access hash:/etc/postfix/helo_access,
check_client_access hash:/etc/postfix/access,
check_sender_access hash:/etc/postfix/access,
reject_unknown_hostname,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_client,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,

Now, here we have some real changes. I had copied my previous settings for client restrictions (that Postfix Enabler created for me) and brought those into the helo restriction block, and placed these after the checks I wanted in there first.

Specifically, the check_recipient_maps will make sure that the recipient actually has an account on my server, the check_helo_access is what I wrote about here, then the client and sender access filters kick in so that I can specifically allow certain email addresses or server names to pass through without going through further filters (for users on misbehaving servers that their admins won't fix, or some mail lists that happen to show up on a spammer listing, etc.), then my usual checking to make sure that the server I'm talking with checks out and is well configured.


smtpd_recipient_restrictions =
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/access,
check_client_access hash:/etc/postfix/access,
check_sender_access hash:/etc/postfix/access,
check_policy_service inet:127.0.0.1:2525,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client relays.ordb.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.ahbl.org,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client relays.visi.com,
reject_rhsbl_client blackhole.securitysage.com,
reject_rhsbl_sender blackhole.securitysage.com,
reject_rhsbl_client rhsbl.ahbl.org,
reject_rhsbl_sender rhsbl.ahbl.org,
reject_rhsbl_client rhsbl.sorbs.net
reject_rhsbl_sender rhsbl.sorbs.net,
reject_rhsbl_client block.rhs.mailpolice.com,
reject_rhsbl_sender block.rhs.mailpolice.com,
reject_rhsbl_client dynamic.rhs.mailpolice.com,
reject_rhsbl_sender dynamic.rhs.mailpolice.com,
reject_rhsbl_client bogusmx.rfc-ignorant.org,
reject_rhsbl_sender bogusmx.rfc-ignorant.org,
reject_rhsbl_client dsn.rfc-ignorant.org,
reject_rhsbl_sender dsn.rfc-ignorant.org

smtpd_data_restrictions =
reject_unauth_pipelining,
permit

Here we can actually check the recipient access list, and I also check client and sender again for good measure, but I think perhaps that's not needed again here. Next is a check using the Gld Greylisting software, this will force a server to try a second time to deliver the message, which most spammers won't, then once the mail comes in again, we run it through the various block lists. If it passes those, it should be pretty clean.


header_checks = regexp:/etc/postfix/maps/header_checks
mime_header_checks = regexp:/etc/postfix/maps/mime_header_checks
body_checks = regexp:/etc/postfix/maps/body_checks

unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 450

default_rbl_reply=$rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason} - see http://$rbl_domain for additional info. If this was actually a legitimate email to a real user, please forward this message to postmaster@wrightthisway.com for assistance.

###End Custom Config###

Here we stop the pipelining that some spammers use to flood a server, then do the header/body checks I've covered previously, set some reject codes (I'm now doing a 450 instead of a 550 on bad hostnames, this has helped some mails come through from larger ISPs that might have one bad server out of several, often redeliveries will come through from a different box and make it in, so the 450 gives them another chance), and lastly a custom rbl_reply, with some added text to help legitimate users reach me in the case of a problem. Spammers won't ever read these even if they do get the bounce.

And to guarantee that my postmaster account gets all mail sent to it, I've assed that account to my access list, so when the recipient checks run, this will pass those mails right on through without filtering.

So, that's this month's round of changes, we'll see how far this gets me. ;)

No TrackBacks

TrackBack URL: http://www.wrightthisway.com/cgi-bin/mt/mt-tb.cgi/108

November 2010

Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

About this Entry

This page contains a single entry by Jim published on July 15, 2004 1:40 AM.

Blocking forged HELO in Postfix was the previous entry in this blog.

Hitting the road... is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 5.031