Re: Preferred/maintained greylisting options?
See POSTSCREEN_README for logging examples and explanation, also on-line at http://www.postfix.org/POSTSCREEN_README.html. That includes PASS NEW, PASS OLD, and if some example is missing. please let me know. Wietse
Re: Preferred/maintained greylisting options?
> On May 24, 2020, at 7:21 PM, Wietse Venema 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=, to=, proto=ESMTP, helo= 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=, to=, proto=ESMTP, helo= 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
Re: Preferred/maintained greylisting options?
On 26 May 2020, at 15:11, Marvin Renich wrote: > However, when I first set up greylisting on my family email server (it > was exim way back then, but has long been postfix), I set it up so that > all incoming mail was sent through spamassassin _during_ SMTP, prior to > accept or reject. Mail with a high enough spam score was rejected > outright. I then used greylisting _only_ for email whose spamassassin > score was considered spam, but not high enough to reject outright. This method can work, but for me anymore the zone between accept mail that might be spam and reject during MSTP has narrowed considerably over the years (anything over 5.0 in SA gets tagged as spam and anything over 7.0 gets rejected outright), so this is not that useful anymore. And, somehow banks seemed to frequently send messages that appeared spammy (much less of a problem now), to was not rare to see a bank mail hitting a score that was high enough to kick in the greylist and then the banks would never retry. -- Can I tell you the truth? I mean this isn't like TV news, is it?
Re: Preferred/maintained greylisting options?
> On 25 May 2020, at 12:00, Chris Wedgwood wrote: > >> Greylisting has become pretty much useless. When I disabled it a >> couple years ago, the spam levers did not increase by any measurable >> amount. We now use just 3 RBLs and that seems to be a relatively >> acceptable level of spam. > > Checking for %ge of messages that "return after defer" I see: > >WeekOf PctReturned >-- --- >2020-04-30 22.1 >2020-05-07 26.5 >2020-05-14 21.2 >2020-05-21 26.5 I would guess that our users were hit by spammers with more resources ;-) I would have kept greylisting if we had seen numbers like that. -- Doug
Re: Preferred/maintained greylisting options?
> Contrary to someone else's experience related in this thread, I > still see a significant amount of spam that greylisting blocks, and > extremely few spammers retry and get through. I concurn, as reported, I curently see greylisting reduce spam by a factor of 4. > I have only had one known case (i.e. someone said they were > expecting an email that they didn't receive) in a very long time > where a legitimate email was greylisted and the sending server did > not retry, and that was recently from an outlook365 server. Aliexpress is one perplexing offender I've had to deal with. The send badly formed messages, retry aggressively for a few seconds then never again so messages get lost. I've not been able to reach anyone there.
Re: Preferred/maintained greylisting options?
* Laura Smith [200524 16:00]: > > 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. > > IMHO Greylisting is rather pointless. Its a blunt tool, and not only > that it does that unforgivable thing of annoying genuine people. I agree that greylisting, as most documentation, blogs, etc, describe how to configure it, has always been a bad idea, primarily because it delays most or all mail that is not whitelisted. However, when I first set up greylisting on my family email server (it was exim way back then, but has long been postfix), I set it up so that all incoming mail was sent through spamassassin _during_ SMTP, prior to accept or reject. Mail with a high enough spam score was rejected outright. I then used greylisting _only_ for email whose spamassassin score was considered spam, but not high enough to reject outright. This setup virtually eliminates false positives from spamassassin, and avoids delaying legitimate email except for the few that would have been rejected falsely. Contrary to someone else's experience related in this thread, I still see a significant amount of spam that greylisting blocks, and extremely few spammers retry and get through. I have only had one known case (i.e. someone said they were expecting an email that they didn't receive) in a very long time where a legitimate email was greylisted and the sending server did not retry, and that was recently from an outlook365 server. Ironically, someone was following Microsoft's instructions to have an IP address removed from outlook365's internal RBL, and the message sent by Microsoft failed several of spamassassin's default tests (way to go, Microsoft!) and their server never retried (I watched the logs and they did not retry from a different IP address). What a well-run mail system, Microsoft. ...Marvin
Re: Preferred/maintained greylisting options?
> Greylisting has become pretty much useless. When I disabled it a > couple years ago, the spam levers did not increase by any measurable > amount. We now use just 3 RBLs and that seems to be a relatively > acceptable level of spam. Checking for %ge of messages that "return after defer" I see: WeekOf PctReturned -- --- 2020-04-30 22.1 2020-05-07 26.5 2020-05-14 21.2 2020-05-21 26.5
Re: Preferred/maintained greylisting options?
Kris Deugau writes: > micah anderson wrote: >> Allen Coates writes: >>> The web page https://www.abuseat.org/faq.html (about half-way down the >>> page) >>> has an honest - and fairly recent - appraisal of a number of DNSBLs. >> >> Its a little outdated... >> >> For example: >> >> Invaluement DNSBL >> [Note: Commercial] ivmURI and ivmSIP are good solid and >> professionally operated lists. ivmURI is a URI (domain) DNSBL like >> SURBL or URIBL or DBL, with high effectiveness (comparable with >> DBL/URIBL/SURBL), extremely low false positives, and quick to >> list. ivmSIP is a IP-based DNSBL which is particularly good at >> catching "new" emitters. Its FP rate is quite low. Neither of which >> should be considered substitutes for Spamhaus Zen/Spamcop, but do >> complement them well. >> >> They no longer exist. > > Not sure where you're looking, but we have an active subscription for > Invaluement and the datafeed files all have timestamps within the last > ~10 minutes or so. > > https://www.invaluement.com/ ah, the link on https://www.abuseat.org/faq.html goes to: https://dnsbl.invaluement.com/ which is not a valid site. -- micah
Re: Preferred/maintained greylisting options?
micah anderson wrote: Allen Coates writes: The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. Its a little outdated... For example: Invaluement DNSBL [Note: Commercial] ivmURI and ivmSIP are good solid and professionally operated lists. ivmURI is a URI (domain) DNSBL like SURBL or URIBL or DBL, with high effectiveness (comparable with DBL/URIBL/SURBL), extremely low false positives, and quick to list. ivmSIP is a IP-based DNSBL which is particularly good at catching "new" emitters. Its FP rate is quite low. Neither of which should be considered substitutes for Spamhaus Zen/Spamcop, but do complement them well. They no longer exist. Not sure where you're looking, but we have an active subscription for Invaluement and the datafeed files all have timestamps within the last ~10 minutes or so. https://www.invaluement.com/ They *are* strictly paid access; they do not have a free tier. -kgd
Re: Preferred/maintained greylisting options?
On 25 mai 2020, at 13:56, Michael wrote: > > I've found the Barracuda rbl to be very useful. > > https://www.barracudacentral.org/rbl I'm using paid spamhaus RBL (local zone file rsynched) for a very long time, at work, and we are very happy about it. I use complementary RBL also like fresh.spameatingmonkey.net for reject_rhsbl_sender, reject_rhsbl_client and reject_rhsbl_reverse_client and b.barracudacentral.org. I've had false positives with b.barracudacentral.org so I've had to add a permit clause to whitelist clients before the b.barracudacentral.org reject. For a month I've tested Abusix configured just after Spamhaus: it catched many spams that Spamhaus wouldn't block, including a cutting edge phishing campaign. It's a very effective RBL, but it's pricey too. They are open to negotiation though. I might replace Spamhaus with Abusix someday. patpro
Re: Preferred/maintained greylisting options?
Hello,
> On 25 mai 2020, at 03:59, Vincent Pelletier wrote:
>
> On Fri, May 22, 2020 at 5:43 AM Ralph Seichter wrote:
>> Yeah, delays... Used to be people understood the difference between
>> asynchronous messaging (i.e. email) and instant messaging. Nowadays it
>> seems that no day goes by without somehing along these lines:
>>
>> "Hi. We have not seen you login using this browser, this IP address or
>> during this week. Therefore we have just sent you an email containing
>> a verification code, which will remain valid for 10 minutes."
>
> Personally, I've hacked together a mixed SPF check + greylist milter.
> If SPF check passes, the greylist is skipped, and any other result
> ("do not reject any mail" approach modulo greylisting) goes to greylist.
> The companies which send such emails are likely (in my experience)
> to have a properly setup SPF, so this solved these issues for me.
>
> I'm not planning on releasing the source, it's really an ugly milter, but
> I'm putting the idea out here - and maybe I'll learn it has already been
> done and properly implemented...
I've been using milter-greylist for a very long time, and it does natively
support for years a "nospf" config flag that will allow you to skip greylist
when SPF verification if good. You don't need to hack anything ;)
patpro
Re: Preferred/maintained greylisting options?
I've found the Barracuda rbl to be very useful. https://www.barracudacentral.org/rbl On 2020-05-25 3:21 am, Allen Coates wrote: On 24/05/2020 23:22, micah anderson wrote: We paid for access to spamhaus for a while, but they jacked up the prices and now its far too expensive even for their non-profit rate. What RBLs do people find to be effective now days? I was looking at SpamRats, which I did not know about before, but it looks decent. The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. The ones I use are listed there. Allen C
Re: Preferred/maintained greylisting options?
Allen Coates writes: > On 24/05/2020 23:22, micah anderson wrote: >> We paid for access to spamhaus for a while, but they jacked up the >> prices and now its far too expensive even for their non-profit rate. >> >> What RBLs do people find to be effective now days? I was looking at >> SpamRats, which I did not know about before, but it looks decent. > > > The web page https://www.abuseat.org/faq.html (about half-way down the page) > has an honest - and fairly recent - appraisal of a number of DNSBLs. Its a little outdated... For example: Invaluement DNSBL [Note: Commercial] ivmURI and ivmSIP are good solid and professionally operated lists. ivmURI is a URI (domain) DNSBL like SURBL or URIBL or DBL, with high effectiveness (comparable with DBL/URIBL/SURBL), extremely low false positives, and quick to list. ivmSIP is a IP-based DNSBL which is particularly good at catching "new" emitters. Its FP rate is quite low. Neither of which should be considered substitutes for Spamhaus Zen/Spamcop, but do complement them well. They no longer exist. SPEWS, TQMCube, ORDB, OSIRUS, MONKEYS, DSBL All of these lists have been decommissioned and should not be used. DO NOT USE. The spameatingmonkeys *does* exist. -- micah
Re: Preferred/maintained greylisting options?
On 24/05/2020 23:22, micah anderson wrote: > We paid for access to spamhaus for a while, but they jacked up the > prices and now its far too expensive even for their non-profit rate. > > What RBLs do people find to be effective now days? I was looking at > SpamRats, which I did not know about before, but it looks decent. The web page https://www.abuseat.org/faq.html (about half-way down the page) has an honest - and fairly recent - appraisal of a number of DNSBLs. The ones I use are listed there. Allen C
Re: Preferred/maintained greylisting options?
On Fri, May 22, 2020 at 5:43 AM Ralph Seichter wrote:
> Yeah, delays... Used to be people understood the difference between
> asynchronous messaging (i.e. email) and instant messaging. Nowadays it
> seems that no day goes by without somehing along these lines:
>
> "Hi. We have not seen you login using this browser, this IP address or
> during this week. Therefore we have just sent you an email containing
> a verification code, which will remain valid for 10 minutes."
Personally, I've hacked together a mixed SPF check + greylist milter.
If SPF check passes, the greylist is skipped, and any other result
("do not reject any mail" approach modulo greylisting) goes to greylist.
The companies which send such emails are likely (in my experience)
to have a properly setup SPF, so this solved these issues for me.
I'm not planning on releasing the source, it's really an ugly milter, but
I'm putting the idea out here - and maybe I'll learn it has already been
done and properly implemented...
Regards,
--
Vincent Pelletier
Re: Preferred/maintained greylisting options?
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? 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. Wietse
Re: Preferred/maintained greylisting options?
> On 24 May 2020, at 13:05, Charles Sprickman wrote: > > > >> On May 24, 2020, at 3:59 PM, Laura Smith >> wrote: >> >>> >>> 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. >>> >> >> >> IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it >> does that unforgivable thing of annoying genuine people. >> >> I would hazard a guess that if you are being innundated with spam, then your >> RBL setup is less than adequate. Both the choice of RBLs ***AND*** the >> correct configuration thereof is critical. > > As I described in my original email, this isn’t a failure of RBL setup. I’m > just being inundated with: > > - Correctly configured hosts that don’t fail any obvious protocol checks > - Hosts that are not on any RBLs until 5-10 minutes after delivering > > As I see it, I have limited options: > > - Do more filtering on content (blech - these only score +1 or so in SA) > - Delay the mail (from non-whitelisted senders) until the hosts are listed. > >> I should also add that you should not be afraid to pay for access. The good >> lists will (a) block you if you hammer them with high volumes of requests >> (b) save some of their better content (or new innovations) for their paid >> subscribers. > > I’ve trialed the major ones with no improvement. The greylisting suggestion > came from Abusix because they looked up a day of “leaks” and found they were > simply delivering before they were being listed. > >> RBLs these days are pretty darn good, with everything setup correctly you >> can easily be in the very high 90-percentiles of catching spam and pretty >> much zero false-positives. > > Sadly, we seem to be at the head of most spammer’s lists. One of these “paid” > services should give us free access in return for a spamtrap. :) > > It’s also incredibly obvious there are some colos that are catering to these > people, esp. that firm out of Buffalo… I ran an ISP for a number of years and we had to deal with a lot of spam. When greylisting first became available, I added it into our mix of spam protection. While I don't recall the exact number, over 95% of received mail was blocked. There were a few issues with some legitimate mailers who refused to retry, eventually we whitelisted enough that our users had no issues. This worked because at that time virtually all spammers were drive-by spammers. They sent the email once, and didn't bother to queue it if it couldn't be delivered. The cost of diskspace and internet connections were too high for them. With time, those costs came down. Effectively today there is no additional cost to queue spam. Hence, virtually all the spammers are now using high quality mail servers like postfix. They seem to retry forever. Greylisting has become pretty much useless. When I disabled it a couple years ago, the spam levers did not increase by any measurable amount. We now use just 3 RBLs and that seems to be a relatively acceptable level of spam. -- Doug
Re: Preferred/maintained greylisting options?
Laura Smith writes: > I should also add that you should not be afraid to pay for access. The > good lists will (a) block you if you hammer them with high volumes of > requests (b) save some of their better content (or new innovations) > for their paid subscribers. We paid for access to spamhaus for a while, but they jacked up the prices and now its far too expensive even for their non-profit rate. What RBLs do people find to be effective now days? I was looking at SpamRats, which I did not know about before, but it looks decent. -- micah
Re: Preferred/maintained greylisting options?
> On May 24, 2020, at 3:59 PM, Laura Smith > wrote: > >> >> 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. >> > > > IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it > does that unforgivable thing of annoying genuine people. > > I would hazard a guess that if you are being innundated with spam, then your > RBL setup is less than adequate. Both the choice of RBLs ***AND*** the > correct configuration thereof is critical. As I described in my original email, this isn’t a failure of RBL setup. I’m just being inundated with: - Correctly configured hosts that don’t fail any obvious protocol checks - Hosts that are not on any RBLs until 5-10 minutes after delivering As I see it, I have limited options: - Do more filtering on content (blech - these only score +1 or so in SA) - Delay the mail (from non-whitelisted senders) until the hosts are listed. > I should also add that you should not be afraid to pay for access. The good > lists will (a) block you if you hammer them with high volumes of requests (b) > save some of their better content (or new innovations) for their paid > subscribers. I’ve trialed the major ones with no improvement. The greylisting suggestion came from Abusix because they looked up a day of “leaks” and found they were simply delivering before they were being listed. > RBLs these days are pretty darn good, with everything setup correctly you can > easily be in the very high 90-percentiles of catching spam and pretty much > zero false-positives. Sadly, we seem to be at the head of most spammer’s lists. One of these “paid” services should give us free access in return for a spamtrap. :) It’s also incredibly obvious there are some colos that are catering to these people, esp. that firm out of Buffalo… Charles >
Re: Preferred/maintained greylisting options?
> > 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. > IMHO Greylisting is rather pointless. Its a blunt tool, and not only that it does that unforgivable thing of annoying genuine people. I would hazard a guess that if you are being innundated with spam, then your RBL setup is less than adequate. Both the choice of RBLs ***AND*** the correct configuration thereof is critical. I should also add that you should not be afraid to pay for access. The good lists will (a) block you if you hammer them with high volumes of requests (b) save some of their better content (or new innovations) for their paid subscribers. RBLs these days are pretty darn good, with everything setup correctly you can easily be in the very high 90-percentiles of catching spam and pretty much zero false-positives.
Re: Preferred/maintained greylisting options?
On 21 May 2020, at 12:49, Charles Sprickman wrote: > I was wondering if greylisting might be a good option here. It's a matter of how much Nanking you are willing to do and how much legitimate mail your are willing to lose. The usual method of greylisting where you tell a server to try again later (4xx error) will cost you legitimate mail as many senders, including very large senders, will retry from different servers (google, Amazon). Others, in the idiotic belief they are being "secure", will never retry. Many of the latter are banks. Other forms off greylisting, like slowing the connection rate and making the transaction take a bit longer than usual are far more effective and less likely to cause issues with legitimate senders. Greylosting also really screws up the "authenticate your email right now. No, right this second. We sent you the code, enter it now in the next ten seconds or we delete your account and ban your IP" idiocy on the web that, nonetheless, some of us are forced to deal with. It's impossible to keep up with the list of domains doing that, especially when most of the verification emails originate from other servers. Postscreen, out-of-the-box, works exceptionally well and blocks more spam than any thing else I've used. Sure, I run SpamAssassin as well, but it sees very little use. Add an RBL or two, and it's kind of like magic. -- Knowledge equals power... --... Power equals energy... People were stupid, sometimes. They thought the Library was a dangerous place because of all the magical books, which was true enough, but what made it really one of the most dangerous places there could ever be was the simple fact that it was a library. Energy equals matter... --... Matter equals mass. And mass distorts space. It distorts it into polyfractal L-Space. --Guards! Guards!
Re: Preferred/maintained greylisting options?
* Charles Sprickman: > 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. Yeah, delays... Used to be people understood the difference between asynchronous messaging (i.e. email) and instant messaging. Nowadays it seems that no day goes by without somehing along these lines: "Hi. We have not seen you login using this browser, this IP address or during this week. Therefore we have just sent you an email containing a verification code, which will remain valid for 10 minutes." Nevermind that the web session times out after 5 minutes, but hey, it's the *thought* about security that counts. :-P In any case, time-based greylisting croaks with this scenario. The solution for our machines is Postscreen, for which I want to thank Wietse once again on this occasion. The logs show a large number of thwarted spam attempts while time-sensitive email passes unhindered. Personally, I cannot think of a better solution when you are using Postfix. -Ralph
Re: Preferred/maintained greylisting options?
On 2020-05-21 19:49 BST, Charles Sprickman wrote: > What is your “go to” greylisting solution these days? It wasn't keeping much out after configuring postscreen and I gave up on greylisting about a year ago, so this might be out of date but: postgrey worked reliably for me without any fuss. -- Nick
Re: Preferred/maintained greylisting options?
On 21.05.20 14:49, Charles Sprickman wrote: 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. postscreen provides very similar functionality. If needed, I would try dcc https://www.dcc-servers.net/dcc/ for the greylisting functionality: https://www.dcc-servers.net/dcc/greylist.shtml 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. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete
Re: Preferred/maintained greylisting options?
Den 21.05.2020 20:49, skrev 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. Postscreen http://www.postfix.org/POSTSCREEN_README.html#victory with some "deep protocol test" will give a slight greylist-like delay. Since you already have it, that would be the go-to. Further than that, I don't know what is best practice atm, but personally I use rspamd which has a greylisting feature. 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. Having the first connect get a 4xx will actually get a lot of spammers to just move on and not come back until the next time rent is due. Must-have I'd say.
Preferred/maintained greylisting options?
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. Thanks, Charles
