But the main problem here is as far as I see it that imail doesn't work as it should 
on w2003.

This problem as I have described in ealier mails to this list, is only occuring when I 
try to go to the w2003 platform, as soon as I
roll it back to the w2k its solved.

The try today showed that there is no ig difference in receiving mail on w2003 with 
7.x and 8.x 
When I opened the smtp after moving the mailboxes there where a queue on the Imgate 
gateway with around 1000 mails
Now 16 hours later it was 2600, switching back it took 30 minuttes an the queue was 
delivered.

Now its down to 150 which is rather normal on a Sunday

Imgate is already dumping around 4-5k of messages everyday which are rejected based on 
the rules.

Having an Imgate as outgoing gateway only to take care of mail to go out on the 
internet it is as offloaded as I can get it.

The network traffic on this new box is a mystery even with all the mail in queue it 
still could be standing there doing nothing...
Using spoolviewer from Horizon I saw that it several times was receving 0 mails doin a 
flush got it going for a while but still
after around 20 - 25 minutes it looked like the same.

And even at the time right after a flush I got only 1,5 % use on the nic, but the nic 
is working doing a copy paste of 25gb of data
and around 180 000 files it took only 50 minutes to copy the mailboxes from one server 
to the other, using around 70% of the
bandwith.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Len Conrad
Sent: 16. november 2003 19:02
To: [EMAIL PROTECTED]
Subject: RE: [IMail Forum] after upgrade to 8.04


>So now I rolled back to the old server and in less than 15 minutes I 
>have delivered more than 25% of the queue.
>Out of this I conclude that Imail 7.x and 8.x does not run very well 
>with heavy traffic on w2003.

You can throttle internet-to-IMail flow by reducing the number of concurrent SMTP 
sessions to Imail in your IMGate:

transport_destination_concurrency_limit
Limit on the number of parallel deliveries to the same destination, for delivery via 
the named message transport.

Create a new transport in master.cf by duplicating the standard smtp line, and name it 
"imail", and make the maxproc param "1" (vs
default 50)

in transport.map, change each Imail domain like this:

isphuset.no smtp:[ip.ad.re.ss]

to

isphuset.no imail:[ip.ad.re.ss]

and in main.cf,

imail_destination_concurrency_limit = 1

...... which will prevent postfix from opening more than 1 SMTP client sending to 
Imail.  This is a slow as you can go for
deliveries.  :))

A problem could arise if IMGate's inbound mailq for IMail domains is filling quicker 
than IMGate can send to IMail with one SMTP (if
true, you are totally screwed).


With "1", if Imail is still refusing mail from IMGate, you can't really do any more 
with IMGate to fix the mess within IMail.

If IMGate's inbound queue is growing (which is not to say that it must be emtpy, but 
just stable), AND Imail is ok, then increase
the 1 above to 2, watch IMail queue, repeat.

The objective is to smooth out spikes in inbound to Imail by buffering in IMGate, so 
the spikes don't send Imail queue into spiral
of queue buildup.  All inbound to Imail gets dribbled by IMGate to Imail with 1 SMTP 
session.

For the Imail outbound, you must also have Imail sending its outbound to IMGate, so 
Imail can dump its queue on the IP of IMGate
without DNS/SMTP delays.

Of course, you should have the filtering in IMGate such that it is blocking 80% of 
inbound mail as spam anyway, which is a typical
number these days for larger ISPs, and probably about where an operation such as yours 
will be.

Len


_____________________________________________________________________
http://MenAndMice.com/DNS-training: St Louis; Atlanta; Orlando; San Jose
IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free


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/



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/

Reply via email to