Many times when I'm working on various mail servers that have Spam Filter for ISP I have to start/restart various services in testing. For example, I may have to stop Exchange to do a patch or fix or something. In that process I often don't want SF shoving email into my data stores while I'm bringing them up and down. Currently I set the forward IP to a non-existant one to force SF to start queing mail rather than delivering it. This way I don't lose any email but I also don't worry about changing my data stores in the middle of patches or updates. Rather than faking the system out with this non-existant IP maybe it would be better to have a checkbox to force SF to queue mail so that it doesn't continually look for a non-existant IP.

<G>

bill

Bill,

I'm not sure I understand the need for this. If you had email coming in directly from the internet to Exchange, you'd still have the same issue, either you need to stop the IMC or change the config on your router/firewall to stop the email to exchange. Adding SpamFilter in the picture would mean having the additional option to stop SpamFilter instead of reconfiguring the router/IMC.

But as I said, maybe I didn't understand fully your need :-)

Roberto F.
LogSat Software

This feature is simply a checkbox that forces Spam Filter for ISP to stop delivering emails... the same routine that would happen if the destination SMTP server were unavailable would be forced to occur. Basically, this makes SF store and queue emails rather than delivering them. An environment that already has SF installed and operational and forwarding email over to a mail server based on the SMTP destination may still at times need to take down the mail server. Whether it's to rebuild, upgrade, backup, restore, troubleshoot corruption of an Exchange information store, restore overtop of an online information store, or rebuild an information store from scratch (if this happens then emails bounce because the mailbox doesn't exist yet but the SMTP service may have started automatically during boot, I have to race SF to stop the service before SF gets to it), apply patches, whatever, the need is still there. During those times it would be beneficial not to stop email from coming in, but to stop SF from attempting delivery. Store it up and queue it just like what would happen if the server is not there. What I do when I'm doing a series of upgrades or troubleshooting on one of the mail servers is put a ficticious IP in the SMTP delivery config. In essence I've forced SF into a store and queue mode so that nothing changes in my information stores during one of these processes. LOL, I bet that's the longest post I've had here <G>

bill