Re: NOQUEUE when relaying mail to host with greylisting

[Wietse Venema]

Juerg Reimann:
> Hi everybody
> 
> I have a relatively dumb host in mynetworks that should be able to relay mail 
> through my server. This host does not retry sending a mail if something goes 
> wrong. It works until there is a recipient host that has graylisting 
> activated:
> 
> postfix/smtpd[68055]: [ID 197553 mail.info] NOQUEUE: reject: RCPT from 
> host.in.mynetworks[1.2.3.4]: 450 4.1.1 : Recipient 
> address rejected: unverified address: host some.mail.server[4.3.2.1] said: 
> 450 4.7.1 : Recipient address rejected: Greylisted for 5 
> minutes (in reply to RCPT TO command); from= 
> to= proto=ESMTP helo=
> 
> Why is such a mail not ending up in my postfix' mailqueue so that postfix can 
> retry later?
> 

Because someone configured Postfix to reject that mail with
reject_unverified_recipient.

Workaround: specify permit_mynetworks *before* reject_unverified_recipient.

Wietse

Re: Preferred/maintained greylisting options?

[Wietse Venema]

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?

[Charles Sprickman]

> 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

An

Re: Preferred/maintained greylisting options?

[@lbutlr]

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?

[Doug Hardie]

> 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?

[Chris Wedgwood]

> 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?

[Marvin Renich]

* 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?

[Chris Wedgwood]

> 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?

[micah anderson]

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?

[Kris Deugau]

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?

[Patrick Proniewski]

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?

[Patrick Proniewski]

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?

[Michael]

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?

[micah anderson]

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?

[Allen Coates]

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?

[Vincent Pelletier]

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?

[Wietse Venema]

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?

[Doug Hardie]

> 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?

[micah anderson]

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?

[Charles Sprickman]

> 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?

[Laura Smith]

>
> 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?

[@lbutlr]

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?

[Ralph Seichter]

* 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?

[Nick]

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?

[Matus UHLAR - fantomas]

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?

[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.

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

Re: Greylisting -- current recommendations?

[Wietse Venema]

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

Re: Greylisting -- current recommendations?

[Peter]

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

Re: Greylisting -- current recommendations?

[Rich Wales]

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
ri...@richw.org

Re: Greylisting -- current recommendations?

[Peter]

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

Re: Greylisting -- current recommendations?

[Peter]

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

Re: Greylisting -- current recommendations?

[Thilo Molitor]

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

Re: Greylisting -- current recommendations?

[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

Re: Greylisting -- current recommendations?

[A. Schulze]

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

Re: Greylisting -- current recommendations?

[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?

--
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.
"The box said 'Requires Windows 95 or better', so I bought a Macintosh".

Re: Greylisting -- current recommendations?

[A. Schulze]

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

Re: Greylisting -- current recommendations?

[Durga Prasad Malyala]

On Sat, Jun 22, 2019, 07:33 Ralph Seichter  wrote:

> * 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
>

I've stopped using greylisting due to the huge expectations of users for
instant delivery.
Postscreen or rspamd does a good alternative.

DP

>

Re: Greylisting -- current recommendations?

[Ralph Seichter]

* 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

Re: Greylisting -- current recommendations?

[Wietse Venema]

I have not used greylisting in 5+ years, not even fake greylisting
with address_verify_poll_count or postscreen_whitelist_interfaces,

Wietse

Greylisting -- current recommendations?

[Rich Wales]

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
ri...@richw.org

Re: SPF and Greylisting

[@lbutlr]

On 5 Apr 2019, at 09:11, Viktor Dukhovni  wrote:
> Note that you SHOULD NOT ultimately refuse email on SPF softfail,
> but greylisting would be OK, if you find it meets your needs.

Is grey listing still effective? I know when I stopped using it it was not 
doing much of anything and I can't imagine it's gotten more effective.


-- 
Lisa Bonet ate no Basil

RE: SPF and Greylisting

[steve]

Thanks for all of the suggestions.

smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_unauth_pipelining,
permit_mynetworks,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_unknown_reverse_client_hostname,
reject_non_fqdn_helo_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
check_policy_service unix:/var/spool/postfix/postgrey/socket

So far, I've made a copy of policyd-spf and modified it so that Softfail and
Neutral returned defer.

However, there really doesn't seem to be a practical difference between
defer and reject in terms since a retry to the deferral would just lead to a
subsequent deferral until some action is taken.

I suppose the whole thing is moot since I'm greylisting as the last
condition, so really if the spf check returns dunno (everything other than
Fail or Permerror), eventually it will either be rejected by a following
rule or greylisted by the final policy check.

Steve

-Original Message-
From: owner-postfix-us...@postfix.org  On
Behalf Of Wietse Venema
Sent: April 5, 2019 11:20 AM
To: Postfix users 
Subject: Re: SPF and Greylisting

st...@douville.net:
> Hi,
>
> policyd-spf and postgrey are implemented and working.
>
> With exim, I was able to check the spf result and greylist upon 
> receiving a certain result. I'm using Mail_From_pass_restriction = 
> mfrom_passed_spf in policy-spf.conf.
>
> Is there any way I can defer or greylist based on an spf result of
Softfail?

If these are plugged in with check_policy_service, then the result from the
SPF check is not limited to permit or deny, it can be the full repertoire of
smtpd_mumble_restrictions.

So the SPF check could output something like

check_policy_service name-of-greylist-plugin

if the client needs to be greylisted, and

dunno

if not.

Wietse

Re: SPF and Greylisting

[Scott Kitterman]

On April 5, 2019 2:55:38 PM UTC, st...@douville.net wrote:
>Hi,
>
> 
>
>policyd-spf and postgrey are implemented and working.
>
> 
>
>With exim, I was able to check the spf result and greylist upon
>receiving a
>certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf
>in
>policy-spf.conf. 
>
> 
>
>Is there any way I can defer or greylist based on an spf result of
>Softfail?

This isn't precisely what you asked for, but I think it's close enough to give 
you the idea:

https://git.launchpad.net/spf-engine/tree/README.per_user_whitelisting

It shows how to use Postfix restriction classes to take different actions based 
on SPF result.

Note that this has not been updated in quite some time.  If you do use it and 
find it can be improved, bug reports on the Launchpad project would be 
appreciated.

Scott K

Re: SPF and Greylisting

[Wietse Venema]

st...@douville.net:
> Hi,
>
> policyd-spf and postgrey are implemented and working.
>
> With exim, I was able to check the spf result and greylist upon receiving a
> certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf in
> policy-spf.conf.
>
> Is there any way I can defer or greylist based on an spf result of Softfail?

If these are plugged in with check_policy_service, then the result
from the SPF check is not limited to permit or deny, it can be the
full repertoire of smtpd_mumble_restrictions.

So the SPF check could output something like

check_policy_service name-of-greylist-plugin

if the client needs to be greylisted, and

dunno

if not.

Wietse

Re: SPF and Greylisting

[Viktor Dukhovni]

On Fri, Apr 05, 2019 at 10:55:38AM -0400, st...@douville.net wrote:

> Hi,
> 
> policyd-spf and postgrey are implemented and working.
> 
> Is there any way I can defer or greylist based on an spf result of Softfail?

Yes, by having the policy service return a 4XX response.  Postfix
will do whatever the policy service asks.  Your question is perhaps
about those policy services, rather than Postfix per-se.

Note that you SHOULD NOT ultimately refuse email on SPF softfail,
but greylisting would be OK, if you find it meets your needs.

-- 
Viktor.

SPF and Greylisting

[steve]

Hi,

 

policyd-spf and postgrey are implemented and working.

 

With exim, I was able to check the spf result and greylist upon receiving a
certain result. I'm using Mail_From_pass_restriction = mfrom_passed_spf in
policy-spf.conf. 

 

Is there any way I can defer or greylist based on an spf result of Softfail?

 

TIA,

 

Steve

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

[Patrick Ben Koetter]

* @lbutlr :
> On 07 Aug 2018, at 04:49, Luc Pardon  wrote:
> > but in any case it serves no useful purpose (unlike greylisting, SAV, etc.
> 
> Are people still finding grey listing to be useful? I found it caused far
> more problems than it solved and the endless game of scanning logs for sites
> like Amazon that resend from different machines or many banks that will
> never resend was time consuming and tedious.

Yes, I find it still useful, but I don't use it as a primary tool ever since
postscreen has landed. Actually I was very happy to send it back into line,
because it kills one of the most attractive features in email: instant
communication.

Nowadays we use it in rspamd, where it works as "dynamic greylisting" addon.
Whenever a certain threshold has been reached rspamd sends the client off to
greylisting. Any mail that stays below that threshold will not be subject to
greylisting.

I like that conditional behaviour better. It adds delay to email delivery only
when in doubt.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

[Matus UHLAR - fantomas]

On 07 Aug 2018, at 04:49, Luc Pardon  wrote:

but in any case it serves no useful purpose (unlike greylisting, SAV, etc.


On 07.08.18 13:57, @lbutlr wrote:

Are people still finding grey listing to be useful? I found it caused far
more problems than it solved and the endless game of scanning logs for
sites like Amazon that resend from different machines or many banks that
will never resend was time consuming and tedious.


I migrate greylisting towards postscreen (some clients still send unauth
mail through port 25, so it's not so easy)

whitelist is important with greylisting, but it's usually already settled.
Lyckily there's not much services connecting always from different IPs...

Postscreen provides BL scoring and pregreeting tests, and with after-220
checks provides something very similar to greylisting.

--
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.
Eagles may soar, but weasels don't get sucked into jet engines. 

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

[Wietse Venema]

@lbutlr:
> On 07 Aug 2018, at 04:49, Luc Pardon  wrote:
> > but in any case it serves no useful purpose (unlike greylisting, SAV, =
> etc.
> 
> Are people still finding grey listing to be useful? I found it caused =
> far more problems than it solved and the endless game of scanning logs =
> for sites like Amazon that resend from different machines or many banks =
> that will never resend was time consuming and tedious.

Not since I started using postscreen.

With postscreen 'after 220' checks turned off, a 'good' client gets
to talk to the Postfix SMTP server without having to reconnect.
This is what I have been doing since 2011 or so.

With postscreen 'after 220' checks turned on, a 'good' client has
to reconnect, which brings all the issues of greylisting. I found
that this blocked practically nothing that wasn't already blocked
otherwise.

Greylisting (whether in postscreen or otherwise) may still be an
option for sites that don't want to use DNSBLs.

Wietse

Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

[Dominic Raferd]

On Tue, 7 Aug 2018, 20:58 @lbutlr,  wrote:

> On 07 Aug 2018, at 04:49, Luc Pardon  wrote:
> > but in any case it serves no useful purpose (unlike greylisting, SAV,
> etc.
>
> Are people still finding grey listing to be useful? I found it caused far
> more problems than it solved and the endless game of scanning logs for
> sites like Amazon that resend from different machines or many banks that
> will never resend was time consuming and tedious.


I gave it up a while ago and haven't missed it. The delayed delivery drove
users wild.

Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)

[@lbutlr]

On 07 Aug 2018, at 04:49, Luc Pardon  wrote:
> but in any case it serves no useful purpose (unlike greylisting, SAV, etc.

Are people still finding grey listing to be useful? I found it caused far more 
problems than it solved and the endless game of scanning logs for sites like 
Amazon that resend from different machines or many banks that will never resend 
was time consuming and tedious.

-- 
If lawyers are disbarred and clergymen defrocked, doesn't it follow that
electricians can be delighted, musicians denoted?

Re: Greylisting?

[john]

Thanks.


On 2018-03-11 10:39 PM, john wrote:
I  was just taking a look through my postfix configuration and noticed 
that I have a "check_policy_service" for postgrey a greylisting service.


I greylisting still considered worthwhile or should I drop it?

TIA

John A

Re: Greylisting?

[/dev/rob0]

On Mon, Mar 12, 2018 at 09:59:27AM +, Allen Coates wrote:
> Late last year I tried the Postscreen "deep protocol tests" as a 
> primitive form of greylisting; It was a high-maintenance exercise 
> for minimal benefit and I have since stopped using it.
> 
> Google and the like, use a different mail server for each connect
> attempt.  You need an actively maintained whitelist to bypass the
> grey-list process.

Postfix 2.11+ (which is to say, all supported versions of Postfix at 
this time) supports DNS whitelists via 
postscreen_dnsbl_whitelist_threshold, and this is a very good and 
low-maintenance solution to that problem.  Large senders such as 
Google are all listed at dnswl.org.  What few smaller senders you 
encounter typically retry from the same IP address.

We get the potential benefit of greylisting without much pain.

> Also, (in my case) I was plagued by Ukrainian spamming mail 
> servers; they just retried and got through.

Of course.  The only potential benefit of greylisting a real MTA is 
that DNSBLs might have listed a spamming one by the time it retries 
delivery.

> The experiment DID stop a few zombies, but not many.

Every little bit helps, in such a hostile protocol as SMTP.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Greylisting?

[@lbutlr]

On 2018-03-12 (06:40 MDT), "@lbutlr"  wrote:
> 
> It is not worthwhile because two many mailers will use different servers to 
> send mail, which will hit the greylist all over again. This means a lot of 
> maintenance for those (and we're talking mailers like google, amazon, PayPal, 
> fleabay, etc).

One other thing, some (idiot) companies, especially banks, will only sent an 
email once and treat any temporary failure as a rejection/bounce.

-- 
Women like silent men, they think they're listening.

Re: Greylisting?

[@lbutlr]

On 2018-03-11 (20:39 MDT), john <j...@klam.ca> wrote:
> 
> I greylisting still considered worthwhile or should I drop it?

It is not worthwhile because two many mailers will use different servers to 
send mail, which will hit the greylist all over again. This means a lot of 
maintenance for those (and we're talking mailers like google, amazon, PayPal, 
fleabay, etc).

Also, there is very little upside.

I used it years ago and found it too burdensome.

-- 
Man is born free, but is everywhere in chains.

Re: Greylisting?

[Matus UHLAR - fantomas]

The experiment DID stop a few zombies, but not many.
On 12/03/18 02:39, john wrote:

I  was just taking a look through my postfix configuration and noticed
that I have a "check_policy_service" for postgrey a greylisting service.

I greylisting still considered worthwhile or should I drop it?


On 12.03.18 09:59, Allen Coates wrote:

Late last year I tried the Postscreen "deep protocol tests" as a
primitive form of greylisting; It was a high-maintenance exercise for
minimal benefit and I have since stopped using it.


I use postscreen's pre-220 tests as primitive form of greylisting.
I have removed the former (real) greylisting when switching to postscreen.

I didn't want to risk remporaty rejection that must happen with deep
protocol tests and any problems resulting from that.


Google and the like, use a different mail server for each connect
attempt.  You need an actively maintained whitelist to bypass the
grey-list process.


while it's of course advisable to use whitelists for caces like google and
hotmail, it's usually not necessary with pre-220 tests.

you will of course need whitelisting when communicating with other broken
server, but that applies to any type of mail rejection or spam detection.


Also, (in my case) I was plagued by Ukrainian spamming mail servers;
they just retried and got through.


this (and the above) applies to all types of greylistings.
they are designed to get rid of spambots, not of spam sent through real mail
servers.

--
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.
I'm not interested in your website anymore.
If you need cookies, bake them yourself.

Re: Greylisting?

[Allen Coates]

Late last year I tried the Postscreen "deep protocol tests" as a
primitive form of greylisting; It was a high-maintenance exercise for
minimal benefit and I have since stopped using it.

Google and the like, use a different mail server for each connect
attempt.  You need an actively maintained whitelist to bypass the
grey-list process.

Also, (in my case) I was plagued by Ukrainian spamming mail servers;
they just retried and got through.

The experiment DID stop a few zombies, but not many.

Allen C



On 12/03/18 02:39, john wrote:
> I  was just taking a look through my postfix configuration and noticed
> that I have a "check_policy_service" for postgrey a greylisting service.
> 
> I greylisting still considered worthwhile or should I drop it?
> 
> TIA
> 
> John A
> 
> 
> 

Greylisting?

[john]

I  was just taking a look through my postfix configuration and noticed 
that I have a "check_policy_service" for postgrey a greylisting service.


I greylisting still considered worthwhile or should I drop it?

TIA

John A

Re: simple greylisting by geoip? milter or policy server?

[Noel Jones]

On 6/14/2016 7:21 PM, Allen Coates wrote:
> 
> 
> On 14/06/16 23:31, list...@tutanota.com wrote:
>>
>> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org
>> :
>>
>> Is there some way to integrate the GeoIP dbs with postscreen?
>>
>>
>> No, at least not easily.
>>
>>  
>>
>> Ok.  That would be a nice function to have, in my own opinion.
>>
> 
> FWIW -  my postscreen_dnsbl_sites contains the lines:-
> 
> zz.countries.nerd.dk,
> zz.countries.nerd.dk=127.0.3.58*-1,
> 
> The first line ALWAYS returns  a country code (for analysis), and also
> scores 1 "blacklist point" which is
> recinded by the second line if the remote host is in my own country (the UK)
> 
> You can also interrogate the site by country, eg   "host
> 4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip
> address belongs to the uk...
> 
> It might give you another "angle" on processing by country
> 
> Regards
> 
> Allen C
> 


Clever.  The OP can arrange for his own country to have a negative
score exceeding postscreen_dnsbl_whitelist_threshold.  That will
effectively only delay foreign mail with deep inspection.


  -- Noel Jones

Re: simple greylisting by geoip? milter or policy server?

[Wietse Venema]

list...@tutanota.com:
> 
> 15. Jun 2016 02:55 by wie...@porcupine.org:
> 
> > list...@tutanota.com> :
> >> > As for greylisting, you could use postscreen's deep protocol tests
> >> > instead - those tests require that clients disconnect and come back
> >> > before they can send mail.
> >>
> >> I do not want to delay all the inbound mail.
> >
> > You are not delaying all email. Deep protocol tests results
> > are cached for 30 days.
> 
> Ok. I think I have to correct the requirement.
> 
>   I think I understand then that every NEW mail that is not having
>   already been cached by a deep protocol test will be delayed??
>   At least the one time?

Nope. The caching is by CLIENT IP ADDRESS not EMAIL.

These details matter. Computers are like that.

Wietse

Re: simple greylisting by geoip? milter or policy server?

[lists42]

15. Jun 2016 02:55 by wie...@porcupine.org:

> list...@tutanota.com> :
>> > As for greylisting, you could use postscreen's deep protocol tests
>> > instead - those tests require that clients disconnect and come back
>> > before they can send mail.
>>
>> I do not want to delay all the inbound mail.
>
> You are not delaying all email. Deep protocol tests results
> are cached for 30 days.
>




Ok. I think I have to correct the requirement.




  I think I understand then that every NEW mail that is not having already 
been cached by a deep protocol test will be delayed?  At least the one time?




I cannot tolerate that for even new mails.  I'm chasing the goal of only 
delaying/greylisting ever the mails from a list of countries.

Re: simple greylisting by geoip? milter or policy server?

[lists42]

14. Jun 2016 22:49 by i...@markusbenning.de:

> may be mtpolicyd is an option for you:
>
> https://www.mtpolicyd.org
>
> It is a modular policyd and ships with a plugin for geoip.
> It works like this:
>




This looks like another option to milter-greylist.




I notice that it's different because it is a policyd daemon instead a milter.




If I am only using the geoip-greylisting capability is there a better reason 
to use one over the other?




It looks to be that milter-greylist maybe a lighter weight solution.

Re: simple greylisting by geoip? milter or policy server?

[Wietse Venema]

list...@tutanota.com:
> > As for greylisting, you could use postscreen's deep protocol tests
> > instead - those tests require that clients disconnect and come back
> > before they can send mail.
> 
> I do not want to delay all the inbound mail.

You are not delaying all email. Deep protocol tests results
are cached for 30 days.

Wietse

Re: simple greylisting by geoip? milter or policy server?

[Tom Hendrikx]

On 15-06-16 02:21, Allen Coates wrote:
> 
> 
> On 14/06/16 23:31, list...@tutanota.com wrote:
>>
>> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org
>> <mailto:njo...@megan.vbhcs.org>:
>>
>> Is there some way to integrate the GeoIP dbs with postscreen?
>>
>>
>> No, at least not easily.
>>
>>  
>>
>> Ok.  That would be a nice function to have, in my own opinion.
>>
> 
> FWIW -  my postscreen_dnsbl_sites contains the lines:-
> 
> zz.countries.nerd.dk,
> zz.countries.nerd.dk=127.0.3.58*-1,
> 
> The first line ALWAYS returns  a country code (for analysis), and also
> scores 1 "blacklist point" which is
> recinded by the second line if the remote host is in my own country (the UK)
> 
> You can also interrogate the site by country, eg   "host
> 4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip
> address belongs to the uk...
> 
> It might give you another "angle" on processing by country
> 

You could also convert the cidr tables from
http://www.ipdeny.com/ipblocks/ into check_client_access rules that
whitelist some countries from greylisting.

Kind regards,
Tom

Re: simple greylisting by geoip? milter or policy server?

[Benning, Markus]

On 2016-06-14 02:28, list...@tutanota.com wrote:

I am considering the installation of Greylisting with Postfix.

I want it only for one condition, to greylist mail originating from
certain countries.


Hi,

may be mtpolicyd is an option for you:

https://www.mtpolicyd.org

It is a modular policyd and ships with a plugin for geoip.
It works like this:

  
module = "GeoIPLookup"
database = "/usr/share/GeoIP/GeoIP.dat"
  
  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "DE,AT,CH,FR,IT"
mode = passive
score = -1
  
  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "RU,UA,CN,IN"
mode = passive
score = 5
  

Instead of a score you could also set actions:

  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "AQ"
mode = "reject"
reject_message = "too cold"
  

Theres also a Greylisting plugin.
You can combine them for conditional greylisting:

  
module = "ScoreAction"
threshold = 5

  module = "Greylist"
  score = -5
  mode = "passive"
  # activating the autowl will require a SQL database
  use_autowl = 0

  


Markus

--
https://markusbenning.de/

Re: simple greylisting by geoip? milter or policy server?

[Allen Coates]

On 14/06/16 23:31, list...@tutanota.com wrote:
>
> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org
> <mailto:njo...@megan.vbhcs.org>:
>
> Is there some way to integrate the GeoIP dbs with postscreen?
>
>
> No, at least not easily.
>
>  
>
> Ok.  That would be a nice function to have, in my own opinion.
>

FWIW -  my postscreen_dnsbl_sites contains the lines:-

zz.countries.nerd.dk,
zz.countries.nerd.dk=127.0.3.58*-1,

The first line ALWAYS returns  a country code (for analysis), and also
scores 1 "blacklist point" which is
recinded by the second line if the remote host is in my own country (the UK)

You can also interrogate the site by country, eg   "host
4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip
address belongs to the uk...

It might give you another "angle" on processing by country

Regards

Allen C




> Or for that case is the milter-greylist idea better?
> Yes, that will work fine for selective greylisting.
>
>
> I've been looking at this and am uncertain that it helps.
>
>
> Because the milter will have to be after postscreen right?  So The
> traffic from blocked countries will still get past the postscreen stage?
>
>
> I guess that is better than all the way through to delivery in any case.
>
>
>

Re: simple greylisting by geoip? milter or policy server?

[lists42]

14. Jun 2016 15:01 by njo...@megan.vbhcs.org:

>> Is there some way to integrate the GeoIP dbs with postscreen?
>
> No, at least not easily.

 

Ok.  That would be a nice function to have, in my own opinion.





> Or for that case is the milter-greylist idea better?
> Yes, that will work fine for selective greylisting.
>




I've been looking at this and am uncertain that it helps.




Because the milter will have to be after postscreen right?  So The traffic 
from blocked countries will still get past the postscreen stage?




I guess that is better than all the way through to delivery in any case.

Re: simple greylisting by geoip? milter or policy server?

[Michael J Wise]

> On 6/14/2016 4:06 PM, list...@tutanota.com wrote:
>>
>> Is there some way to integrate the GeoIP dbs with postscreen?
>
> No, at least not easily.

I would think it would be a Simple Matter of Programming, given a list of
the countries and languages you trusted, to generate a list of all the
ones you didn't. Would require a little binary math, but the list
shouldn't change that often.

Or, it could be a lookup of some sort.

>> Or for that case is the milter-greylist idea better?
>
> Yes, that will work fine for selective greylisting.

Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...  http://kapu.net/~mjwise/
" To Thunderous Applause.

Re: simple greylisting by geoip? milter or policy server?

[Noel Jones]

On 6/14/2016 4:06 PM, list...@tutanota.com wrote:
> 
> Is there some way to integrate the GeoIP dbs with postscreen?

No, at least not easily.

> 
> Or for that case is the milter-greylist idea better?

Yes, that will work fine for selective greylisting.


  -- Noel Jones

Re: simple greylisting by geoip? milter or policy server?

[lists42]

13. Jun 2016 17:54 by wie...@porcupine.org:

> list...@tutanota.com> :
>> But then I also read that that 'Policy delegation is now the preferred 
>> method
>> for adding policies to Postfix.'
>
> Milter support was added later, because some things can't be done
> with policy servers.




Ok.  I was'not sure about the differences or benefits.




> As for greylisting, you could use postscreen's deep protocol tests
> instead - those tests require that clients disconnect and come back
> before they can send mail.
>




I do not want to delay all the inbound mail.





I didn't understand that I could delay only some countries with the deep 
protocol tests, using for example the GeoIP databases.



Is there some way to integrate the GeoIP dbs with postscreen?

Or for that case is the milter-greylist idea better?

Re: simple greylisting by geoip? milter or policy server?

[Wietse Venema]

list...@tutanota.com:
> But then I also read that that 'Policy delegation is now the preferred method 
> for adding policies to Postfix.'

Milter support was added later, because some things can't be done
with policy servers. 

As for greylisting, you could use postscreen's deep protocol tests
instead - those tests require that clients disconnect and come back
before they can send mail.

Wietse

simple greylisting by geoip? milter or policy server?

[lists42]

I am considering the installation of Greylisting with Postfix.

I want it only for one condition, to greylist mail originating from certain 
countries.

I use Postfix 3.1 with postscreen.

I am already using milters for dkim and dmarc and a policy server for spf.

So looking through the addons and some posts I came to 'milter-greylist'.

    milter-greylist postfix
     http://hcpnet.free.fr/milter-greylist

It is a milter so I think it can be used in Postfix.  And it has a very 
simple easy ability to greylist only for specific countries

    milter-greylist+GeoIP
     http://milter-greylist.wikidot.com/geoip

But then I also read that that 'Policy delegation is now the preferred method 
for adding policies to Postfix.'

(1) For such only-geoip greylisting is the milter-greylist a recommendation 
?  I do not want any complicated rules, only the "greylist this country" 
ones.

(2) Is the postfix documentation saying there that we should use policy 
servers instead of milters?  I think I am maybe not fully clear with the 
terminology.

Despite greylisting result, recipient restrictions still run

[martin f krafft]

Hello,

I am doing greylisting in smtpd_client_restrictions and later
a policy server check in smtpd_recipient_restrictions (postconf
included below). smtpd_delay_reject is on (the default).

The weird behaviour I am seeing is that despite a greylisting match
(4xx) in sender restrictions, the recipient restrictions are still
all being evaluated. In the logs, this looks as follows:

  postgrey[27226]: action=greylist, reason=new, client_name=unknown,
client_address=120.28.68.66, sender=reconnoitering...@bk.ru,
recipient=new-...@pobox.madduck.net
  postfwd2/policy[1002]: [RULES] rule=3, id=REJECT_HELO_NODNS,
client=unknown[120.28.68.66], sender=<reconnoitering...@bk.ru>,
recipient=<new-...@pobox.madduck.net>, helo=<[120.28.68.66]>,
proto=ESMTP, state=RCPT, delay=0.00s,
hits=SET_HELO;SET_NODNS;REJECT_HELO_NODNS, action=REJECT Blocked
- Suspicious HELO [[120.28.68.66]] and missing reverse DNS
[120.28.68.66]
  postfix/smtpd[14225]: NOQUEUE: reject: RCPT from
unknown[120.28.68.66]: 554 5.7.1 <new-...@pobox.madduck.net>:
Recipient address rejected: Blocked - Suspicious HELO
[[120.28.68.66]] and missing reverse DNS [120.28.68.66];
from=<reconnoitering...@bk.ru> to=<new-...@pobox.madduck.net>
proto=ESMTP helo=<[120.28.68.66]>

This comes as a surprise, especially since the SMTPD_ACCESS_README
says the following about the case when smtpd_delay_reject is on and
all lists are only processed after RCPT TO was sent:

  Restriction lists are still evaluated in the proper order of
  (client, helo, etrn) or (client, helo, sender, relay, recipient,
  data, or end-of-data) restrictions. When a restriction list
  (example: client) evaluates to REJECT or DEFER the restriction
  lists that follow (example: helo, sender, etc.) are skipped.

In my case, the postgrey check in the sender restrictions returns
DEFER, and the README leads me to assume that the recipient list
would be skipped. But it is not.

The end result (5xx) isn't so bad, but I'd still like to understand
what's going on.

Is this behaviour tunable? Or am I doing something wrong?

Thanks!
martin

postconf -n follows:

alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
body_checks = pcre:$config_directory/body_checks.pcre
broken_sasl_auth_clients = no
common_recipient_restrictions = reject_non_fqdn_recipient 
reject_unknown_recipient_domain reject_unlisted_recipient
common_sender_restrictions = reject_non_fqdn_sender 
reject_unknown_sender_domain check_sender_mx_access 
cidr:$config_directory/bogus_mx_addresses.cidr
common_submission_access = permit_mynetworks permit_sasl_authenticated 
permit_tls_clientcerts
config_directory = /etc/postfix
debug_peer_level = 1
defer_transports = hold
delay_warning_time = 3h
disable_vrfy_command = yes
header_checks = pcre:$config_directory/header_checks.pcre 
pcre:$config_directory/header_checks_antivirus.pcre
inet_interfaces = all
inet_protocols = all
mailbox_command_maps = hash:$config_directory/mailbox_command_maps.hash
mailbox_transport_maps = hash:$config_directory/mailbox_transport_maps.hash
mailman_destination_recipient_limit = 1
message_size_limit = 26214400
mydomain = madduck.net
mynetworks_style = host
postscreen_access_list = permit_mynetworks
postscreen_blacklist_action = ignore
postscreen_dnsbl_action = ignore
postscreen_greet_action = drop
proxy_read_maps = $canonical_maps $lmtp_generic_maps $local_recipient_maps 
$mydestination $mynetworks $recipient_bcc_maps $recipient_canonical_maps 
$relay_domains $relay_recipient_maps $relocated_maps $sender_bcc_maps 
$sender_canonical_maps $smtp_generic_maps $smtpd_sender_login_maps 
$transport_maps $virtual_alias_domains $virtual_alias_maps 
$virtual_mailbox_domains $virtual_mailbox_maps
prxysql = proxy:${sql}
recipient_delimiter = +
relay_clientcerts = hash:$config_directory/relay_ccerts.hash
relay_domains = hash:$config_directory/mailman_lists.hash
relocated_maps = ${prxysql}relocated_maps.pgsql
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_fingerprint_digest = sha1
smtp_tls_loglevel = 1
smtp_tls_policy_maps = hash:$config_directory/smtp_tls_policy.hash
smtp_tls_security_level = may
smtpd_client_restrictions = reject_unauth_pipelining check_recipient_access 
pcre:$config_directory/allow_admin_rcpts.pcre check_client_access 
pcre:$config_directory/greylist_dialups.pcre
smtpd_data_restrictions =
smtpd_end_of_data_restrictions =
smtpd_etrn_restrictions =
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_helo_hostname check_recipient_access 
pcre:$config_directory/allow_admin_rcpts.pcre check_helo_access 
pcre:$config_directory/reject_helo_myhostname.pcre
smtpd_milters = unix:/clamav/clamav-milter.ctl
smtpd_recipient_restrictions = common_recipient_restrictions 
check_recipient_access pcre:$config_directory/tarpits.pcre 
check_recipient_access pcre:$config_directory/allow_admin_rcpts.pcre 
check_policy_service inet

Re: Despite greylisting result, recipient restrictions still run

[Viktor Dukhovni]

On Fri, Nov 13, 2015 at 09:12:54PM +1300, martin f krafft wrote:

> I am doing greylisting in smtpd_client_restrictions and later
> a policy server check in smtpd_recipient_restrictions (postconf
> included below). smtpd_delay_reject is on (the default).

Greylisting typically generates a "defer_if_permit" verdict.

http://www.postfix.org/access.5.html

   DEFER_IF_PERMIT optional text...
  Defer the request if some later restriction would result in a an
  explicit   orimplicitPERMITaction. Replywith
  "$access_map_defer_code   4.7.1optional  text..."  when  the
  optional text is specified, otherwise reply with a generic error
  response message.

This is good, because it is silly to defer mail that will ultimately
be rejected.  With "defer_if_permit", processing goes on in the
"hope" that the mail may yet still be rejected by later restrictions.

> The weird behaviour I am seeing is that despite a greylisting match
> (4xx) in sender restrictions, the recipient restrictions are still
> all being evaluated. In the logs, this looks as follows:
> 
>   postgrey[27226]: action=greylist, reason=new, client_name=unknown,
> client_address=120.28.68.66, sender=reconnoitering...@bk.ru,
> recipient=new-...@pobox.madduck.net

Replies with "defer_if_permit".

>   postfwd2/policy[1002]: [RULES] rule=3, id=REJECT_HELO_NODNS,
> client=unknown[120.28.68.66], sender=<reconnoitering...@bk.ru>,
> recipient=<new-...@pobox.madduck.net>, helo=<[120.28.68.66]>,
> proto=ESMTP, state=RCPT, delay=0.00s,
> hits=SET_HELO;SET_NODNS;REJECT_HELO_NODNS, action=REJECT Blocked
> - Suspicious HELO [[120.28.68.66]] and missing reverse DNS
> [120.28.68.66]
>   postfix/smtpd[14225]: NOQUEUE: reject: RCPT from
> unknown[120.28.68.66]: 554 5.7.1 <new-...@pobox.madduck.net>:
> Recipient address rejected: Blocked - Suspicious HELO
> [[120.28.68.66]] and missing reverse DNS [120.28.68.66];
> from=<reconnoitering...@bk.ru> to=<new-...@pobox.madduck.net>
> proto=ESMTP helo=<[120.28.68.66]>

Excellent, the mail got rejected, rather than deferred.

> In my case, the postgrey check in the sender restrictions returns
> DEFER, and the README leads me to assume that the recipient list
> would be skipped. But it is not.

Does it in fact return "DEFER"?   My money is on "DEFER_IF_PERMIT".

-- 
Viktor.

Re: Despite greylisting result, recipient restrictions still run

[Viktor Dukhovni]

On Sat, Nov 14, 2015 at 08:03:41AM +1300, martin f krafft wrote:

> > >   postgrey[27226]: action=greylist, reason=new, client_name=unknown,
> > > client_address=120.28.68.66, sender=reconnoitering...@bk.ru,
> > > recipient=new-...@pobox.madduck.net
> > 
> > Replies with "defer_if_permit".
> 
> Could you discern this from the message or did you just know that
> postgrey does this by default and assumed I didn't change that?

The log message is clearly not explicit about the low-level details
and just says "greylist".

-- 
Viktor.

Re: Despite greylisting result, recipient restrictions still run

[martin f krafft]

also sprach Viktor Dukhovni <postfix-us...@dukhovni.org> [2015-11-14 05:43 
+1300]:
> > I am doing greylisting in smtpd_client_restrictions and later
> > a policy server check in smtpd_recipient_restrictions (postconf
> > included below). smtpd_delay_reject is on (the default).
> 
> Greylisting typically generates a "defer_if_permit" verdict.

You are absolutely correct: postgrey returns DEFER_IF_PERMIT by
default. I was looking in the wrong place(s) and didn't consider
that the protocol between postfix and postgrey was more than just
black'n'white.

> >   postgrey[27226]: action=greylist, reason=new, client_name=unknown,
> > client_address=120.28.68.66, sender=reconnoitering...@bk.ru,
> > recipient=new-...@pobox.madduck.net
> 
> Replies with "defer_if_permit".

Could you discern this from the message or did you just know that
postgrey does this by default and assumed I didn't change that?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"everyone smiles as you drift past the flower
 that grows so incredibly high."
-- the beatles
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Conditional Greylisting

[Alex JOST]

Am 19.09.2015 um 00:57 schrieb Bruce Marriner:


On Friday, September 18, 2015 04:59 PM CDT, "Bill Cole" 
<postfixlists-070...@billmail.scconsult.com> wrote:


On 18 Sep 2015, at 14:29, Bruce Marriner wrote:


So I want to be able to set up Postfix so, if it passes DKIM or other
checks that give me a high confidence then just skip the postgrey
stuff
entirely.


In what exactly does a valid DKIM signature give you high confidence? I
suspect that this is misplaced...

All a DKIM signature validation tells you is that a message was in fact
signed at the mail system where it claimed to have been signed by an
entity in control of the DNS for the domain identified the signature and
that none of the message fields specified in the DKIM header have been
changed in transit. Looking at the spam that has made it through my
filters this year, I see that 27% of those messages had a valid DKIM
signature, because in fact any spammer who can open a Yahoo account or
register a domain can send mail with a valid DKIM signature.



Ah, well.  I think you might be right about misplaced.  I've been reading about 
this all day learning it and I've started to realize the same thing.  I would 
like

Now, why can't all the spammers just add a ThisIsSpam header.  Sure would make 
my life easier :)

I'd still like to reduce my dependency on postgrey.  So, if has valid SPF, valid 
DKIM, has a low SpamAssassin score,  then I 
could skip it without raising spam too much, or at all :).

Postgrey just works so well :) I mean, if I have that on I get almost no spam.  
But sometimes somethings that should come though don't and many things are 
delayed.  When I turn it off, I get tons of spam.

So, I need to start adding more stuff into the mix like SpanAssassin, SPF, 
DKIM, whatever so I can reduce my Postgrey dependency a little.

My first few google searches were covered in the DKIM/SPF stuff so I guess  
that's where I've started first.



We are using Postfwd[1] to conditionally use Greylisting when the sender 
seems suspicious. There is already a good example configuration for 
"Selective greylisting".


[1] http://postfwd.org/

--
Alex JOST

Re: Conditional Greylisting

[lst_hoe02]

Zitat von Bruce Marriner <br...@bmts.us>:

On Friday, September 18, 2015 04:59 PM CDT, "Bill Cole"  
<postfixlists-070...@billmail.scconsult.com> wrote:



On 18 Sep 2015, at 14:29, Bruce Marriner wrote:

> So I want to be able to set up Postfix so, if it passes DKIM or other
> checks that give me a high confidence then just skip the postgrey
> stuff
> entirely.

In what exactly does a valid DKIM signature give you high confidence? I
suspect that this is misplaced...

All a DKIM signature validation tells you is that a message was in fact
signed at the mail system where it claimed to have been signed by an
entity in control of the DNS for the domain identified the signature and
that none of the message fields specified in the DKIM header have been
changed in transit. Looking at the spam that has made it through my
filters this year, I see that 27% of those messages had a valid DKIM
signature, because in fact any spammer who can open a Yahoo account or
register a domain can send mail with a valid DKIM signature.



Ah, well.  I think you might be right about misplaced.  I've been  
reading about this all day learning it and I've started to realize  
the same thing.  I would like


Now, why can't all the spammers just add a ThisIsSpam header.  Sure  
would make my life easier :)


I'd still like to reduce my dependency on postgrey.  So, if has  
valid SPF, valid DKIM, has a low SpamAssassin score, possible test heres> then I could skip it without raising spam too  
much, or at all :).


Postgrey just works so well :) I mean, if I have that on I get  
almost no spam.  But sometimes somethings that should come though  
don't and many things are delayed.  When I turn it off, I get tons  
of spam.


Use the auto-whitelist feature from Postgrey in a reasonable way. The  
defaults for this feature are only useful for high traffic sites IMHO.
Use a longer greylisting time and whitelist after first pass with a  
veeerrryy long expire time for whitelisted clients.


Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Conditional Greylisting

[Sebastian Nielsen]

I think he is out after doing a temporary fail after the DATA stage, thus 
avoiding the chicken and egg problem.


-Ursprungligt meddelande- 
From: Wietse Venema

Sent: Friday, September 18, 2015 7:50 PM
To: Postfix users
Subject: Re: Conditional Greylisting

Bruce Marriner:

I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
to completely bypass greylisting.  However, if it soft-fails those
checks then I want it to greylist next.


You have a chicken and egg problem. DKIM signature verification
requires that Postfix receives the email message.  Greylisting
happens BEFORE Postfix receives the email message.

Wietse 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Conditional Greylisting

[Bruce Marriner]

On Friday, September 18, 2015 01:41 PM CDT, wie...@porcupine.org (Wietse 
Venema) wrote:

> Since DKIM requires content inspection and you want decisions before
> Postfix replies to end-of-data, another option is to use the
> smtpd_proxy_filter or smtpd_milters feature (both as before-queue
> content filters) and to let the filter tempfail the message depending
> on DKIM/greylist results.
>
> http://www.postfix.org/SMTPD_PROXY_README.html
> http://www.postfix.org/MILTER_README.html
>
>   Wietse


Oh, thanks I'll read about those more too.  The guide I followed to setup 
opendkim actually did have me set it up using the smtpd_milters setting.  I'll 
have to read up on how to.. tempfail :)

Re: Conditional Greylisting

[Bruce Marriner]

I have (well had, technically) all of these running under the
smtpd_recipient_restrictions with check_policy_service statements.



On Fri, 2015-09-18 at 19:56 +0200, Sebastian Nielsen wrote:
> I think he is out after doing a temporary fail after the DATA stage, thus 
> avoiding the chicken and egg problem.
> 
> -Ursprungligt meddelande- 
> From: Wietse Venema
> Sent: Friday, September 18, 2015 7:50 PM
> To: Postfix users
> Subject: Re: Conditional Greylisting
> 
> Bruce Marriner:
> > I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
> > to completely bypass greylisting.  However, if it soft-fails those
> > checks then I want it to greylist next.
> 
> You have a chicken and egg problem. DKIM signature verification
> requires that Postfix receives the email message.  Greylisting
> happens BEFORE Postfix receives the email message.
> 
> Wietse 
> 

Re: Conditional Greylisting

[Wietse Venema]

Bruce Marriner:
> Thanks, I'll read about that tool.  I'm pretty new to DKIM/SPF and am
> just now trying to set it up.  I've been using postgrey for awhile and

Since DKIM requires content inspection and you want decisions before
Postfix replies to end-of-data, another option is to use the
smtpd_proxy_filter or smtpd_milters feature (both as before-queue
content filters) and to let the filter tempfail the message depending
on DKIM/greylist results.

http://www.postfix.org/SMTPD_PROXY_README.html
http://www.postfix.org/MILTER_README.html

Wietse

Re: Conditional Greylisting

[Wietse Venema]

Bruce Marriner:
> I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
> to completely bypass greylisting.  However, if it soft-fails those
> checks then I want it to greylist next.

You have a chicken and egg problem. DKIM signature verification
requires that Postfix receives the email message.  Greylisting
happens BEFORE Postfix receives the email message.

Wietse

Re: Conditional Greylisting

[Benning, Markus]

I'm also using a policy daemon to build a score based on Whitelists, 
SPF, RBLs, GeoIP, etc.

And then apply greylisting, rejects based on the score.
(as in mtpolicyd example configuration: 
https://github.com/benningm/mtpolicyd/blob/master/etc/mtpolicyd.conf)


But you can't do content checks in a recipient_restriction.
DKIM is based on message content.


 Markus

Am 2015-09-18 20:09, schrieb Bruce Marriner:

I have (well had, technically) all of these running under the
smtpd_recipient_restrictions with check_policy_service statements.

On Fri, 2015-09-18 at 19:56 +0200, Sebastian Nielsen wrote:
I think he is out after doing a temporary fail after the DATA stage, 
thus

avoiding the chicken and egg problem.

-Ursprungligt meddelande-
From: Wietse Venema
Sent: Friday, September 18, 2015 7:50 PM
To: Postfix users
Subject: Re: Conditional Greylisting

Bruce Marriner:
> I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
> to completely bypass greylisting.  However, if it soft-fails those
> checks then I want it to greylist next.

You have a chicken and egg problem. DKIM signature verification
requires that Postfix receives the email message.  Greylisting
happens BEFORE Postfix receives the email message.

Wietse



--
https://markusbenning.de/

Re: Conditional Greylisting

[Bruce Marriner]

Thanks, I'll read about that tool.  I'm pretty new to DKIM/SPF and am
just now trying to set it up.  I've been using postgrey for awhile and
it does work great but it creates a lot of lag and causes problems (lost
e-mail) with a lot of email senders. 

So I want to be able to set up Postfix so, if it passes DKIM or other
checks that give me a high confidence then just skip the postgrey stuff
entirely.  

But, if it's a "Not sure" e-mail, then go ahead and postgrey it.

I'll read about mtpolicyd and see if I can understand what my options
with that would be.


On Fri, 2015-09-18 at 20:20 +0200, Benning, Markus wrote:
> I'm also using a policy daemon to build a score based on Whitelists, 
> SPF, RBLs, GeoIP, etc.
> And then apply greylisting, rejects based on the score.
> (as in mtpolicyd example configuration: 
> https://github.com/benningm/mtpolicyd/blob/master/etc/mtpolicyd.conf)
> 
> But you can't do content checks in a recipient_restriction.
> DKIM is based on message content.
> 
> 
>   Markus
> 
> Am 2015-09-18 20:09, schrieb Bruce Marriner:
> > I have (well had, technically) all of these running under the
> > smtpd_recipient_restrictions with check_policy_service statements.
> > 
> > On Fri, 2015-09-18 at 19:56 +0200, Sebastian Nielsen wrote:
> >> I think he is out after doing a temporary fail after the DATA stage, 
> >> thus
> >> avoiding the chicken and egg problem.
> >> 
> >> -Ursprungligt meddelande-
> >> From: Wietse Venema
> >> Sent: Friday, September 18, 2015 7:50 PM
> >> To: Postfix users
> >> Subject: Re: Conditional Greylisting
> >> 
> >> Bruce Marriner:
> >> > I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
> >> > to completely bypass greylisting.  However, if it soft-fails those
> >> > checks then I want it to greylist next.
> >> 
> >> You have a chicken and egg problem. DKIM signature verification
> >> requires that Postfix receives the email message.  Greylisting
> >> happens BEFORE Postfix receives the email message.
> >> 
> >> Wietse
> >> 
> 

Re: Conditional Greylisting

[Bill Cole]

On 18 Sep 2015, at 14:29, Bruce Marriner wrote:


So I want to be able to set up Postfix so, if it passes DKIM or other
checks that give me a high confidence then just skip the postgrey 
stuff

entirely.


In what exactly does a valid DKIM signature give you high confidence? I 
suspect that this is misplaced...


All a DKIM signature validation tells you is that a message was in fact 
signed at the mail system where it claimed to have been signed by an 
entity in control of the DNS for the domain identified the signature and 
that none of the message fields specified in the DKIM header have been 
changed in transit. Looking at the spam that has made it through my 
filters this year, I see that 27% of those messages had a valid DKIM 
signature, because in fact any spammer who can open a Yahoo account or 
register a domain can send mail with a valid DKIM signature.

Re: Conditional Greylisting

[Bruce Marriner]

On Friday, September 18, 2015 04:59 PM CDT, "Bill Cole" 
 wrote:

> On 18 Sep 2015, at 14:29, Bruce Marriner wrote:
>
> > So I want to be able to set up Postfix so, if it passes DKIM or other
> > checks that give me a high confidence then just skip the postgrey 
> > stuff
> > entirely.
>
> In what exactly does a valid DKIM signature give you high confidence? I
> suspect that this is misplaced...
>
> All a DKIM signature validation tells you is that a message was in fact
> signed at the mail system where it claimed to have been signed by an 
> entity in control of the DNS for the domain identified the signature and
> that none of the message fields specified in the DKIM header have been
> changed in transit. Looking at the spam that has made it through my 
> filters this year, I see that 27% of those messages had a valid DKIM 
> signature, because in fact any spammer who can open a Yahoo account or
> register a domain can send mail with a valid DKIM signature.


Ah, well.  I think you might be right about misplaced.  I've been reading about 
this all day learning it and I've started to realize the same thing.  I would 
like

Now, why can't all the spammers just add a ThisIsSpam header.  Sure would make 
my life easier :)

I'd still like to reduce my dependency on postgrey.  So, if has valid SPF, 
valid DKIM, has a low SpamAssassin score,  
then I could skip it without raising spam too much, or at all :).

Postgrey just works so well :) I mean, if I have that on I get almost no spam.  
But sometimes somethings that should come though don't and many things are 
delayed.  When I turn it off, I get tons of spam.

