Catchall vs Check recipients
We get two different common requests for features that we have solutions for, but it's funny that they are incompatible. I accidentally discovered this on my own Exchange 2003 server at home.
Feature 1: “Catchall” mailbox
The idea with this one is that you have people mailing you at info@company.com, sales@company.com, etc. and you don't want to miss a potential sales opportunity just because the sender mistyped your address. So you designate a “catchall” mailbox, where all mail sent to *@company.com goes to this one mailbox. This is an example of the kind of thing we couldn't do with Exchange 5.5 because we didn't have an extensible architecture. With Exchange 2000 and beyond, you could use an event sink to do this. We have a well-used sample in a KB article. Now these days (this wasn't so true when we first wrote this article) you really don't want to do that, because spammers who use dictionary attacks against your domain will make your life a living hell. Of course the solution to that is a good spam filter, which makes this reasonable.
Feature 2: Validate recipients in the directory before accepting message
This is a feature that was an endemic part of sendmail for a long time, as long as most people used sendmail with a local password file. Many implementations of sendmail that use an LDAP directory instead did not offer this feature, and we did not either for a long time. If you don't have this feature, and you get a lot of spam to random recipients, then your machine can spend a fair amount of effort generating Delivery Status Notifications (DSNs) aka Non-Delivery Reports (NDRs) that are sent to the sender of the spam. Of course, this sender is usually bogus, which results in the NDR “NDRing”, and when Exchange generates an NDR to an NDR, it has nowhere to put that NDR, so it puts it in the “badmail” directory.
Anyway, finally in Exchange 2003, we added this feature. To turn it on, fire up Exchange System Manager (ESM), under Global Settings, get properties on “Message Delivery”. Go to the “Recipient Filtering” tab. Check the box next to “Filter recipients who are not in the Directory”. Like other filtering, make sure that on your SMTP VS that accepts mail from the Internet, turn on the filtering. To do this, click the “Advanced...” button next to the IP address on the General tab, click “Edit”, and enable “Recipient Filtering”. With this feature, at the RCPT command, the server looks up the recipient in the AD and if no one has the email address as one of their addresses, the RCPT is denied, and the message is never accepted. Which is nice because it's up to the sending server to generate the NDR.
What is funny is that if you turn on recipient filtering, and a message comes in to random@mydomain.com, even though the catchall sink would have caught this message and redirected it to my mailbox, because the recipient filtering feature above happens at the SMTP RCPT command, the message never gets accepted. I do need to get the KB above updated to reflect this find! (or maybe some smart person will find a workaround)
Comments
- Anonymous
January 01, 2003
Exchange-faq.dk - Din portal til Microsoft Exchange Server information - Anonymous
January 01, 2003
I am a little late getting this posted!  These are session resources for the Exchange 2003 events... - Anonymous
January 01, 2003
Kevin’s TechNet “Racing Fuel” Event Resources – July-September, 2006
 
E-mail Technical Questions:... - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 20, 2004
The comment has been removed - Anonymous
January 20, 2004
You're absolutely right that turning on this option will cause more AD traffic. The Exchange server does have a local directory lookup cache that will help to some extent, but it could cause quite a load on the GC that your Exchange server is using. (to check which GC your Exchange server is using, use ESM and look at the properties of the server) It's a trade-off: do you want to spend the effort in doing AD lookups, or generating NDRs. The latter is probably more expensive overall.
Another thing to consider, that I didn't cover above but I did cover in a previous post about the recipient lookup feature, is that enabling recipient lookup makes a dictionary attack against your domain much easier. - Anonymous
January 21, 2004
The comment has been removed - Anonymous
January 21, 2004
Unfortunately there is no built-in tarpitting in Exchange 2003. It is something that we're looking at doing for future releases. It would be theoretically possible to do it using a protocol event sink, although I don't think we have ever tested doing that to know what other side effects it might have. For instance, it might slow down other concurrent SMTP connections to your server, depending how you write the sink. - Anonymous
January 22, 2004
Maybe you could, in a future post, explain how features are determined for upcoming releases of Exchange Server. I tested the version 4 Beta release way back in time, and do test for several other current Beta products, but this mainly involves discovering bugs. If features request are made through a Beta program, it's almost always triggered by something that doesn't work as expected in the Beta, not something completly new.
How do you come up with a list of new features that are to be included in a new release?
In a 'Meet the Expert' session here in the Netherlands last December, I discussed a problem for which ' the expert' knew a ' feature design request' was already on the list: how did it get there? Not my single PSS call I assume..
On topic: An event sink might be the solution (isn't that the case for almost anything that's not build into Exchange server). The problem with this sink would be testing: I hate to fiddle with the production environment, and testing this in the lab won't tell much about slowdown effects. Most labs (mine for example) run less speedy hardware and are unable to generate huge amounts of traffics. That's what you need to test this type of sink. - Anonymous
January 29, 2004
Would the Check Recipients also catch domains that you are forwarding to? - Anonymous
January 29, 2004
Oooh, haven't looked at this feature with domain forwarding in mind. For sure with AD contacts this works, they can be validated with a LDAP lookup. But does recipient filtering look at configured address spaces and routing configurations? I would like to know that too. - Anonymous
January 29, 2004
I checked with the PM for the feature and he confirmed my assumption that check recipients only checks recipients in "local" domains. That is, domains that have "this exchange organization is authoritative for this domain". Any other "remote" domains, for which Exchange just relays, are not checked. If it did, then the feature would be broken for most users. - Anonymous
March 01, 2004
David Lemson said:
It's a trade-off: do you want to spend the effort in doing AD lookups, or generating NDRs.
I don't see the tradeoff. If you generate NDRs, don't you still have to do the AD lookup to know it's an NDR? Therefore, isn't just doing AD lookups always less work than doing AD lookups AND generating NDRs? Or am I missing something?
I was pretty excited to see the new feature in 2003 so that we can ease the strain on our Exchange server from all the NDR generating. - Anonymous
March 01, 2004
The comment has been removed - Anonymous
March 03, 2004
The comment has been removed - Anonymous
March 03, 2004
The comment has been removed - Anonymous
March 03, 2004
The comment has been removed - Anonymous
July 05, 2004
Hi,
Is there a way to send mail to one or few catchall mail address from diff. domain. how to add contacts to Active Dir..
from outlook contacts it is easy to send mail. but from exchange address book it is return back to client with the error message. NDR ....
Ex. (1) user1<admin@mydomain.com>
(2) user2<admin@mydomain.com>
Sanjay Dhunna