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

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

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 "" 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   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,
                   check_sender_mx_access hash:/etc/postfix/mxaccess,
                   check_sender_mx_access cidr:/etc/postfix/mxaccess.cidr,
                   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,
                   check_policy_service inet:,
                   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,

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

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:               REJECT Domain MX in broadcast network              REJECT Domain MX in RFC 1918 private network             REJECT Domain MX in loopback network  REJECT Domain MX in link local network   REJECT Domain MX in RFC 1918 private network    REJECT Domain MX in TEST-NET network  REJECT Domain MX in RFC 1918 private network             REJECT Domain MX in class D multicast network             REJECT Domain MX in class E reserved network             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 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 sanders <cas@taz.net.au>

<chesty> xemacs fixed my flatulence
		-- From the "XEmacs: Not just an editor" department

Reply to: