I'm running Postfix 3.1.0 on an Ubuntu 16.04 LTS system.
II'm using Postfix's postscreen filtering, including zen.spamhaus.org (with a large score) as one of my DNSBL sites, but it's not helping in some cases because the spam sources are not showing up on Spamhaus at the time I get e-mail from them -- only later on. I'm wondering if it may be worthwhile for me to enable greylisting in some form on my server. I'm aware of Postgrey, but I'm uneasy because this package seems to get updated so rarely (the latest version is about three years old). I see the Postfix configuration docs (www.postfix.org/postconf.5.html) propose using address_verify_poll_count=1 as "a crude form of greylisting"; how well do people find this to work in practice? Any other suggestions? Rich Wales [hidden email] |
I have not used greylisting in 5+ years, not even fake greylisting
with address_verify_poll_count or postscreen_whitelist_interfaces, Wietse |
In reply to this post by Rich Wales
* Rich Wales:
> I'm wondering if it may be worthwhile for me to enable greylisting in > some form on my server. While postscreen is no silver bullet, it does a fine job for me. I'd rather see some spammers connect (doesn't mean their postings go through) than risk blocking inbound "confirmation token" email which has become quite prevalent these days. As is usual here, I get assigned new IP addresses (IPv4 and IPv6) every 24 hours and hence see many of these tokens, but your mileage may vary. > I'm aware of Postgrey, but I'm uneasy because this package seems to > get updated so rarely Could just be a case of "don't fix what is not broken". I used Postgrey before postscreen was available and had no technical problems, but it occasionally required some manual whitelisting. -Ralph |
On Sat, Jun 22, 2019, 07:33 Ralph Seichter <[hidden email]> wrote: * Rich Wales: I've stopped using greylisting due to the huge expectations of users for instant delivery. Postscreen or rspamd does a good alternative. DP |
In reply to this post by Rich Wales
Am 22.06.19 um 02:49 schrieb Rich Wales: > Any other suggestions? I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't Andreas |
>Am 22.06.19 um 02:49 schrieb Rich Wales:
>> Any other suggestions? On 22.06.19 14:43, A. Schulze wrote: >I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't even compared to postscreen? -- 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. "The box said 'Requires Windows 95 or better', so I bought a Macintosh". |
Am 23.06.19 um 16:57 schrieb Matus UHLAR - fantomas: > On 22.06.19 14:43, A. Schulze wrote: >> I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't > > even compared to postscreen? yes while running postscreen and postgrey I still see some connections deferred by postgrey... no more details available on a sunday. Andreas |
In reply to this post by Matus UHLAR - fantomas
Matus UHLAR - fantomas:
> >Am 22.06.19 um 02:49 schrieb Rich Wales: > >> Any other suggestions? > > On 22.06.19 14:43, A. Schulze wrote: > >I'm still using greylisting with moderate effects. It catches some percent other AntiSpam technics doesn't > > even compared to postscreen? I would expect that greylisting blocks some spambots before they are blacklisted in DNSBLs. Wietse |
I'm using conditional greylisting with policy-weightd and postgrey.
And another conditional greylisting if the spamassassin score is too high using milter-greylist. This doesn't introduce delays for most of the incoming mails but penalizes zombies / mailservers with strange behaviours :) - tmolitor Am Sonntag, 23. Juni 2019, 13:24:59 CEST schrieb Wietse Venema: > Matus UHLAR - fantomas: > > >Am 22.06.19 um 02:49 schrieb Rich Wales: > > >> Any other suggestions? > > > > On 22.06.19 14:43, A. Schulze wrote: > > >I'm still using greylisting with moderate effects. It catches some > > >percent other AntiSpam technics doesn't> > > even compared to postscreen? > > I would expect that greylisting blocks some spambots before they > are blacklisted in DNSBLs. > > Wietse |
In reply to this post by Rich Wales
On 22/06/19 12:49 PM, Rich Wales wrote:
> I'm running Postfix 3.1.0 on an Ubuntu 16.04 LTS system. > > II'm using Postfix's postscreen filtering, including zen.spamhaus.org > (with a large score) as one of my DNSBL sites, but it's not helping in > some cases because the spam sources are not showing up on Spamhaus at > the time I get e-mail from them -- only later on. > > I'm wondering if it may be worthwhile for me to enable greylisting in > some form on my server. I'm aware of Postgrey, but I'm uneasy because > this package seems to get updated so rarely (the latest version is about > three years old). Just enable (and use) the after-220 tests for postscreen which have basically the same effect as greylisting. Postscreen with the after-220 tests enabled basically makes postgrey obsolete. See http://rob0.nodns4.us/postscreen.html which uses dnswl scoring to address some of the issues with major ESPs such as google and the after-220 tests. Peter |
In reply to this post by A. Schulze
On 24/06/19 5:21 AM, A. Schulze wrote:
> while running postscreen and postgrey I still see some connections deferred by postgrey... > no more details available on a sunday. If you're running the after-220 tests in postscreen then these messages are actually deferring twice, and the fact that postgrey defers does not mean it caught spam, it means it may be spam and it is delaying the message further to try to check. If postscreen is catching the vast majority of these then all you're seeing is unnecessary delay on legitimate mail. Peter |
In reply to this post by Peter Ajamian
I've enabled the post-220 postscreen tests now on my server, and this is
making a significant difference -- most spam from random garbage domains is never returning anymore after the initial soft rejection. However, a handful of spam messages are still getting through. It seems some spam-sending engines are getting smarter and are retrying almost immediately after an initial rejection -- before Spamhaus has had a chance to list them -- and since they already got rejected once by postscreen, they are being allowed in on the second try. Is there -- or should there be -- a configuration parameter to tell the postscreen server to reject new(ish) clients for a specified minimum period of time before stepping out of the way and allowing them to pass? At the moment, it seems to me that requiring a minimum of 5 minutes after the first soft rejection should be more than sufficient. Rich Wales [hidden email] |
On 25/06/19 5:12 AM, Rich Wales wrote:
> However, a handful of spam messages are still getting through. It seems > some spam-sending engines are getting smarter and are retrying almost > immediately after an initial rejection -- before Spamhaus has had a > chance to list them -- and since they already got rejected once by > postscreen, they are being allowed in on the second try. I should immediately point out that postscreen is not designed to get *all* spam, but rather it is designed to get the bulk of spam in a very efficient way to descrease the load on other anti-spam solutions that you have which are more costly. > Is there -- or should there be -- a configuration parameter to tell the > postscreen server to reject new(ish) clients for a specified minimum > period of time before stepping out of the way and allowing them to pass? > At the moment, it seems to me that requiring a minimum of 5 minutes > after the first soft rejection should be more than sufficient. Not at this time that I'm aware of, perhaps Wietse might consider adding such a feature in a future release? The downside here is that it would introduce yet another unfortunate delay in the delivery of mail, and it would pay to ask if the handful of messages getting through (that might be caught by another anti-spam solution later in your pipeline) is worth catching for the delay you are introducing with such a setting. Peter |
In reply to this post by Rich Wales
Rich Wales:
> Is there -- or should there be -- a configuration parameter to tell the > postscreen server to reject new(ish) clients for a specified minimum > period of time before stepping out of the way and allowing them to pass? > At the moment, it seems to me that requiring a minimum of 5 minutes > after the first soft rejection should be more than sufficient. postscreen does not have to block all spam. If you want to greylist, you can still do that with check_policy_service. Wietse |
Free forum by Nabble | Edit this page |