On Tue, Mar 30, 2010 at 06:52:49AM -0600, Christer Edwards wrote: > I had a look this morning at the postfix/main.cf in regards to > filtering. It was mentioned that spam runs rampant through that > server, and I _hate_ spam. Below is an example of the postfix > restrictions that I run on my personal mail server. I also implemented > these restrictions on our corporate mail server with great results. > > I like this type of implementation because it filters mail in multiple > steps. For those familiar with a basic SMTP handshake, it requires a > HELO/EHLO identification, sender, recipient and then data. The > configuration below filters at each step, and I've found that I block > a huge amount of spam simply at the HELO/EHLO due to misconfigured and > zombie spam bots. I prefer to dump them at this point rather than > waste any additional cpu trying to decide if they are spam. As you can > see below, postgrey, spamhaus.org RBL, spf-policy and spamassassin are > the final lines of defense, after the obvious stuff is filtered out. > > An example of the below filter might be one of the following: > > 1) zombie spammer connects. HELO/EHLO is invalid. connection dropped. > 2) HELO/EHLO is valid. recipient invalid. connection dropped. > 3) HELO/EHLO is valid. sender is invalid. connection dropped. > ... you get the idea. > > Not all of the below settings may apply to the gnome.org mail setup, > but I'm sure many of them will. I'll leave it open for some discussion > before we add anything.
AFAIK we already check for all of them. > ---- > > ...[snip]... > smtpd_delay_reject = no I do not like that. In case of broken clients you will get problems if you reject too early. Same setting is on mail.gnome.org, but restrictions are only applied at the smtpd_recipient_restrictions stage. > disable_vrfy_command = yes > smtpd_helo_required = yes > > # helo restrictions > smtpd_helo_restrictions = > permit_mynetworks, > check_helo_access hash:/etc/postfix/access, > reject_invalid_hostname, > reject_non_fqdn_hostname, > reject_unknown_hostname, AFAIK we all have those. > permit > > smtpd_client_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_client_access hash:/etc/postfix/access, > reject_unauth_pipelining, > permit > > # sender restrictions > smtpd_sender_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_sender_access hash:/etc/postfix/access, Should be split out (access-sender). > reject_non_fqdn_sender, > reject_unknown_address, > reject_unknown_sender_domain, AFAIK we all have these. > permit > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > check_sender_access hash:/etc/postfix/access, Should be split out (access-sender). We have a access-recipient. > reject_non_fqdn_hostname, > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > reject_invalid_hostname, > reject_unauth_destination, > reject_unauth_pipelining, > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > reject_rhsbl_sender dsn.rfc-ignorant.org Not sure if using rfc-ignorant.org is a good idea.. > reject_rbl_client zen.spamhaus.org We already use that one and a few others. Note that spamhaus.org blocked gnome.org DNS requests for 1 or 2 years delaying every mail for 30sec+. > check_policy_service unix:private/policyd-spf Perhaps, though Spamassassin can do that as well. > check_policy_service inet:127.0.0.1:60000 postgrey? Does that scale to gnome.org levels? > permit > > smtpd_data_restrictions = > reject_unauth_pipelining, Already have that. > permit > > content_filter = smtp-amavis:[127.0.0.1]:10024 > ...[snip]... > > -- > Christer Edwards > _______________________________________________ > gnome-infrastructure mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-infrastructure -- Regards, Olav _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
