How to track who is sending spam through an Exchange server

You don't want to specify a smart-host on the SMTP virtual servers. That's what's causing your mail not to be delivered between the servers. You might think that your SMTP connector will "override" the settings on the SMTP virtual servers, but it won't.

Postini has problems taking delivery from an SMTP connector. They aren't actually doing store-and-forward-- they were acting more like a layer 7 proxy between the remote destination SMTP server and your sending SMTP server. If the remote SMTP server had rejects a recipient, for example, Postini will return an error that puts the SMTP connector into retry state, "clogging up" the SMTP connector's queue. They haven't changed this behavior, so you're going to have to go thru stupid configuration tricks to route around their brain-damage.

Edit: Here's some background on what Postini's problem was, historically. I know this was still the case in 2007, but I don't know if they've buckled down and made their service a true store-and-forward service or not: http://groups.google.com/group/microsoft.public.exchange.admin/msg/9155c2fb5a0c3238

Edit 2: Have a look at the guide here: http://www.postini.com/webdocs/outbound/en/outbound_config_en.pdf

Postini is still completely brain-damaged and stupid, apparently. They want you go through wild gyrations (and, frankly, they have you screw up how Exchange is supposed to work) to get your mail delivered to them w/o using an SMTP connector in an Exchange 2003 environment because they're STILL not just doing store-and-forward.

Basically, rather than allow you to use built-in functionality in an SMTP connector in Exchange (and allowing the Exchange routing engine to make the best judgements about how to move the mail around between servers in a multi-server environmnet) they want you to create a patchword of SMTP virtual servers with smart hosts enabled and relaying allowed-- in effect end-running the routing functionality in Exchange.

Morons.

We got attacked by a spammer earlier this week as well. One piece of advice I found was to look at the full headers of the earliest spam message you can find and look for the invoked by UID. You can look this up in the password file to determine which login was used to run the process that sent the emails.

For what its worth, the entry point for the spam turned out to be our web mail interface. The spammer logged in using an existing account and password and then sent emails using the web mail application. From what I can tell, the spammer never compromised the actual system.