George, you have a point in allowing admins deciding what to do with that empty mail from option. We discovered that the RFC strictly forbits refusing emails with the empty mail froms. But yes, too many spammers are abusing that. Perhaps the RFC should change...

We'll see as it goes in the forums, but we are now inclined to leave the option there in future versions, but with a very visible notice informing of the RFC violation. It will be up to the users to decide what to do then.

Roberto F.
LogSat Software

Just installed the new public build and it is great. I think that the Empty From option should stay in just as it is. You have given the option the ability to quarantine or not and also to enable or not. As a ISP owner and a consultant for other ISP's I see a lot of email issues and this is one feature that is very useful.

I would think most mail servers should have a from address like root@domain.com. I know Sendmail will use root@domain.com when sending error messages.

Without the ability to block Empty From emails, this would prove to be a big security hole in this otherwise great application.

I have been monitoring all emails going through the Filtering server for almost a month now and have seen a lot of SPAM that has no From address and have been very happy with being able to block them. Now with the new version I can quarantine them and forward the Error Messages that should be forwarded and delete the SPAM.

We have not thought yet on how to handle the empty mail from in the future. The problem is that legitimate emails (mainly system error messages, undeliverable notices, email receipts) have it null. There may be nothing we can do on that one.

We are still looking in finding the most compatible error code that can be customized. The key there is the numeric response. Unfortunately there is not RFC standard that we found yet that deals with a reject due to spam. We are doing some tests with a numeric code of 550 instead of 552 and 557, but haven't finished testing yet.

FYI, we've just uploaded public build 1.1.2.117 on the website, which should take care of the access violations you experienced.

Roberto F.
LogSat Software

Hi Robert,

How do you plan on handling SPAM emails that do not have a Mail From address once you remove the "reject if empty Mail From" option?

What error message numbers would be recommened in the customized response's to prevent the reject notices from being ignored?

One of the reasons testing your application is so important to me is that besides wanting this for the ISP that I own, I also provide support to other ISP's and already have one that is interested in your product and are waitng on me to give the final say as to whether or not this is what they want. They are also looking at SpamAssassin but so far I am more inclined to use your product.

George,

When we released build 114 two bugs were discovered by users, and we had the patch ready (.117) within hours. So far, all the problems we've seen reported have to do with settings that are present in build .90 and above:

The "reject if empty Mail From" is causing valid emails to be rejected, it should be unchecked in both build .90 and .117. We'll remove this option in the next build.

An email address other than a NULL "<>" in the customized Error Handler Email field can cause mail loops in both .90 and .117.

SpamFilter's reject notices are sometimes being ignored by some mail servers, this also has to do with the error number used in the customized response. This is user selectable, and is the same in .90 and .117.

We've had a single report about attachments being blocked, but have been able to reproduce it, and are waiting for the user to confirm that it's actually SpamFilter that causes the problem.

Build .90 has some access violation issues, which unfortunately you experienced. We believe they were identified and fixed in build 114 & 117. Shortly we will release a new version that will have a fully redesigned quarantine, allowing end users to access their own quarantined items via the web. At that point we will most likely release a new public build as well.

For your last questions, we try to make all new versions fully compatible with the previous ones, so yes, it will use the same external text files as before. But it will also remove some more black/white lists from the SpamFilter.ini file and move them as well in external files. So if you have a process which appends data to the ini file, that will not work anymore.

Roberto F.
LogSat Software

Hi I am still using Spam Filter for ISP 1.1.0.90.  I am still waiting to see what other issues arise with this application before I decide to purchase it. Before I make a major change, I need to make sure that it will be trouble free, and after reading some of the issues other have had with the newer versions, I am waiting for all the bugs to be found. I don't need to put an application on my network that will give me headaches so I test and test and test more before I purchase. I guess I have been using Microsoft products too long. hehe

All in all, I like your product, I just need to be sure thats all. Besides, I want to see what new features are added and how thay work.

Q. When I do purchase it, will the new version use the same text files and this one?

IE. keyword list etc.

George,

What version of SpamFilter are you using? In build 1.1.2.114 we fixed an issue that looks related the error you received.

Roberto Franceschetti
LogSat Software

Hello,
What would cause this error?

05/10/03 01:49:48:546 -- Exception occurred during TimerSecondTimer: Access violation at address 2D2D2039. Read of address 2D2D2039 - 3

This error took place as my online billing (Quickbooks) was sending 32 billing reminders to my clients. This is the second time I have seen this happened during the last 3 weeks of testing SpamFilter ISP.