[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: Preferred/maintained greylisting options?
From:       Charles Sprickman <css () morefoo ! com>
Date:       2020-06-04 4:17:39
Message-ID: 5EE36C1B-E6E3-4587-8D4E-E903E387839D () morefoo ! com
[Download RAW message or body]


> On May 24, 2020, at 7:21 PM, Wietse Venema <wietse@porcupine.org> wrote:
> 
> Charles Sprickman:
> > Hi all,
> > 
> > I have a site with a very old domain that's at the front of the
> > alphabet. For some reason (age, alphabetical order, ???) that
> > domain gets bombarded with spam before the senders make it onto
> > any of the blacklists I use (even trialed a few for-profit
> > blacklists). Literally some of these miss getting caught by 2-3
> > minutes. Aside from the general jaw-on-floor reaction I have to
> > just how so many new 'clean' IPs are enlisted in these spamming
> > efforts on a daily basis, I was wondering if greylisting might be
> > a good option here. One of the folks that runs the Abusix service
> > suggested this since he pointed out that I'm really missing these
> > spammers by minutes 
> > 
> > What is your 'go to' greylisting solution these days? My main
> > concerns are that it's something that's well-maintained, does not
> > need babysitting, and is here for the long haul.
> > 
> > I've been sort of opposed to greylisting in the past due to a
> > userbase that's sensitive to delays, but the spam is worse.
> 
> With any form of greylisting you will need to whitelist senders
> that have a large pool of sending IP addresses. Those can take an
> excessive amount of time to whitelist, because each attempt is
> likely to come from a different IP address.
> 
> I would suggest using postscreen (supported with Postfix) with
> postwhite for whitelisting large senders.
> 
> Steve Jenkins wrote postwhite (available from github) for postscreen.
> It mines the SPF records from major email senders and creates a
> whitelist for their (outbound) IP addresses. Postwhite has been
> updated for some 6 years; and its data source, SPF records, isn't
> likely to change soon. Is that stable enough?

I have this setup now, seems fine.

> Apply the whitelist as described on postwhite documentation, and
> enable some postscreen after-220 protocol test. You don't even have
> to drop clients that fail the test.
> 
> 	postscreen_pipelining_enable=yes
> 	postscreen_pipelining_action=ignore
> 
> postscreen's after-220 protocol tests implement a weaker form of
> greylisting (based on IP address only) that should eliminate most
> clients that are ahead of DNSBL lists. The clients won't know that
> it's fake greylisting.

I've been running this for a week or so, I think I've seen a slight dip in spam, but \
still a pretty healthy daily dose of thermometer, oximeter and other covid-related \
junk.

Before I go further, I do want to make sure I'm reading the logs correctly. I just \
grabbed a random sample here from yesterday. Very similar to the other leaky spam - \
always technically correct (DKIM-signed, SPF records, protocol-correct). Here's what \
I see when these types of folks hit with my after-220 checks enabled (and a \
manually-set 11s delay). I hope this isn't too long, want to give context for the \
spam run:

These first two CONNECT lines are the client connecting and waiting for the server \
response. Both have a single DNSBL hit, but not nearly enough to reject, correct?

Jun  2 11:41:12  postfix/postscreen[46515]: CONNECT from [212.83.188.221]:29701 to \
[216.220.96.26]:25 Jun  2 11:41:13  postfix/dnsblog[46555]: addr 212.83.188.221 \
listed by domain dnsbl.spfbl.net as 127.0.0.4 Jun  2 11:41:13  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:50205 to [216.220.96.26]:25 \
Jun  2 11:41:13  postfix/dnsblog[46529]: addr 212.83.188.221 listed by domain \
dnsbl.spfbl.net as 127.0.0.4

Is this the client coming back after giving up or just a third connection?
Jun  2 11:41:21  postfix/postscreen[46515]: CONNECT from [212.83.188.221]:37463 to \
[216.220.96.26]:25 Jun  2 11:41:21  postfix/dnsblog[50192]: addr 212.83.188.221 \
listed by domain dnsbl.spfbl.net as 127.0.0.4

This is a tempfail, so I assume that is one of the above connects getting the \
pseudo-greylisting, correct?  Jun  2 11:41:23  postfix/postscreen[46515]: NOQUEUE: \
reject: RCPT from [212.83.188.221]:29701: 450 4.3.2 Service currently unavailable; \
from=<connie@singanddiscover.com>, to=<REDACTED>, proto=ESMTP, \
helo=<big.singanddiscover.com>

What qaulifies it as a PASS here?
Jun  2 11:41:23  postfix/postscreen[46515]: PASS NEW [212.83.188.221]:29701

Is this the client disconnecting in response to the 450 message above?
Jun  2 11:41:23  postfix/postscreen[46515]: DISCONNECT [212.83.188.221]:29701

And another pseudo greylist for another connection?
Jun  2 11:41:25  postfix/postscreen[46515]: NOQUEUE: reject: RCPT from \
[212.83.188.221]:50205: 450 4.3.2 Service currently unavailable; \
from=<sofia@singanddiscover.com>, to=<REDACTED>, proto=ESMTP, \
helo=<big.singanddiscover.com>

Again, not sure what this is telling me. Especially the "NEW" portion as two seconds \
ago it gave the same IP a "NEW" designation... Jun  2 11:41:25  \
postfix/postscreen[46515]: PASS NEW [212.83.188.221]:50205

And the client disconnects:
Jun  2 11:41:25  postfix/postscreen[46515]: DISCONNECT [212.83.188.221]:50205

And another pseudo-greylist:
Jun  2 11:41:32  postfix/postscreen[46515]: NOQUEUE: reject: RCPT from \
[212.83.188.221]:37463: 450 4.3.2 Service currently unavailable; \
from=<nicole@singanddiscover.com>, to=<REDACTED>, proto=ESMTP, \
helo=<big.singanddiscover.com>

Same WRT "PASS" and "NEW" and the disconnect:
Jun  2 11:41:32  postfix/postscreen[46515]: PASS NEW [212.83.188.221]:37463
Jun  2 11:41:32  postfix/postscreen[46515]: DISCONNECT [212.83.188.221]:37463

Now a few seconds later, we have the client connecting again, they have seen the 450 \
error yet they are going to check again, correct? Jun  2 11:41:47  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:55541 to [216.220.96.26]:25

Now since there were no DNSBL hits before (does postscreen not re-check the DNSBLs \
here?), and all the protocol tests were OK, we're giving the spammer the green light: \
Jun  2 11:41:47  postfix/postscreen[46515]: PASS OLD [212.83.188.221]:55541

And now they are in and going full bore:
Jun  2 11:41:47  postfix/smtpd[31873]: connect from \
big.singanddiscover.com[212.83.188.221] Jun  2 11:41:47  postfix/smtpd[31873]: \
C1518109B3F4: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:48  \
postfix/smtpd[31873]: 39DE1109B40D: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:48  postfix/smtpd[31873]: 6E6E5109B41A: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:50  postfix/smtpd[31873]: \
DA0AB109B446: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:51  \
postfix/smtpd[31873]: 6438D109B452: client=big.singanddiscover.com[212.83.188.221]

Including some more, just for more context/scale below.

I feel like these sort of spammers are a bit too clean to trip up, and an 11 second \
delay is just not enough to stop them. I'm still tempted to add real greylisting to \
the mix here unless I'm totally misreading this set of logs. I feel like I need to a) \
assume these senders are always going to be protocol-correct, so I'm not going to \
fool them with some of the more clever checks b) I need to keep them away for at \
least a few minutes for them to show up on the DNSBLs.

