No, you can't do messages-per-second restrictions with IIS alone.
What I would immediately recommend is installing a HIPS product like eEye
Blink, which has an IPS signature for the number of messages in a set
period of time and will drop connections over that limit. However,
realize that in a virtual hosting environment the blocking will be by IP.
So if you have a malicious client sending messages from an ASP script on
webserver 1.2.3.4 to mailserver 1.2.3.5, and 1.2.3.5 detects the limit has
been exceeded, it will block SMTP traffic from _any_ website on 1.2.3.4
for a set period.
Controlling SMTP overuse from virtual hosts is a complex problem. You
should be ready to spend some time on a comprehensive solution. For
example, you should try to lock down your clients to only using a
particular ESMTP username/password to submit mail (do not simply allow
relay from the webserver IP), as this adds accountability/auditability.
You can then build (or have built, possibly buy) event sinks to
distinguish the abusive traffic and limit/block it.
Another solution is to look at installing an anti-spam proxy in-between
your webservers and mailservers. You need to treat your clients as
severely untrusted in this matter, and performing egress filtering, if
only for rate limiting (not content inspection), is totally legitimate IMO.
-- Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
------------------------------------
Have you considered an additional SMTP Virtual Server (different IP and
/ or port) for the client that needs to send the mass emails? That
would allow you to remove (or raise) the per connection message limit
for that given sender.
Grant. . . .
I told you that! Do you want to be able to have any detection of the
problem, or not? As I said, this is an immediate way to prevent what
sounds like malicious abuse of your system.
> So, I can't force users to use
> ESMTP username/password in they application.
What do you mean, "so" -- what does that have to do with the above? You
can _always_ force people to present credentials before you relay for
them. And in fact you should, since that is the only way to determine
that username j...@example.com submitted MAIL FROM j...@example.com, as
opposed to username ma...@anotherexample.com submitted MAIL FROM
j...@example.com.
> For example in Linux environment
> the customers use only sendmail for send mail and this program can be
> modificable for add at the header the domain that send mail.
When you require a web application to present credentials, you are
ensuring that you have a thorough audit trail of which user at a given
source IP submitted the mail. There is no better, more accurate way of
tagging each SMTP session with the responsible SMTP sender so you can take
action accordingly.
In IIS is
> not
> possible control the domail that send mail? only is use an
> authentication I
> can make this?
I don't know what your problem is with authentication: it is the most
granular, accurate way of determining who was responsible for mail
submission. Anything else is either forgeable or meaningless. For
example, if user on web site example.com authenticates as X...@example.com
and sends MAIL FROM Y...@someotherdomain.com, would you say that
'someotherdomain.com' is the one that submitted the mail and penalize them
for overuse? Of course not. The responsible party is X...@example.com on
the hosted web site example.com.
In shared hosting environment how to configured IIS smtp
> for
> evict the problem of massive send mail?
How about reading my suggestions more closely?
-- Sandy
My impression was that the mass e-mails were not an appropriate use of the
system (the word "evict" being used later) -- but I dunno.