Postini offers SMTP mail filtering and other options as a service. You typically configure your mail server to use their mail servers as a smarthost so that you can get accurate metering of your e-mail flow and various other add on features.
Postini doesn't use the typical 'store-and-forward' method but reflects the destination's mail server messages back to your server. Typically, this isn't a problem with Windows 2000 and 2003's SMTP server. It is however a problem with Exchange 2000 and 2003's modified virtual SMTP server.
This issue has been talked about at length in the Exchange newsgroups
here without any real resolution to the problem. Various things tried were setting the
SuppressStateChanges registry key, which is a good idea anyway if you ever plan on going to Exchange 2007, and also shortening the
Glitch Retry Interval value.
The problem happens when you have a batch of e-mails destined for various mail servers and you have one (or more) e-mail that triggers an error.
As an example, if you have 200 messages to deliver through Postini, and you have your SMTP virtual server set to deliver 200 messages per connection, if one e-mail gets rejected by any server, all 200 e-mails will get dumped into the
Messages with an unreachable destination queue. More outgoing e-mail will start to pile up on top of the 200 e-mail messages, until the retry interval is reached or you find and delete the offending e-mail that punted all the e-mail into the unreachable destination bin.
The not exactly elegant, but usable workaround? Set the
Limit number of messages per connection to: in your SMTP virtual server to
1. It isn't the most efficient method of transferring e-mail, but it will at least keep your e-mail flowing without using various registry hacks to short circuit Exchange's routing engine.

I wouldn't advise setting your retry value to
1 minute, as suggested in the newsgroup link above.
If you have a slow Internet link and send e-mails that are larger than a few megabytes, Exchange will see that the original message still has not been sent successfully and open up yet another connection to send the large e-mail out after a minute has elapsed. You basically end up with an endless amount of bandwidth being used up to send a single e-mail message that never quite makes it to the destination.
Hopefully someone out there will find this helpful, because it is an interesting "case study" in interoperability.