We've recently switched from "sendmail" to "qmail" as the "SMTP Server" for
the majority of Eudora/Outlook/Messenger clients on campus.
We've been looking through the tcpserver/qmail logs and see a disturbing
pattern. We see hundreds of entries per day like the following pair, mostly
sporadic, but often occurring in clusters:
Apr 25 10:31:38 larch SMTP: 988212698.570558 tcpserver: ok 620
larch.cc.uic.edu: 128.248.155.164:25070.counsel.uic.edu:131.193.141.82::1066
Apr 25 10:31:38 larch SMTP: 988212698.586034 tcpserver: end 620 status 256
It's the "status 256" that bothers us. It seems we don't see a "new msg"
creation entry from qmail after these "status 256" entries, but we do see
"new msg" not long after "status 0" entries.
From what I can gather from reading the qmail discussion list archives,
status 256 is somewhat of a "catch-all" for several possible
problems. (Note: we are running the "fixcrio" filter to fix the "bare
linefeed" problem and tcpserver is running paranoid if that matters. We've
also checked to be sure that "status 256" hosts resolve correctly on
inverse and forward DNS queries).
So, here are some questions we hope someone will be able to answer:
1. Does "status 256" from tcpserver->qmail-smtpd on the SMTP conversation
mean that no message was created for delivery? (It seems that way to us,
but we'd be a bit shocked to hear it's true because we have not gotten many
complaints, and it would seem that this would be a major problem).
2. Is there any way to get more verbosity/specificity out of qmail (other
than by using "recordio") about what is happening to trigger the "status 256"?
3. Is there any way we can tie an "ok" log entry like the one above to the
corresponding "new msg" entry created by qmail? We need to be able to tie
it all together from first SMTP contact to final
message disposition. This was possible in sendmail, but we're not seeing
an obvious way to link the entire history of a message together in our
qmail logs.
We've searched the qmail mailing-list archives and have yet to find a clear
answer to any of the 3 questions.
The concurrency limit is set to 200 and the smtp.cdb contains just two
entries to permit relaying only from our 2 class B networks.
The server is redhat 6.2. The "free" command shows lots of available swap
space.
Could this be a ulimit problem?
Any help is appreciated.