Additionally, it doesn't look like the client gets checked against the DNSBLs again, \
so even if by some chance they landed on a list in the 11 seconds I delay them, I'd \
not catch it.

If I have to greylist, I can't really use the tricks others mentioned in this thread, \
such as giving the sender a pass if they have a correct SPF record - these guys \
always DKIM sign and may do SPF as well. But I suspect I can rely on some sort of \
whitelists - both as you specified above and probably something else for more minor, \
but troublesome senders.

Any further thoughts?

Thanks,

Charles



(Additional log lines from above run)

Jun  2 11:41:52  postfix/smtpd[31873]: D4853109B472: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:53  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:39015 to [216.220.96.26]:25 \
Jun  2 11:41:53  postfix/postscreen[46515]: PASS OLD [212.83.188.221]:39015 Jun  2 \
11:41:53  postfix/smtpd[31853]: connect from big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:53  postfix/smtpd[31853]: 56023109B479: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:54  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:64731 to [216.220.96.26]:25 \
Jun  2 11:41:54  postfix/postscreen[46515]: PASS OLD [212.83.188.221]:64731 Jun  2 \
11:41:54  postfix/smtpd[42215]: connect from big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:54  postfix/smtpd[42215]: 426BC109B488: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:54  postfix/smtpd[31873]: \
56202109B48E: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:54  \
postfix/smtpd[42215]: disconnect from big.singanddiscover.com[212.83.188.221] Jun  2 \
11:41:55  postfix/smtpd[31853]: 5C0DB109B4C3: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:56  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:61135 to [216.220.96.26]:25 \
Jun  2 11:41:56  postfix/postscreen[46515]: PASS OLD [212.83.188.221]:61135 Jun  2 \
11:41:56  postfix/smtpd[41652]: connect from big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:56  postfix/smtpd[31873]: 1DE18109B4D5: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:56  postfix/smtpd[41652]: \
49061109B4D9: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:56  \
postfix/smtpd[31873]: 6E573109B4DF: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:57  postfix/smtpd[31873]: 1C999109B4FA: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:58  postfix/smtpd[41652]: \
9F603109B51B: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:58  \
postfix/smtpd[31853]: 9FEE4109B51C: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:41:58  postfix/smtpd[31873]: CB6E7109B51D: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:41:59  postfix/smtpd[41652]: \
disconnect from big.singanddiscover.com[212.83.188.221] Jun  2 11:41:59  \
postfix/smtpd[31873]: DA614109B54E: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:00  postfix/smtpd[31873]: disconnect from \
big.singanddiscover.com[212.83.188.221] Jun  2 11:42:00  postfix/smtpd[31853]: \
DA304109B55C: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:03  \
postfix/smtpd[31853]: 0D6CB109B59E: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:05  postfix/postscreen[46515]: CONNECT from [212.83.188.221]:9969 to \
[216.220.96.26]:25 Jun  2 11:42:05  postfix/postscreen[46515]: PASS OLD \
[212.83.188.221]:9969 Jun  2 11:42:05  postfix/smtpd[31915]: connect from \
big.singanddiscover.com[212.83.188.221] Jun  2 11:42:05  postfix/smtpd[31915]: \
38C0C109B623: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:05  \
postfix/smtpd[31853]: 70311109B637: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:05  postfix/smtpd[31915]: disconnect from \
big.singanddiscover.com[212.83.188.221] Jun  2 11:42:07  postfix/smtpd[31853]: \
9FB66109B6D6: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:07  \
postfix/postscreen[46515]: CONNECT from [212.83.188.221]:2273 to [216.220.96.26]:25 \
Jun  2 11:42:07  postfix/postscreen[46515]: PASS OLD [212.83.188.221]:2273 Jun  2 \
11:42:07  postfix/smtpd[41652]: connect from big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:08  postfix/smtpd[41652]: 35108109B6E1: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:08  postfix/smtpd[41652]: \
disconnect from big.singanddiscover.com[212.83.188.221] Jun  2 11:42:09  \
postfix/smtpd[31853]: B6E64109B713: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:11  postfix/smtpd[31853]: 9C083109B766: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:13  postfix/smtpd[31853]: \
5FCB2109B7B2: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:14  \
postfix/smtpd[31853]: A8B21109B7C6: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:16  postfix/smtpd[31853]: 32CAC109B7D7: \
client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:16  postfix/smtpd[31853]: \
90F33109B7E8: client=big.singanddiscover.com[212.83.188.221] Jun  2 11:42:18  \
postfix/smtpd[31853]: 97CDF109B807: client=big.singanddiscover.com[212.83.188.221] \
Jun  2 11:42:19  postfix/postscreen[46515]: CONNECT from [212.83.188.221]:39653 to \
[216.220.96.26]:25 Jun  2 11:42:19  postfix/postscreen[46515]: PASS OLD \
[212.83.188.221]:39653


> 
> 	Wietse


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic