Noel, Wietse, Victor, Thanks for your replies. Here goes the description of my problem:
I have a pool of postfix servers receiving SMTP traffic from an upstream MTA via a load-balancer. Both the MTA and the LB are out of my control; the MTA may not be a postfix, and the LB may not be using a "least-connection" strategy. The LB should balance messages coming from the MTA, but it is actually balancing new connections only. The MTA is opening very few simultaneous connections, and reusing each of them for thousands of messages. As a result, only a subset of my pool is actually working, each of them with one connection being intensively reused. In order to improve this situation, I want to close the connection at the server side from time to time, thus forcing the MTA to open a new connection for the next message to come. The new connection will be balanced and may be opened against a new postfix server of the pool, which otherwise may remain unused for hours. So my understanding is that I need to launch anvil at each server of the pool, and make it reply 421 from time to time to its local smptd, so that this smtpd will disconnect from its client (the MTA). However, there is no way to force this 421 reply at anvil based on total connection duration or total number of transactions. The existing parameter that may be close to what I'm looking for could be [http://www.postfix.org/postconf.5.html#smtpd_client_message_rate_limit], which is rate-based. If I use this parameter, how can I instruct anvil to reply with 421 and not any other non-special reply? At what point of the SMTP transaction will the disconnection happen, after acknowledgement of a DATA command? The SMTP client may not be sending any RSET command at all, just thousands of MAIL-RCPT-DATA series... Regards, Diego -----Original message----- From: [EMAIL PROTECTED] Sent: lunes, 17 de noviembre de 2008 17:29 To: postfix-users@postfix.org; [EMAIL PROTECTED] Subject: Re: Force SMTP server disconnect On Mon, Nov 17, 2008 at 11:07:44AM -0500, Wietse Venema wrote: > > I don't want to force a retry at the client side, I want to force > > the client to stop reusing the connection and open a new one from > > time to time. Ideally after a max number of messages, if not possible > > after a TTL for the connection between the SMTP client and Postfix. > > Can you describe the PROBLEM, instead of the SOLUTION (limit > connection reuse)? If the right solution is to indeed cause clients to re-establish connections, the most plausible way to do that would be to issue a "421" response to the "RSET" command after ".". If the client is a Postfix system trying to re-use connections, it will discard the cached connection, and open a new one. Other MTAs may (will) behave differently, but this is the most robust approach as responding 421 to "MAIL TO", ... will be taken as a transaction failure, and will more likely cause the client to defer mail. The current implementation of RSET is subject only to the "junk command limit", which limits the number of non-transaction commands *before* a transaction, but not the total number for the connection lifetime. The feature the OP is requesting (if it in fact solves a real problem and is not the result of poor problem analysis), requires new code to implement an optional connection-wide limit on "RSET" commands. Note, this feature used on servers, would defeat the "time-domain" connection re-use strategy in Postfix clients. Postfix switched from re-use counters to re-use timers, because counters lead to "slow-attractor" problems, where a very slow busy server attracts all the available connections. Servers forcing clients into counted re-use model risk the same phenomenon unless they are behind load-balancers that implement a "least-connection" load distribution strategy. The dynamic behaviour of SMTP under load is rather subtle, naive anti-abuse strategies can damage the infrastructure by forcing sub-optimal client-behaviour onto legitimate and abusive systems alike. -- Viktor.
