Diego Castillo:
> 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
No anvil is the wrong tool.
> pool, and make it reply 421 from time to time to its local smptd, so that
Use a policy daemon.
Wietse
> 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.
>
>
>
>