So, I need to start adding more stuff into the mix like SpanAssassin, SPF, 
DKIM, whatever so I can reduce my Postgrey dependency a little.

My first few google searches were covered in the DKIM/SPF stuff so I guess  
that's where I've started first.

Conditional Greylisting

[Bruce Marriner]

Is it possible to configure Postfix so that greylisting only happens
under specific conditions?

I'd like to have DKIM/SPF setup and if an e-mail passed those I want to
to completely bypass greylisting.  However, if it soft-fails those
checks then I want it to greylist next.

I have all of the above things working already - just not the
conditional greylisting.  I'd love some help accomplishing this!

Thank you very much!

Greylisting with reject_unverified_sender negative cache

[Mick]

Good morning,


I have found 'reject_unverified_sender' superb at reducing the number of 
SPAM messages getting though.  I've set up a whitelist for those few 
trusted senders or domains where their dopey mail servers' don't comply. 
I do have a minor problem with mail servers that do comply, but apply 
greylisting.


Originally I omitted 'address_verify_negative_cache =no' from main.cf. 
This defaults to 'yes' and sender verification failures were cached 
saving a constantly chattering probe relay. Unfortunately it would 
appear that this method also caches temporary errors too (those also 
being a fail), so when I receive a 471 as part of a greylisting policy, 
that message won't be delivered.  Postfix will reject when remote server 
re-attempts to deliver relying on its cache from the first attempt 
rather than sending another dummy message. I have now set the negative 
cache to 'no'  meaning a retry for every incoming message that hasn't 
passed address verification. It is either that or adding all domain that 
use greylisting to the whitelist.


