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

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.

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

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

[ot] Zen and the art of spam abatement (was: Re: greylisting generates error email?)

[/dev/rob0]

Whilst this subject is of some interest to many or most Postfix 
users, it has departed from being fully on topic here. It would fit 
better on a list like SDLU: 

[Disclaimer: I am a list moderator at SDLU.)

On Sat, Aug 17, 2013 at 10:39:25AM -0700, Grant wrote:
> > [attribution of quotes reconstructed]
rob0:
> > On Sat, Aug 17, 2013 at 12:54:44AM -0700, Grant wrote:
> >> Do you mean there aren't any legitimate servers listed in
> >> zen.spamhaus.org?
> >
> > Zen is a composite list, and indeed it is intended to be safe
> > for widespread use.
> >
> > SBL (Spamhaus Block List) lists IP addresses which are known
> > to be under the control of spammers.
> >
> > XBL (Exploits Block List) lists IP addresses which are actively 
> > spewing bot spam. Legitimate servers are occasionally listed in 
> > XBL, because they meet that condition. Some short time after they 
> > stop their abuse, they are delisted. Typically this is less than 
> > a day.
> >
> > PBL (Policy Block List) lists IP addresses which, according to 
> > the netblock owners, should not normally be sending legitimate 
> > email. Exceptions can be made for hosts with custom PTR upon 
> > request. Many colocation providers submit their networks for PBL, 
> > but removal is easy.
> >
> >> When I switched servers a while back, the new IP
> >> I received was listed on several blacklists and it was a hassle
> >> to get them removed.
> >
> > Far better that you go through that step than the Internet be 
> > exposed to more spam.
> 
> I agree, but the fact is that not everyone will go through that 
> step.

You didn't understand. Those who do NOT get delisted from Zen *will* 
face widespread delivery problems. No hard facts exist (nor could 
valid statistics be collected), and it would vary by that site's 
chosen set of sites they wish to send mail to, but in general I bet 
they're going to have delivery problems for >75% of their mail.

This is speaking from my own experience when moving a server to a 
PBL-listed IP address. Before getting the removal approved, my logs 
were clogged with rejections. It was embarrassing. When I discovered 
the problem I rerouted mail through a nonlisted relayhost until 
delisted.

I have also seen this at exploited sites where I have been called in 
to do the cleanup.

Let them be lazy. If they want to participate in Internet mail, 
they're going to take the time to get removed from PBL.

None of the anti-DNSBL zealots can dispute this fact. In fact, this 
is one of the things they so despise about Spamhaus: they have been 
granted "too much power" by many email administrators, large and 
small.

(I apologise to the "anti-DNSBL zealots" for the name calling. I'm a 
pro-DNSBL and pro-Spamhaus zealot myself. I accept the same label. 
Spamhaus and other DNSBL services have all but eliminated my spam 
problem. I am grateful for that.)

Why have we (TINW) given Spamhaus this power? Do they abuse it? What 
would happen if they did?

Mail administrators support Spamhaus because they have been careful 
and responsible in the exercise of that power. They make our job in 
trying to keep the abuse out of users' mailboxes much easier. Also, 
pre-DATA filtering is safer and more accurate than content-based 
approaches.

There have indeed been suggestions of abuse of power by Spamhaus. 
Many of these suggestions were put forth by spammers and spam
supporters (providers who are willing to sell service to spammers, 
turning a blind eye or making excuses in response to abuse reports.)

I'd say those constitute the majority of complaints, in fact. But to 
be fair, there are other complaints. One I am aware of is the 
Austrian national NIC (dot-AT registry.) Austrian law is demonstrably 
spam-friendly regarding domain registrations.

