On May 13, 2013, at 22:28 , Wietse Venema <wie...@porcupine.org> wrote:
> Patrik Rak: >>> If we want to address the real problem: slow or non-responding DNS >>> and SMTP servers, then we should not waste an entire SMTP client >>> process blocking on DNS lookup and TCP connection handshake in the >>> first place. Instead it is more efficient to interpose a prescreen(8) >>> process between the qmgr(8) and smtp(8) processes. This process >>> can look up DNS, create the initial TCP connection, peek() at the >>> remote server greeting, and keep the bogons away without wasting >>> any smtp(8) processes. Just like postscreen(8) can keep bogus SMTP >>> clients away without wasting smtpd(8) processes. >> >> Hmm, this is definitely an interesting idea. Looks pretty cool. But >> there are few problems as I see it: >> >> First, it seems to work when the servers you talk to are slow, you can >> talk to thousands of them at the same time easily. But what happens if >> you initiate thousands of connections but then you find out that the >> servers do not respond slowly, but are actually pretty fast? You still > > I am not that stupid. Just like postscreen(8) handles up a LIMITED > number of connections at any point in time, so would prescreen(8) > handle only a limited number of delivery requests at any point in > time, giving back pressure to qmgr(8). > > The main benefit is that presecreen(8) parallizes the waiting > for DNS lookup, TCP handshake, and server greeting. That's exactly what I had in mind, too - the thousands I mentioned was the (upper) limit of what prescreen could IMO handle. It may be lower, but there will definitely some limited number. My assumption was that it will be bigger than the amount of delivery agents available (if it was about the same, it would make little point). But then I can't see how you can prevent opening too many connections against fast servers, unless you risk opening too little connections against the slow servers at the same time… Patrik
