How to limit outbound messages per user per day?

To the best of my knowledge E12 (Exchange 2007) does not have this setting set any where.
Yes, there were talks about introducing this feature on E14 (Exchange 2010), however in its BETA Stage I haven't heard of it.

In exim you could implement something like this using the config files, and disallowing access to port 25 with certain restrictions are efective.

Instead you might look into using iptables and restrict the number of port 25 access from inside going out with a rule like, match on port 25, sync packets and use -m limit  --limit 100/day
(that would mean using a linux box the forward outgoing port 25 messages on your LAN.
Or aggregates it for total outgoing mail that comes from your mailserver.

Also be sure to disallow ANY other port 25 to the outside world than comming from either this box OR the mailserver.

i Agree to Exchange_Geek. I have never heard about such a setting on the Exch 2007 Server.
The reason you were blacklisted was coz you may not have the Recipient filter enabled,, and hence your user account got harvested. check if you are open for relay... it should not...
and thats it...
Limiting a user to send mails our wont make much difference in Your senario.. its the Filterngs who can help You !

-x-sAm-

Concentrating on settings in exchange, iptables, firewalls are of little use if the email messages were generated externally referencing the user's email address as the sender which is what I read in from the "identity theft" comment.

Did the mailings originate from your exchange server?
Do you have exchange configured to allow relaying to remote authenticated users?  This might be the simplest thing to cure, do not allow remote relaying through your server.

If you limit a users system to only send 100 mails per hour then it will be limited to 100 mails per hour, ligit or not.

@noci, how would you expect to limit 100 mails per hour ?? which mechanism do you propose within Exchange functionality ??

There is no way.. you can do it through Exchange functionality.... noci, do you have any supporting articles for that?

@x-sam: that is what i was asking to noci, well lets see if he has a new code ??

I was supporting you man.. not fighting for points :-)
That was a good question but... cant help...

-xsam-

In my opinion, Exchange is not such a powerful product.
You should consider turning tu Postfix, on Linux

haha... interesting answers... the question was if its possible on exchange and if yes how...
now the answer is going every where execpt the exchange..
Where is the asker DraconianSoul? no comments from him since he posted this Question..

The author suggested he was willing to set up a separate server running Linux if it provides a solution to his requirements. To be honest, I'm surprised there's not a simple canned solution out there for this given the current state of email affairs, perhaps with some kind of heuristic learning capablility and auto-thresholding based upon past performance.

If there's something available either in Exchange, of at least in the Windows environment, I'm all for staying with familiar technology. If not, a Linux solution makes sense.

@x-sam,

an linux solution was explicitly suggested if Exchange couldn't do it. For linux this is almost a no-brainer,
most components are available on almost all distributions.

Besides if you are willing to setup a linux system as mail-transfer server, then you can do more then just rate-limit mail. Serious mail checking can be done using Amavis (+Spamassassin / +Virus checking (needs one of several available anti virus tools) / +Razor bulk detection) and other supporting tools to fortify your mail service.
Amavis+spamassassin can also support detecting mail from botnet's.
Besides amavis you then still need to choose postfix or exim as front end to the internet.
Both can handle ignoring mails using (DNS) blacklists, Handle SPF or better DKIM or reject misformed mail-messages (not following SMTP protocol).
Using access list macro's you can also make easily exim handle greylisting.  (Accepting mail only when it is sent a second time AFTER a minimum time., but it delays mail form several minutes mostly about 1 hour).

Nice info..

The difficulty is meeting the author's request to rate limit outgoing mail by user if someone ends up on a botnet delivering spam. Eventually the public IP of the outbound mail server ends up on a RBL, a big problem if, like many, email's critical to the business. It's a problem I've faced in the past.

Things like iptables work well for the aggregate email flow, and if you're watching the logs it can provide an alert to a problem. But it's tougher to find that magic threshold for a large group of users than for an individual.

* Addendum: Just avoid the IP-based  limits,  for smarthosting.
The issue is, since your Exchange server will be originating all the mail, it will only be one IP address  -- your smarthosts can't actually see the real user's ip address for tarpitting purposes.

Also, by default  'allowed relay hosts'  bypass all the limits you set.


