>I have been having some weird problems with my mail service. > >I am running Imail 6.05 with it pointed to the IMGate machine for outbound >gateway. > >Problem is the Imail queue has messages in it. Usually there is never more >than 2-3, if that many. It usually never has any messages >in the queue due to the IMGate machine handling final delivery. At one point >there were 70-80. I have since changed Imail to deliver its own outbound >mail, bypassing Imgate except for inbound.
hmm, you're going in the wrong direction. IMail dumps on Imgate ip. When Imail delivers to internet, it must do DNS lookups to find the MX ip, open the often long SMTP session, etc, etc. and re-queue the msg. People install IMgate to offload from Imail, but sometimes Imail just gets so constipated it can't send out mail very well. I bet the problem is within Imail (on the LAN) simply because I haven't seen IMGate ever mess up getting handed mail from Imail, or in handing mail to Imail. It was always a problem external to IMGate. Lots of interesting problems to solve for my ISP clients, but none within the IMGate itself. >In the Imail log files I noticed several things: >The log file from 11/28/01 has entries in it until 08:37 11/29/01 rather >then ending at midnight. The log file for 11/29/01 >has entries starting at 00:00 as it should. > >The Imail server only runs Imail and Bind. > >In the Imail logs I have noticed a large number of these errors for the >SMTP process: >rl-recv: Blocking call cancelled >SMTP_DELIV_FAILED > >Searching the archives I found two things, one was that a large MTU size >could cause this so I changed the MTU on the IMail server to 576. MTU shouldn't be an issue over the LAN. What version of FreeBSD and Imail? >Second was that this is related to a winsock error which reseaching winsock >errors indicates the program calling the winsock is at fault (IMail). ah, that's more like it. >Secondly, my IMGate machine seesm to be under stress. Running top on the >IMGate machine shows load avgs around 65-70% with 140 -180 processes. that's not too bad. count the number of SMTP and SMTPD processes with: ps aux | grep "smtp -t u" -ci ps aux | grep "smtpd " -ci count the number of incoming msgs (delivery by IMgate not yet attemtped) with: mailq | grep "\* " -ci and also just check the mailq in general. Also, in pflogsumm reports, check the "avg dly" for deliveries to IMail. and with ./pflogsumm.pl -u 20 -h 20 -i --smtpd_stats --verbose_msg_detail maillog | less ... check the peak and avg SMTP session connection time from imail to imgate. Note that postfix will always prefer receiving incoming messages over delivering outgoing msgs. A very fast delivery to imgate can exhaust the disk bandwidth (seen as a buildup of incoming queue in posfix, mailq msgs marked with *), leaving no bandwidth for the queue manager to read and send outgoing msgs. >The >IMGate machine is a P200 with 96Mb ram. ah, any swapping going on? postfix smpt and smtpd processes take about 1 meg each, so 96 megs is not a whole lot. might slip in 256 megs. how many msgs do you do per day? what does uptime show for load factors? >It seems to very sluggish and some >clients are reporting duplicate messages. in pflogsumm, postfix will warn when postfix was delivered but postfix didn't get the final handshake back, so defers the msg as undelivered, saying there may be duplicates due to failed SMTP session. any errors dmesg? errors in /etc/log/messages? Note that Imail has a bad habit of getting its knickers twisted trying to deliver big doses of mail, and/or when it's queue backs up. That's why Scott wrote his thingy for helping Imail's queue processing. Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
