On Thursday, March 24, 2005, 11:37:21 AM, Len wrote:
>>In every one of these cases I have had to remove these rules due to >>false positive reports from customers. LC> it's the %ages that count. If you get a handful of complaints that are LC> whitelisted, while stopping 100's of 1000's of msgs/week or month, that's LC> acceptable and manageable. This is a matter of policy and I suppose. Anecdotally, all of the systems we work with - even those we don't work with who ask us about our services - are interested in a system which accepts the messages, blocks / holds the spam, and allows their customers to immediately retrieve any false positives. Those that I have communicated with are very concerned that no legitimate messages will be bounced or held... and if some extremely small number is held it can be identified and recovered quickly. From my perspective this is clearly the direction of market forces at the present time. I don't doubt that there are some systems out there that are willing to be more aggressive but I do not find them in the majority - they are usually very specific niche systems... The same, for example, discard some messages based solely on finding a particular character set. Based on this I would have to say it's not the %ages that count, but the local policy and the level of service that the system administrator wants to provide. I've never had a discussion with one where some percentage of lost (bounced and not recovered or otherwise) messages would be acceptable - no matter how small that number might be. They seem to either care that some messages will be lost, or they do not. >>I'm not saying that it should never be done - only that it is an >>extreme approach LC> absolutely not extreme. What IS extreme is the %age of crap coming out of LC> these networks vs, the extremely small number of legit msgs. How about this... it is an extreme approach in my experience. >> that in my experience has has never been >>satisfactory. LC> but your approach is to accept the entire msg, then decide if it's spam, so LC> you would think like that. Not necessarily. I like to use the best tool for the job. I am working with systems (I can't say who) to scan the first part of a message and reject or break the connection during or immediately after the DATA phase - often after reading less than 1K bytes (frequently less than one packet). These same systems then go on to temporarily block connections based on policy transgressions, etc. The difference here is that there is no blanket policy that says all of x-type of network should be blocked without looking. Rather these systems are very much more precise and dynamic. This approach allows for the best of both worlds. The long term design goal for SNF is to operate intelligently at all of these levels and to have each node share information so that it becomes nearly impossible to spread spam or malware for any reasonable gain, and so that in the mean time and beyond all legitimate messages will get through in spite of the abuse that might be present. This must be the goal of technological solutions that operate on any open environment because such an environment _always_ has the potential for abuse... but I digress... LC> There are plenty of mail admins got fed up trying, and more who are LC> becoming fed up, with that approach that bogs down their mail server, so LC> they've go to an approach like IMGate that rejects after the envelope, and LC> keeps the crap out of the mail system, and above all off of the user's LC> mailbox server. I'm sure there are, and they tend to be very vocal about it - which makes for some sensational press. I've seen the "President of The World" speak loud and clear about this kind of thing - that the incoming spam is equivalent to a denial of service attack etc... I'm sure it is at times (I've seen it myself). However, the approach you are promoting is not, IMHO, the best approach, and I meet more people who feel this way than do not. As a rule, if it is possible to deliver a legitimate message rather than block it arbitrarily then the consensus is to deliver the message. Here the word "possible" is chosen carefully to mean that I find extreme prejudice against any filtering mechanism which by design will bounce or otherwise block any legitimate messages as well as an extremely strong desire to utilize systems which will deliver these messages even in the presence of extreme abuse. This may even, at times, appear to be an irrational bias - one that I find is frequently as strong, or stronger than your bias against systems that make the attempt when such a simple approach (your network blocking scheme) is available. In the end it is a lot easier for a CTO to remain CTO by explaining how the CEO still gets a little spam from time to time than it is for them to keep their job explaining how the CEO didn't get an important message because it came from the wrong network somewhere --- perhaps an important client at an airport with their laptop for example. As for overloaded servers - I've got more than one story where using SNF has allowed several overloaded MTAs to be consolidated onto a single server (often when the alternative was to further increase the size of the server farm). Clearly it is not only possible, but practical to use filtering mechanisms that are more precise than blocking whole networks by type. From what I can see, this represents a higher grade of service to the end users. In the end - each system must make their decision based on their own environment and best thinking. For my money, blocking subscriber networks en-mass is simply not the best solution because there are viable alternatives that provide a higher grade of service. _M To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
