<< 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.