On Tue, Mar 30, 2010 at 9:47 AM, Olav Vitters <[email protected]> wrote: > 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?
Postgrey is currently in use by the linux kernel mailing list. Chances are it will scale to gnome levels :) -- Jeff Schroeder Don't drink and derive, alcohol and analysis don't mix. http://www.digitalprognosis.com _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
