|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Jorey Bump (list
joreybump.com)
Date: Tue Apr 01 2008 - 20:11:05 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Williams wrote, at 04/01/2008 02:16 PM:
> Here is my postconf -n out put and I do want to say I started to read
> the Spamassassin how-to located at
> http://wiki.apache.org/spamassassin/UsedViaProcmail
>
> Now the 3rd command tells me to add "mailbox_command = /usr/bin/procmail
> -a "$EXTENSION"
>
> When I add this and restart Postfix, all emails send to my email account
> bounce because now it attempts to deliver email to /var/mail/user rather
> than /home/user/Maildir. So this essentially breaks mail delivery for
> some reason. I remove that line from main.cf <http://main.cf> and mail
> flows normal again.
Don't blindly follow howtos without understanding how the settings will
affect your environment. SpamAssassin is great, but it's very complex,
and you can afford to wait until you have your house in order before
tackling it. In fact, you'll be better off if you first reduce the
amount of mail it will process.
> [root
email postfix]# postconf -n
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> home_mailbox = Maildir/
> html_directory = no
> inet_interfaces = all
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
> mydomain = ideorlando.net <http://ideorlando.net>
> myhostname = email.ideorlando.net <http://email.ideorlando.net>
> mynetworks = $config_directory/mynetworks
> mynetworks_style = host
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
> sample_directory = /usr/share/doc/postfix-2.3.3/samples
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtpd_banner = $myhostname ESMTP $mail_name
> unknown_local_recipient_reject_code = 550
Well, that's fresh out of the box. Many of these appear to be defaults.
This means that it isn't necessary to include them in main.cf. You can
view the defaults by running:
postconf -d
At some point you should consider removing settings from main.cf if they
match the defaults, but it isn't that important now.
You may notice this default in the output of postconf -d:
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination
An SMTP session is made up of a series of commands. A convenient place
to apply restrictions is when the client issues the RCPT TO: command. At
this point, you have enough information to expose and block a lot of
obvious spam. The Postfix setting smtpd_recipient_restrictions is used
to apply restrictions at this time. The default allows any IP addresses
in $mynetworks to send mail to any destination without restriction.
Ideally, you should severely limit this list, and force your users to
authenticate in order to send mail. The default also restricts delivery
to $mydestination, to prevent your machine from being an open relay.
You can take a big bite out of spam instantly by adding an RBL. Add the
following to your main.cf (you can separate restrictions with either
commas or whitespace):
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_rbl_client zen.spamhaus.org
After saving main.cf, reload it:
postfix reload
You can periodically check the effectiveness of the RBL by searching
your maillog for related rejections (point it to the location of your
actual maillog, which can differ among platforms):
grep blocked /var/log/maillog
It's (currently) safe to recommend zen.spamhaus.org, but I'll stop
there. Don't go overboard adding RBLs. Choosing them appropriately is a
matter of taste and highly dependent on your needs. I only use a few for
outright rejection with reject_rbl_client, and use others for weighted
scoring in SpamAssassin (a more advanced topic that can wait).
There are a few other restrictions you can add that are very safe, yet
somewhat effective. Although opinions may differ on the best order, I
would recommend that you start with this:
smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_unlisted_sender
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_unlisted_recipient
permit_mynetworks
reject_unauth_destination
reject_rbl_client zen.spamhaus.org
You'll still get spam, but this might reduce the flood to a steady
stream. Then you can concentrate on increasingly advanced techniques to
reduce the remaining spam to a trickle.
You don't mention if this is an MX-only server, or if it is also a relay
for your users to send mail to other destinations. If you are simply
providing an open relay for user workstations via $mynetworks, don't be
surprised if they are a major source of spam. You should require users
to authenticate in order to relay (another slightly advanced topic).
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]