Re: spamassassin/postfix - not accepting the false "from" messages
On Fri, Oct 05, 2007 at 04:29:32PM +0200, Wojciech Ziniewicz wrote:
> I have typical spamassassin + postfix + clamav + amavis etc. etc..
> configuration . Everything works well (autolearns etc..) and my users
> nearly don't receive ANY spam except for spam that has their own
> "reply-to" header. I have automatically whitelisted my relay_domains
> in spamassassin and give them -100 points. Let's suppose that i am
> using the xxx@xxx.com domain and all spam from !xxx.com is filtered
> but spam with "reply-to" and "from" set to xxx@xxx.com is not filtered
> (spamass automatically assigns -100 hits for such a message).
this is actually a bad idea. spammers have been forging domains forever,
and they're not going to stop.
you should do thorough anti-spam and anti-virus checks on ALL mail that
is either unauthenticated or from outside your network. regardless of
who it claims to be from. spammers lie.
you should still do some checking (but not as thorough) on ALL mail that
*IS* authenticated or which originates from your network.
> My question is - how to avoid this sittuation - users obviously are
> very nervous saying "who was using my account ?" etc...
>
> a) I think that disabling my domains whitelisting will cause some
> non-delivery situations for messages from my domains to my domains
> (clients using HTML , outlook, broken headers etc.)
an obvious option here is to have postfix listen on two different IP
addresses.
one where your MX points with all filtering enabled (and no whitelisting
of local addresses).
the second, which is only accessible by your users, which whitelists
local addresses. you will need some way to prevent non-local users
accessing this - perhaps a packet filtering rule at your border router,
perhaps iptables rules on the mail server itself.
this will require two configurations of amavis/spamassassin - one with
whitelisting, one without. different smtpd definitions in master.cf can
specify different content_filters to use.
a better variant is to not use a second IP address, but to enable SMTP
Auth. clients who authenticate (i.e. login with password/challenge)
bypass some anti-spam checks. those who don't get the full treatment.
> b) Here's fragment from my postfix main.cf regarding configuration of
> rejecting mails due to dns/etc errors.
>
> reject_unauth_destination,
> reject_unknown_recipient_domain,
> reject_non_fqdn_recipient,
> reject_invalid_hostname,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain,
> reject_sender_login_mismatch
you should also enable grey-listing. and maybe use some of the better
RBLs and/or DULs. and reject mail from clients that use your mail
server's hostname in HELO/EHLO. same for "127.0.0.1" in HELO/EHLO (a
sure sign of spam).
if you do use any RBLs or DULs, make sure you have an override map
before any RBLs. that way if an IP you need to receive mail from is ever
listed, you can add it there with "permit_auth_destination" (NOTE: DO
NOT USE "OK" as that will make you an open relay for that particular
IP address. in fact that's a good general rule - never use OK in a map
where permit_auth_destination will work).
e.g. in main.cf smtpd_recipient_restrictions
check_client_access hash:/etc/postfix/rbl_override,
with rbl_override containing lines like:
# murphy.debian.org
70.103.162.31 permit_auth_destination
my postfix main.cf currently has the following smtpd_recipient_restrictions:
smtpd_recipient_restrictions = pcre:/etc/postfix/pcre.cf,
check_sender_access hash:/etc/postfix/junk,
check_client_access hash:/etc/postfix/junk,
check_helo_access hash:/etc/postfix/junk,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_unknown_sender_domain,
reject_unauth_pipelining,
permit_sasl_authenticated,
permit_mynetworks,
check_sender_mx_access hash:/etc/postfix/mxaccess,
check_sender_mx_access cidr:/etc/postfix/mxaccess.cidr,
reject_unauth_destination,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_unknown_hostname,
check_client_access pcre:/etc/postfix/pcre-client.cf,
check_sender_access pcre:/etc/postfix/pcre-sender.cf,
check_helo_access hash:/etc/postfix/nolocal,
check_helo_access pcre:/etc/postfix/pcre-helo.cf,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:60000,
check_client_access hash:/etc/postfix/rbl_override,
reject_rbl_client list.dsbl.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client combined.njabl.org,
reject_rbl_client bhnc.njabl.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rhsbl_sender rhsbl.sorbs.net,
reject_rhsbl_sender bogusmx.rfc-ignorant.org,
the order of rules is carefully chosen, e.g. with local maps used before
RBL lookups - no point in doing a RBL lookup if the local junk map will
cause a rejection anyway. i.e. do less expensive/faster checks before
more expensive/slower checks.
order is also significant in postfix restriction rules: FIRST MATCH WINS
and no further checks will be done.
e.g. the reject_non_fqdn_hostname, reject_invalid_hostname, and
reject_unknown_hostname checks come AFTER permit_mynetworks and
permit_sasl_authenticated. this is to allow local users with badly
configured outlook or whatever to send mail through the server, even
without a decent hostname in the HELO/EHLO.
the "junk" map contains domain names that i do not want to receive
mail from, whether they appear in the SMTP FROM envelope, the client's
hostname, or in the SMTP HELO/EHLO string. generally spammer owned
domains. it currently contains about 27000 lines. it has been built up
over many years - many of the domains probably no longer exist.
(the domains in this junk map are also used to generate many thousands
of local spamassassin rules for header, URIs, and rawbody checks. i also
generate more rules for SA containing phrases commonly seen in spam -
nigerian 419 scammer phrases, stock market scam phrases, porn phrases,
etc)
the "mxaccess" map is for me to list hostnames which, if the sender's
domain MX record points to them, will trigger a rejection. currently
contains:
dev.null REJECT
this.domain.is.not.used.for.email REJECT
the "mxaccess.cidr" map is similar, but lists network/netmask pairs of
various netblocks that should never appear in MX records. e.g. contains:
0.0.0.0/8 REJECT Domain MX in broadcast network
10.0.0.0/8 REJECT Domain MX in RFC 1918 private network
127.0.0.0/8 REJECT Domain MX in loopback network
169.254.0.0/16 REJECT Domain MX in link local network
172.16.0.0/12 REJECT Domain MX in RFC 1918 private network
192.0.2.0/24 REJECT Domain MX in TEST-NET network
192.168.0.0/16 REJECT Domain MX in RFC 1918 private network
224.0.0.0/4 REJECT Domain MX in class D multicast network
240.0.0.0/5 REJECT Domain MX in class E reserved network
248.0.0.0/5 REJECT Domain MX in reserved network
the "nolocal" map lists my own hostnames and domain names prevent
spammers from forging them in HELO/EHLO.
pcre-client.cf, pcre-sender, and pcre-helo.cf are PCRE maps for regexp
blocking of particular patterns in client, sender, and helo addresses.
the policy service on 127.0.0.1:60000 is postgrey, a grey-listing
daemon. there are other (perhaps better) greylisting daemons around,
some with support for SPF or other checks. i still use postgrey because
it works and i'm too lazy to bother investigating alternatives.
"rbl_override" is the RBL override map i mentioned.
craig
--
craig sanders <cas@taz.net.au>
<chesty> xemacs fixed my flatulence
-- From the "XEmacs: Not just an editor" department
Reply to: