At Fri, 11 Oct 2024 15:53:31 +0200, "Hauke Fath (SPG)" <hf%spg.tu-darmstadt.de@localhost> wrote: Subject: Re: 2. Greylisting > > On 2024-10-09 19:21, Greg A. Woods wrote: > > I would recommend turning off greylisting, as an experiment, to see what > > happens. I've found it to be entirely counter-productive. It hasn't > > been useful for literally years now -- the spammers have long ago adapted. > > That is not the impression that my server log gives. > > There still appear to be enough > hit-and-run mail bots about, which are > effectively discouraged by greylisting. I would wonder just how you can be certain of that. An "impression" doesn't "impress me much". Doing a proper analysis of the effects of greylisting to be certain it is worthwhile is not an easy task, at least not without turning it off for a period of time. One must collectively look at many days of connection logs and as many other details as possible about each connection and then develop algorithms to be able to try to identify their intent for each connection, filtering out those origins that eventually do attempt to deliver email (regardless of whether it is junk mail or good mail). Unfortunately greylisting makes it impossible to tell for sure whether a returning bot is trying to deliver the same message or a new message or if it has simply delayed to long and bumps into the greylisting delay again. Maybe it's just a legitimate site with poor queueing and retry policies. Maybe it is even just one of dozens of servers in a pool of systems all delivering email from the same queue for the same domain. Do you explicitly whitelist large sites with pools of outbound servers? The only way to be certain is to turn off greylisting and analyze the patterns again with the full details of at least their entire SMTP envelope (if not the whole message), hoping the bots haven't changed addresses in the mean time. In the end one cannot even determine the full effectiveness of all the other necessary verifications and anti-spam measures when greylisting is in use. Greylisting is just a wild shot in the dark against statistics and it is entirely counter-productive to all non-abusive email; and it does not, and cannot, help reduce the need for any other normal verifications and anti-spam measures that must be implemented and in place anyway. I must also wonder how people using email at sites that implement greylisting deal with the myriad of email verification messages that so many services require these days, many of which expire within rather short periods, and of course all of which must be received and opened before one can proceed with whatever task one is attempting with such a service. Just try fixing a flight booking while on the way to the airport and then have to wait for an email confirmation message to arrive before you can confirm the change! Once upon a time, say about 15 to 18 years ago, greylisting did help reduce the need for hardware and resources, including network bandwidth, significantly enough to be cost-effective particularly for larger sites, and of course back then email verification messages were far less common so people often didn't notice if their email was delayed. I helped manage several small ISP mail servers at the height of that time, and I implemented all the MTA code and backend support to enable greylisting for them -- and many people still complained about email delays when it was enabled! However its effectiveness has declined even faster than the corresponding improvements to most people's hardware and network connectivity over the same period of time since. I think I turned off all greylisting for every mail server I operated as long ago as 2007. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpIrJjxnl6oW.pgp
Description: OpenPGP Digital Signature