Am 30.07.2016 um 13:10 schrieb Kim Roar Foldøy Hauge: > 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. >
Greylisting was invented as an idea against bots. Its based on the idea that bots "fire and forget" when they see a tmp error and dont get back. This idea was criticized for design failures since it exists ( Harald and me explained it in detail ), but was acceptable in lack of better ideas that time. But thats historic, bots are recoded, better antibot tecs were invented. The only problem now is people still believe in historic stuff. Best Regards MfG Robert Schetterer -- [*] sys4 AG http://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 Aufsichtsratsvorsitzender: Florian Kirstein
