----- Original Message -----
From: Len Conrad <[EMAIL PROTECTED]>
To: inFusion Support List <[EMAIL PROTECTED]>
Sent: Monday, April 24, 2000 5:16 PM
Subject: Re: [iMS] Benchmark


>
> >iMS is just as fast as any server for sending mail (it can optimally
deliver
> >over 7 million email messages).
>
> but over what period?  need to calculate a "msgs per time", no?
>

Per day.  We found that in ideal conditions that iMS can deliver 20 mails
per minute per thread.  Of course these are not real world conditions but
should be considered lab conditions.  However, the POST Server will deliver
mail to multiple recipients in the same domain (that are to receive the same
mail) silultaneously.

> One LSMTP user told me that with 200 SMTP client processes sqawned (the
max
> process number is an LSMTP license restriction), the Solaris machine was
> delivering an average of one 1 msg every 7 seconds, for I think 20 or 30
> thousand msgs, IIRC.  This of course isn't screamingly fast delivery and
> obviously the SMTP protocol handshaking and slowness-over-Internet of the
> SMTP client (LSMTP) to remote SMTP server would be the dominating factor
> for sending.
>

Yes, absolutely.  Which is why mail server benchmarking should be based on
ideal conditions (sort of like measuring horsepower from the rear wheels so
that there is a common point of reference).

> In the discussions I've seen with Wietse Venema in the postfix.org user's
> list, the postfix developer, he says the limiting factor is the disk
> channel, and more specifically, the mechanical delays of head movement
time
> an disk rotation time (as opposed to delivered bit rate once on track)
> since the RFC requires that every incoming msg be committed to disk before
> the SMTP server sends RECD back to the SMTP client.
>

I don't think that is much of a factor considering the performance that can
be obtained from today's hardware.

> >Receiving mail is a little bit different.
> >Whereas other mail servers have hard-coded message receipt and storage
> >functions iMS relies on ColdFusion to make many decisions.
>
> For incoming mail and anti-spam defenses, does the iMS SMTP server do
> lookups to Mail-Abuse.org, or reverse the SMTP client ip for validity?

It will use one or more RBL servers that you specify.  Of course this will
make for an additional delay.  If you want to lessen the delay you can
become a secondary DNS to the RBL servers.  Also, iMS has built-in RBL
caching.

> or
> validate that the SMTP client has MX and A records?

iMS doesn't do this natively but you could add this functionality easily
with our MX Lookup CFX tag.  We tried to design iMS with most of the
functionality outside of the server for complete customization.

> These are growingly
> common anti-spam techniques for mail servers sticking their faces right
> into the Internet nastiness.
>
> btw, Howie, for a candidate "iMS mail application", take a look at
> www.Mustang.com's own "IMS", vbg.
>
> This product is considered to have pride of place in its category and I
> think that the  category would it would be an ideal target for an "iMS"
> application.
>

If you are referring to the Mustang Server then iMS can do all of this and
more...

Regards,

Howie

> Len
>
>
> ========================================================================
>      This list server is Power by iMS
>   'The Swiss Army Knife of Mail Servers'
>    -------------------------------------
> To leave this list please complete the form at
> http://www.CoolFusion.com/iMS.htm
>
> List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
> ========================================================================
>


========================================================================
     This list server is Power by iMS
  'The Swiss Army Knife of Mail Servers'
   -------------------------------------
To leave this list please complete the form at 
http://www.CoolFusion.com/iMS.htm

List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
========================================================================

Reply via email to