However,  by  using the options to relay POP3 and IMAP connections, AND use the external server as your MTA,  you  could place your  Exchange server completely behind a firewall.

Don't allow any connections  directly to your Exchange server whatsoever, except from your LAN, and let the more suitable software  accept connections from the internet,  and implement necessary restrictions

(Like restricting the ability to send e-mail for authenticated users  and applying tarpit limits  per-ip)


i.e.  Instead of someone outside your network being able to connect to your exchange server to send mail to you, or for a remote worker to connect directly to SMTP, they must connect to your other server.

Or use your Outlook Web Access,   provided  you secure that appropriately  (with tarpit limits as an emergency fallback  for that as well).

 

I think hfraser and noci are on the right track...  I think many might be mislead however.  It wasn't Exchange SMTP  that was compromised.  The spammer sent out a message posing as IT staff and asked all the users for their names and passwords.  One user took the bait and sent back their credentials.  After that, the spammers were able to make MAPI connections (most likely via RPC over HTTPS).  We have an antispam SMTP gateway already in place and no SMTP service from Exchange is available outside the firewall, authenticated or otherwise.

It sounds like exchange doesn't have the ability built in and that I need to forward all outbound email to a smart host running an SMTP service, which I'm OK with.  It doesn't sound like Iptables or any sort of firewall would do the trick.

@ arnold - Yes the mailings were coming from our Exchange servers.  SMTP is blocked at the firewall and Exchange SMTP is set to reject mail not from our subnets.

@ ai_ja_nai - Switching from Exchange is not an option.  I can implement tools from other makers, however.

@ hfraser & noci - You mention a few different products.  Do any of them seem to fit the bill better than the others?  Can you point me in the right direction for more information?

The exchange has to be open to access from the outside to have this done.
Do you have OWA available to the outside?

All rate limiting will do is take longer for the mailings to go out, but they will eventually go out.  The problem you will run into is that important mailings will be intertwined and will be unnecessarily delayed.   As well as adversely affect your server/s.

An option you can use is to setup a server based rule to check for incoming impersonator type of mailings and block them from reaching your users. I.e. use domain signature, SPF, etc.

Often administrators make the mistake of requesting information from users via email, but then are surprised when a fake request comes and the user responded.

That is correct. Outlook Web Access and Outlook Anywhere are both enabled and available from the internet.  This is how the spammers were able to use this person's email account to send spam.

"important mailings will be intertwined and will be unnecessarily delayed."  This is fine and desired.  The user would call to complain and we would investigate and discover the problem.  In the mean time no excessive mail would be delivered to the internet.

Again inbound SMTP is not the problem.  The only SMTP server on our network visible to the internet is an Antispam gateway that does not allow relaying.

An inbound phishing mailing is what started this process. This is what needs to be addressed and prevented from happening again.
Using account lockouts if they are not in place should be done to prevent harvesting.

If someone breaks into your place, limiting how many items can be carried out at the same time does not fix the issue that someone broke into your place.

The same technique used to get the credentials from the user could get the same user to run an attachment or access a website that would install a bot, backdoor, virus etc. into your network and potentially bringing your entire network down.

Limiting those emails from getting through is a simpler/easier process and is likely an additional setup/configuration on your existing mail gateway server.

Depending on which mail gateway you use, you could setup mail log data crunchers that would crunch the maillog and generate traps alerts if excessive mailings from the same source is done rather than waiting for the recipient to call the sender to advise them two, three, four times that they have yet to receive the mailing before the user will check with the administrator to determine if there is a mailing issues.  The none-receipt of mail process can last from a few hours to a few days.

Many linux distributions fit the bill.
Take your pick:

CentOS or RedHat   (http://centos.org  http://redhat.com)
Debian (http://debian.org ) + derivatives
Gentoo (http://gentoo.org) + derivatives
Suse (http://suse.com )

Choose upon your preference.
Also you need tools like: (with their websites for reference).
Amavis:   http://www.ijs.si/software/amavisd/
SpamAssassin: http://spamassassin.apache.org/
Razor: http://razor.sourceforge.net/
Clamav: http://www.clamav.net/
Also checkout any linux AV tool, several are available.

w.r.t. iptables, all distro's have a config file/script that activate the iptables settings.

Reliably identifying phishing attempts is almost as tricky as identifying spam. I use MailScanner and Spamassassin on my mail server for inbound and outbound email. It will flag as phishing and email with a link if the domain doesn't agree with the domain that sent the email. So a message from TD CanadaTrust bank with a link to http://hackme.com will get flagged. Problem is, it's not too difficult to forge the email envelope as well. To make matters worse, I still get false positives from companies that don't understand how anti-phishing works, leaving it up to me to decide if the mail's legit or not.

Phishing is common, and the success of botnets/spam indicates that it's also very successful. All this spam I'm getting is coming from somewhere, and there's a chance it might be me. So even if I've got the latest anti-phishing techniques, some will get through.

The issue is not to identify a broad scope of phishing attempts, but a limited scope that will prevent an external phishing attempt to expose local user credentials with access to the OWA. I.e. administrator@localdomain or sysadmin@localdomain, etc.  Using domain signatures, or SPF could limit that type of a phishing attempt where it is more likely than not that the user will respond to an email seeming to come from Administrator@localdomain asking for the AD domain credentials especially if the real administrator has made similar requests.

My suggestion is instead of concentrating on trying to rate limit outgoing emails, one should concentrate on improving the mail gateway functionality to tag/reduce the possibility of an external false mailing making its way to the local user.

Exchange outgoing SMTP is precisely what was compromised.  Without using the SMTP protocol,  Exchange can't send a single message to hosts on the internet.
I suppose what you really mean is they didn't use authenticated SMTP to relay messages.  

By using a smarthost to a server with configurations to rate-limit e-mail, you will be able to accomplish outbound rate limiting, which cannot be done natively by Exchange itself.

I sent you a reference to a very decent mail server software program, that is fairly easy to configure  (GUI-based) and has a "Max msgs from a single email address/hour"  option, which means that if you allow the Exchange server to relay, but disable bypassing the limit, and set such limit,  the Exchange traffic will be limited in rate.  Other spam controls are available.

You might want to think about setting up some scripts to PAGE you immediately, if the rate limit ever gets hit.

Granted, as with any MTA/smarthost solution, there is a caveat that you will have to fully configure the MTA.

Another caveat, is, that,  the spammer can change what e-mail address they "claim"  to be coming from at any point in time, i.e. change their From address, in the mail headers, and such, if they successfully determine they are being rate limited. Rate limiting doesn't prevent _ALL_ spam at all from getting out, and they can probably get around it.

It just takes possibly a dozen or so messages a day for a couple days to get blacklisted, unfortunately.

You best watch your  postmaster@domain.com  mailbox carefully, and other abuse addresses for any complaints,  in addition to any throttling methods.


An alternative  to just a smarthost MTA that may take a little more work is to use a dedicated Linux-based distro like Untangle --  http://www.untangle.com/   place the box in bridging mode, in-between your Exchange server and the internet.  This has a "Spam blocker"  plugin available, and by removing the default outbound policy, this can be set it apply spam filtering  to _outgoing_ messages, also, instead of just incoming.


If someone outside your LAN is able to make MAPI requests, then you have a bigger issue  also -- an inadequately secured network.   RPC over HTTPs  shouldn't be enabled on a properly secured Exchange server,  if HTTPs is allowed through the firewall.
(If HTTP and HTTPs traffic to the Exchange server are blocked at your perimeter by a firewall, then RPC over HTTP is fine, it's a serious exposure to outside attacks, otherwise.)

From the MS Technet KB http://support.microsoft.com/kb/266686


How to Limit Outbound Connections

 1. In Exchange System Manager, click the virtual server that you want to configure.
   2. On the Action menu, click Properties.
   3. Click the Delivery tab, and then click Outbound Connections.
   4. In the Outbound Connections dialog box, click to select the Limit connections to check box, and then type a value for the maximum outbound connections.
   5. By default, the time-out time is set to 600 minutes. Type a new value if you want to change the default value.
   6. Click to select the Limit connections per domain to check box, and then type a value for the number of connections that you want to allow for each domain.
   7. Click OK and then click OK again to close the virtual server properties.