Re: proposed postfix changes



On Tue, Mar 30, 2010 at 9:47 AM, Olav Vitters <olav vitters nl> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]