From some big time, our server suddenly stops sendindg the emails at the queue and we have to force it to send all email through a Postfix gateway (Wich is from my perspective, the best smtp server around, the only missing or hard thing is the logging format, much easyer with Imail Syslog to catch a problem)
:) quite the contrary, the absence of basic info in the IMail log makes it much harder to find/diagnose problems. some time spent working with postfix logs is very well spent.
The (reports for) postfix logging tells IMGate users much more than they ever knew about their Imail server and outbound mail, and IMGate has exposed all kinds of other undetected problems with routers, WAN links, DNS, and screwed up upstream networks.
220 geo.net.co (IMail 8.13 18171-79) NT-ESMTP Server X1
As you can see, this tells me that i Have like 79 connections active, the average for this values is like 50-63 .
How come, there are other companys with like 1000 Vhosts and more email volume than us, doing to handle the concurrent connectoins with Imail?
Is it possible to increment the actual response of the server for external Email connections (Because, recently, if i send for example an email from yahoo, it can take at least 2 hours to reach our server, but if i try to send an email a second later, it gets instantly to the server ??)
I've seen yahoo's internal mail routing delay msgs for up 2 hours. Don't blame your systems always.
Whats the best solution for a company like ours, beside using 100% Imail for the EmailService?
What does pflogsumm say your "avg (delivery) delay" is to Imail domains? it should be under 10 seconds, even under 5 seconds. Does the report show any deferrals for Imail domains? deferrals are the "dead canary" telling you Imail is drowning, either responding so slowly that postfix times out, or worse, refusing connections on port 25.
a Imail large queue has the well known disastrous effect on all of Imail, but with your imail relaying to postfix, you should have not Imail queue congestion (at least not for external reasons. Imail has its own completly internal problems handling its own queue).
Have you guys tried for example having Imail only as the frontend for the customers , but having like Postfix for receiveing and sending all the emails??
Most IMGate systems are setup up exactly like that. Customers send their (smtp auth) outbound through Imail which sends all outbound to IMGate, which also handles all MX traffic.
I just replaced an IMail/declude MX gateway that was taking hours to relay mail the same box running IMGate. the old gateway was totally underwater. 2.8 GHz CPU, 2 GB RAM, 15K RPM scsi disks, useless. That setup used to work great, but went to hell very fast recently, and the ISP couldn't get it back from hell. He came to me in desperation. I will report on the IMGate results later and the astonishingly bad situation of this ISP, but (of course) IMGate is running well, saved the ISP's mail system, with only 5, 6 seconds delay in relaying inbound MX traffic, with IMGate maintaining about 180 SMTPD inbound connections, and about 75 SMTP outbound connections, while doing up to 40 rejects/second and 2 million DNS operations/hour (BIND9 DNS cache is at 100 MB). I've seen the sum of those two SMTPD/SMTP session numbers at over 300 on that IMGate. postfix exhausted the default 12K open files limit, which I increased to 16K open files.
Here's the instantaneous response of that imail:
mx1# telnet xxx 25 Trying xxx... Connected to mail.xxx.com. Escape character is '^]'. 220 mail.xxx.com (IMail 8.05 xxx-4) NT-ESMTP Server X1
27K users, 143 domains.
If your Imail has 80 smtp sessions open, then that is not all coming from postfix gateway, which usually needs only 5 to 10 connections open (and will still flood/kill Imail with so few connections).
You have SMTP connections direct from Internet, plus a few smtp auth sessions (which should run quite fast: connect, smtp auth, send one msg, hangup). Verify this in the Imail logs by the IPs connecting to Imail that are not your IPs.
You've correctly identified the problem: many Imail machines cannot handle large numbers of SMTP connections and traffic, even after tweaking/tuning/powerful hardware and expert advice from Ipswitch and others.
Imail SMTPD is also extremely patient in waiting for an SMTP client to give the next command, so if Imail is being hit with a lot of slow attackers, Imail can open a lot of long SMTPD sessions which do nothing except consume Imail resources.
The solution: study your Imail logs to see what is going on with Imail SMTP, esp where those 80 sessions are coming from. You can also add more aggressive filtering on postfix, so less spam gets through to Imail.
Why isn't postfix answering as your MX?
# telnet smtp.geonet.com.co. 25 Trying 200.124.168.11... Connected to mail.geonetsa.com. Escape character is '^]'. 220 geo.net.co (IMail 8.13 3351-35) NT-ESMTP Server X1
You can try to play with Imail and friends, but you might have one of those Imail boxes that simply can't, somewhat mysteriously, handle the load. Use your postfix more to remove the load from Imail.
Slow DNS can also be a huge problem for mail, so look at using a single unix DNS for Imail's and postfix's recursive lookups.
Finally, high volume mail systems require total systems engineering. Having somebody who can "handle Unix" ain't good enough to do it.
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
