Re: proposed postfix changes

[Olav Vitters <olav vitters nl>]

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
> gnome-infrastructure gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-infrastructure

-- 
Regards,
Olav