TimerSecondTimer: Access violation |
Post Reply ![]() |
Author | |
George S. Forsyth ![]() Guest Group ![]() |
![]() ![]() ![]() ![]() ![]() Posted: 10 May 2003 at 5:15am |
Hello, 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.
|
|
![]() |
|
LogSat ![]() Admin Group ![]() ![]() Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
![]() ![]() ![]() ![]() ![]() |
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 |
|
![]() |
|
George S. Forsyth ![]() Guest Group ![]() |
![]() ![]() ![]() ![]() ![]() |
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. |
|
![]() |
|
LogSat ![]() Admin Group ![]() ![]() Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
![]() ![]() ![]() ![]() ![]() |
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.
|
|
![]() |
|
George S. Forsyth ![]() Guest Group ![]() |
![]() ![]() ![]() ![]() ![]() |
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? |
|
![]() |
|
LogSat ![]() Admin Group ![]() ![]() Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
![]() ![]() ![]() ![]() ![]() |
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. |
|
![]() |
|
George ![]() Guest Group ![]() |
![]() ![]() ![]() ![]() ![]() |
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. |
|
![]() |
|
LogSat ![]() Admin Group ![]() ![]() Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
![]() ![]() ![]() ![]() ![]() |
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. |
|
![]() |
Post Reply ![]() |
|
Tweet
|
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.184 seconds.