I really don't want to sound like a whiner. I need to express how satisfied I am with your product and your support. Thank you for taking the time to read each message and for sincerely listening to your customers. I wish you continued success with this product.

I believe you have a very valid logic here. Those emails need not be quarantined, no matter what. We will be releasing an updated build with customized quarantine/delete options very very soon. There won't be such an option if the dest. domain is not in your local list of domains. As you so strongly believe, you conviced us as well that such emails should simply be deleted.

Within 24/48 hours we should have a new build which will allow customized quarantine/delete options for every reject. In the meantime, disabling the quarantine will cause messages to be rejected immediately.

In fact my earlier comments are valid -- what's ironic about this issue is that my server's IP address is now listed as an open relay on relays.ordb.org -- probably because it doesn't reject immediately after a non-local RCPT TO.

I agree with your statement that SpamFilter should quarantine all mail or not, but I don't think non-local mail is in the "all mail" category. To me, there is a difference between filterable mail (mail destined to my domain(s)) and non-filterable mail (somebody is trying to use my server as a relay). I think it's fine to log it, but SpamFilter should not be spending any time doing lookups or keyword checking on mail that's not going to get to my site anyway.

We agree with you on the technical side. The decision to implement the current behavior was for simplicity on the user's end. It's easier for users to know that "either all emails are ALL quarantined or none of them are". Having exceptions where quarantine is enabled but some emails are not saved can be misleading.

In any case, soon that will not matter as we are planning of adding options for almost every blacklist field to indicate if emails rejected for that reason are to be quarantined or rejected immediately.

OK, that makes sense -- I have quarantine enabled. However, I still think it makes sense to check if a connection is trying to relay a non-local message before accepting the DATA command, even if quarantine is enabled. For example:

I stand corrected. Double-checking the code, we saw that if quarantine is disabled, and there is a reason to reject a message before having to reach the DATA command (blacklists, MAPS, no relay allowed etc), the remote connection will be disconnected before arriving at the DATA command as it should to optimize the process.