Does anyone know if there's a way to exempt / prevent 471 (or other 
temporary reject codes) from being cached?



Thanks,

Mick.

Re: Greylisting with reject_unverified_sender negative cache

[Noel Jones]

On 6/11/2015 5:49 AM, Mick wrote:
 Good morning,
 
 
 I have found 'reject_unverified_sender' superb at reducing the
 number of SPAM messages getting though.  I've set up a whitelist for
 those few trusted senders or domains where their dopey mail servers'
 don't comply. I do have a minor problem with mail servers that do
 comply, but apply greylisting.
 
 Originally I omitted 'address_verify_negative_cache =no' from
 main.cf. This defaults to 'yes' and sender verification failures
 were cached saving a constantly chattering probe relay.
 Unfortunately it would appear that this method also caches temporary
 errors too (those also being a fail), so when I receive a 471 as
 part of a greylisting policy, that message won't be delivered. 
 Postfix will reject when remote server re-attempts to deliver
 relying on its cache from the first attempt rather than sending
 another dummy message. I have now set the negative cache to 'no' 
 meaning a retry for every incoming message that hasn't passed
 address verification. It is either that or adding all domain that
 use greylisting to the whitelist.
 
 Does anyone know if there's a way to exempt / prevent 471 (or other
 temporary reject codes) from being cached?
 