(I don't care about Austrian law. To a large extent I don't even care 
about laws where I live and where my server is situated. Spam is 
crime, and such crime is not excused by ignorant laws. Any valid law 
which is going to require me to accept and handle spam will also 
reimburse my costs in doing so. None of them do. So I block spam, 
including some CAN-SPAM compliant hosts on my US-based server. The 
You-Can-Spam law doesn't pay to accept spam.)

To answer my final question above, if Spamhaus went overboard and 
became like a SORBS, blocking mail providers who have occasional 
issues with spam, well, I'd relegate them to the same status I did 
SORBS. I consider SORBS' opinion on a client useful, but not enough 
to consider the mail to be spam and worthy of blocking.

I am sure that Spamhaus administrators know this. Thus they are 
careful and responsible.

> > Here's my example postscreen configuration which is intended
> > to be safe and reasonable for most uses:
> > http://rob0.nodns4.us/postscreen.html
> 
> Do you use that config on a commercial mail server?  I don't mean 
> to say that you shouldn't, I'm just wondering if you do.  In a 

Not much. The majority of t

Re: greylisting generates error email?

[Stan Hoeppner]

On 8/20/2013 3:06 AM, Grant wrote:

> Has anyone had a confirmed false positive with zen.spamhaus.org ?

http://lmgtfy.com/?q=spamhaus+false+positive

-- 
Stan

Re: greylisting generates error email?

[Jose Borges Ferreira]

On Aug 20, 2013 8:03 AM, "Erwan David"  wrote:
>
> On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme  said:
> .
> >
> > 
> >
> > zen blocks these categories:
> >
> > SBL Direct UBE sources, spam operations & spam services
> > CSS Direct snowshoe spam sources detected via automation
> > CBL (3rd party exploits such as proxies, trojans, etc.)
> > PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
> >
> > SBL and CSS are confirmed spammers. CBL are confirmed exploited
machines. PBL are IPs that the IP owner has classified as not allowed to
send mail directly.
> >
> > Blocking all of those is perfectly safe.
>
> Perfectly safe is the categorizing process is itself perfect.
> ANd since nothing is perfect, you'll always have false positive.

+1

Re: greylisting generates error email?

[Grant]

>> 
>>
>> zen blocks these categories:
>>
>> SBL Direct UBE sources, spam operations & spam services
>> CSS Direct snowshoe spam sources detected via automation
>> CBL (3rd party exploits such as proxies, trojans, etc.)
>> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
>>
>> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. 
>> PBL are IPs that the IP owner has classified as not allowed to send mail 
>> directly.
>>
>> Blocking all of those is perfectly safe.
>
> Perfectly safe is the categorizing process is itself perfect.
> ANd since nothing is perfect, you'll always have false positive.

Has anyone had a confirmed false positive with zen.spamhaus.org ?

- Grant

Re: greylisting generates error email?

[Erwan David]

On Tue, Aug 20, 2013 at 05:58:44AM CEST, LuKreme  said:
.
> 
> 
> 
> zen blocks these categories:
> 
> SBL Direct UBE sources, spam operations & spam services
> CSS Direct snowshoe spam sources detected via automation
> CBL (3rd party exploits such as proxies, trojans, etc.)
> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
> 
> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL 
> are IPs that the IP owner has classified as not allowed to send mail directly.
> 
> Blocking all of those is perfectly safe.

Perfectly safe is the categorizing process is itself perfect.
ANd since nothing is perfect, you'll always have false positive.

Re: greylisting generates error email?

[Grant]

> zen is, for all practical purposes, perfect. You will not get false positives 
> as everyone in zen is either a confirmed spammer or in the PBL (policy block 
> list). That is to say, no one in zen should be connecting to your mailserver 
> to send mail, ever.
>
> 
>
> zen blocks these categories:
>
> SBL Direct UBE sources, spam operations & spam services
> CSS Direct snowshoe spam sources detected via automation
> CBL (3rd party exploits such as proxies, trojans, etc.)
> PBL End-user Non-MTA IP addresses set by ISP outbound mail policy
>
> SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL 
> are IPs that the IP owner has classified as not allowed to send mail directly.
>
> Blocking all of those is perfectly safe.

Would anyone agree/disagree with this?  If there is a consensus that
this is true, I will add zen.spamhaus.org to postscreen_dnsbl_sites.

- Grant

Re: greylisting generates error email?

[LuKreme]

On 16 Aug 2013, at 07:13 , Grant  wrote:

 Use a dns white list with a negative score in the
 postscreen_dnsbl_sites, and set a negative value for
 postscreen_dnsbl_whitelist_threshold.  Simple example:
 # main.cf
 postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
 postscreen_dnsbl_whitelist_threshold = -1
>>> 
>>> I've added the following to main.cf:
>>> 
>>> postscreen_dnsbl_sites = list.dnswl.org*-1
>>> postscreen_dnsbl_whitelist_threshold = -1
>>> 
>>> Thank you for your help!
>> 
>> Yes, that should whitelist known good sites from deep inspection,
>> certainly all the big mailers such as google, yahoo, comcast, etc.
>> 
>> However, I wonder why you don't have any dns blacklists such as
>> zen.spamhaus.org defined there.  The ability of postscreen to reject
>> known bad sites without using precious smtpd processes is one of its
>> key features.
> 
> I would just rather have a false negative than a false positive.  I
> get a pretty small amount of spam at this point so I don't think
> reducing it further is worth increasing the chances of a false
> positive.

zen is, for all practical purposes, perfect. You will not get false positives 
as everyone in zen is either a confirmed spammer or in the PBL (policy block 
list). That is to say, no one in zen should be connecting to your mailserver to 
send mail, ever.



zen blocks these categories:

SBL Direct UBE sources, spam operations & spam services
CSS Direct snowshoe spam sources detected via automation
CBL (3rd party exploits such as proxies, trojans, etc.)
PBL End-user Non-MTA IP addresses set by ISP outbound mail policy

SBL and CSS are confirmed spammers. CBL are confirmed exploited machines. PBL 
are IPs that the IP owner has classified as not allowed to send mail directly.

Blocking all of those is perfectly safe.

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

Re: greylisting generates error email?

[Grant]

>> Do you use that config on a commercial mail server?  I don't mean to
>> say that you shouldn't, I'm just wondering if you do.  In a commercial
>> environment, the penalty for a false positive is a customer unable to
>> reach the company behind the server which just isn't tolerable
>
> there is *no way* to have never ever false positivies
>
> and without spam protection someone deletes your message
> within the 500 spam mails each day as collateral damagae
>
> in case of a false positive: the sender get a bounce from his mailserver
> in case of deleted: it was silently dropped
>
> chosse one.

I think what happened is the postscreen deep protocol checks did such
an excellent job of reducing spam on their own that I figured the
increased chance of rejecting legitimate mail by using one or more IP
lists wasn't worth dropping the small amount of remaining spam.

- Grant

Re: greylisting generates error email?

[li...@rhsoft.net]

Am 17.08.2013 19:39, schrieb Grant:
> Do you use that config on a commercial mail server?  I don't mean to
> say that you shouldn't, I'm just wondering if you do.  In a commercial
> environment, the penalty for a false positive is a customer unable to
> reach the company behind the server which just isn't tolerable

there is *no way* to have never ever false positivies

and without spam protection someone deletes your message
within the 500 spam mails each day as collateral damagae

in case of a false positive: the sender get a bounce from his mailserver
in case of deleted: it was silently dropped

chosse one.

Re: greylisting generates error email?

[Grant]

> [attribution of quotes reconstructed]
> On Sat, Aug 17, 2013 at 12:54:44AM -0700, Grant wrote:
> Noel:
>> > However, I wonder why you don't have any dns blacklists such
>> > as zen.spamhaus.org defined there.  The ability of postscreen
>> > to reject known bad sites without using precious smtpd
>> > processes is one of its key features.
> Grant:
>> > I would just rather have a false negative than a false positive.
>> > I get a pretty small amount of spam at this point so I don't
>> > think reducing it further is worth increasing the chances of a
>> > false positive.
> Charles:
>> > From what (little) I know about how postscreen works, rejecting
>> > the known bad sites doesn't really have any (substantive) chance
>> > of false positives, but it provides much more than just
>> > protection from spam - it protects you from the botnets/zombies
>> > hammering your server needlessly.
>>
>> Do you mean there aren't any legitimate servers listed in
>> zen.spamhaus.org?
>
> Zen is a composite list, and indeed it is intended to be safe for
> widespread use.
>
> SBL (Spamhaus Block List) lists IP addresses which are known to be
> under the control of spammers.
>
> XBL (Exploits Block List) lists IP addresses which are actively
> spewing bot spam. Legitimate servers are occasionally listed in XBL,
> because they meet that condition. Some short time after they stop
> their abuse, they are delisted. Typically this is less than a day.
>
> PBL (Policy Block List) lists IP addresses which, according to the
> netblock owners, should not normally be sending legitimate email.
> Exceptions can be made for hosts with custom PTR upon request. Many
> colocation providers submit their networks for PBL, but removal is
> easy.
>
>> When I switched servers a while back, the new IP
>> I received was listed on several blacklists and it was a hassle
>> to get them removed.
>
> Far better that you go through that step than the Internet be exposed
> to more spam.

I agree, but the fact is that not everyone will go through that step.

> All that said, to address a point from Charles above, sure, it is
> possible for an over-eager person to make a postscreen which will
> block non-spam. Here's my example postscreen configuration which is
> intended to be safe and reasonable for most uses:
> http://rob0.nodns4.us/postscreen.html

Do you use that config on a commercial mail server?  I don't mean to
say that you shouldn't, I'm just wondering if you do.  In a commercial
environment, the penalty for a false positive is a customer unable to
reach the company behind the server which just isn't tolerable.

- Grant

Re: greylisting generates error email?

[/dev/rob0]

[attribution of quotes reconstructed]
On Sat, Aug 17, 2013 at 12:54:44AM -0700, Grant wrote:
Noel:
> > However, I wonder why you don't have any dns blacklists such
> > as zen.spamhaus.org defined there.  The ability of postscreen
> > to reject known bad sites without using precious smtpd
> > processes is one of its key features.
Grant:
> > I would just rather have a false negative than a false positive.  
> > I get a pretty small amount of spam at this point so I don't 
> > think reducing it further is worth increasing the chances of a 
> > false positive.
Charles:
> > From what (little) I know about how postscreen works, rejecting 
> > the known bad sites doesn't really have any (substantive) chance 
> > of false positives, but it provides much more than just 
> > protection from spam - it protects you from the botnets/zombies 
> > hammering your server needlessly.
> 
> Do you mean there aren't any legitimate servers listed in 
> zen.spamhaus.org?

Zen is a composite list, and indeed it is intended to be safe for 
widespread use.

SBL (Spamhaus Block List) lists IP addresses which are known to be 
under the control of spammers.

XBL (Exploits Block List) lists IP addresses which are actively 
spewing bot spam. Legitimate servers are occasionally listed in XBL, 
because they meet that condition. Some short time after they stop 
their abuse, they are delisted. Typically this is less than a day.

PBL (Policy Block List) lists IP addresses which, according to the 
netblock owners, should not normally be sending legitimate email. 
Exceptions can be made for hosts with custom PTR upon request. Many 
colocation providers submit their networks for PBL, but removal is 
easy.

> When I switched servers a while back, the new IP 
> I received was listed on several blacklists and it was a hassle
> to get them removed.

Far better that you go through that step than the Internet be exposed 
to more spam. Anyway, did you notice how bad your deliverability was 
during the time of your PBL listing? That's how it is. Lots of 
Internet sites use Zen for blocking.

There is safety in numbers. Any Zen-listed site which is wanting to 
deliver mail to you is also having problems getting mail to the rest 
of the Internet. They simply must address the problem[s] that caused 
the listing.

All that said, to address a point from Charles above, sure, it is 
possible for an over-eager person to make a postscreen which will 
block non-spam. Here's my example postscreen configuration which is 
intended to be safe and reasonable for most uses:
http://rob0.nodns4.us/postscreen.html
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: greylisting generates error email?

[Grant]

> Yes, that should whitelist known good sites from deep inspection,
> certainly all the big mailers such as google, yahoo, comcast, etc.
>
> However, I wonder why you don't have any dns blacklists such as
> zen.spamhaus.org defined there.  The ability of postscreen to reject
> known bad sites without using precious smtpd processes is one of its
> key features.
>
> I would just rather have a false negative than a false positive.  I
> get a pretty small amount of spam at this point so I don't think
> reducing it further is worth increasing the chances of a false
> positive.
>
>
> From what (little) I know about how postscreen works, rejecting the known
> bad sites doesn't really have any (substantive) chance of false positives,
> but it provides much more than just protection from spam - it protects you
> from the botnets/zombies hammering your server needlessly.

Do you mean there aren't any legitimate servers listed in
zen.spamhaus.org?  When I switched servers a while back, the new IP I
received was listed on several blacklists and it was a hassle to get
them removed.

- Grant

Re: greylisting generates error email?

[Charles Marcus]

On 2013-08-16 9:13 AM, Grant  wrote:

Yes, that should whitelist known good sites from deep inspection,
certainly all the big mailers such as google, yahoo, comcast, etc.

However, I wonder why you don't have any dns blacklists such as
zen.spamhaus.org defined there.  The ability of postscreen to reject
known bad sites without using precious smtpd processes is one of its
key features.

I would just rather have a false negative than a false positive.  I
get a pretty small amount of spam at this point so I don't think
reducing it further is worth increasing the chances of a false
positive.


From what (little) I know about how postscreen works, rejecting the 
known bad sites doesn't really have any (substantive) chance of false 
positives, but it provides much more than just protection from spam - it 
protects you from the botnets/zombies hammering your server needlessly.


But, your system, your rules... ;)

