"Stan Hoeppner" Monday, April 11, 2011 4:43 PM
pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:
My thought on auto combating this is to use a CIDR list to kick these
networks (and only these networks) over to a greylist policy that delays
these emails for 4+ hours. By then, most of the bad IPs would be listed
in one or more RBL and be blocked.
So, has anyone else already done something like this?
Why bother with this complex greylisting setup? Simply hammer the big
blocks with a CIDR entry and whitelist individual IPs in the range from
which you need legit mail. If such IPs are used to send both snowshoe
spam and ham, that's a human shield tactic, and deserves permanent
blocking, FOREVER. If anyone complains, lay the full skinny on them as
to why. I.e. lay the blame at the proper feet, and direct complaints at
the guilty.
Life is too short to waste _your_ valuable time playing whack-a-mole
with spammers, isn't it? We don't live in a totally "collateral damage
free" world. People must get used to this.
Just because most of the emails are spam, doesn't mean that most of their customers are spammers. After all, the
spammers are sending a lot more mail than legit sites do.
If the ISP has multiple /15's and /16's, I think that blocking all of their IPs then exempting specific IPs would take
too much time and effort. I would just be playing a different version of whack-a-mole and constantly be adding new
exempted IPs. My goal is to automate anything I can, and not replace one problem with another.
I don't think it would be particularly complex...
smtpd_restriction_classes = long_grey
long_grey = check_policy_service unix:private/greylist
smtpd_client_restrictions = ...,check_client_access
cidr:/etc/postfix/grey.cidr,...
xx.xx.0.0/15 long_grey
xx.xx.0.0/16 long_grey
0.0.0.0/0 DUNNO
But another user on the list has already said that greylist wait times of a couple hours caused more problems than they
solved in his experience.