The best solution is to not attempt to verify external senders.
Many sites will consider this abuse and blacklist you.




  -- Noel Jones

Re: Greylisting with reject_unverified_sender negative cache

[Mick]

Noel Jones wrote:


Does anyone know if there's a way to exempt / prevent 471 (or other
temporary reject codes) from being cached?




The best solution is to not attempt to verify external senders.
Many sites will consider this abuse and blacklist you.

  

Thanks for your comment Noel. I will bear that in mind.


Mick.

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[Benny Pedersen]

On 28. jan. 2015 23.33.45 lst_ho...@kwsoft.de wrote:


 block spam with Spamassassin
 block viruses with ClamAV
 greylist mail from freemail domains with one policy
 greylist mail from certain countries with another policy

Don't do this. Greylisting should not be used to punish real MTAs. Use
Greylisting with automatic whitelist so only the Spam-Bots get cut
away and let already know MTAs pass by. Works exceptionally well here,
the Bots go away after 2-3 tries and 90% of the sending MTAs are on
the whitelist after some time.


mtpolicyd can call greylist when ip is on dnsbl or simply not on dnswl, ips 
that is on dnswl will not be greylisted so, readding docs in mtpolicyd 
seems to show it can self do the greylist part, but i have not yet seem it 
works, but it can use another policy server called from mtpolicyd


