> On May 24, 2020, at 7:21 PM, Wietse Venema <wie...@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=<con...@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=<so...@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=<nic...@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
