Preferred/maintained greylisting options?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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.

Thanks,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Håkon Alstadheim

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.
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Matus UHLAR - fantomas
In reply to this post by Charles Sprickman
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, [hidden email] ; 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Nick-5
In reply to this post by Charles Sprickman
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Ralph Seichter-2
In reply to this post by Charles Sprickman
* 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

@lbutlr
In reply to this post by Charles Sprickman
On 21 May 2020, at 12:49, Charles Sprickman <[hidden email]> 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!


Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Laura Smith
In reply to this post by 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.
>


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.


Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Charles Sprickman


> On May 24, 2020, at 3:59 PM, Laura Smith <[hidden email]> 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

>

Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Micah Anderson-2
In reply to this post by Laura Smith
Laura Smith <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

wa6vvv
In reply to this post by Charles Sprickman

> On 24 May 2020, at 13:05, Charles Sprickman <[hidden email]> wrote:
>
>
>
>> On May 24, 2020, at 3:59 PM, Laura Smith <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Wietse Venema
In reply to this post by Charles Sprickman
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Vincent Pelletier
In reply to this post by Ralph Seichter-2
On Fri, May 22, 2020 at 5:43 AM Ralph Seichter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

allenc
In reply to this post by Micah Anderson-2


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

Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Micah Anderson-2
Allen Coates <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Michael-4
In reply to this post by allenc
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Patrick Proniewski
In reply to this post by Vincent Pelletier
Hello,

> On 25 mai 2020, at 03:59, Vincent Pelletier <[hidden email]> wrote:
>
> On Fri, May 22, 2020 at 5:43 AM Ralph Seichter <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Patrick Proniewski
In reply to this post by Michael-4
On 25 mai 2020, at 13:56, Michael <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Kris Deugau
In reply to this post by Micah Anderson-2
micah anderson wrote:

> Allen Coates <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Micah Anderson-2
Kris Deugau <[hidden email]> writes:

> micah anderson wrote:
>> Allen Coates <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Preferred/maintained greylisting options?

Chris Wedgwood
In reply to this post by wa6vvv
> 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
12