> My friend is one of the most capable programmers that you will find,
> he's done a great deal of work in the last 5 years within
> Microsoft's framework, and I don't expect for this to be a challenge
> for him.
This is not at all a comment on his skills--many of us program for
Win32 as well--but you're talking about an OS platform whose companion
mail platform (Exchange) had no way (zero) to reject at the envelope
until last year.
> In terms of scale, I would expect to see a server handle not much
> more than 500,000 messages in a full Declude/IMail environment, and
> with an average of more than 10 pieces of spam per address per day,
> a solution of this sort would need to effectively resolve against
> 50,000 or so E-mail addresses.
# of messages has no intrinsic relationship to # of users. These are
different requirements, though they are related insofar as the former
predicts the number of simultaneous lookups against the data source
that must be completed without quenching socket, memory, or CPU
resources.
In any case, you're defining this requirement: "Must support up to
50,000 addresses." That's fine for you. MXs we support service
millions of accounts in constant flux due to adds and changes.
Something built to your requirements would not be sufficient for us.
As I mentioned, however, _even you_ have no need to build anything:
ORF already does what you need.
> While I'm not at all sure how to properly index this information for
> rapid use, I do know that you could split the data into user and
> domain, and first query the domain, and then the user, and that
> would likely mean for the most part that you would need to do one
> query (full string match) on about 1,000 domains, and then another
> query on an average of maybe 50 user addresses.
You're goldmanning--I guess that's the opposite of strawman :)--one of
a zillion use cases to match your design, so that's not an accurate
general depiction of MXs that accept mail for 50,000 accounts. Our
largest installations by user count have very small numbers by domain
count.
> Pete over at Sniffer has figured out how to search the entire source
> of a message with tens of thousands of rules complete with
> wildcards, and he does that quite efficiently considering that the
> application loads the entire rule base every time it is hit with a
> message.
A very different task. I won't bother you with any more
differentiators. Suffice it to say that tens of thousands of objects
is not a realistic target for a scaleable mail application. It may be
a realistic target for a particular deployment. I am not questioning
that it may work for you, but (see below) there's nothing to build!
> I think a capable programmer would not at all be bothered by the
> demands. There's absolutely no reason why this couldn't be done.
My ultimate point is that _there is no reason for anything to be
written_. If you want 50,000 users and text file input is what you
want, use ORF. Geez, it's 99 bucks. Vamsoft has done a very fine job
with their product.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
