I am running Exchange 2000 with Symantec Mail Security 4.6. We have contacted with a commercial service to provide us a secondary email server offsite. The offsite server collects and queues mail for us whenever our system is unreachable to the outside world.
We are having some issues with the queue hanging when the secondary server tries to transfer mail to us. I would like to "whitelist" the server to bypass filtering as an aid in trouble shooting the problem but I can't find a way to do that in the SMS software. I see how to whitelist by sender name but I can't find any way to white list a particular server.
You seem to be combining concepts of a sender whitelist (allowed sender users/domains) and a recipient whitelist (allowed recipient users/domains).
Out-of-the-box, IIS SMTP supports a form of recipient whitelist, since you can configure it to only accept mail sent in _unauthenticated_ sessions for its local and alias domains and a specific list of relay remote domains. All other remote domains will not be serviced in unauthenticated sessions. You can also choose whether authenticated sessions will be allowed higher privileges so that they may send to unlisted remote domains.
With 5xxSink, the recipient whitelist is enhanced greatly by only accepting mail to a list of specific _users_ @ serviced domains -- instead of initially accepting mail to any username @ local, alias, and remote domains *regardless* of whether a mailbox exists.
As far as a sender whitelist, 5xxSink has no participation at that level (the MAIL FROM part of the SMTP convo).
IIS SMTP on its own can restrict connections at the stack level by source IP (so no one else can even start a convo with the server); it can restrict delivery to both local/listed and unlisted domains by always requiring an authenticated session; or it can allow anonymous sessions to deliver to local/listed domains, while requiring an auth'd session to send to unlisted domains.
If you only want to accept mail from specific partner domains, it is best to require incoming authentication for all mail and not even publish an MX record. Otherwise, you're just inviting people to forge one of your allowed sender domains, easily foregoing any apparent security; further, publishing an MX in the public DNS for a server that, in reality, accepts mail only from a private list of allowed servers is misleading.
If you did not want to require a login and password -- by the way, you *can* log in to IIS SMTP regardless of whether you have a local mailbox; you just need to exist in the SAM or AD -- but you want to have non-forgeable protection, you'd gather the source IPs of the outbound mailservers of your allowed domains and allow anonymous connections only from those IPs. Problem with this approach is maintenance; logins and passwords are portable once you provide them to a partner, while their source IP would have to be changed on your end if it ever changes on theirs. I hope these could get you a reply.