RE: Re[2]: [Declude.JunkMail] XML? Just Say ``NO`` !
An error checker would be handy. Especially for filters. I think I've found just about every which was to mis-spell endswith and startswith. <<< [EMAIL PROTECTED] 7/12 7:33p >>> The XML file has one more advantage: A GUI could be created by Declude (which seems to be in our future anyway) that could easily configure Declude in a very structured way. This would simplify Declude configuration immensely! It could easily be done with a group policy looking editor. That should make all of the MS admins very happy. One other advantage is that Declude could include a config file checker that can parse the file and report any errors (like missing or duplicate info). This would be much more difficult on a flat file (probably why they haven't done it before now). As for the speed issue: IMO, the difference between the XML file and the flat file processing will be negligible with the relatively small file size. The disk cache will have the file in memory almost all of the time and the extra bytes required of the XML file will be offset by the faster parsing of the XML structure (parsing of regular expressions is very fast) provided by the MS XML object parser. MS has put a lot of effort into the efficiency of the XML object parser because they use it so often! Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Monday, July 12, 2004 4:06 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! Well we differ here on this point. XML is much more verbose and will explode the size of the config files probably 1000 fold Here is a sample Now SPFFAIL spf failx 14 0 After XML - Possible Sample spf fail x 14 0 To parse the xml code for every load of declude.exe would take much more processing. This example takes the text lien and explodes it from 23 characters to 161 characters not to mention the added size to declude.exe to process the xml files. I do not think you have done much performace testing of XML in e loaded server environment. The loading of the config files from disk is minimal they should be cached due to the high frequecy of use. So 1 config file or 10 should not make much difference. Kevin Bilbee > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil > Sent: Monday, July 12, 2004 3:57 PM > To: Kevin Bilbee > Subject: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! > > > On Monday, July 12, 2004, 4:54:31 PM, Kevin wrote: > > KB> XML will definitly slow down the loading of Declude and I > know scott will > KB> not do that. XML will be a greate feature for the gateway > version though. > KB> Hint, Hint. > > I respectfully submit that this is not necessarily true. There is no > clear reason I can think of that an XML file configuration would need > to load any more slowly than the current configuration files. In fact, > I suspect that the structured nature of the file would most probably > improve the load speed if the parser were coded properly. This has > almost always been my experience when converting applications from > complex flat-file configs to xml configs. > > Consider also that it is likely an XML based configuration would > reduce the number of files required for a given system. - searching > for files takes time too. > > _M > > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the D --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: Re[2]: [Declude.JunkMail] XML? Just Say "NO" !
The XML file has one more advantage: A GUI could be created by Declude (which seems to be in our future anyway) that could easily configure Declude in a very structured way. This would simplify Declude configuration immensely! It could easily be done with a group policy looking editor. That should make all of the MS admins very happy. One other advantage is that Declude could include a config file checker that can parse the file and report any errors (like missing or duplicate info). This would be much more difficult on a flat file (probably why they haven't done it before now). As for the speed issue: IMO, the difference between the XML file and the flat file processing will be negligible with the relatively small file size. The disk cache will have the file in memory almost all of the time and the extra bytes required of the XML file will be offset by the faster parsing of the XML structure (parsing of regular expressions is very fast) provided by the MS XML object parser. MS has put a lot of effort into the efficiency of the XML object parser because they use it so often! Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Monday, July 12, 2004 4:06 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! Well we differ here on this point. XML is much more verbose and will explode the size of the config files probably 1000 fold Here is a sample Now SPFFAIL spf failx 14 0 After XML - Possible Sample spf fail x 14 0 To parse the xml code for every load of declude.exe would take much more processing. This example takes the text lien and explodes it from 23 characters to 161 characters not to mention the added size to declude.exe to process the xml files. I do not think you have done much performace testing of XML in e loaded server environment. The loading of the config files from disk is minimal they should be cached due to the high frequecy of use. So 1 config file or 10 should not make much difference. Kevin Bilbee > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil > Sent: Monday, July 12, 2004 3:57 PM > To: Kevin Bilbee > Subject: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! > > > On Monday, July 12, 2004, 4:54:31 PM, Kevin wrote: > > KB> XML will definitly slow down the loading of Declude and I > know scott will > KB> not do that. XML will be a greate feature for the gateway > version though. > KB> Hint, Hint. > > I respectfully submit that this is not necessarily true. There is no > clear reason I can think of that an XML file configuration would need > to load any more slowly than the current configuration files. In fact, > I suspect that the structured nature of the file would most probably > improve the load speed if the parser were coded properly. This has > almost always been my experience when converting applications from > complex flat-file configs to xml configs. > > Consider also that it is likely an XML based configuration would > reduce the number of files required for a given system. - searching > for files takes time too. > > _M > > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: Re[2]: [Declude.JunkMail] XML? Just Say "NO" !
Well we differ here on this point. XML is much more verbose and will explode the size of the config files probably 1000 fold Here is a sample Now SPFFAIL spf failx 14 0 After XML - Possible Sample spf fail x 14 0 To parse the xml code for every load of declude.exe would take much more processing. This example takes the text lien and explodes it from 23 characters to 161 characters not to mention the added size to declude.exe to process the xml files. I do not think you have done much performace testing of XML in e loaded server environment. The loading of the config files from disk is minimal they should be cached due to the high frequecy of use. So 1 config file or 10 should not make much difference. Kevin Bilbee > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil > Sent: Monday, July 12, 2004 3:57 PM > To: Kevin Bilbee > Subject: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! > > > On Monday, July 12, 2004, 4:54:31 PM, Kevin wrote: > > KB> XML will definitly slow down the loading of Declude and I > know scott will > KB> not do that. XML will be a greate feature for the gateway > version though. > KB> Hint, Hint. > > I respectfully submit that this is not necessarily true. There is no > clear reason I can think of that an XML file configuration would need > to load any more slowly than the current configuration files. In fact, > I suspect that the structured nature of the file would most probably > improve the load speed if the parser were coded properly. This has > almost always been my experience when converting applications from > complex flat-file configs to xml configs. > > Consider also that it is likely an XML based configuration would > reduce the number of files required for a given system. - searching > for files takes time too. > > _M > > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: REC: [Declude.JunkMail] XML? Just Say "NO" !
On Monday, July 12, 2004, 4:59:27 PM, decjunkmail wrote: d> I guess I wasn't clear enough -- Maybe I should be blunt: d> Editing XML files in notepad sucks! I should be able to d> quickly edit configuration files in notepad like we can do today d> with .txt or .ini files. d> Sure a simple XML file is ok, but try, for example, editing the d> Microsoft IIS metabase files for Windows 2003 which are now in XML. These files are not meant to be edited by humans. The XML structures used here are intended only to be edited by machine so they are constructed to match the objects and concepts that make the programming task easier with no consideration of a human editor. An XML based configuration for Declude could be made much more friendly. As for node checking, in practice this would be no more difficult than the editing that is done now... consider a test line with 7 or so fields - some of them optional. When you edit one of these you usually just follow the convention you remember and use the surrounding lines as a reference. It would be no different in a well designed XML format. _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] XML? Just Say "NO" !
On Monday, July 12, 2004, 4:54:31 PM, Kevin wrote: KB> XML will definitly slow down the loading of Declude and I know scott will KB> not do that. XML will be a greate feature for the gateway version though. KB> Hint, Hint. I respectfully submit that this is not necessarily true. There is no clear reason I can think of that an XML file configuration would need to load any more slowly than the current configuration files. In fact, I suspect that the structured nature of the file would most probably improve the load speed if the parser were coded properly. This has almost always been my experience when converting applications from complex flat-file configs to xml configs. Consider also that it is likely an XML based configuration would reduce the number of files required for a given system. - searching for files takes time too. _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] GUI - End-User is the priority!
On Monday, July 12, 2004, 3:50:39 PM, R. wrote: >>Something getting lost here in the discussion of the installation GUI is >>the request from time-to-time for an end-user GUI. RSP> This is something that we would love to do -- and would have been done RSP> *years* ago if Ipswitch allowed third-party access to web messaging (with RSP> about 20 lines of code, they could). RSP> The problem is that it requires packets going to and from your mailserver RSP> and your clients. If we don't use IMail's web messaging, we have to either RSP> write our own webserver, or come up with our own protocol for transferring RSP> the data. Worse, firewalls become a huge issue -- not only do you have to I've had this idea on my back shelf - you know, for when I get a few spare moments. ( I store those with my grove of money trees. ) At the risk of getting flamed, an XML based configuration could be leveraged here as well. Consider: An end-user GUI that sends and receives control messages (plain old text email) to the server though a special email account. The software being configured (in this case Declude) would intercept a properly formatted message to the appropriate account and would interpret the XML in the body of the message to make the required changes. A response would be sent back to that email account, again with an XML based packet of data, that indicates success, failure, or otherwise, and/or provides additional data as needed - including any part of the existing configuration that the end-user GUI might need. In fact, this mechanism would work for the admin GUI as well - (the two might even be parts of the same software). in case anybody is thinking this, yes this is part of a tool for Message Sniffer, but we always intended to share it with Declude if they would be interested once we had the time to present a prototype. It's vaporware right now due to a lack of resources - but I hope the concept starts a few wheels turning. We use a similar concept right now to offer high-end users direct access to their rulebase data. That is, we have a working tool called RESCU (REmote SCripted Updater) that can be used to create rulebase updates automatically without logging in to our online application. That utility is written in Java and runs at the command line accepting and producing XML files that contain the commands and responses respectively. In declude it would go something like this: Success! True bl.spamcop.net 127.0.0.2 0 10 12 Success! Fail weight changed from 10 to 12. ___ I know this example shows an administrative task and the thread is about an end-user GUI, however I wanted to show a proof of concept using something everyone would recognize - and without clouding it with an apparent recommendation of what the end-user GUI should be. Suffice to say that whatever features might be made available for an end user, this mechanism could easily be adapted to that task and the GUI for managing these tasks could be implemented without using any protocols that the user does not already have - the ability to send and receive email. ___ Hope this helps, _M --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] XML? Just Say "NO" !
I have to disagree with this. XML, when done properly, can be good both for people and for machines. I've seen it done this way, and worked with this kind of configuration for quite a while. It can be done well, and it can be done badly. When done well, a few simple conventions can make the XML file just as handy as a flat text file - often even better since complex configurations can be represented more clearly. That done, a GUI can then be more easily developed which will read the XML configuration file, modify it, and save the results without making it difficult to open again in a plain old text editor. This is a much harder trick to do reliably when a flat file is employed. I think with the right level of effort you will find that an XML file can be developed that will not make you want to run for the hills and will quite possibly feel even better than a plain old text file. My $0.02 _M PS: One of the really nice things about an XML file like this is that folks will be able to easily cut and paste meaningful sections of the file to share with others on the list - and to show as examples. On Monday, July 12, 2004, 3:46:24 PM, decjunkmail wrote: d> Hi, d> I vote NO for XML. d> I'm sorry, but XML is much more like a registry setting or a d> binary configuration file -- Great for programmatic manipulation, d> but terrible for manual/interactive use. d> A text file in notepad is easy to change and edit interactively d> (even remotely on low-bandwidth connections) - as long as the goal d> for declude configuration files is to facilitate quick and easy d> changes, then it should stay as a text file. d> If the goal is to create a parametric-driven, API for automatic d> configuration/provisioning or programming, then XML or registry d> keys, or a binary database is fine. d> Note - I have used some XML, mostly with ASP.NET/VB.NET and d> although I can dig my way around config.net files and the like, I d> still prefer ".ini" files if I'm going to be fiddling with d> configurations. d> Yes, XML is great to serialize database structures, move them d> across web services, or dissimiliar internal database stores, but d> they are not as friendly for configuration files. d> -Original Message- d> From: [EMAIL PROTECTED] d> [mailto:[EMAIL PROTECTED] On Behalf Of David d> Sullivan d> Sent: Monday, July 12, 2004 9:43 AM d> To: [EMAIL PROTECTED] d> Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat d> Lookup Database test for Declude JunkMail d> Ok, couldn't resist my $.02 M>> sense, but I think they are putting the cart before the horse. Wouldn't M>> it be much better to work on creating a new format for the config files d> d> Like an XML based config file that incorporated Junkmail, Virus and d> Hijack configurations as well as per user controls. Ooooh, how much d> easier that would be to control from code d> M>> In the mean time, it would make sense to also spend some time tightening M>> up loose ends which have not been getting that much attention. If you M>> asked for everyone's top 5 list from around here at least, I'm pretty M>> sure that it would include things besides a new DNSBL test on virus data M>> with a GUI installer, or the GUI itself. Declude is very capable at the M>> moment, but there are some loose ends that could be tied up over a short M>> period of time that would really help finish the foundation. Voicing d> Like a sender white list option for Vulnerabilities in DV. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] XML? Just Say "NO" !
> Editing XML files in notepad sucks! I should be able to quickly edit configuration files > in notepad like we can do today with .txt or .ini files. XML is not designed to be edited with notepad. In fact, as simple mistake could create a major problem. This is from MS itself. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] GUI - End-User is the priority!
Scott, Thanks for the technical insight - yes, I understand the challenges and remember this from your earlier feedback. However, with the new "suits" in charge, I though it was worth mentioning again for two reasons: 1. If it was easy, we would all do it ourselves :-) 2. With a bigger company now, the investment in time/people/money might be feasible to solve it a "better way" than just slaving off the Imail limitations. 3. If your new business goal is to be more general-purpose, then NOT trying to use IMail web server is a good thing. Gen-up an end-user GUI using IIS or your own embedded server and give us the option to use a dedicated IP address and port 80, or any host header combo (ip, header, port) for maximum flexibility in the firewall issue. A common trend is for network apps to have web-based GUI configuration/control. Most include their own "run-time" web server or else they put a stake in the ground and require IIS or Apache. For example, Lyris Mailing List Server (embedded TCLweb), LiveStats Log Analysis (requires IIS), and of course IMail (Embedded Apache?) Not trying to design it, but personally I would prefer a solution that is not dependent much on Imail itself and either has it's own embedded server or runs under IIS/ASP.NET -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, July 12, 2004 12:51 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] GUI - End-User is the priority! >Something getting lost here in the discussion of the installation GUI is >the request from time-to-time for an end-user GUI. This is something that we would love to do -- and would have been done *years* ago if Ipswitch allowed third-party access to web messaging (with about 20 lines of code, they could). The problem is that it requires packets going to and from your mailserver and your clients. If we don't use IMail's web messaging, we have to either write our own webserver, or come up with our own protocol for transferring the data. Worse, firewalls become a huge issue -- not only do you have to make sure that *your* firewall can handle packets on oddball ports (since the standard WWW port 80 is usually taken on an IMail server), your users do too. Some of your users will have firewalls preventing them from sending to non-standard ports. That's not to say that we won't come up with an end-user GUI -- it's just that it becomes very complicated (much more so than a GUI for our customers). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
REC: [Declude.JunkMail] XML? Just Say "NO" !
I guess I wasn't clear enough -- Maybe I should be blunt: Editing XML files in notepad sucks! I should be able to quickly edit configuration files in notepad like we can do today with .txt or .ini files. Sure a simple XML file is ok, but try, for example, editing the Microsoft IIS metabase files for Windows 2003 which are now in XML. Wordwrapping, tons of tags, and complicated node-nesting is just too much to wrestle with non-programmatically. I do not think admins should be forced to buy XMLSpy just to tweak a config file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Holt Sent: Monday, July 12, 2004 1:19 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] XML? Just Say "NO" ! I like the XML idea. It is certainly editable by Notepad across a slow connection because an XML file is a plain text file (with specific chars used for specific purposes). But it would give the people that want programmatic control over the file a great capability. Then we can choose our method: Notepad or XML object. Also, viewing an XML file in IE is very easy to pick out the data you want to view. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of decjunkmail Sent: Monday, July 12, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] XML? Just Say "NO" ! Hi, I vote NO for XML. I'm sorry, but XML is much more like a registry setting or a binary configuration file -- Great for programmatic manipulation, but terrible for manual/interactive use. A text file in notepad is easy to change and edit interactively (even remotely on low-bandwidth connections) - as long as the goal for declude configuration files is to facilitate quick and easy changes, then it should stay as a text file. If the goal is to create a parametric-driven, API for automatic configuration/provisioning or programming, then XML or registry keys, or a binary database is fine. Note - I have used some XML, mostly with ASP.NET/VB.NET and although I can dig my way around config.net files and the like, I still prefer ".ini" files if I'm going to be fiddling with configurations. Yes, XML is great to serialize database structures, move them across web services, or dissimiliar internal database stores, but they are not as friendly for configuration files. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Sullivan Sent: Monday, July 12, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Ok, couldn't resist my $.02 M> sense, but I think they are putting the cart before the horse. Wouldn't M> it be much better to work on creating a new format for the config files Like an XML based config file that incorporated Junkmail, Virus and Hijack configurations as well as per user controls. Ooooh, how much easier that would be to control from code M> In the mean time, it would make sense to also spend some time tightening M> up loose ends which have not been getting that much attention. If you M> asked for everyone's top 5 list from around here at least, I'm pretty M> sure that it would include things besides a new DNSBL test on virus data M> with a GUI installer, or the GUI itself. Declude is very capable at the M> moment, but there are some loose ends that could be tied up over a short M> period of time that would really help finish the foundation. Voicing Like a sender white list option for Vulnerabilities in DV. -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] XML? Just Say "NO" !
XML will definitly slow down the loading of Declude and I know scott will not do that. XML will be a greate feature for the gateway version though. Hint, Hint. Rember that declude loads and parses the config files for every email and unless declude could keep the parsed XML files in memory and access them from another process (declude.exe) it will put a major load on our servers in processing each email message. I agree at this time XML? Just Say "NO" ! But for a gateway product where the config files would be loaded once when the service starts up I would say "XML? Just Say "YES" !" (my 2c) Kevin Bilbee > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mike Hyslip > Sent: Monday, July 12, 2004 1:30 PM > To: [EMAIL PROTECTED] > Subject: RE: [Declude.JunkMail] XML? Just Say "NO" ! > > > Declude can always have an option to edit a file by hand, or just display > each current value, test, etc and let changes be fine tuned there and have > it write the config file itself. > > I also think it would be nice for it to either have a global include file > for the default junkmail file (for when adding a test and not having to > define on every single domain specific config file) or having it travel > through subdirectories adding tests heh. > > A module to pay my bills would be nice also :) > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Todd Holt > Sent: Monday, July 12, 2004 4:19 PM > To: [EMAIL PROTECTED] > Subject: RE: [Declude.JunkMail] XML? Just Say "NO" ! > > I like the XML idea. It is certainly editable by Notepad across a slow > connection because an XML file is a plain text file (with specific chars > used for specific purposes). But it would give the people that want > programmatic control over the file a great capability. Then we can > choose our method: Notepad or XML object. Also, viewing an XML file in > IE is very easy to pick out the data you want to view. > > Todd Holt > Xidix Technologies, Inc > Las Vegas, NV USA > 702.319.4349 > www.xidix.com > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of decjunkmail > Sent: Monday, July 12, 2004 11:46 AM > To: [EMAIL PROTECTED] > Subject: [Declude.JunkMail] XML? Just Say "NO" ! > > Hi, > > I vote NO for XML. > > I'm sorry, but XML is much more like a registry setting or a binary > configuration file -- Great for programmatic manipulation, but terrible > for manual/interactive use. > > A text file in notepad is easy to change and edit interactively (even > remotely on low-bandwidth connections) - as long as the goal for declude > configuration files is to facilitate quick and easy changes, then it > should stay as a text file. > > If the goal is to create a parametric-driven, API for automatic > configuration/provisioning or programming, then XML or registry keys, or > a binary database is fine. > > Note - I have used some XML, mostly with ASP.NET/VB.NET and although I > can dig my way around config.net files and the like, I still prefer > ".ini" files if I'm going to be fiddling with configurations. > > Yes, XML is great to serialize database structures, move them across web > services, or dissimiliar internal database stores, but they are not as > friendly for configuration files. > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Sullivan > Sent: Monday, July 12, 2004 9:43 AM > To: [EMAIL PROTECTED] > Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup > Database test for Declude JunkMail > > Ok, couldn't resist my $.02 > > M> sense, but I think they are putting the cart before the horse. > Wouldn't > M> it be much better to work on creating a new format for the config > files > > > Like an XML based config file that incorporated Junkmail, Virus and > Hijack configurations as well as per user controls. Ooooh, how much > easier that would be to control from code > > > M> In the mean time, it would make sense to also spend some time > tightening > M> up loose ends which have not been getting that much attention. If > you > M> asked for everyone's top 5 list from around here at least, I'm pretty > M> sure that it would include things besides a new DNSBL test on virus > data > M> with a GUI installer, or the GUI itself. Declude is very capable at > the > M> moment, but there are some loose ends that could be tied up over a > short > M> period of time that would really help finish the foundation. Voicing > > Like a sender white list option for Vulnerabilities in DV. > > > -- > Best regards, > Davidmailto:[EMAIL PROTECTED] > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be f
RE: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
People on this list hopefully will appriciate the irony of the following: 07/12/2004 13:42 MTLDB:1 nIPNOTINMX:-3 nNOLEGITCONTENT:-5 . Total weight = -7. 07/12/2004 13:42 Using [incoming] CFG file d:\IMail\Declude\$default$.junkmail. 07/12/2004 13:42 Msg failed MTLDB (This E-mail came from 63.246.13.90, a potential spam source listed in MTLDB.). Action=WARN. 07/12/2004 13:42 L1 Message OK 07/12/2004 13:42 [Declude.JunkMail] GUI - End-User is the priority! 07/12/2004 13:42 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] IP: 63.246.13.90 ID: A9EBEAB010C 07/12/2004 13:42 Tests failed [weight=-7]: MTLDB=WARN CATCHALLMAILS=IGNORE 07/12/2004 13:42 Last action = IGNORE. $ nslookup 63.246.13.90 Server: hi-cs-dc2.horizonint.corp Address: 192.168.1.4 Name:mail.declude.com Address: 63.246.13.90 Regards, Brad Morgan --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Introduction & Preliminary Survey Results
Yes, I agree with that. Declude as a standalone gateway product? I would love to see it. Kevin Bilbee > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bud Durland > Sent: Monday, July 12, 2004 11:42 AM > To: [EMAIL PROTECTED] > Subject: Re: [Declude.JunkMail] Introduction & Preliminary Survey > Results > > > Barry @ CHPZ wrote: > > > I realize that I have been slow in posting on this list and in my own > > defense we have been very busy, adding new staff to our business, > > visiting and talking to customers, building the business > > infrstructure and attempting to learn everything we could about our > > customers needs for both the short term and long term. > > > > * Most common complaints: > > - Documentation > > - Only available on IMail (It appears that some customers only use > > IMail to operate Declude) > > - Steep learning curve > > > If I may, I would submit that the steep learning curve is at least > partially a function of the (lack of / insufficient / not up to date) > documentation. > > And I'd also say that the minute there's a version of delcude that has > it's own built-in SMTP engine with decent logging and LDAP verification > of e-mail addresses, it's hasta lavista iMail for us. > > > -- > - > "Good is better than Evil because it's nicer" > -- Mammy Yokum > - > Bud Durland, CNE Mold-Rite Plastics > Network Administrator http://www.mrpcap.com > - > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] XML? Just Say "NO" !
Declude can always have an option to edit a file by hand, or just display each current value, test, etc and let changes be fine tuned there and have it write the config file itself. I also think it would be nice for it to either have a global include file for the default junkmail file (for when adding a test and not having to define on every single domain specific config file) or having it travel through subdirectories adding tests heh. A module to pay my bills would be nice also :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Holt Sent: Monday, July 12, 2004 4:19 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] XML? Just Say "NO" ! I like the XML idea. It is certainly editable by Notepad across a slow connection because an XML file is a plain text file (with specific chars used for specific purposes). But it would give the people that want programmatic control over the file a great capability. Then we can choose our method: Notepad or XML object. Also, viewing an XML file in IE is very easy to pick out the data you want to view. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of decjunkmail Sent: Monday, July 12, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] XML? Just Say "NO" ! Hi, I vote NO for XML. I'm sorry, but XML is much more like a registry setting or a binary configuration file -- Great for programmatic manipulation, but terrible for manual/interactive use. A text file in notepad is easy to change and edit interactively (even remotely on low-bandwidth connections) - as long as the goal for declude configuration files is to facilitate quick and easy changes, then it should stay as a text file. If the goal is to create a parametric-driven, API for automatic configuration/provisioning or programming, then XML or registry keys, or a binary database is fine. Note - I have used some XML, mostly with ASP.NET/VB.NET and although I can dig my way around config.net files and the like, I still prefer ".ini" files if I'm going to be fiddling with configurations. Yes, XML is great to serialize database structures, move them across web services, or dissimiliar internal database stores, but they are not as friendly for configuration files. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Sullivan Sent: Monday, July 12, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Ok, couldn't resist my $.02 M> sense, but I think they are putting the cart before the horse. Wouldn't M> it be much better to work on creating a new format for the config files Like an XML based config file that incorporated Junkmail, Virus and Hijack configurations as well as per user controls. Ooooh, how much easier that would be to control from code M> In the mean time, it would make sense to also spend some time tightening M> up loose ends which have not been getting that much attention. If you M> asked for everyone's top 5 list from around here at least, I'm pretty M> sure that it would include things besides a new DNSBL test on virus data M> with a GUI installer, or the GUI itself. Declude is very capable at the M> moment, but there are some loose ends that could be tied up over a short M> period of time that would really help finish the foundation. Voicing Like a sender white list option for Vulnerabilities in DV. -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] XML? Just Say "NO" !
I like the XML idea. It is certainly editable by Notepad across a slow connection because an XML file is a plain text file (with specific chars used for specific purposes). But it would give the people that want programmatic control over the file a great capability. Then we can choose our method: Notepad or XML object. Also, viewing an XML file in IE is very easy to pick out the data you want to view. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of decjunkmail Sent: Monday, July 12, 2004 11:46 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] XML? Just Say "NO" ! Hi, I vote NO for XML. I'm sorry, but XML is much more like a registry setting or a binary configuration file -- Great for programmatic manipulation, but terrible for manual/interactive use. A text file in notepad is easy to change and edit interactively (even remotely on low-bandwidth connections) - as long as the goal for declude configuration files is to facilitate quick and easy changes, then it should stay as a text file. If the goal is to create a parametric-driven, API for automatic configuration/provisioning or programming, then XML or registry keys, or a binary database is fine. Note - I have used some XML, mostly with ASP.NET/VB.NET and although I can dig my way around config.net files and the like, I still prefer ".ini" files if I'm going to be fiddling with configurations. Yes, XML is great to serialize database structures, move them across web services, or dissimiliar internal database stores, but they are not as friendly for configuration files. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Sullivan Sent: Monday, July 12, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Ok, couldn't resist my $.02 M> sense, but I think they are putting the cart before the horse. Wouldn't M> it be much better to work on creating a new format for the config files Like an XML based config file that incorporated Junkmail, Virus and Hijack configurations as well as per user controls. Ooooh, how much easier that would be to control from code M> In the mean time, it would make sense to also spend some time tightening M> up loose ends which have not been getting that much attention. If you M> asked for everyone's top 5 list from around here at least, I'm pretty M> sure that it would include things besides a new DNSBL test on virus data M> with a GUI installer, or the GUI itself. Declude is very capable at the M> moment, but there are some loose ends that could be tied up over a short M> period of time that would really help finish the foundation. Voicing Like a sender white list option for Vulnerabilities in DV. -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] GUI - End-User is the priority!
> Having an easy way for users to change their spam settings - especially managing > their own whitelists/blacklists would allow them to turn up the blocking to higher > weighting level with less false positives would be very desirable - much more so than > a cosmetic GUI for admin installations.. Has been discussed and there are examples of such in use. Sandy has one. Search the archives for more information. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GUI - End-User is the priority!
Something getting lost here in the discussion of the installation GUI is the request from time-to-time for an end-user GUI. This is something that we would love to do -- and would have been done *years* ago if Ipswitch allowed third-party access to web messaging (with about 20 lines of code, they could). The problem is that it requires packets going to and from your mailserver and your clients. If we don't use IMail's web messaging, we have to either write our own webserver, or come up with our own protocol for transferring the data. Worse, firewalls become a huge issue -- not only do you have to make sure that *your* firewall can handle packets on oddball ports (since the standard WWW port 80 is usually taken on an IMail server), your users do too. Some of your users will have firewalls preventing them from sending to non-standard ports. That's not to say that we won't come up with an end-user GUI -- it's just that it becomes very complicated (much more so than a GUI for our customers). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] XML? Just Say "NO" !
Hi, I vote NO for XML. I'm sorry, but XML is much more like a registry setting or a binary configuration file -- Great for programmatic manipulation, but terrible for manual/interactive use. A text file in notepad is easy to change and edit interactively (even remotely on low-bandwidth connections) - as long as the goal for declude configuration files is to facilitate quick and easy changes, then it should stay as a text file. If the goal is to create a parametric-driven, API for automatic configuration/provisioning or programming, then XML or registry keys, or a binary database is fine. Note - I have used some XML, mostly with ASP.NET/VB.NET and although I can dig my way around config.net files and the like, I still prefer ".ini" files if I'm going to be fiddling with configurations. Yes, XML is great to serialize database structures, move them across web services, or dissimiliar internal database stores, but they are not as friendly for configuration files. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Sullivan Sent: Monday, July 12, 2004 9:43 AM To: [EMAIL PROTECTED] Subject: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Ok, couldn't resist my $.02 M> sense, but I think they are putting the cart before the horse. Wouldn't M> it be much better to work on creating a new format for the config files Like an XML based config file that incorporated Junkmail, Virus and Hijack configurations as well as per user controls. Ooooh, how much easier that would be to control from code M> In the mean time, it would make sense to also spend some time tightening M> up loose ends which have not been getting that much attention. If you M> asked for everyone's top 5 list from around here at least, I'm pretty M> sure that it would include things besides a new DNSBL test on virus data M> with a GUI installer, or the GUI itself. Declude is very capable at the M> moment, but there are some loose ends that could be tied up over a short M> period of time that would really help finish the foundation. Voicing Like a sender white list option for Vulnerabilities in DV. -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] GUI - End-User is the priority!
Hi, Something getting lost here in the discussion of the installation GUI is the request from time-to-time for an end-user GUI. I feel the biggest drawback to our clients (we are hosting company) using our spam blocking is the total lack of any way for them to customize. Believe it or not, even trying to get them to use autowhitelist by putting entries in the WebMail addressbook is over their heads. Many of our clients simply cant understand how using the WebMail addressbook can help them with their Outlook email and they are already confused between the contact/address list inside Outlook or other client software and the WebMail addressbook. Were tired of trying to explain to a non-computer expert how to use the [EMAIL PROTECTED] IMail technique to see their spamhold folder. Expecting them all to switch to IMAP is simply not realistic, so for many users, the middle ground settings of sending suspected spam to a folder for review is not as viable as it may seem unless they are willing to use WebMail or learn these techniques. Having an easy way for users to change their spam settings especially managing their own whitelists/blacklists would allow them to turn up the blocking to higher weighting level with less false positives would be very desirable much more so than a cosmetic GUI for admin installations. PLEASE! I am not talking about unleashing the full internals of declude on end-users. Im referring to a GUI that allows them to control reasonable things like whitelists and blacklists and perhaps turn on/off groups of tests or toggle some tests. The actual grouping of the tests or the toggles should be defined by each declude admin. Thus, we could abstract everything as we choose and give our users choices like block non-US mail or enable non-US mail; Set blocking level to low, medium, or high, block using content rules block using dns rules only or whatever we choose to define. Some folks have built some of this themselves. Although I admire the cleverness in piggybacking ontop of some existing Imail rules, config files, and Webmail menus, I think an end-user GUI should not be slaved to Imail internals/specifics. The goal should be something better than what Postini or Brightmail offer as a hosted service, we wish we could offer similar easy-to-understand end-user tools for controlling the settings, reviewing the spam folder, etc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, July 12, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Sharyn (and others that despise GUI's and learning new things at this stage in the game), I think that we must all recognize that the majority of Declude's market lies with those that aren't nearly as experienced with this stuff as we are, and they need a GUI in order to tap deeper into that market. Whether we like it or not, a GUI will happen and I'm sure it's a top priority for them. I think that at the same time we should be understanding of the need and the importance of this for their business even though it doesn't suit our needs. Scott already indicated that he planed on having a system where the GUI was just simply an overlay to the config files and not necessarily required. There is no reason why they can't do that if they set out to make that happen. So if they do this right, it will have little or no effect on us. We shouldn't complain about the proposition of a GUI as long as this is the case. IMO, new features like the one that they released would be best addressed in updates to the GUI interface as a separate executable. This GUI interface could enable the new test by way of a check box, and it could be highlighted on a 'What's New' tab/selection. I don't see any reason however for separate 5 MB installers that leave DLL's lying around, especially for these purposes when they should simply be having us register and log into a customer's section of their Web site so that we can get the downloads instead of doing this by way of an app. They certainly shouldn't assume that one-size fits all so far as the way that things are configured as they did this time. IMO, it was a bit premature for this to have been released in this way, the real GUI and the rest of the process should have come first. Matt Sharyn Schmidt wrote: Declude is not a simple thing to implement and configure. Those of us running it are more than capable of adding a line to our config files and deciding how to weight it/configure it/otherwise implement it. We don't NEED a "click OK to install" GUI that does something to our configurations that we're going to have to go change anyway. I have been quietly listening to this thread, before I threw in my 2 cents, but I have to agree here. The "old" system of just letting us manually a
Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
> Scott already indicated that he planed on having a system where the > GUI was just simply an overlay to the config files and not > necessarily required... I agree that there's nothing wrong with a configuration GUI. There is, however, something VERY wrong with a non-working, non-informative INSTALLATION GUI as far as it predicts non-working, non-informative GUIs to come. When the mainstream configuration option is (still) manual editing, (a) not revealing what is to be silently added to the configuration; (b) not allowing the manual addition to be turned off; and (c) not disclosing the non-negotiable 8-point weight are all very poor indicators of the authors' present ability to create a GUI for less experienced users. Adding an 8-point test abounding in FPs without notification would be catastrophic for the targeted crop of newbies, far more than it was for us. Nobody would mind a user-friendly GUI that we could work around if desired. But the "GUI" we've seen this week was user-unfriendly in the extreme, really a poorer omen for its intended audience than it was for us. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange Addresses into IMail Aliases! http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/ --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Introduction & Preliminary Survey Results
Barry @ CHPZ wrote: I realize that I have been slow in posting on this list and in my own defense we have been very busy, adding new staff to our business, visiting and talking to customers, building the business infrstructure and attempting to learn everything we could about our customers needs for both the short term and long term. * Most common complaints: - Documentation - Only available on IMail (It appears that some customers only use IMail to operate Declude) - Steep learning curve If I may, I would submit that the steep learning curve is at least partially a function of the (lack of / insufficient / not up to date) documentation. And I'd also say that the minute there's a version of delcude that has it's own built-in SMTP engine with decent logging and LDAP verification of e-mail addresses, it's hasta lavista iMail for us. -- - "Good is better than Evil because it's nicer" -- Mammy Yokum - Bud Durland, CNE Mold-Rite Plastics Network Administrator http://www.mrpcap.com - --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] GUI
Title: Message Hi, I don't need the GUI (anymore) - but I fully appreciate the need for one. However, I wonder whether it is wise to invest into a GUI at THIS stage. The Declude product has been very quick to grow in features, way beyond what Scott could have originally imagined when he "designed" the current set of config files. Declude has outgrown the current config file concept. Frankly - I think it would make more sense to FIRST overhaul Declude in a new version that uses a different config file system (e.g., XML with nested nodes and using attributes where applicable. This would repalce the current text files in a bunch of subdirectories having positional parameters that can take call kind of meanings depending on context.) Once the configuration of Declude has been moved into a sensible structure, then writing a GUI would be much more sensible. Otherwise, a GUI will be written for something that should be obsolete in the first place. Best RegardsAndy SchmidtH&M Systems Software, Inc.600 East Crescent Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206http://www.HM-Software.com/
[Declude.JunkMail] OT - Managed firewall
Anyone out there know of a good managed firewall solution? Please contact me directly. Many thanks in advance, Jose Gosende --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.718 / Virus Database: 474 - Release Date: 7/9/2004 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
Sharyn (and others that despise GUI's and learning new things at this stage in the game), I think that we must all recognize that the majority of Declude's market lies with those that aren't nearly as experienced with this stuff as we are, and they need a GUI in order to tap deeper into that market. Whether we like it or not, a GUI will happen and I'm sure it's a top priority for them. I think that at the same time we should be understanding of the need and the importance of this for their business even though it doesn't suit our needs. Scott already indicated that he planed on having a system where the GUI was just simply an overlay to the config files and not necessarily required. There is no reason why they can't do that if they set out to make that happen. So if they do this right, it will have little or no effect on us. We shouldn't complain about the proposition of a GUI as long as this is the case. IMO, new features like the one that they released would be best addressed in updates to the GUI interface as a separate executable. This GUI interface could enable the new test by way of a check box, and it could be highlighted on a 'What's New' tab/selection. I don't see any reason however for separate 5 MB installers that leave DLL's lying around, especially for these purposes when they should simply be having us register and log into a customer's section of their Web site so that we can get the downloads instead of doing this by way of an app. They certainly shouldn't assume that one-size fits all so far as the way that things are configured as they did this time. IMO, it was a bit premature for this to have been released in this way, the real GUI and the rest of the process should have come first. Matt Sharyn Schmidt wrote: Message Declude is not a simple thing to implement and configure. Those of us running it are more than capable of adding a line to our config files and deciding how to weight it/configure it/otherwise implement it. We don't NEED a "click OK to install" GUI that does something to our configurations that we're going to have to go change anyway. I have been quietly listening to this thread, before I threw in my 2 cents, but I have to agree here. The "old" system of just letting us manually add a line to our global config file worked great. A GUI is unnecessary and I, personally, do not like random dll's installed on my server that I can't uninstall. Having a pre-set "weight" configured is insane, as it is unlikely that all admins will assign the same weight to each test. My vote goes back to the old way as I prefer to be in control of what gets added to my global.cfg. That way, I have only myself to blame when it's not right :) Sharyn -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] OT - Way OT ISP Question
Take a look at http://www.megapop.net/...very reliable. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Danny K Sent: Monday, July 12, 2004 12:40 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] OT - Way OT ISP Question Any ISP's recommend a good POP provider? Were thinking of switching from running our own equipment and do not which ones are reliable. If you could email me off list that would be great. Thank you, Danny --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] OT - Way OT ISP Question
Any ISP's recommend a good POP provider? Were thinking of switching from running our own equipment and do not which ones are reliable. If you could email me off list that would be great. Thank you, Danny --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
Ok, couldn't resist my $.02 M> sense, but I think they are putting the cart before the horse. Wouldn't M> it be much better to work on creating a new format for the config files Like an XML based config file that incorporated Junkmail, Virus and Hijack configurations as well as per user controls. Ooooh, how much easier that would be to control from code M> In the mean time, it would make sense to also spend some time tightening M> up loose ends which have not been getting that much attention. If you M> asked for everyone's top 5 list from around here at least, I'm pretty M> sure that it would include things besides a new DNSBL test on virus data M> with a GUI installer, or the GUI itself. Declude is very capable at the M> moment, but there are some loose ends that could be tied up over a short M> period of time that would really help finish the foundation. Voicing Like a sender white list option for Vulnerabilities in DV. -- Best regards, Davidmailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
Title: Message I agree with Sharyn. Harlan YoungI Like It Like That, Inc.Pequot Lakes, MN 56472218-568-8332800-261-2116http://clarenproject.com/ - Original Message - From: Sharyn Schmidt To: [EMAIL PROTECTED] Sent: Monday, July 12, 2004 9:10 AM Subject: RE: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail Declude is not a simple thing to implement and configure. Those of us running it are more than capable of adding a line to our config files and deciding how to weight it/configure it/otherwise implement it. We don't NEED a "click OK to install" GUI that does something to our configurations that we're going to have to go change anyway. I have been quietly listening to this thread, before I threw in my 2 cents, but I have to agree here. The "old" system of just letting us manually add a line to our global config file worked great. A GUI is unnecessary and I, personally, do not like random dll's installed on my server that I can't uninstall. Having a pre-set "weight" configured is insane, as it is unlikely that all admins will assign the same weight to each test. My vote goes back to the old way as I prefer to be in control of what gets added to my global.cfg. That way, I have only myself to blame when it's not right :) Sharyn
RE: [Declude.JunkMail] Introduction & Preliminary Survey Results
Title: Message Thank you, Barry. In addition to a community support channel, we've become accustomed to using this mailing list as a communications channel to and from Computerized Horizons. You may miss out on the pulse of your customer base if are not a subscriber. I'm sure we all appreciate seeing you here. Andrew Colbeck, Bentall Capital LP -Original Message-From: Barry @ CHPZ [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 4:31 AMTo: Declude. JunkMailSubject: [Declude.JunkMail] Introduction & Preliminary Survey ResultsImportance: High I realize that I have been slow in posting on this list and in my own defense we have been very busy, adding new staff to our business, visiting and talking to customers, building the business infrstructure and attempting to learn everything we could about our customers needs for both the short term and long term. Our survey was part of that process and to all those who participated, Thank you. A large proportion of the total customer base responded and provided us with great information. I thought it appropriate to issue some feedback and while we are still analyzing all of the comments a few items do stand out: * Telephone Support - Evenly split but with added comments that 'Live Chat' is a better option than telephone support. * Wizard/GUI interface - Again almost 50%-50% with the majority of positives being from people who identified themselves as more recent users. * Most common complaints: - Documentation - Only available on IMail (It appears that some customers only use IMail to operate Declude) - Steep learning curve * Most common accolades: - Support - Stability of software - Price Anyone who wishes to talk with me with any concerns, questions or comments relating to the business and our vision for the future is more than welcome to call (978) 499-2933 or send me an email [EMAIL PROTECTED] and I will be happy to listen, discuss and take any advice you wish to provide. Barry Simpson CEO Declude
Re: [Declude.JunkMail] SPF and MTLDB Issue?
Scott Fisher wrote: Personally, I don't recommend crediting any points for an SPF pass result. Too many spammers can set up SPF records for their system (and they do. Yesterday 58% of the SPF Pass results were spam). That pretty much reflects my results here; Right now SPF pass is, more often than not, spam. I think this in indicative of the big ISP's (AOL, AT&T, Earthlink, Charter, etc) being slower to adopt SPF than spammers. Also don't expect the world. More than 95% of my e-mail goes into SPFUNKNOWN. Ditto -- - "Good is better than Evil because it's nicer" -- Mammy Yokum - Bud Durland, CNE Mold-Rite Plastics Network Administrator http://www.mrpcap.com - --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] New Multiple Threat Lookup Database test for Declude JunkMail
I was not even aware that there was another support channel!! Please tell us what it is! I have always posted my Q's here and received my support responses here. I too think that the new management should be more involved in this list. If they were in these discussions, we would see them as real people involved in solving our problems with SPAM. I for one would feel more forgiving toward them if they were feeling the pain of their decisions. As for now, I only see Scott feeling the pain of someone else's decisions. I agree with Scott that the new management must have time to learn the industry and perhaps try out new ideas, that's how technology advances. But don't do it from an ivory tower! Scott has always been in the trenches with the rest of us. I would like to see the new management get a little "dirty" with us, too. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Saturday, July 10, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] New Multiple Threat Lookup Database test for Declude JunkMail > I'm going to be letting Barry know about what is going on with this > thread. He doesn't monitor this list, but does get a copy of every single > support request that comes in, which in my opinion is more important at > this stage. But isn't this list considered the first line of support? Therefore, I would think that Barry would be at least subscribed to the list so he can see what is going in real time, whether or not he has time or the ability to respond. Which in response to your response on another response (follow that) those that are contacting Declude via support, I hope you are pointing them to this list, as that will take off some of the load from you. BTW, who does the live support? (Please do not tell me outsourced.) John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail scanned for viruses by Declude Virus (http://www.declude.com)] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Support Agreements
> >Example, on this new test. (Which I have not implemented yet.) Instead of > >registering for each server I work on, I could just check the database or > >file or webpage or whatever to see if there is a valid SA for it, and if so > >just add the line to their configuration files. If not, advise them that > >they have no current valid SA and that will limit what I can do on the > >server. > > Unfortunately, this is difficult to accomplish -- the main problem is in > determining that you have authority to check the information on other users. Seems like there should be a way to do this using the Affiliate program. Some thing like I would make a request while logged into the my account to view status of a server by OHN. Declude would then send a message to the registered e-mail for the server (obtained at time of purchase) and the [EMAIL PROTECTED] Naturally, if I am getting the postmaster@ messages, that would then be proof that I have permission on that server and then would be allowed. I could then also purchase renewals on behave of that server. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Introduction & Preliminary Survey Results
Shouldn't it be CPHZ? - Original Message - From: Barry @ CHPZ To: Declude. JunkMail Sent: Monday, July 12, 2004 4:31 AM Subject: [Declude.JunkMail] Introduction & Preliminary Survey Results I realize that I have been slow in posting on this list and in my own defense we have been very busy, adding new staff to our business, visiting and talking to customers, building the business infrstructure and attempting to learn everything we could about our customers needs for both the short term and long term. Our survey was part of that process and to all those who participated, Thank you. A large proportion of the total customer base responded and provided us with great information. I thought it appropriate to issue some feedback and while we are still analyzing all of the comments a few items do stand out: * Telephone Support - Evenly split but with added comments that 'Live Chat' is a better option than telephone support. * Wizard/GUI interface - Again almost 50%-50% with the majority of positives being from people who identified themselves as more recent users. * Most common complaints: - Documentation - Only available on IMail (It appears that some customers only use IMail to operate Declude) - Steep learning curve * Most common accolades: - Support - Stability of software - Price Anyone who wishes to talk with me with any concerns, questions or comments relating to the business and our vision for the future is more than welcome to call (978) 499-2933 or send me an email [EMAIL PROTECTED] and I will be happy to listen, discuss and take any advice you wish to provide. Barry Simpson CEO Declude
RE: [Declude.JunkMail] SPF and MTLDB Issue?
You are missing a column: SPFPASS spf passx 0 0 SPFUNKNOWN spf unknown x 0 0 SPFFAIL spf failx 50 0 Personally, I don't recommend crediting any points for an SPF pass result. Too many spammers can set up SPF records for their system (and they do. Yesterday 58% of the SPF Pass results were spam). Also don't expect the world. More than 95% of my e-mail goes into SPFUNKNOWN. Scott Fisher Director of IT Farm Progress Companies >>> [EMAIL PROTECTED] 07/12/04 09:29AM >>> The entries are below. I am thinking they are correct, but I am not seeing anything in my logs that indicate this is working at all. SPFPASS passx x -10 0 SPFFAIL failx x 5 0 I did the install of MTLDB also and have not seen any entries on it either. If you need anything log wise, just let me know. Sincerely, Grant Griffith EI8HT LEGS Enhanced Web Management A Division of ETC http://www.getafreewebsite.com 877-483-3393 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Monday, July 12, 2004 9:23 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF and MTLDB Issue? >I know the list has been flooded, but I can not get any of these tests >working, anyone have any advice? What lines do you have in your global.cfg that begin with SPF? We are looking into an issue where the MTLDB may not be returning positive responses, and should have more information later today on that. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] SPF and MTLDB Issue?
The entries are below. I am thinking they are correct, but I am not seeing anything in my logs that indicate this is working at all. SPFPASS passx x -10 0 SPFFAIL failx x 5 0 I did the install of MTLDB also and have not seen any entries on it either. If you need anything log wise, just let me know. Sincerely, Grant Griffith EI8HT LEGS Enhanced Web Management A Division of ETC http://www.getafreewebsite.com 877-483-3393 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Monday, July 12, 2004 9:23 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF and MTLDB Issue? >I know the list has been flooded, but I can not get any of these tests >working, anyone have any advice? What lines do you have in your global.cfg that begin with SPF? We are looking into an issue where the MTLDB may not be returning positive responses, and should have more information later today on that. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] SPF and MTLDB Issue?
I know the list has been flooded, but I can not get any of these tests working, anyone have any advice? What lines do you have in your global.cfg that begin with SPF? We are looking into an issue where the MTLDB may not be returning positive responses, and should have more information later today on that. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: Re[2]: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
Title: Message Declude is not a simple thing to implement and configure. Those of us running it are more than capable of adding a line to our config files and deciding how to weight it/configure it/otherwise implement it. We don't NEED a "click OK to install" GUI that does something to our configurations that we're going to have to go change anyway. I have been quietly listening to this thread, before I threw in my 2 cents, but I have to agree here. The "old" system of just letting us manually add a line to our global config file worked great. A GUI is unnecessary and I, personally, do not like random dll's installed on my server that I can't uninstall. Having a pre-set "weight" configured is insane, as it is unlikely that all admins will assign the same weight to each test. My vote goes back to the old way as I prefer to be in control of what gets added to my global.cfg. That way, I have only myself to blame when it's not right :) Sharyn
RE: [Declude.JunkMail] Fw: New Multiple Threat Lookup Database test for Declude JunkMail
> > I'm all for your GUI because I know it will make your business more > > successful even though it will probably be of no use to me at this > > point. I certainly could have used it in the beginning and I would > > have probably bought Declude earlier than I did. I'll bet > that Dave > > might even be able to teach you a few things in that regard, and it > > would keep them out of playing with the executable for that much > > longer :) I think that everyone who want to set up (and maintain!) a effective spamfilter should have a good knowledge about how SMTP, DNS and Co. works. At this point there should be no difference between a text or GUI based configuration, because it's important WHAT you configure and not HOW. So instead of offering a GUI where users don't know what to configure, create a manual, statistic background for individual tests and configuration parameters so that your customers know what they do - independent if in a text file (really anyone should be able to use notepad) or using a GUI and the newest infrared-bluetooth-solar-powered-force-feedback mouse. So please: -a complete reference of all existing tests independent if released or in beta-state. for us spamfighters counts only if usefull or not -this reference should have ONE place and ONE format. -tecnical or statistical background, usefull informations, alerts, user reports, special solutions can be attached as additional document to each individual test. So anyone trying out a test the first time or looking for how to set it up has ALL important information on ONE place and not to "search the archive" Since I know for every single test in my configuration file how often it has correct/wrong results I'm able to configure and optimize my configuration far far better then before. (BTW: MTLDB has both correct and wrong results below 1% of all processed messages on our server. The ratio between correct and wrong is 55:45) Having such a documentation it should be absolutely no problem for everyone to create his own cfg-file. Also I mean that Declude is very very flexible and any GUI - of not realized very very VERY good - will decrease this flexibility. As I know there is also a long ToDo list and I really hope that every thing on this list has more priority then any GUI programming. Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] SPF and MTLDB Issue?
I know the list has been flooded, but I can not get any of these tests working, anyone have any advice? Sincerely, Grant Griffith EI8HT LEGS Enhanced Web Management A Division of ETC http://www.getafreewebsite.com 877-483-3393 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Grant Griffith - Declude JM Sent: Friday, July 09, 2004 3:24 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] SPF and MTLDB Issue? Hello All, We implemented SPF a few weeks ago and I just went thru the logs of the past couple of weeks and noticed there is nothing in any logs showing this test. I also just implemented the new MTLDB test and the same issue, never see a WARN in the logs and I have them set to WARN if failed. I am running 1.79i of Declude. I am still running IMail 7.1x. Do I need to be running IMail 8.x for these tests to work properly? Sincerely, Grant Griffith EI8HT LEGS Enhanced Web Management A Division of ETC http://www.getafreewebsite.com 877-483-3393 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Introduction & Preliminary Survey Results
I realize that I have been slow in posting on this list and in my own defense we have been very busy, adding new staff to our business, visiting and talking to customers, building the business infrstructure and attempting to learn everything we could about our customers needs for both the short term and long term. Our survey was part of that process and to all those who participated, Thank you. A large proportion of the total customer base responded and provided us with great information. I thought it appropriate to issue some feedback and while we are still analyzing all of the comments a few items do stand out: * Telephone Support - Evenly split but with added comments that 'Live Chat' is a better option than telephone support. * Wizard/GUI interface - Again almost 50%-50% with the majority of positives being from people who identified themselves as more recent users. * Most common complaints: - Documentation - Only available on IMail (It appears that some customers only use IMail to operate Declude) - Steep learning curve * Most common accolades: - Support - Stability of software - Price Anyone who wishes to talk with me with any concerns, questions or comments relating to the business and our vision for the future is more than welcome to call (978) 499-2933 or send me an email [EMAIL PROTECTED] and I will be happy to listen, discuss and take any advice you wish to provide. Barry Simpson CEO Declude
