<< btw, Please abstain from using "tiny arial blue characters"  Such a 
style, any styel, really adds absolutely nothing to your content of your 
text, except aggravation for readers vbg >>

>How should I configure IMAIL or should I bother?

It's technically impossible to "configure Imail" for your purpose, so, 
hmmm,  don't bother. vbg

ie., there are no params within Imail that correspond to external load 
balancing systems. Imail is strictly an RFC compliant mail system.

 > run 4 or more front end IMAIL servers load balanced from the Cisco 
6509.  have those servers sync users

Imail doesn't "sync users", (whatever that means).

Even when Imail's user base is external, eg SQL Server, each Imail host 
retains "ownership" of any given user account as "local" exlusively to that 
Imail machine. No Imail machine knows about accounts on other Imail machines.

So you set up 4 Imail machines, A, B, C, D,  all using the same external 
SQL server and tables for the user accounts database.  Specifically, ImailA 
will only know about ImailA's users, will know nothing about B, C, D's users.

A user accountA exists on ImailA. UserA is unknown to Imail's B, C, and D.

The following must occur:

1. Incoming mail for accountA must be delivered/routed specifically to 
ImailA.  Imails B, C, & D know nothing about accountA and will reject the 
mail as "unknown user". (see below for some relief).

2. User A must know, and define in his mail client program, his specific 
ImailA server's addresses for POP3 and SMTPD protocols.   eg

POP3.ImailA.domain.com

SMTPD.ImailA.domain.com

Also, each user must know the URL of the Imail machine where his mail 
account is:

http://ImailA.domain.com

UserA cannot Web login to http://ImailB.domain.com, or C or D.

(I'm assuming your half million accounts are under one domain. If not, the 
pb is segmented and therefore easier)

Why?  Because only ImailA "knows" that UserA is local to ImailA even if 
ImailA's database is external SQL, and therefore only server ImailA will 
AUTHenticate UserA for POP3/IMAP reading, SMTP AUTH sending, Web Messaging 
login.  UserA simply cannot connect to Imails B, C, and D.

 > then presto it all crashes because of open file issues?

Well, that's a littlle simple minded, since SQL knows a thing or two about 
locking, and anyway, SQL is not a "file server" but a "database server". 
vbg If your SQL DBA has configured SQL to be a file server, fire him, or 
her !! vbg

Ipswitch does not support SQL7 in the Imail's ODBC driver, which, even for 
SQL 6.5, appears to have serious multi-threading limitations when the level 
of simultaneous users is "high" (ie, "it doesn't scale well" buzz buzz).

But the "Amazing Technicolor Imail Admin Cavalry" rides in to the rescue, 
just as the Native Americans appear to overrun the fort !!

First Lieutenant Eponymous Mike Nice has re-worked Imail's ODBC source code 
for SQL 7 compatibility AND increased the multi-threadedness, so it scales, 
uh, Nice-ly.

http://home.worldnet.att.net/~niceman

 > I don't know any ideas would help?  even other products you tell me

First, that "relief" to the pb of "incoming mail must be routed to a 
specific Imail machine".

Imail's "peering" of Imail servers is a feature of the Imail SMTPD (smtp 
daemon/server) where the SMTPD A will accept mail for any account on the 
peers B, C, and D as if the mail account was local to ImailA, and then use 
the SMTP VRFY command to go rummage around the peer group to find out which 
of the peers really hosts this mail account and deliver the mail. So, this 
is "relief" exclusivley for incoming SMTP mail, because a user still must 
know and use exclusively his specific ImailA, B, C, D for POP3/IMAP, SMTP 
AUTH, and Web Messaging operations. Imaill provides no peering for 
POP3/IMAP, SMTP AUTH, and Web Messaging operations.

So, first off, since you cannot spread / loadshare a single mail domain 
over X number of Imail servers, is that acceptable?

If yes, then I think you can build a 500,000 account Imail system 
successfully, maybe even on one NT machine.

We know there is already one successful Imail system, reported to this 
list, with 250,000 accounts on one machine (and the machine is essentially 
idling), and 25 gigabytes of mail traffic per day, and many successful 
Imail systems  with 100,000+ accounts.

However, the 250K system used some of the techniques and external systems I 
discuss here: http://imgate.MEIway.com/IMGate-dual.cfm, which I'm fairly 
sure is why that system is successful.

I can't see any role for your undoubtedly very expensive load balancing 
Cisco hardware in an Imail-based mail infrastructure.  There is sufficient 
load balancing and fail over already built into the well-proven and quite 
amazing DNS and SMTP protocols to do all that you require.

Have you given any thought to defending against the 10's of 1000's of SPAM 
and email virus msg's that will be sent to 500,000 accounts every day?

Len

Please visit http://www.ipswitch.com/support/mailing-lists.html 
to be removed from this list.

Reply via email to