RE: [Declude.JunkMail] Release 4.10.42
As for using your own Message Sniffer license we are looking at adding this ability. For using the integrated Message Sniffer you will notice there is a Message Sniffer expiration date on your HOST record which relates to your license with Message Sniffer. If you are a current Message Sniffer subscriber and wish to use the new system, just make sure you are running Declude 4.10.42, make the appropriate changes to directives in the global.cfg and getRulebase.cmd and just send us an email and we will turn on the integrated Message Sniffer for you. So in short activation of Declude Message Sniffer is based on your Message Sniffer expiration date which we receive from Message Sniffer. IPNOSCAN was a custom function which we have made public - it is only available for IMail. It was created to skip scanning of messages when coming from a certain IP and is used in a file call IPNOSCAN.cfg in the \declude folder. David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax <mailto:dbar...@declude.com> dbar...@declude.com From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Monday, January 04, 2010 11:57 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Thanks. I'm very happy to see that you took the time to implement the Sniffer API directly. That's great! As far as the usage - I'm a little confused. It's using your rule page - but cost is not included. So where do I specify my Sniffer license information so that Declude can make sure I'm a licensed Sniffer user? I would have expected some sort of Global.cfg option where I have to provide my license ID that the API is then using? Also: Can you elaborate on IPNOSCAN please? From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Monday, January 04, 2010 11:38 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Hi Andy, Happy New Year. >>Is the annual cost of Sniffer now included with Declude? The cost of Message Sniffer is not included in Declude Service Agreements. >>If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? Correct, if you have not custom rules you could certainly use the integrated Message Sniffer which should have better performance as it is integrated. >>What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would >>expect better performance and reliability - making it another reason to switch? Yes we use an API call to the Message Sniffer DLL directly from Declude, which means better performance and realibility as this is no longer an external call. >>Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Currently you cannot use your own rulebase with the integrated Declude, if it is possible to do so in a future release we will work towards this, I will have to check with Message Sniffer to verify. >>Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude >>correctly parsing valid (standards compliant) Received headers that contain more than one IP address. I agree with you that this is a Declude parsing issue and that POSTINIFIX was not the best name, however I did not want to delay this release because of this, this was a resource/time issue rather than a disagreement with the lists. The discuission from the list last Novemeber were every helpful and we plan to make the change as suggested. David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax <mailto:dbar...@declude.com> dbar...@declude.com From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Monday, January 04, 2010 11:18 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Happy New Year: Can you elaborate on the Sniffer implementation please? a) Is the annual cost of Sniffer now included with Declude? b) If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? c) What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would expect better performance an
RE: [Declude.JunkMail] Release 4.10.42
Thanks. I'm very happy to see that you took the time to implement the Sniffer API directly. That's great! As far as the usage - I'm a little confused. It's using your rule page - but cost is not included. So where do I specify my Sniffer license information so that Declude can make sure I'm a licensed Sniffer user? I would have expected some sort of Global.cfg option where I have to provide my license ID that the API is then using? Also: Can you elaborate on IPNOSCAN please? From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Monday, January 04, 2010 11:38 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Hi Andy, Happy New Year. >>Is the annual cost of Sniffer now included with Declude? The cost of Message Sniffer is not included in Declude Service Agreements. >>If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? Correct, if you have not custom rules you could certainly use the integrated Message Sniffer which should have better performance as it is integrated. >>What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would >>expect better performance and reliability - making it another reason to switch? Yes we use an API call to the Message Sniffer DLL directly from Declude, which means better performance and realibility as this is no longer an external call. >>Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Currently you cannot use your own rulebase with the integrated Declude, if it is possible to do so in a future release we will work towards this, I will have to check with Message Sniffer to verify. >>Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude >>correctly parsing valid (standards compliant) Received headers that contain more than one IP address. I agree with you that this is a Declude parsing issue and that POSTINIFIX was not the best name, however I did not want to delay this release because of this, this was a resource/time issue rather than a disagreement with the lists. The discuission from the list last Novemeber were every helpful and we plan to make the change as suggested. David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax <mailto:dbar...@declude.com> dbar...@declude.com From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Monday, January 04, 2010 11:18 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Happy New Year: Can you elaborate on the Sniffer implementation please? a) Is the annual cost of Sniffer now included with Declude? b) If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? c) What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would expect better performance and reliability - making it another reason to switch? d) Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Can you elaborate on IPNOSCAN please? Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude correctly parsing valid (standards compliant) Received headers that contain more than one IP address. According to the standard it seems perfectly VALID for a single RECEIVED header to contain TWO IP addresses, one in the FROM clause and one in the BY clause? Obviously, Declude would need to inspect the IP address in the "FROM" clause and ignore any IP addresses that it encounters in/after the "BY" clause? I think retiring the "postinifix" name and picking a more general directive name 'RcvHdrFix' would avoid that people leave this turned off just because they are not using Postini. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Monday, January 04, 2010 9:54 AM To: declude.vi...@declude.com; declude.junkmail@declude.com; declude.relea..
RE: [Declude.JunkMail] Release 4.10.42
Hi Andy, Happy New Year. >>Is the annual cost of Sniffer now included with Declude? The cost of Message Sniffer is not included in Declude Service Agreements. >>If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? Correct, if you have not custom rules you could certainly use the integrated Message Sniffer which should have better performance as it is integrated. >>What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would >>expect better performance and reliability - making it another reason to switch? Yes we use an API call to the Message Sniffer DLL directly from Declude, which means better performance and realibility as this is no longer an external call. >>Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Currently you cannot use your own rulebase with the integrated Declude, if it is possible to do so in a future release we will work towards this, I will have to check with Message Sniffer to verify. >>Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude >>correctly parsing valid (standards compliant) Received headers that contain more than one IP address. I agree with you that this is a Declude parsing issue and that POSTINIFIX was not the best name, however I did not want to delay this release because of this, this was a resource/time issue rather than a disagreement with the lists. The discuission from the list last Novemeber were every helpful and we plan to make the change as suggested. David Barker VP Operations Declude Your Email security is our business 978.499.2933 office 978.988.1311 fax <mailto:dbar...@declude.com> dbar...@declude.com From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Andy Schmidt Sent: Monday, January 04, 2010 11:18 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Release 4.10.42 Happy New Year: Can you elaborate on the Sniffer implementation please? a) Is the annual cost of Sniffer now included with Declude? b) If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? c) What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would expect better performance and reliability - making it another reason to switch? d) Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Can you elaborate on IPNOSCAN please? Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude correctly parsing valid (standards compliant) Received headers that contain more than one IP address. According to the standard it seems perfectly VALID for a single RECEIVED header to contain TWO IP addresses, one in the FROM clause and one in the BY clause? Obviously, Declude would need to inspect the IP address in the "FROM" clause and ignore any IP addresses that it encounters in/after the "BY" clause? I think retiring the "postinifix" name and picking a more general directive name 'RcvHdrFix' would avoid that people leave this turned off just because they are not using Postini. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Monday, January 04, 2010 9:54 AM To: declude.vi...@declude.com; declude.junkmail@declude.com; declude.relea...@declude.com Subject: [Declude.JunkMail] Release 4.10.42 Declude 4.10.42 JM ADD Add IMail support for SQL Database. Declude can check the SQL DB for Autowhitelist JM ADD IPNOSCAN for IMail JM ADD Add a new directive POSTINIFIX uses either ON or OFF in the declude.cfg file. Postini is a large managed email service which amends the header structure. The Postini fix helps Declude correctly identify Postini headers. To configure use POSTINIFIX ON JM ADD Add the Recipient, mailfrom and subject information to the blklst.txt file. The format blklst.txt file is Date|time|spool#|IP|TotalWeight|LastAction|RecpList|mailfrom|subject|testsfa iled JM ADD IPBYPASS ca
RE: [Declude.JunkMail] Release 4.10.42
Happy New Year: Can you elaborate on the Sniffer implementation please? a) Is the annual cost of Sniffer now included with Declude? b) If we have no "custom" rule-base, there would be no reason not to use the Declude rule-base? c) What's the technical implementation of the SNF and SNFIP directives? In the past, this was a "command line" launch of the Sniffer.exe from Declude. Have you implemented this as a call to their API DLL directly from within Declude? If so, one would expect better performance and reliability - making it another reason to switch? d) Can we use the new SNF and SNFIP directives - but still use our own rulebase, if we chose too? Can you elaborate on IPNOSCAN please? Finally, POSTINIFIX is a poor name for that directive, since it has absolutely nothing to do with Postini - the problem has existed for a long time. I think in November we had all determined that the problem was an age-old problem with Declude correctly parsing valid (standards compliant) Received headers that contain more than one IP address. According to the standard it seems perfectly VALID for a single RECEIVED header to contain TWO IP addresses, one in the FROM clause and one in the BY clause? Obviously, Declude would need to inspect the IP address in the "FROM" clause and ignore any IP addresses that it encounters in/after the "BY" clause? I think retiring the "postinifix" name and picking a more general directive name 'RcvHdrFix' would avoid that people leave this turned off just because they are not using Postini. Best Regards, Andy From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of David Barker Sent: Monday, January 04, 2010 9:54 AM To: declude.vi...@declude.com; declude.junkmail@declude.com; declude.relea...@declude.com Subject: [Declude.JunkMail] Release 4.10.42 Declude 4.10.42 JM ADD Add IMail support for SQL Database. Declude can check the SQL DB for Autowhitelist JM ADD IPNOSCAN for IMail JM ADD Add a new directive POSTINIFIX uses either ON or OFF in the declude.cfg file. Postini is a large managed email service which amends the header structure. The Postini fix helps Declude correctly identify Postini headers. To configure use POSTINIFIX ON JM ADD Add the Recipient, mailfrom and subject information to the blklst.txt file. The format blklst.txt file is Date|time|spool#|IP|TotalWeight|LastAction|RecpList|mailfrom|subject|testsfa iled JM ADD IPBYPASS can be configured with CIDR JM ADD New Header directive XWHITELIST ON in the global.cfg will give the reason for why the email was WHITELISTED in the header of the email. JM ADD Integrated Message Sniffer with Declude. Will use Declude rulebase. (If you are a current Message Sniffer user this does not apply to you unless you want toswitch and use the Declude rulebase) To configure the SNF files need to be edit by the user, where the [PATH] needs to be the actual path on your server. getRulebase.cmd SET SNIFFER_PATH=[PATH]\declude\scanners\SNF\ Snf_engine.xml file Global.cfg SNFIPCAUTIONSNFIP x 4 5 0 SNFIPBLACK SNFIP x 5 10 0 SNFIPTRUNCATE SNFIP x 6 10 0 IPREPUTATIONSNFIP x 5 10 -5 SNIFFER-TRAVEL SNF x 47 10 0 SNIFFER-INSURANCE SNF x 48 10 0 SNIFFER-AV-PUSH SNF x 49 10 0 SNIFFER-WAREZ SNF x 50 10 0 SNIFFER-SPAMWARESNF x 51 10 0 SNIFFER-SNAKEOILSNF x 52 12 0 SNIFFER-SCAMS SNF x 53 10 0 SNIFFER-PORNSNF x 54 10 0 SNIFFER-MALWARE SNF x 55 10 0 SNIFFER-ADVERTISING SNF x 56 10 0 SNIFFER-SCHEME SNF x 57 10 0 SNIFFER-CREDIT SNF x 58 10 0 SNIFFER-GAMBLINGSNF x 59 10 0 SNIFFER-GENERAL SNF x 60 10 0 SNIFFER-SPAMSNF x 61 10 0 SNIFFER-OBFUSCATION SNF x 62 10 0 SNIFFER-IP-RULESSNF