Robert Meyer wrote: > > Hi, > > On Mon, Feb 09, 2004 at 10:15:22PM +0100, Andre Oppermann wrote: > > Daniel Lorch wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Robert, > > > > > > | From 217.26.52.23: > > > | Trying 62.2.95.11... > > > | Connected to mx.hispeed.ch. > > > | Escape character is '^]'. > > > | 220 mx.hispeed.ch ESMTP Sendmail 8.12.6/8.12.6/tornado-1.0; Thu, 29 Jan > > > | 2004 15:53:30 +0100 > > > | > > > | From 217.26.52.15: > > > | Trying 62.2.95.11... > > > | telnet: connect to address 62.2.95.11: Connection timed out > > > | > > > | > > > | So your statement sounds kind of incomplete to me... Have you > > > | implemented other 'protection' mechanisms? > > > > > > in case you don't understand Markus' statement: You're doing it the > > > wrong way. If my mailserver wants to connect to mx.hispeed.ch it > > > does not get a connection, therefore it keeps the mails in its > > > queue (by default 1 week for qmail), retries and retries, because > > > it thinks that it might get a connection sometime. > > > > > > Now the users think their mails have been succesfully delivered > > > because they won't receive a bounce mail until the mail expires > > > in the queue (1 week). Quite frankly, that sucks. > > > > Yep. > > > > > Doing it the right way would mean accepting the connection and > > > sending back an error such as > > > > > > ~ 451 Your mailserver has been blocked, please see > > > http://url/to/policy.html for more information > > > > > > That would bounce immediately and the error message is verbose > > > enough for sysadmins to understand what's going on. > > > > This is not correct. A 4xx error will keep the mail in the queue > > until it expires (just like blocking smtp connections). What you > > want is an 5xx answer for an immediate bounce to the user. > > > > > My server is blocked. You'll get a call from me tomorrow. > > > > > > Please be a good net citizen and do it the right way. > > > > Blocking on the network level is a bad idea. To reject emails > > it is the best thing accept the connection and emit a 5xx error. > > That will generate a bounce on the sending mail server and get > > it out of the queue. Otherwise the sending mail server will try > > again and again until the week is over. That might look like there > > is someone hitting on you without ever stopping. > > > > If you don't have enough capacity to do the 5xx errors on the main > > mail servers then setup another (small) machine and redirect (instead > > of blocking) all connections to that box and let it emit 5xx errors. > > That can be a very small and fast deamon. It can reject maaaany > > connections per second. Even if it is too slow it doesn't matter > > much. Important is that sometime soon there will be a 5xx error > > and the sending mail server stops trying. We could write such a > > small 5xx error deamon if you need one. It's not a big thing. > > that's exactly what we are about to implement at the > moment. Unfortunately, it will take some more time, > until we have tasted and set up everything. Besides > what would you suggests for such a small one-purpose > deamon (we are currently examinig Turnaway from > http://postmaster.gtcs.com/turnaway.nxdl). Are there > any other recomendations?
I'd suggest using tcpserver from DJB daemontools package and just the smtpd program from the qmail-ldap package (www.nrg4u.com). -- Andre ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