else try sqlgrey where its possible to have more fine grayned configs pr ip 
/ hostname / what ever :)

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[lst_hoe02]

Zitat von srach hndls...@tutanota.de:


I have read the documents for some different Greylisting opportunities for
Postfix

This built into Postfix

http://www.postfix.org/SMTPD_POLICY_README.html#greylist

and popular ones

http://wiki.policyd.org
http://postgrey.schweikert.ch

I am not finding a modern comparison of these and a decision point for
choosing one to use best in the latest Postfix versions.  Many online
postings have a comment but they are most for older versions of Postfix.

I wonder if Postfix with modern versions is integrating better ideas and to
do it all in one?  I think maybe that the choice is not just the recommended
built in one of Postifx?  It depends on the goals?

My interested goals are to

block spam with Spamassassin
block viruses with ClamAV
greylist mail from freemail domains with one policy
greylist mail from certain countries with another policy


Don't do this. Greylisting should not be used to punish real MTAs. Use  
Greylisting with automatic whitelist so only the Spam-Bots get cut  
away and let already know MTAs pass by. Works exceptionally well here,  
the Bots go away after 2-3 tries and 90% of the sending MTAs are on  
the whitelist after some time.


Regards

Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[srach]

I have read the documents for some different Greylisting opportunities for 
Postfix

