On Sat, 30 Jul 2016, Robert Schetterer wrote:
Am 30.07.2016 um 03:34 schrieb Reindl Harald:
Am 29.07.2016 um 22:48 schrieb Dianne Skoll:
On Fri, 29 Jul 2016 22:39:15 +0200
Robert Schetterer <r...@sys4.de> wrote:
I don't use postfix or postscreen.
hm.. that does not fit the subject..why did you involved yourself ?
I am sorry. I should have changed the thread subject.
you may get that quite better, i see
a lot of server greylisting useless ,only filling up others queues
waiting for a second slot ,so it may only cheap for you but not for
your partners
Dont slow down communication if you dont need to
So what I didn't mention is that in our implementation, once an IP
address successully passes greylisting, we no longer greylist it for
the next 45 days. (It would probably be pointless... if an IP passes
greylisting once, it probably will keep passing it.)
that's nothing special and postgrey does the same, the whole point of
greylisting is that badly written bots don't try again (the same happens
if they connect to a backup-MX responding with 4xx)
also it don't help for clients which *do not* pass like large senders
with outbound clusters coming each time from a different IP
hence you skip greylisting based on DNSWL and spf-policyd because that
big legit senders hit DNSWL or have a proper SPF while random bots of
infected machines don't and this ones are your target for greylisting
Harald is right, the goal has to be "reject" spam asap, not to tell
"come again later", i.e i had 4 bot cons per second, this will run out
the system of smtp slots rapidly which means any good sender isnt able
to sent mail too, greylisting makes such situations more worst.
I'm no expert here, but postgrey is usually a purely local test. It should
terminate with a "currently busy, try again later" message very quickly.
SPF checks and white listing require dns lookups that can potentially take
much longer. Several orders of magnitude longer.
Efficient handling of spam is all about doing the least expensive tests
first in terms of cpu/time. Caching DNS can probably help a bit, but it
will still require the occasional lookup now and then that take a lot
longer than a good greylisting implementation should ever do.
Doing an expensive test on every mail when it's not needed is badly
designed setup.
Many of the dns based lists also limit the amount of checks per day. Worst
case scenario, you stop getting results from lists due to over use. If you
use google's 8.8.8.8 servers for dns lookups one can quickly run into that
problem, I did. A high volume of dns checks could force you into having to
pay for the amount of traffic you cause.
Many expensive network (takes a long time) checks will probably make you
run out of slots a lot faster than the reconnects due to greylisting will
do due to the time spent waiting for the lookups to finish.
If speed of delivery is important, you could lower the amount of time mail
stays greylisted. Ideally you'd like the mail delivered the first time
a server tries to send it again. If a server tries to resend once, it will
most likely try more than once anyway. Having a minimum time of 300
seconds, the default of postgrey, is probably a bit excessive.
--
Kim Roar Foldøy Hauge
Event:Presse - The Gathering 2016
webmas...@samfunnet.no
Root@HC,HX,JH,LZ,OT,P,VH
