Catchall vs Check recipients

Exchange-faq.dk - Din portal til Microsoft Exchange Server information

TrackBack — Tue, 20 Jan 2004 15:30:00 GMT

Exchange-faq.dk - Din portal til Microsoft Exchange Server information

re: Catchall vs Check recipients

Michel — Tue, 20 Jan 2004 23:33:00 GMT

I'm wondering how this 'validation' will affect performance on the AD. There is a Anti-SPAM server in front of our Exchange environment, and to prevent the NDR NDRing activating this on our incoming Exchange box (next in line) doesn't help. The Anti-SPAM box must do this. I've never used the Anti-SPAM server's LDAP lookup option to avoid an AD performance decrease, but in the future there will be a point were I must start using it. Hundreds of NDR each day...

Michel

re: Catchall vs Check recipients

David Lemson — Tue, 20 Jan 2004 23:41:00 GMT

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.

re: Catchall vs Check recipients

Michel — Wed, 21 Jan 2004 10:39:00 GMT

In the previuos post you mention that doing a brute-force dictionary attack could be solved by "tarpitting" where the <x>th RCPT command and higher all add a sleep period to each next one. If this is a MSX SMTP virtual setting (or SMTP Internet Mail Connector setting) I'm missing something.
I can start another connection for each incoming message exceeding <x> recipient, but not slow it down AFAIK.

(Digging in the Anti-SPAM server SMTP settings to see if this box can do it...)

re: Catchall vs Check recipients

David Lemson — Thu, 22 Jan 2004 03:51:00 GMT

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.

re: Catchall vs Check recipients

Michel — Thu, 22 Jan 2004 22:15:00 GMT

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.

re: Catchall vs Check recipients

Ed Woodrick — Thu, 29 Jan 2004 13:40:00 GMT

Would the Check Recipients also catch domains that you are forwarding to?

re: Catchall vs Check recipients

Michel — Thu, 29 Jan 2004 22:25:00 GMT

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.

re: Catchall vs Check recipients

David Lemson — Thu, 29 Jan 2004 22:33:00 GMT

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.

re: Catchall vs Check recipients

Craig Webster — Mon, 01 Mar 2004 20:28:00 GMT

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.

re: Catchall vs Check recipients

David Lemson — Mon, 01 Mar 2004 21:28:00 GMT

I didn't make it clear above. You're right, you have to do the AD lookup eventually, but the tradeoff is whether you do the AD lookup during the SMTP protocol, making the client wait, or just accept the message and then do the lookup later and potentially expend more effort to generate the NDRs. The other tradeoff is whether you want spammers to know immediately if a recipient is invalid vs the effort to generate the NDRs to the bogus address for invalid user mail.

re: Catchall vs Check recipients

Craig Webster — Wed, 03 Mar 2004 14:53:00 GMT

That makes sense. We're a small company, so we only have one AD domain and one Exchange server. In addition, we have a mail gateway sitting in front of our Exchange server, so the traffic is all local. In our case, the "client" is always our gateway, so I don't think making it wait while the Exchange server does its AD lookup will be a problem. Plus the spammers are contacting the gateway (which accepts mail to all users, valid or invalid), not talking directly to the Exchange server, so that won't be a problem either.

Question - do you know if spammers gather NDR's to determine if a recipient is invalid? If so, then does it really matter whether they get an immediate "user unknown" in the SMTP conversation, as opposed to waiting a little bit to get the NDR?

re: Catchall vs Check recipients

David Lemson — Wed, 03 Mar 2004 15:46:00 GMT

They probably rarely gather NDRs that are sent back later, firstly because that requires them to have given a real address in the MAIL FROM: of the SMTP conversation, which would receive that NDR. If the client is notified that a recipient is invalid, the server tells it immediately in the SMTP conversation "that recipient is invalid", so the server does not generate an NDR (or in SMTP terms, a DSN). It is the CLIENT that actually generates the DSN in this case.
So for yourself, your "mail gateway" is the machine that is generating the NDR/DSN back to the spammer. I would say that in your situation, turning on the "resolve anonymous recipients" feature does you almost no good, because when you turn it on, you're just transferring the work of generating NDRs from the Exchange server to the "mail gateway". Also, you continue to get the traffic of those messages in and out. (if they're blocked at the RCPT command in SMTP, the data never gets sent).

re: Catchall vs Check recipients

Craig Webster — Wed, 03 Mar 2004 17:54:00 GMT

What a useful discussion this is turning out to be for me. I follow what you're saying about the spammers. I also agree that if we shift the work of NDRs to our mail gateway, we still have the traffic in and our of our T1. However, we have reduced the amount of data our Exchange server receives (even though the gateway still has to receive it). Since our Exchange server is more than just an SMTP server (it is our primary information store as well), offloading work from it to the gateway seems to be a decent tradeoff, especially since the gateway is just sitting there passing mail along.

However, since you brought it up, do you have any other suggestions? It seems to me that you can't have it both ways. If we have our gateway block bad addresses at the RCPT command in SMTP, we will reduce the traffic in and our and force the work of the NDRs back to the sending server (which would be the "client" in this scenario). Sounds good so far. However, doesn't this allow the spammers to know immediately if a recipient is invalid?

So, in our case, if we assume we don't want the spammers to know immediately if a recipient is invalid, then it sounds like our best option is to at least shift the burden of NDRs from the Exchange server to the mail gateway. Am I getting close?

The joys of home improvement

David Lemson's WebLog — Wed, 05 May 2004 06:58:00 GMT

re: Catchall vs Check recipients

Sanjay Dhunna — Mon, 05 Jul 2004 07:37:00 GMT

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

Resources for Webcast - Exchange Server 2003: Tips, Tricks, and Shortcuts (March 24, 2006)

Full of I.T. — Fri, 24 Mar 2006 20:36:09 GMT

Kevin&rsquo;s Webcast Resources:
Exchange Server 2003 &ndash; Tips, Tricks, and Shortcuts
Here are...

re: left the window open, spammers attacked!

Coreyh.com — Thu, 27 Apr 2006 19:33:06 GMT

July-September 2006 - TechNet Event Resources

Full of I.T. — Sat, 05 Aug 2006 23:16:51 GMT

Kevin’s TechNet “Racing Fuel” Event Resources – July-September, 2006
&nbsp;
E-mail Technical Questions:...

Exchange 2003 Event Resources...

Stewed Prunes... — Tue, 15 Aug 2006 06:45:06 GMT

I am a little late getting this posted!&nbsp; These are session resources for the Exchange 2003 events...