This built into Postfix

http://www.postfix.org/SMTPD_POLICY_README.html#greylist

and popular ones

http://wiki.policyd.org
http://postgrey.schweikert.ch

I am not finding a modern comparison of these and a decision point for 
choosing one to use best in the latest Postfix versions.  Many online 
postings have a comment but they are most for older versions of Postfix.

I wonder if Postfix with modern versions is integrating better ideas and to 
do it all in one?  I think maybe that the choice is not just the recommended 
built in one of Postifx?  It depends on the goals?

My interested goals are to

block spam with Spamassassin
block viruses with ClamAV
greylist mail from freemail domains with one policy
greylist mail from certain countries with another policy
not use Amavis, it is too confusing for me

My use will be usually less than 1 mails per day.

What do the experts here do for these policies when all together?
There are many choices I know, with so much information.  It is like 
drinking from a firehose !  I enjoy though the option to learn and build 
each piece - it is a better road to sucess.

Thanks for your good advice and experience!

*S*

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[li...@rhsoft.net]

Am 28.01.2015 um 19:38 schrieb srach:

I have read the documents for some different Greylisting opportunities
for Postfix

This built into Postfix

http://www.postfix.org/SMTPD_POLICY_README.html#greylist

and popular ones

http://wiki.policyd.org
http://postgrey.schweikert.ch

