David,
>>> A separate dæmon written in C++ with a 'thread pool' implementation and
>>> weird OS 'abstraction' layers to handle signals... that's not overkill?
>> It's really fast and scalable (actually what it was written for - one of
>> mid size ISP asked me for help). Also it couldn't cause email loss -
>> i.e. if something goes wrong e-mail just passed in.
>
> Sounds like it's being used too much. Ideally, I believe greylisting
> should only be invoked for mails which look suspicious in some way, if
> they come from a host which hasn't previously been observed to queue and
> retry.
I try to greylist all incoming mail as early as possible to minimize
relay load and (less important) traffic.
>>> You also don't seem to be passing it anything other than $sender_address
>>> and $sender_host_address -- and you're even assuming the latter is
>>> Legacy IP, afaict.
>> I'm checking sender host address and sender from address, e.g:
>> 209.85.218.168:*@gmail.com
>
> How's it going to cope with what I get on your incoming mail:
> 2001:4830:2446:ff00:214:51ff:fe65:c65c:dms@???
What is it? MSG ID? My outgoing e-mail not graylisted - I use
login/pass & SSL.
> There is some discussion of that on the wiki page to which I referred.
Some comments on wiki page:
I.
"One problem is that some "genuine" mail servers might be broken in the
same way as we expect the spam bots to be."
Much more often problem is clusters: lots of SMTP clusters can resend
e-mail from another IP address. Fortunately most of them is not
spammers. I think a) the problem should be mentioned in this chapter b)
it's better to whitelist such clusters rather then exclude sender IP
from hash calculation.
II.
"Firstly, there's the database of "known resenders", which lists the
hosts that are known to retry sending mail."
In the NAT world I'm in doubt that such list have a sense.
--
Dmitry Samersoff
dms@???,
http://devnull.samersoff.net
* There will come soft rains ...