--

Best regards,

*/Charles/*

Re: greylisting generates error email?

[Grant]

>>> Use a dns white list with a negative score in the
>>> postscreen_dnsbl_sites, and set a negative value for
>>> postscreen_dnsbl_whitelist_threshold.  Simple example:
>>> # main.cf
>>> postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
>>> postscreen_dnsbl_whitelist_threshold = -1
>>
>> I've added the following to main.cf:
>>
>> postscreen_dnsbl_sites = list.dnswl.org*-1
>> postscreen_dnsbl_whitelist_threshold = -1
>>
>> Thank you for your help!
>
> Yes, that should whitelist known good sites from deep inspection,
> certainly all the big mailers such as google, yahoo, comcast, etc.
>
> However, I wonder why you don't have any dns blacklists such as
> zen.spamhaus.org defined there.  The ability of postscreen to reject
> known bad sites without using precious smtpd processes is one of its
> key features.

I would just rather have a false negative than a false positive.  I
get a pretty small amount of spam at this point so I don't think
reducing it further is worth increasing the chances of a false
positive.

- Grant

Re: greylisting generates error email?

[Noel Jones]

On 8/16/2013 1:29 AM, Grant wrote:
>> Use a dns white list with a negative score in the
>> postscreen_dnsbl_sites, and set a negative value for
>> postscreen_dnsbl_whitelist_threshold.  Simple example:
>> # main.cf
>> postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
>> postscreen_dnsbl_whitelist_threshold = -1
> 
> I've added the following to main.cf:
> 
> postscreen_dnsbl_sites = list.dnswl.org*-1
> postscreen_dnsbl_whitelist_threshold = -1
> 
> Thank you for your help!
> 
> - Grant
> 


Yes, that should whitelist known good sites from deep inspection,
certainly all the big mailers such as google, yahoo, comcast, etc.

However, I wonder why you don't have any dns blacklists such as
zen.spamhaus.org defined there.  The ability of postscreen to reject
known bad sites without using precious smtpd processes is one of its
key features.


  -- Noel Jones

Re: greylisting generates error email?

[Grant]

>> So I'm sure I understand, well-known mail servers should be whitelisted?
>
> No known mailer should ever hit your greylist. Think about it, what is the 
> greylist food? It's not to stop Google or comcast sending you mail. You know 
> those are legitimate mailers and they will retry, so what are you 
> accomplishing?

That makes perfect sense.

> You use a greylist (though I recommend you don't) so try to stem the flow of 
> botnets sending spam. They don't come back and retry, so greylisting is 
> effective.

You don't recommend it for the reason you state below?

>> The deep protocol checks have eliminated most of the spam from my
>> inbox so I'd like to keep them in place.
>
> Yes, but the key up there is "per unique IP". So, let's say that google has 
> 4,000 mail servers. You could potentially hit all of them. If you are a 
> low-traffic site, you will be deferring google mail all the time, and that 
> may not be good because let's say you need an email and it comes from machine 
> 1, and is retried by machine 211 and then retried by machine 3855. And you 
> defer it every time.
>>
>>> Postfix 2.11 (currently in development snapshots) includes a
>>> wonderful feature to bypass postscreen tests for clients listed in
>>> dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
>>> tests.
>
> And there was much rejoicing. \O/

If I understand correctly, this will completely eliminate the problem
you described above?

- Grant

Re: greylisting generates error email?

[Grant]

>>> Postfix 2.11 (currently in development snapshots) includes a
>>> wonderful feature to bypass postscreen tests for clients listed in
>>> dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
>>> tests.
>>
>> I'm actually using postfix-2.11_pre20130710.  Can you point me in the
>> right direction for setting up the DNS whitelist interaction?  Should
>> that (for example) prevent comcast.net users from receiving 450 error
>> email notices?
>
> Excellent!
>
> Use a dns white list with a negative score in the
> postscreen_dnsbl_sites, and set a negative value for
> postscreen_dnsbl_whitelist_threshold.  Simple example:
> # main.cf
> postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
> postscreen_dnsbl_whitelist_threshold = -1

I've added the following to main.cf:

postscreen_dnsbl_sites = list.dnswl.org*-1
postscreen_dnsbl_whitelist_threshold = -1

Thank you for your help!

- Grant

Re: greylisting generates error email?

[LuKreme]

On 15 Aug 2013, at 01:30 , Grant  wrote:

> A few people have told me they received an email error message after
> emailing me.  I'm trying to get a copy of one of the error emails,
> but I can't imagine what would cause that besides possibly my
> greylisting.  Has greylisting been known to lead to email error
> messages being sent to senders in some instances?
 
 The sender may receive an error if their server has an unusual
 setup. Such servers must be whitelisted in your greylist software.
>>> 
>>> The last sender who told me about the error message was on a
>>> comcast.net address.
>> 
>> Comcast (nor any major provider) should be greylisted.  Any
>> reasonable greylist software should have a setting to whitelist
>> well-known mail servers.
> 
> So I'm sure I understand, well-known mail servers should be whitelisted?

No known mailer should ever hit your greylist. Think about it, what is the 
greylist food? It's not to stop Google or comcast sending you mail. You know 
those are legitimate mailers and they will retry, so what are you accomplishing?

You use a greylist (though I recommend you don't) so try to stem the flow of 
botnets sending spam. They don't come back and retry, so greylisting is 
effective.


>>> It turns out I'm using postscreen with deep protocol checks:
>> 
>> Postscreen will defer one mail once every 30 days per unique client IP.
>> 
>> If that's not acceptable, turn off postscreen deep protocol checks
>> or whitelist known good servers (from domain SPF records?) in the
>> postscreen access list.
> 
> The deep protocol checks have eliminated most of the spam from my
> inbox so I'd like to keep them in place.

Yes, but the key up there is "per unique IP". So, let's say that google has 
4,000 mail servers. You could potentially hit all of them. If you are a 
low-traffic site, you will be deferring google mail all the time, and that may 
not be good because let's say you need an email and it comes from machine 1, 
and is retried by machine 211 and then retried by machine 3855. And you defer 
it every time.

> 
>> Postfix 2.11 (currently in development snapshots) includes a
>> wonderful feature to bypass postscreen tests for clients listed in
>> dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
>> tests.

And there was much rejoicing. \O/


-- 
I WILL NOT SCREAM FOR ICE CREAM Bart chalkboard Ep. AABF03

Re: greylisting generates error email?

[Noel Jones]

On 8/15/2013 2:30 AM, Grant wrote:
> A few people have told me they received an email error message after
> emailing me.  I'm trying to get a copy of one of the error emails,
> but I can't imagine what would cause that besides possibly my
> greylisting.  Has greylisting been known to lead to email error
> messages being sent to senders in some instances?

 The sender may receive an error if their server has an unusual
 setup. Such servers must be whitelisted in your greylist software.
>>>
>>> The last sender who told me about the error message was on a
>>> comcast.net address.
>>
>> Comcast (nor any major provider) should be greylisted.  Any
>> reasonable greylist software should have a setting to whitelist
>> well-known mail servers.
> 
> So I'm sure I understand, well-known mail servers should be whitelisted?

well-known mail servers should be whitelisted in greylist software.
 You can ignore this with postscreen and postfix 2.11+.


>> Postfix 2.11 (currently in development snapshots) includes a
>> wonderful feature to bypass postscreen tests for clients listed in
>> dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
>> tests.
> 
> I'm actually using postfix-2.11_pre20130710.  Can you point me in the
> right direction for setting up the DNS whitelist interaction?  Should
> that (for example) prevent comcast.net users from receiving 450 error
> email notices?

Excellent!

Use a dns white list with a negative score in the
postscreen_dnsbl_sites, and set a negative value for
postscreen_dnsbl_whitelist_threshold.  Simple example:
# main.cf
postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1
postscreen_dnsbl_whitelist_threshold = -1

See the RELEASE_NOTES and POSTSCREEN_README for details.


  -- Noel Jones

Re: greylisting generates error email?

[Grant]

 A few people have told me they received an email error message after
 emailing me.  I'm trying to get a copy of one of the error emails,
 but I can't imagine what would cause that besides possibly my
 greylisting.  Has greylisting been known to lead to email error
 messages being sent to senders in some instances?
>>>
>>> The sender may receive an error if their server has an unusual
>>> setup. Such servers must be whitelisted in your greylist software.
>>
>> The last sender who told me about the error message was on a
>> comcast.net address.
>
> Comcast (nor any major provider) should be greylisted.  Any
> reasonable greylist software should have a setting to whitelist
> well-known mail servers.

So I'm sure I understand, well-known mail servers should be whitelisted?

>> It turns out I'm using postscreen with deep protocol checks:
>
> Postscreen will defer one mail once every 30 days per unique client IP.
>
> If that's not acceptable, turn off postscreen deep protocol checks
> or whitelist known good servers (from domain SPF records?) in the
> postscreen access list.

The deep protocol checks have eliminated most of the spam from my
inbox so I'd like to keep them in place.

> Postfix 2.11 (currently in development snapshots) includes a
> wonderful feature to bypass postscreen tests for clients listed in
> dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
> tests.

I'm actually using postfix-2.11_pre20130710.  Can you point me in the
right direction for setting up the DNS whitelist interaction?  Should
that (for example) prevent comcast.net users from receiving 450 error
email notices?

- Grant

Re: greylisting generates error email?

[Noel Jones]

On 8/14/2013 10:21 AM, Grant wrote:
>>> A few people have told me they received an email error message after
>>> emailing me.  I'm trying to get a copy of one of the error emails,
>>> but I can't imagine what would cause that besides possibly my
>>> greylisting.  Has greylisting been known to lead to email error
>>> messages being sent to senders in some instances?
>>
>> The sender may receive an error if their server has an unusual
>> setup. Such servers must be whitelisted in your greylist software.
> 
> The last sender who told me about the error message was on a
> comcast.net address.  I found this which describes the same problem
> with greylisting and comcast addresses but the solution turned out to
> be fixing the MX record:
> 
> https://discussions.apple.com/thread/3030480?start=0&tstart=0

Nothing described in that posting indicates a problem with the MX
record. Either the poster didn't describe the problem he found and
fixed, or didn't understand the problem (the rDNS problem that was
described is not a problem for receiving mail, but might affect
sending).

Comcast (nor any major provider) should be greylisted.  Any
reasonable greylist software should have a setting to whitelist
well-known mail servers.

> 
> My DNS is hosted by my domain name registrar and the MX record looks
> like this (but with my real domain):
> 
> Host Name: example.com
> Mailserver Host Name: example.com
> Mail Type: MX
> MX Pref: 10
> TTL: 1800
> 
> Does it look OK?

Yes, this is fine, and not the source of any problems.


> It turns out I'm using postscreen with deep protocol checks:

Postscreen will defer one mail once every 30 days per unique client IP.

If that's not acceptable, turn off postscreen deep protocol checks
or whitelist known good servers (from domain SPF records?) in the
postscreen access list.


Postfix 2.11 (currently in development snapshots) includes a
wonderful feature to bypass postscreen tests for clients listed in
dns whitelists, such as list.dnswl.org, greatly reducing unnecessary
tests.


  -- Noel Jones

Re: greylisting generates error email?

[Charles Marcus]

On 2013-08-14 11:24 AM, Grant  wrote:

You were right, I'm using postscreen and deep protocol checks.


Turn them off (did you read the warnings associated with enabling them?)...

--

Best regards,

*/Charles /*

Re: greylisting generates error email?

[Grant]

>> A few people have told me they received an email error message
>> after emailing me.  I'm trying to get a copy of one of the error
>> emails, but I can't imagine what would cause that besides possibly
>> my greylisting.  Has greylisting been known to lead to email error
>> messages being sent to senders in some instances?
>
> delay_warning_time is disabled by default, but might cause the
> confusion you are describing. Sendmail and other MTAs have similar
> features. I think Sendmail's might be enabled by default at 4 hours.
>
> http://www.postfix.org/postconf.5.html#delay_warning_time

I checked but that directive doesn't appear in my config.

> It's not unheard of for greylisting to cause delays in excess of 4
> hours, especially for senders from large providers like Gmail. Gmail
> hands off deferred mail to an outbound farm which always tries from
> different IP addresses, thus meaning more delay with each unknown IP
> address.
>
>> How is greylisting set up in postfix now?
>
> I won't repeat the other replies you got about policy services, but
> I'll mention that postscreen(8) can provide most of the pain and
> benefits of greylisting, by enabling the after-220 ("deep protocol")
> tests.

You were right, I'm using postscreen and deep protocol checks.

- Grant

Re: greylisting generates error email?

[Grant]

>> A few people have told me they received an email error message after
>> emailing me.  I'm trying to get a copy of one of the error emails,
>> but I can't imagine what would cause that besides possibly my
>> greylisting.  Has greylisting been known to lead to email error
>> messages being sent to senders in some instances?
>
> The sender may receive an error if their server has an unusual
> setup. Such servers must be whitelisted in your greylist software.

The last sender who told me about the error message was on a
comcast.net address.  I found this which describes the same problem
with greylisting and comcast addresses but the solution turned out to
be fixing the MX record:

https://discussions.apple.com/thread/3030480?start=0&tstart=0

My DNS is hosted by my domain name registrar and the MX record looks
like this (but with my real domain):

Host Name: example.com
Mailserver Host Name: example.com
Mail Type: MX
MX Pref: 10
TTL: 1800

Does it look OK?

> One place to start is search your mail log for errors relating to
> the sender's email address and/or their server.

I grep'ed my mail logs for the email address in question and I don't
see anything that looks like an error.

>> How is greylisting set up in postfix now?  I know I used to use
>> postgrey but then I remember some sort of change.  I can see that I
>> have postgrey installed but the service is not running.  I checked
>> main.cf  and master.cf  but I
>> can't figure out how it's implemented now.
>
> Postfix has no "default" greylist, and there are several that are in
> widespread use.  Look in your "postconf -n" for a
> check_policy_service entry, then find that service in master.cf. Or
> some folks use a milter defined in smtpd_milters for greylisting.

It turns out I'm using postscreen with deep protocol checks:

smtp  inet  n   -   n   -   1   postscreen

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

- Grant

Re: greylisting generates error email?

[/dev/rob0]

On Wed, Aug 14, 2013 at 03:23:11AM -0700, Grant wrote:
> A few people have told me they received an email error message 
> after emailing me.  I'm trying to get a copy of one of the error 
> emails, but I can't imagine what would cause that besides possibly 
> my greylisting.  Has greylisting been known to lead to email error 
> messages being sent to senders in some instances?

In Postfix, see delay_warning_time: "To enable this feature, specify 
a non-zero time value (an integral value plus an optional one-letter 
suffix that specifies the time unit)."

delay_warning_time is disabled by default, but might cause the 
confusion you are describing. Sendmail and other MTAs have similar 
features. I think Sendmail's might be enabled by default at 4 hours.

http://www.postfix.org/postconf.5.html#delay_warning_time

It's not unheard of for greylisting to cause delays in excess of 4 
hours, especially for senders from large providers like Gmail. Gmail 
hands off deferred mail to an outbound farm which always tries from 
different IP addresses, thus meaning more delay with each unknown IP 
address.

> How is greylisting set up in postfix now?

I won't repeat the other replies you got about policy services, but 
I'll mention that postscreen(8) can provide most of the pain and 
benefits of greylisting, by enabling the after-220 ("deep protocol") 
tests.

http://www.postfix.org/POSTSCREEN_README.html
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: greylisting generates error email?

[Noel Jones]

On 8/14/2013 5:23 AM, Grant wrote:
> A few people have told me they received an email error message after
> emailing me.  I'm trying to get a copy of one of the error emails,
> but I can't imagine what would cause that besides possibly my
> greylisting.  Has greylisting been known to lead to email error
> messages being sent to senders in some instances?

The sender may receive an error if their server has an unusual
setup. Such servers must be whitelisted in your greylist software.

Of course, there are a number of other errors the sender might get
that have nothing to do with greylisting.

You really need to see the error before you start trying to fix things.

One place to start is search your mail log for errors relating to
the sender's email address and/or their server.


> 
> How is greylisting set up in postfix now?  I know I used to use
> postgrey but then I remember some sort of change.  I can see that I
> have postgrey installed but the service is not running.  I checked
> main.cf  and master.cf  but I
> can't figure out how it's implemented now.

Postfix has no "default" greylist, and there are several that are in
widespread use.  Look in your "postconf -n" for a
check_policy_service entry, then find that service in master.cf. Or
some folks use a milter defined in smtpd_milters for greylisting.

If you need more help, you'll need to provide "postconf -n" output,
master.cf contents, and any associated log entries.

http://www.postfix.org/DEBUG_README.html#mail



  -- Noel Jones

Re: greylisting generates error email?

[James Griffin]

!-- On Wed 14.Aug'13 at 11:23:11 BST, Grant (emailgr...@gmail.com), wrote: 
> A few people have told me they received an email error message after
> emailing me.  I'm trying to get a copy of one of the error emails, but I
> can't imagine what would cause that besides possibly my greylisting.  Has
> greylisting been known to lead to email error messages being sent to
> senders in some instances?
> 
> How is greylisting set up in postfix now?  I know I used to use postgrey
> but then I remember some sort of change.  I can see that I have postgrey
> installed but the service is not running.  I checked main.cf and
> master.cfbut I can't figure out how it's implemented now.
> 
> - Grant

I would imagine the log file and your configuration settings (postconf
-n) would yield some useful information.

-- 


James Griffin: jmz at kontrol.kode5.net 

A4B9 E875 A18C 6E11 F46D  B788 BEE6 1251 1D31 DC38

Re: greylisting

[polloxx]

Thanks to all of you for the suggestions.

On Fri, Jan 4, 2013 at 2:56 PM, polloxx  wrote:
> I have a question regarding greylisting:
>
> Some of our users are complaining mails have a large delay, especially
> those from providers like gmail. This is because these use different
> IP addresses on each delivery attempt.
> Using listgrey is not an option.
>
> Anyone who has a solution for this?
>
> Thx,
> P.

Re: greylisting

[Benny Pedersen]

polloxx skrev den 2013-01-04 14:56:

I have a question regarding greylisting:

Some of our users are complaining mails have a large delay, 
especially

those from providers like gmail. This is because these use different
IP addresses on each delivery attempt.
Using listgrey is not an option.

Anyone who has a solution for this?


use pypolicyd-spf latest version and then if spf pass dont greylist, if 
sender is after this test still gmail.org then greylist or reject that 
user for not using gmail servers


#  For a fully commented sample config file see 
policyd-spf.conf.commented


debugLevel = 1
defaultSeedOnly = 1

HELO_reject = SPF_Not_Pass
Mail_From_reject = SPF_Not_Pass

PermError_reject = True
TempError_Defer = False

skip_addresses = 127.0.0.0/8

Header_Type = AR
Authserv_Id = duggi.junc.org


then do greylist AFTER check spf

and if spf passed skip greylist google postfwd as an example config, 
but with spf as above then its not needed to use another daemon


and lastly remember to not greylist non existsing recipient, 
reject_unlisted_recipient before check_policy_service

Re: greylisting

[Robert Schetterer]

Am 04.01.2013 14:56, schrieb polloxx:
> I have a question regarding greylisting:
> 
> Some of our users are complaining mails have a large delay, especially
> those from providers like gmail. This is because these use different
> IP addresses on each delivery attempt.
> Using listgrey is not an option.
> 
> Anyone who has a solution for this?
> 
> Thx,
> P.
> 

use greylisting only selective, thats enough
i.e
http://www.arschkrebs.de/postfix/postfix_greylisting.shtml

Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: greylisting

[Thomas Leuxner]

* polloxx  2013.01.04 15:20:

> We use postfix-gld.

That seems to have gathered some dust. Anyway you should be able to
whitelist the affected domains _before_ the check_policy_service
statement:

  check_client_access hash:/etc/postfix/client_access

...or the like.

Thomas


signature.asc
Description: Digital signature

Re: greylisting

[polloxx]

On Fri, Jan 4, 2013 at 3:13 PM, Thomas Leuxner  wrote:
> * polloxx  2013.01.04 14:56:
>
>> Some of our users are complaining mails have a large delay, especially
>> those from providers like gmail. This is because these use different
>> IP addresses on each delivery attempt.
>> Using listgrey is not an option.
>>
>> Anyone who has a solution for this?
>
> You haven't told us what you piece of software you are using to
> greylist. Postgrey for instance can overcome such problems
> with 'client_whitelists' and a little regex magic.
>
> Or religiously, don't use greylisting at all but postscreen:
>
> http://www.postfix.org/POSTSCREEN_README.html
>
> Regards
> Thomas


We use postfix-gld.

Re: greylisting

[Thomas Leuxner]

* Thomas Leuxner  2013.01.04 15:13:

> You haven't told us what piece of software you are using to
> greylist. Postgrey for instance can overcome such problems
> with 'client_whitelists' and a little regex magic.
> 
> Or religiously, don't use greylisting at all but postscreen:
> 
> http://www.postfix.org/POSTSCREEN_README.html
> 
> Regards
> Thomas

Oops I failed to multitask, please disregard wrong reply-to. Fixed


signature.asc
Description: Digital signature

Re: greylisting

[Thomas Leuxner]

* polloxx  2013.01.04 14:56:

> Some of our users are complaining mails have a large delay, especially
> those from providers like gmail. This is because these use different
> IP addresses on each delivery attempt.
> Using listgrey is not an option.
> 
> Anyone who has a solution for this?

You haven't told us what you piece of software you are using to
greylist. Postgrey for instance can overcome such problems
with 'client_whitelists' and a little regex magic.

Or religiously, don't use greylisting at all but postscreen:

http://www.postfix.org/POSTSCREEN_README.html

Regards
Thomas


signature.asc
Description: Digital signature

Re: greylisting + postfix 101

[lst_hoe02]

Zitat von Razvan Chitu :


Hello all,
Please take a moment and point me in the right direction: I  
would like to set up a greylisting solution (such as postgrey or  
greylist.pl) only for one recipient (local delivery to *nix  
account). A link or any pointer in the right direction would be  
welcomed.


http://www.postfix.org/RESTRICTION_CLASS_README.html
http://www.postfix.org/SMTPD_POLICY_README.html

Regards

Andreas

Re: greylisting with postscreen?

[Craig Waddington]

On 10/02/2011 3:59 PM, Wietse Venema wrote:

To greylist, see: http://www.postfix.org/SMTPD_POLICY_README.html

On th eother hand, making the "PASS NEW" event a trigger for a
penalty time should require little new code. I added support for
"penalty time" late last year but it is currently unused for lack
of a "trigger" mechanism. Penalty time means the client gets 4xx
replies until the penalty time expires.

Penalty time after "PASS NEW" is a relatively crude mechanism
compared to real greylisting, but it might do the job. Perhaps
later in the year.

Wietse


Many thanks for the info - I will keep an eye out for the new versions!


__ Information from ESET Smart Security, version of virus signature 
database 5892 (20110221) __

The message was checked by ESET Smart Security.

http://www.eset.com

Re: greylisting with postscreen?

[Craig Waddington]

On 10/02/2011 3:04 PM, Christian Roessner wrote:

Hi,


I am trying out the postscreen server - and am very impressed so far. My 
original interest was in greylisting - so I have the deep protocol tests turned 
on so that the temporary failure code 45x is returned for non-whitelisted 
clients.

During my testing - I noticed that the small trickle of spam that still makes 
it past postscreen reattempts immediately after a 45x with no delay, whereas 
genuine mail will wait at least a few minutes before reattempting after a 45x.


I hope, I may ask, but if a client is able to queue mail after a 45x, wouldn't 
this same client come back after 300 seconds, too? And so skipping the 
greylisting barrier? Or are there some bots outside that can do that? But even 
then, they might be lucky at a later time, when the host, where they live on, 
returns (even with dynamic IP; just a question of patients).

Christian


Yes - I am assuming that most bots wouldn't queue, although I have no 
evidence for this. I think you are right that there may be cases where 
bots will still get through if they send different spam at a later time.



__ Information from ESET Smart Security, version of virus signature 
database 5892 (20110221) __

The message was checked by ESET Smart Security.

http://www.eset.com

Re: greylisting with postscreen?

[/dev/rob0]

On Thu, Feb 10, 2011 at 02:33:09PM +, Craig Waddington wrote:
> I am trying out the postscreen server - and am very impressed
> so far. My original interest was in greylisting - so I have the 
> deep protocol tests turned on so that the temporary failure code 
> 45x is returned for non-whitelisted clients.
> 
> During my testing - I noticed that the small trickle of spam
> that still makes it past postscreen reattempts immediately
> after a 45x with no delay, whereas genuine mail will wait at
> least a few minutes before reattempting after a 45x.

Could you share logs and spam samples for these? Thanks.

IME with greylisting, which admittedly was not very recent, delay 
time length was insignficant. A 5-second delay was as good as 5 
minutes. Some bots retried, others did not.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: greylisting with postscreen?

[Jeroen Geilman]

On 02/10/2011 04:59 PM, Wietse Venema wrote:

Craig Waddington:
   

Hi,

I am trying out the postscreen server - and am very impressed so far. My
original interest was in greylisting - so I have the deep protocol tests
turned on so that the temporary failure code 45x is returned for
non-whitelisted clients.

During my testing - I noticed that the small trickle of spam that still
makes it past postscreen reattempts immediately after a 45x with no
delay, whereas genuine mail will wait at least a few minutes before
reattempting after a 45x.

So - my question - do we know if it will be possible to enforce a delay
after the 45x before a reconnect is accepted? I have seen references to
a postcreen_greylist_threshold parameter in a postscreen strawman
document, and am wondering whether this, or some other configuration
will allow the exclusion of clients who respond instantly to a 45x?
 

To greylist, see: http://www.postfix.org/SMTPD_POLICY_README.html

On th eother hand, making the "PASS NEW" event a trigger for a
penalty time should require little new code. I added support for
"penalty time" late last year but it is currently unused for lack
of a "trigger" mechanism. Penalty time means the client gets 4xx
replies until the penalty time expires.

Penalty time after "PASS NEW" is a relatively crude mechanism
compared to real greylisting, but it might do the job.


If the penalty response is also a 4xx, it sounds to me exactly the same 
as that aspect of greylisting - except that greylisting can choose to 
permanently whitelist clients that passed.


In fact, since the RFC says that clients MUST wait before retrying after 
a 4xx response, wouldn't postscreen be warranted to send a 5xx if it 
doesn't wait?


OTOH, if the suspected spam client ignores the RFC for 4xx responses, I 
guess it would be naive to expect it to obey the 5xx response; it could 
just retry and retry and consume resources until something stops it.



--
J.

Re: greylisting with postscreen?

[Wietse Venema]

Victor Duchovni:
> On Thu, Feb 10, 2011 at 10:59:31AM -0500, Wietse Venema wrote:
> 
> > On th eother hand, making the "PASS NEW" event a trigger for a
> > penalty time should require little new code. I added support for
> > "penalty time" late last year but it is currently unused for lack
> > of a "trigger" mechanism. Penalty time means the client gets 4xx
> > replies until the penalty time expires.
> > 
> > Penalty time after "PASS NEW" is a relatively crude mechanism
> > compared to real greylisting, but it might do the job. Perhaps
> > later in the year.

Note, I wrote "PASS NEW".

> What would happen with clients that are "OLD", when their status
> "expires"? While "brand-new" clients can reasonably be asked to come
> back later, should the same apply to clients that are being re-tested
> from time to time? Is the database purge ttl longer than the record
> revalidation ttl? Does postscreen have a concept of re-validation
> vs. initial validation?

Note, I did not write "PASS OLD".

Wietse

Re: greylisting with postscreen?

[Victor Duchovni]

On Thu, Feb 10, 2011 at 10:59:31AM -0500, Wietse Venema wrote:

> On th eother hand, making the "PASS NEW" event a trigger for a
> penalty time should require little new code. I added support for
> "penalty time" late last year but it is currently unused for lack
> of a "trigger" mechanism. Penalty time means the client gets 4xx
> replies until the penalty time expires.
> 
> Penalty time after "PASS NEW" is a relatively crude mechanism
> compared to real greylisting, but it might do the job. Perhaps
> later in the year.

What would happen with clients that are "OLD", when their status
"expires"? While "brand-new" clients can reasonably be asked to come
back later, should the same apply to clients that are being re-tested
from time to time? Is the database purge ttl longer than the record
revalidation ttl? Does postscreen have a concept of re-validation
vs. initial validation?

-- 
Viktor.

Re: greylisting with postscreen?

[Wietse Venema]

Craig Waddington:
> Hi,
> 
> I am trying out the postscreen server - and am very impressed so far. My 
> original interest was in greylisting - so I have the deep protocol tests 
> turned on so that the temporary failure code 45x is returned for 
> non-whitelisted clients.
> 
> During my testing - I noticed that the small trickle of spam that still 
> makes it past postscreen reattempts immediately after a 45x with no 
> delay, whereas genuine mail will wait at least a few minutes before 
> reattempting after a 45x.
> 
> So - my question - do we know if it will be possible to enforce a delay 
> after the 45x before a reconnect is accepted? I have seen references to 
> a postcreen_greylist_threshold parameter in a postscreen strawman 
> document, and am wondering whether this, or some other configuration 
> will allow the exclusion of clients who respond instantly to a 45x?

To greylist, see: http://www.postfix.org/SMTPD_POLICY_README.html

On th eother hand, making the "PASS NEW" event a trigger for a
penalty time should require little new code. I added support for
"penalty time" late last year but it is currently unused for lack
of a "trigger" mechanism. Penalty time means the client gets 4xx
replies until the penalty time expires.

Penalty time after "PASS NEW" is a relatively crude mechanism
compared to real greylisting, but it might do the job. Perhaps
later in the year.

Wietse

Re: greylisting with postscreen?

[Christian Roessner]

Hi,

> I am trying out the postscreen server - and am very impressed so far. My 
> original interest was in greylisting - so I have the deep protocol tests 
> turned on so that the temporary failure code 45x is returned for 
> non-whitelisted clients.
> 
> During my testing - I noticed that the small trickle of spam that still makes 
> it past postscreen reattempts immediately after a 45x with no delay, whereas 
> genuine mail will wait at least a few minutes before reattempting after a 45x.

I hope, I may ask, but if a client is able to queue mail after a 45x, wouldn't 
this same client come back after 300 seconds, too? And so skipping the 
greylisting barrier? Or are there some bots outside that can do that? But even 
then, they might be lucky at a later time, when the host, where they live on, 
returns (even with dynamic IP; just a question of patients).

Christian
---
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com



PGP.sig
Description: Signierter Teil der Nachricht

Re: Greylisting after header check

[Wietse Venema]

Stan Hoeppner:
> ? ? put forth on 10/27/2010 10:51 AM:
> > I can't add clients to whitelist because I don't know their addresses. One
> > of our manager call to client with phone and say him email address. And in
> > this case manager should receive a letter without greylisting, so in fact I
> > need some method to pass greylisting, which manager could describe to
> > client. The simplest way for manager and client is to add to mail subject
> > some digital code, but I can't understand how to configure Postfix to
> > support this method.
> 
> Will all these clients be sending to the same email address
> @yourcompany.tld upon this initial contact?  If so, simply whitelist the
> recipient address.  There are many ways to skin this cat.  The key is
> that any anti-spam measures should always be 100% transparent to
> senders.  I.e. they shouldn't have to add something to the subject line
> just to get their email through your server, or jump through any other
> hoops.
> 
> I use Postgrey here, and the most I've ever had to wait on greylist
> delay after signing up for a new mailing list or placing an order with a
> new company was a few minutes.  If you can't whitelist in one form or
> another, and a few minutes delay is too long for you, then you shouldn't
> be using greylisting at all, as it's not a good fit for your needs.

You could use a greylisting implementation that automatically
whitelists clients that pass the test a few times. That is a good
indicator greylisting is not useful for that client. Look for
implementations with auto-whitelist support.

Wietse

Re: Greylisting after header check

[Stan Hoeppner]

Неворотин Вадим put forth on 10/27/2010 10:51 AM:
> I can't add clients to whitelist because I don't know their addresses. One
> of our manager call to client with phone and say him email address. And in
> this case manager should receive a letter without greylisting, so in fact I
> need some method to pass greylisting, which manager could describe to
> client. The simplest way for manager and client is to add to mail subject
> some digital code, but I can't understand how to configure Postfix to
> support this method.

Will all these clients be sending to the same email address
@yourcompany.tld upon this initial contact?  If so, simply whitelist the
recipient address.  There are many ways to skin this cat.  The key is
that any anti-spam measures should always be 100% transparent to
senders.  I.e. they shouldn't have to add something to the subject line
just to get their email through your server, or jump through any other
hoops.

I use Postgrey here, and the most I've ever had to wait on greylist
delay after signing up for a new mailing list or placing an order with a
new company was a few minutes.  If you can't whitelist in one form or
another, and a few minutes delay is too long for you, then you shouldn't
be using greylisting at all, as it's not a good fit for your needs.

-- 
Stan


> 2010/10/27 Stan Hoeppner 
> 
>>
>> Greylisting has but one purpose:  stopping spam bots (zombies)
>>
>> Are these new clients sending emails to you from zombies?  No, of course
>> not.  So simply whitelist their addresses or IPs in your greylist daemon
>> setup (not in Postfix).  This is trivial to do with Postgrey, though I
>> don't know about other daemons.
>>
>> Whitelisting in your greylist software is not the same as whitelisting
>> in Postfix.  It only allows clients to bypass the greylisting step.  Any
>> real MTA will retry, so if you _know_ it's a real MTA, which in this
>> case you do, whitelist it in your greylist config.
>>
>> --
>> Stan
>>
> 

Re: Greylisting after header check

[Stan Hoeppner]

Неворотин Вадим put forth on 10/27/2010 4:47 AM:
> I have greylisting on my server, but sometimes I need to allow some external
> users to send mail to my server without greylisting. I can't add them to
> whitelist, because in most cases it's a new clients, so the good idea is to
> ask them to add to mail's subject some code and to accept letters with this
> code in subject without greylisting. But I can't understand how to implement
> this simple idea in postfix. I need to move greylisting from SMTP headers
> check to mail's body check and start greylisting only if Subject: mail
> header doesn't match a regexp. How can I do it?

Greylisting has but one purpose:  stopping spam bots (zombies)

Are these new clients sending emails to you from zombies?  No, of course
not.  So simply whitelist their addresses or IPs in your greylist daemon
setup (not in Postfix).  This is trivial to do with Postgrey, though I
don't know about other daemons.

Whitelisting in your greylist software is not the same as whitelisting
in Postfix.  It only allows clients to bypass the greylisting step.  Any
real MTA will retry, so if you _know_ it's a real MTA, which in this
case you do, whitelist it in your greylist config.

-- 
Stan

Re: Greylisting or not ?

[Len Conrad]

=>I actually use postgrey as greylisting utility
>
>I have no experience with other greylisting softwares
>but Postfix "gurus" advice would be greatly appreciated
>to compare and eventually change for another software.

postgrey and its fork sqlgrey are pretty much optimum.  I think changing to 
something else won't buy you much if any improvement.

I have one high volume site, 200K+ msgs/day accepted per MX, with SQLgrey on 3 
MXs where the: 

(new but retried) / (total new) 

is less that 2%.  

Len

Re: Greylisting or not ?

[Noel Jones]

On 10/1/2010 8:43 AM, Frank Bonnet wrote:

Hello

I actually use postgrey as greylisting utility

I have no experience with other greylisting softwares
but Postfix "gurus" advice would be greatly appreciated
to compare and eventually change for another software.

Thanks a lot



What you use depends greatly on what your needs and 
expectations are.


I don't know of any "bad" greylisting software, but some of 
the choices may be inappropriate for particular sites (eg. too 
simple for a large multi-MX site, too complex for a home/hobby 
site with an inexperienced admin).


What are you looking for? Some feature that postgrey doesn't 
seem to support?


If you don't have any problem with postgrey, no need to 
change.  If you just want to experiment, pick something and 
try it out.



  -- Noel Jones

Re: Greylisting or not ?

[lst_hoe02]

Zitat von Frank Bonnet :


Hello

I actually use postgrey as greylisting utility

I have no experience with other greylisting softwares
but Postfix "gurus" advice would be greatly appreciated
to compare and eventually change for another software.


We also use Postgrey

Works stable and as expected and saved us from blocking dynamic IPs per RBLs.

What is always recommended:
- Use auto-whitelist=1 and a very long purge delay for the client list
- Use more than some seconds as greylist delay

Regards

Andreas




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Greylisting & SMTP auth

[Christopher Sean Hilton]

On Jul 9, 2010, at 4:57 AM, Hendrik Pahl wrote:

> Hi folks,
> 
> we're having some trouble with greylisting (postgrey) and smtp auth.
> 
> smtp_recipient_restrictions looks like:
> 

I'm not sure what the rest of your network looks like but I greylist through 
openbsd's spamd and to sasl authenticated SMTP submission on tcp/465 and 
tcp/587. The details are as follows:


 tcp/25 -- greylisted

 tcp/465, tcp/587 -- not greylisted, TLS required, SMTP Auth required.

Obviously this works for me because I can tell my clients that they should 
submit mail at tcp/587 rather than port 25. (I also submission on tcp/465 
because some older Outlook clients default there.) I had guessed that this was 
the pretty standard these days.

-- Chris

Chris Hilton   tildeChris -- http://myblog.vindaloo.com
email -- chris/at/vindaloo/dot/com
.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.
 "I'm on the outside looking inside, What do I see?
   Much confusion, disillution, all around me."
 -- Ian McDonald / Peter Sinfield

Re: Greylisting & SMTP auth

[Ralf Hildebrandt]

* Hendrik Pahl :
> Hi folks,
> 
> we're having some trouble with greylisting (postgrey) and smtp auth.
> 
> smtp_recipient_restrictions looks like:

It's smtpd_recipient_restrictions

> permit_sasl_authenticated, permit_mynetworks,
> reject_unauth_destination, warn_if_reject,
> reject_unknown_sender_domain, warn_if_reject,
> reject_invalid_hostname,
> warn_if_reject, reject_non_fqdn_sender,
> warn_if_reject, reject_non_fqdn_recipient,
> warn_if_reject, reject_rbl_client 
> ix.dnsbl.manitu.net,
> check_policy_service inet:127.0.0.1:10030
> 
> Now, when a client authenticates the mail is greylisted

No, it's not.

permit_sasl_authenticated returns OK in that case, and no other
restriction fires.

Maybe you have more restrictions?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: greylisting question

[J.D. Bronson]

On 1/24/10 8:09 AM, Martin Strand wrote:

On Sun, 24 Jan 2010 14:00:21 +0100, J.D. Bronson
 wrote:


I have noticed (at times) that sometimes email gets greylisted
when the user doesn't exist in my system. The mail ultimately get's
rejected, but I cant figure out why it's greylisting when it's invalid
to begin with? Greylisting, to me..should be the last resort..


I have this way up near the top of main.cf:

# REJECTING MAIL FOR UNKNOWN LOCAL USERS
local_recipient_maps = proxy:unix:passwd.byname $alias_maps

# ADDRESS REWRITING
alias_maps = $default_database_type:/etc/postfix/aliases
alias_database = $default_database_type:/etc/postfix/aliases


and then the typical stuff:

smtpd_recipient_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unknown_client,
reject_unauth_pipelining,
check_policy_service inet:127.0.0.1:10023



You need to tell Postfix when to lookup the recipient address or else
that will happen after all the other checks, i.e. after a client has
passed greylisting. Just add the "reject_unlisted_recipient" check
somewhere before your greylisting service.

http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

.



Bingo...that was it. Much thanks!


--
J.D. Bronson
Information Technology
Aurora Health Care - Milwaukee WI
Office: 414.978.8282 // Fax: 414.978.3988

Re: greylisting question

[Martin Strand]

On Sun, 24 Jan 2010 14:00:21 +0100, J.D. Bronson  
wrote:


I have noticed (at times) that sometimes email gets greylisted
when the user doesn't exist in my system. The mail ultimately get's
rejected, but I cant figure out why it's greylisting when it's invalid
to begin with? Greylisting, to me..should be the last resort..


I have this way up near the top of main.cf:

# REJECTING MAIL FOR UNKNOWN LOCAL USERS
local_recipient_maps = proxy:unix:passwd.byname $alias_maps

# ADDRESS REWRITING
alias_maps = $default_database_type:/etc/postfix/aliases
alias_database = $default_database_type:/etc/postfix/aliases


and then the typical stuff:

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 reject_unauth_destination,
 reject_invalid_hostname,
 reject_non_fqdn_hostname,
 reject_unknown_client,
 reject_unauth_pipelining,
 check_policy_serviceinet:127.0.0.1:10023



You need to tell Postfix when to lookup the recipient address or else that will happen 
after all the other checks, i.e. after a client has passed greylisting. Just add the 
"reject_unlisted_recipient" check somewhere before your greylisting service.

http://www.postfix.org/postconf.5.html#reject_unlisted_recipient

Re: Greylisting

[mouss]

Tom Allison wrote:

I'm going by recent memory so please be kind if I miss something.

I recall in the greylisting docs that under DATA and something else only 
one recipient is transmitted. Is that also true immediately following 
the RECIPIENT block?


Is just the first one listed or any particular order?


you only have the "current" recipient. if mail has multiple recipients, 
then the policy server is called for each recipient if the check is done 
at RCPT stage (so this doesn't apply to data stage, when you don't get 
the recipient(s)).





What I am trying to do long term is look for some kind if a hook to keep 
deferring the bad email so it stays on the senders machine and I don't 
have to own it, other than this deferral process.




not clear what you mean. defer causes the mail to stay on the "previous" 
MTA, if this is really an MTA. In case of ratware, the behaviour is 
unpredictable (ratware can retry or not).


Of course, sine I thought of trying to do this yesterday it's probably 
already been tried a dozen different ways... 


do you mean you want to defer the mail indéfinitely. you can use 
"defer", but be careful here. you'll have to be very selective because a 
false positive that is detected 5 days later is worst than one that is 
detected shortly. so "reject" is generally the way to go. don't think 
too much about zombies. defer won't help (they don't have to follow the 
smtp protocol!). and for real MTAs, it is unfriendly to delay mail too 
long.