Milter-greylist

Tere.
> If you increase the delay, they will give up.
I don't think so. That's by the way why I tried to change this error
code, as seems some of them will specially attack these servers which
give the 4.7.1 (greylisted) error.

> Handling resends needs resources. The spammer midly care, since he
> is not paying for the CPU, memory, and disk space of hijacked machines.
> On the other hand, this free resource is not infinite. If the machine 
> sends 100 message per second to servers with a delay of 12 hours, the 
> resend queue will grow up exhausting available resources.
>
> But it is not possible to have a delay of 12 hours for everyone. This is
> why I indtroduced DNSRBL and per-ACL delays in milter-greylist. You can
> now have different delays depending on the sender reputation. Machines on
> dynamic IP pools are not likely to be real SMTP servers, so we can 
> affore a much higher delay for them. And that seems to do the trick.
>
>   
Yes, and no. I personally can't use this dnsbl.sorbs.net as it
blacklists usually by subnets, even by county, not by address. And at
least in Baltic States and Scandinavian countries, at least 90% home
users uses dynamic ip and they will be infinitely greylisted even if
send emails true their ISP -s smtp server as the senders (dynamic) ip is
still in message  header.

-- 
Mart