Hello Clint,
On Fri, 16 Dec 2016 07:21:47 -0700 Clint Pachl wrote:
> I would like to share my 45-day experience with running spamd and my
> observations and how I'm allowing mail from SMTP clusters to bypass
> spamd. Feedback and discussion would be greatly appreciated.
>
spamd in greylisting mode is indeed truly awesome!
With over 10 years real world experience running this way,
with several domains, I've tried a lot of ideas & scripts too...
The original design is very good and doesn't need much assistance.
To solve the clustered round robin senders (Gmail, etc.) simply bump
the -G:greyexp: time from 4 hours to 4+ days - 100 hours is good.
Job done! No scripts needed.
When configured like this, most gmails come through in around 6 hours
to 1.5 days, with some a bit longer. The more inbound gmails, the
shorter the delay, down to a few minutes as volume increases.
Same for Outlook, Amazon, (which are both worse than Gmail) etc,....
Bumping the -G :whiteexp time to 40 days helps a bit too.
Aggressive stuttering and a shrunk window foils almost all zombies.
Add in a fake highlisting -M to the mix, and it is game over for the
zombies, which love to target a backup MX box, so give them a trap.
(This needs a constantly deferring MTA on that IP address too.)
spamd_flags='-G 25:100:960 -S 90 -s 5 -w 1 -M .... -y .... -Y ... -Y ... -Y ...'
spamlogd_flags='-I -W 960 -Y ... -Y ... -Y ...'
(AOL only retries for 25 minutes (not the RFC 4 days....), so if you
want to receive from AOL, the -G passtime: needs to be ~10 minutes.)
Some pf rate limiting kills off those zombies that understand the 'try
again later' SMTP code, then start hammering the server all at once:
The 2nd rule blocks (after almost 2 days) badly setup M$ Extrange
servers, which retry every minute....
set block-policy drop
# Normal & highlisting Internet inbound operation via spamd:
pass in on $ext_if inet proto tcp \
from any port > 1023 \
to {$ext_if:0, $ext_if:2} port smtp \
divert-to localhost port spamd \
keep state \
(max-src-conn 30, max-src-conn-rate 50/90000, \
overload <scanners> flush global)
pass in log on $ext_if inet proto tcp \
from <spamd-white> port > 1023 \
to {$ext_if:0, $ext_if:2} port smtp \
user root \
modulate state \
(max-src-conn 80, max-src-conn-rate 150/15000, \
overload <scanners> flush global)
block in log from <scanners>
EASY! SIMPLE! Nothing to break.
No special domain lookups or exception lists. No maintenance labour.
Bob's other tool I deployed for many years was his greyscanner (in
ports). Over the years, I modified this to do aggregate DNS black &
white listing too. When I realised that it was very rare for spam to
pass the extended stuttering, I stopped running greyscanner.
Reverting to the default -G flags (4 hours grey expire), and help
promote round robin senders faster from grey to white, I wrote this
simple script. It runs unprivileged once every 4 hours from cron.
No pf tables/lists, no doas/sudo rules. No SPF checks.
It operates on an fgrep pattern of spamd HELO hostnames, as Gmail,
Outlook, etc. relay for many domains, but HELO from Google/Outlook.
The decision to upgrade from grey to whitelisted status is based on
an accumulated sliding score of multiple DNS list lookups.
See http://web.Britvault.Co.UK/products/ungrey-robins/ & logs there.
Also try Boudewijn's patch (see his continued blocking graph):
https://github.com/bdijkstra82/OpenBSD-spamlogd
>
> Thanks to all the developers who made spamd; an amazing, simple,
> clever tool.
>
Aye!
--
Craig Skinner | http://linkd.in/yGqkv7