I am not finding a modern comparison of these and a decision point for
choosing one to use best in the latest Postfix versions.  Many online
postings have a comment but they are most for older versions of Postfix.

I wonder if Postfix with modern versions is integrating better ideas and
to do it all in one?  I think maybe that the choice is not just the
recommended built in one of Postifx?  It depends on the goals?


besides that greylisting is harmful in case of large sending clusters 
not returning with the same IP while re-try a deferred message 
postscreen can do this more or less as side effect with deep protool tests


postscreen_greet_action  = enforce
postscreen_bare_newline_enable   = no
postscreen_bare_newline_action   = enforce
postscreen_pipelining_enable = no
postscreen_pipelining_action = enforce
postscreen_non_smtp_command_enable   = no
postscreen_non_smtp_command_action   = enforce

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[li...@rhsoft.net]

Am 28.01.2015 um 20:21 schrieb srach:

28. Jan 2015 19:17 by wie...@porcupine.org mailto:wie...@porcupine.org:

There are good reasons to NOT integrate, and instead use the
least-expensive solution before the most-expensive solution.

postscreen implements a least-expensive solution that eliminates
most of the spambots without even allowing them to talk to a Postfix
SMTP server process.

Spamassassin and Clamav are most-expensive solutions that should
be used only for mail that cannot be stopped via other means.


Okay I see that.  Don not spend your money unless you have to!

So if that is done using Postscreen for some greylisting what option in
Postscreen for only greylisting with the depp protocl tests for some
domains is there? I am looking but still see no maps for it


*none* - read my previous mail and look how most junk is killed long, 
long, long before any chance to deliver and so you have *no reason* for 
do yourself the burden of slow down legit delivery for no benefit

Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[srach]

28. Jan 2015 18:43 by li...@rhsoft.net:


 besides that greylisting is harmful in case of large sending clusters not 
 returning with the same IP while re-try a deferred message postscreen can 
 do this more or less as side effect with deep protool tests





Yes I see that opportunity in Postscreen.




I do understand the warning for the large clusters.  Then I have to be 
careful for choosing domains I know.  For some I care , but for some I do 
not.




But I do not see how to apply Postscreen maps for deep protocol tests only 
for some domains  countries.   Does it do this?





And if there will be more checking with the Spamassassin and Clamav too I 
think there is good value in all in one policy integration instead of some in 
Postscreen too.   I think that is making some sense?











*S*

Re: Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[Wietse Venema]

srach:
 And if there will be more checking with the Spamassassin and Clamav too I 
 think there is good value in all in one policy integration instead of some in 
 Postscreen too.

There are good reasons to NOT integrate, and instead use the
least-expensive solution before the most-expensive solution.

postscreen implements a least-expensive solution that eliminates
most of the spambots without even allowing them to talk to a Postfix
SMTP server process.

Spamassassin and Clamav are most-expensive solutions that should
be used only for mail that cannot be stopped via other means.

Wietse

Re: Using greylisting and other policies all in one. Use built in Postifx policy functions or other popular ones?

[li...@rhsoft.net]

Am 28.01.2015 um 20:08 schrieb srach:

28. Jan 2015 18:43 by li...@rhsoft.net mailto:li...@rhsoft.net:

besides that greylisting is harmful in case of large sending
clusters not returning with the same IP while re-try a deferred
message postscreen can do this more or less as side effect with deep
protool tests

Yes I see that opportunity in Postscreen.

I do understand the warning for the large clusters.  Then I have to be
careful for choosing domains I know.  For some I care , but for some I
do not.


honestly with postscreen *without deep protocol tests) and rbl-scoring 
(DSNBL as well as DNSWL) there is no point for greylisting at all


postscreen_dnsbl_ttl = 5m
postscreen_dnsbl_threshold = 8
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_sites =
 b.barracudacentral.org=127.0.0.2*7
 dnsbl.inps.de=127.0.0.2*7
 bl.mailspike.net=127.0.0.2*5
 bl.mailspike.net=127.0.0.[10;11;12]*4
 dnsbl.sorbs.net=127.0.0.10*8
 dnsbl.sorbs.net=127.0.0.5*6
 dnsbl.sorbs.net=127.0.0.7*3
 dnsbl.sorbs.net=127.0.0.8*2
 dnsbl.sorbs.net=127.0.0.6*2
 dnsbl.sorbs.net=127.0.0.9*2
 zen.spamhaus.org=127.0.0.[10;11]*8
 zen.spamhaus.org=127.0.0.[4..7]*6
 zen.spamhaus.org=127.0.0.3*4
 zen.spamhaus.org=127.0.0.2*3
 hostkarma.junkemailfilter.com=127.0.0.2*3
 hostkarma.junkemailfilter.com=127.0.0.4*1
 hostkarma.junkemailfilter.com=127.0.1.2*1
 wl.mailspike.net=127.0.0.[18;19;20]*-2
 list.dnswl.org=127.0.[0..255].0*-2
 list.dnswl.org=127.0.[0..255].1*-3
 list.dnswl.org=127.0.[0..255].2*-4
 list.dnswl.org=127.0.[0..255].3*-5
 hostkarma.junkemailfilter.com=127.0.0.1*-2
_

if you additionally configure a honeypot-backup-MX always responding 
with 450 if not already blacklisted around 50% of all bots will try the 
backup MX and never come back to the primary and they ones coming back 
are waiting some minutes by assuming greylisting and in the meantime 
many are on RBL's which where not at the first contact


postscreen_whitelist_interfaces = !ip-of-backup-mx, static:all


But I do not see how to apply Postscreen maps for deep protocol tests
only for some domains  countries.   Does it do this?


it can't by design, if it would have such capapbilities it would no 
longer be a lightweight daemon in front of spmtpd



And if there will be more checking with the Spamassassin and Clamav too
I think there is good value in all in one policy integration instead of
some in Postscreen too. I think that is making some sense?


that makes *zero* sense

postscreen kills 90% of all junk long before it connects to a expensive 
smtpd at all, independent of contentfilters that's much more value then 
pass every connection to limited smtpd and to harm with misconcepts like 
greylisting