I had a similar issue - "Lost Connection after RCPT" on sending or
receiving from the internet or the local network. No network or dns related
issues, all the sudden the smtp process was very slow. I did a tcpdump of
the Lo interface and noticed a number of dns lookups to the maps/rbl stuff.
Remembering that the RBL stuff is no longer free, I commented out all maps
related configuration and the smtp process came back to life, no delays at
all.

  Not sure if this is related to your problem but it might help. I am still
attempting to discover WHY having the maps configurations still enabled
killed the smtp process. If anyone else has any ideas, please let me know.

Vernon A. Fort

-----Original Message-----
From: Duke Ionescu [mailto:dukemastre.com]
Sent: Monday, October 01, 2001 12:39 PM
To: postfix-userscloud9.net
Subject: Oct-01 bug in 20010228-pl03? SMTPd SLOOOOOW

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2 separate servers, both running heavily modified RedHat 6.x with
kernels 2.4.x, the same exact thing has happened this morning after
running fine and independent of eachother with Postfix 20010228-pl03
and Cyrus 2.0.15/SASL 1.5.24 for a few months. One server had light
loads, the other relatively high (mail-wise, not CPU-wise).

This morning, both servers started to exibit long timeouts when
accepting mail from email clients both local and remote addressed to
either local or remote recipients. Many of the Outlook [Express]
clients, which have the default timeout set to 60s, saw the dreaded
"Wait or Stop" message which seems to baffle corporate users ;)

At first I thought it was a DNS problem since I was only aware one of
the servers was exibiting this behavior at the time. I looked around
and BIND/hosts/resolv.conf were fine.

I then telnetted directly to the SMTP port for a manual session. I
was expecting for smtpd to time out before greeting me with `220
mail.domain.com ESMTP.´ This was not the case, as this response came
instantly. It timed out once I issued a `RCPT TO:<userdomain.com>´
command. At this point I didn't really know what was wrong, I
thought maybe something had gotten corrupted and Postfix couldn't
find its mailboxes - a person on-site just does hard reboots w/o
looking at what's on the screen when something doesn't work (against
my explicit instructions not to do so!), and this morning he just
unplugged the power cord while the server was running! I ran e2fsck,
no probs there.

In any case, to make a long story short, before looking at the source
code to see what Postfix tries to do after it recieves a `RCPT TO:´
command I decided to upgrade to the Snapshot 20010808 - I was
planning on doing this anyway because I wanted to have the ability to
gracefully delete messages from the queue while Postfix was running.
To my surprise, after upgrading, smtpd is running proper again!

I then noticed the same behavior on the other server, I telnetted
into it to verify it had the same problem which it did, and I
resolved it the same way.

Just a report, although I am curious how many others have had this
happen and if it affects any other versions (release pl04, pl05?).

P.S. Is there a digest version of this list? The `help´ command (to
majordomo) does not mention anything of the kind.

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBO7iqHcWLnVTiCTx7EQLNdwCgpm5Zy8YFTQQb2MVKsPKr7845zKUAoPMP
m5bHYy2Rlr1Q2+nPKegJui2P
=SKxM
-----END PGP SIGNATURE-----

-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.281 / Virus Database: 149 - Release Date: 9/18/2001
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.281 / Virus Database: 149 - Release Date: 9/18/2001
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]