Hi Victor, On 2 juin 2010, at 18:49, Victor Duchovni wrote:
> On Wed, Jun 02, 2010 at 05:14:45PM +0200, Proniewski Patrick wrote: > >> So it appears that the connection between MAILGW and LB is not always >> properly closed. Am I wrong? > > http://www.postfix.org/postconf.5.html#smtp_connection_cache_on_demand > http://www.postfix.org/CONNECTION_CACHE_README.html > http://www.postfix.org/postconf.5.html#connection_cache_ttl_limit perfect shot. You pinpointed the origin of my timeout issue. After reading the aforementioned documentation, I've decided I don't need connection cache on this particular postfix instance. I've added to main.cf: smtp_connection_cache_on_demand = no and now, timeout count has dropped to 0-5 per hour (due to other smtp server). Very nice. >> smtp_destination_concurrency_limit = 10 > > A bit low, especially when most traffic goes to the same place. I would > recommend the default of 20 or even 50 in some similar cases. Increasing > the concurrency limit will likely reduce the backlog and demand for > cached connections. Raised to 50 >> smtp_destination_recipient_limit = 15 > > This too is likely counter-productive. Decreasing envelope splitting > will reduce the number of messages and thus demand for cached connections. Will have to discuss this a little bit later, because I think I have another problem that could be related. >> 15:51:24.276369 F 5721:5721(0) > > Postfix closes the connection two seconds later. > >> 15:51:24.276858 P 205:265(60) >> 221 co7.domain.tld service closing transmission channel > > The LB or the server behind it violates SMTP by sending an out-of-turn > SMTP reply. > >> 15:51:24.276910 R >> 15:51:24.276916 F 265:265(0) >> 15:51:24.276930 R 4094209693:4094209693(0) win 0 > > Postfix is already gone. This is harmless, but the either LB or > custom mail-server behind it mishandles EOF by sending an out-of-turn > reply. If you don't want connection caching, turn it off. load balancer is fine (I've tried two: Nortel 2424 and Cisco+ACE module). The proprietary mail-server is to blame, certainly. Thank you very much for this educative reading of my tcpdump output. Patrick PRONIEWSKI -- Administrateur Système - SENTIER - Université Lumière Lyon 2
smime.p7s
Description: S/MIME cryptographic signature
