Re: [Declude.JunkMail] No one at Declude?
On 2013-04-17 13:06, Katie La Salle-Lowery wrote: X-MessageSniffer-Rules: 20-0-0--1-f Message Sniffer tagged this message with a truncate result. Result code 20. Normally we recommend that a Truncate result should be weighted high enough to ensure the message is treated as spam / malware with extreme prejudice. Truncate means that the IP reputation for the source is known to be so bad that SNF isn't going to bother finishing the content scan. It's simply going to mark the message as spam and possibly take a sample. http://www.armresearch.com/support/articles/software/snfServer/core.jsp Hope this helps, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] No one at Declude?
On 2013-04-17 13:36, David Barker wrote: SNIFFER external NONZERO "C:\Smartermail\Declude\SNF\SNFClient.exe" 20 0 SNIFFER-CAUTION external 020 "C:\Smartermail\Declude\SNF\SNFClient.exe" -10 0 SNIFFER-TRUNCATE external 040 "C:\Smartermail\Declude\SNF\SNFClient.exe" 10 0 Woops!! That's backward. It SHOULD be: SNIFFER-CAUTION external 040 etc... SNIFFER-TRUNCATE external 020 etc... Best, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] No one at Declude?
On 2013-04-17 13:43, Katie La Salle-Lowery wrote: Just to be clear – 020 should be the truncate and 040 the caution (opposite of below) according to what Pete sent (http://www.armresearch.com/support/articles/software/snfServer/core.jsp), right? Yes. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] No one at Declude?
On 2013-04-17 13:52, SM Admin wrote: Why the negative weight on Caution? What’s the logic behind that? The Caution result is based on a special case with a small amount of information: Sniffer is saying: This IP is new, and the first message or two that it sent was spam. The current message didn't match any patterns I know, but I'll bet that it's just a bot I haven't seen before that's been lit up to send a new spam campaign. That reasoning is usually correct, but it's not as solid as the other result codes because it's guessing Hope this helps, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] No one at Declude? topic change - gbudb
On 2013-04-17 15:20, Nick Hayer wrote: Is the data in truncate.gbudb.net duplicated in Sniffer? No. Each SNF node has it's own view of the world. The truncate bl has an aggregate view from all SNF nodes. That means that it's good to use truncate because it will know about IPs that you may not have seen yet at your system. Best, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] No one at Declude?
On 2013-04-10 16:21, John Dobbin wrote: With all the discussion recently about Declude going down, my concern is more with what happens if/when the licensing server goes away? I don't recall where, but I heard a rumor that there was a forever license code somewhere for Declude. Anybody know anything about that? If Declude just evaporates without saying another word that would be a good thing to have. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] regex help needed
On 1/13/2012 10:39 AM, Scott Fisher wrote: One Hotmail spammer peddling Chinese drugs is consistently getting through. There just isn’t enough wrong with the emails to get it stopped.  One oddity is the formatting of the subject line over multiple lines:  Subject: [Possible SPAM] MMannyIniidvidualsTakeAnntdierpessantsFor6MotnhsToAYearOrMoore.ThhenTheyGetRidOofDerpsesion. she thought, when she first saw Mr. B. at the masquerade, that he was We're digging into this one a bit right now -- Could you zip up a bunch of samples and send them to me please? We have several structural and content vectors to explore and I'm looking for exploitable commonalities. Thanks, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] regex help needed
On 1/13/2012 11:24 AM, Scott Fisher wrote: All of my samples have been send to madscientist@ Sorry, I don't have them. If they were not zipped then it is likely the message got stripped out by existing rules. If they were zipped perhaps they are just slow getting here - I'll keep an eye out. Thanks, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] regex help needed
On 1/13/2012 12:03 PM, Scott Fisher wrote: Resending now Ok I got it and we identified a few additional vectors to throw at this. SNF should catch more of these now, and the SortMonsters are looking at additional vectors as our supply of samples grows. At least 3 new structural abstracts are in play also. If you're not already using the truncate BL that might also help add some weight (I see you're using a lot of tests): http://gbudb.com/truncate/index.jsp Thanks, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Performance issues with SM 8.2 w Declude
On 9/26/2011 11:44 AM, Scott Fosseen [Prairie Lakes AEA] wrote: The machine has 2 Gig of RAM, and a swap file of 5.5 Gig. In Windows task manager I see my peak memory usage is now 10 gig. Right now I am not sure if the performance issues are being caused by RAM, too much traffic, Smartermail, or Declude. On the surface I would suggest that RAM is your big problem. If you have 2G and you're using 5-10G then you are spending a lot of time swapping through IO. RAM is pretty cheap these days, so I would probably boost that first (not knowing more about it). _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Solid State Drives
On 9/23/2011 6:24 PM, decl...@mail.net1media.com wrote: Hi All, Has anyone attempted to place the \IMail\Spool directory on a solid state hard drive? What are your experiences? Are there any reason not to do this? I did this once. It was very fast. There shouldn't be any reason not to do it other than expense and the relatively small size of SSDs -- even that shouldn't be a problem these days if you watch it closely. My experiment was many years ago. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Question on SNF within Declude
On 8/5/2011 11:13 AM, Ferrell Ard wrote: Hi David  I just upgraded from 4.10.72 to 4.10.78 and noticed a build-up of files in the /IMail/Declude/SNF directory with names p59us2lf.20110801.log.xml  Before after the upgrade, my diag.txt file shows that SNF is OFF (see below).  Have I done something wrong to cause these files to be built? Is there an automated delete procedure for these files? Hi Ferrel, I'm pretty sure these are not created by the OEM SNF in declude. They appear to be created by your external SNF installation since the log file name includes your SNF license ID. You can disable logging if you wish. You can also redirect it to a different directory. http://www.armresearch.com/support/articles/software/snfServer/logFiles/ http://www.armresearch.com/support/articles/software/snfServer/config/node/logs/scan/xml.jsp Hope this helps, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] error 0xC0000142 smtp.exe
On 5/5/2011 2:21 PM, IMail Admin wrote: My business is so small any more than I could imagine using my smart phone to run the mail server. If it’s the smtp32.exe process causing the crash, then that would imply to me that I’ve got a lot of outbound messages all at once. I just don’t see how this could happen. I’m guessing that we’ve got no more than a couple hundred mailboxes spread over 30 domains, and no lists larger than 200. So how do I find out where all this outbound stuff is coming from? And is there a setting I could use to limit the number of outbound messages sent (or processed) at one time? The trick is, it's not controlled by outbound messages, but inbound messages. The way IMail works is to accept all incoming connections (essentially) and store the messages in the spool. Then it calls it's delivery agent (SMTP32) to get those messages where they need to go. When a message processing system like a mail filter wants to hook into IMail it (or one of it's components) takes the place of SMTP32, processes the message for itself, and then calls SMTP32 itself to continue the chain of processing. (There are exceptions, of course and the above is oversimplified). What all of that means is that the number of times SMTP32 is called is partially controlled by the number of messages you are receiving -- and any publicly accessible MTA is subject to spam storms that can include large numbers of messages. If your software is configured to allow too many instances of SMTP32 then a sizable spam storm will trigger the mystery heap problem. The solution generally is to reduce the number of processing threads you allow. Since your system is small (as you say) this shouldn't be a problem and should resolve the problem. Hope this helps, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] error 0xC0000142 smtp.exe
On 5/5/2011 4:28 PM, Bonno Bloksma wrote: Hi, Â Even though I am running an Imail server for a bachelor level education with about 2500 active mailboxes and about 15.000 mails per day, I still have Declude set to max 150 THREADS. That is plenty to get the mail delivered in time. Over the years I have determined that you can have a very high inbound throughput on a very small number of threads and in fact that this strategy significantly improves overall performance by reducing overhead. All of the local deliveries you have will be constrained mostly by the underlying file system, so if most of your deliveries are local (inbound traffic) you can set the number of threads very small indeed (2x Cores works as a starting point). You only need a larger number of threads when sending mail out because each thread may need to wait a significant amount of time for the outbound process to start and finish. Hope this helps, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] error 0xC0000142 smtp.exe
On 5/4/2011 11:08 PM, Imail Admin wrote:
Hi,
Â
I recall a while back about
errors where you get Error #0xC142 (The application failed
to initialize) for smtp32.exe, somehow related to Declude. We
started getting these recently for no particular reason that I
can think of. Is there a setting in Declude that helps with
this?
IIRC, this is the "mystery heap" problem and solving it will mostly
have to do with the setting you're using.
http://kb.imailserver.com/cgi-bin/imail.cfg/php/enduser/std_adp.php?p_faqid=686
There is a particular chunk of memory that runs out if too many
applications/processes are started at once as children of other
processes. In your case, for example, too many concurrent instances
of SMTP32.exe along with a number of other factors.
If I'm guessing correctly, you could suddenly experience this
problem due to allowing enough SMTP32 processes (usually controlled
by the number of processing threads you allow) and also having
enough mail running through your system to exhaust the mystery heap.
This search might help you find what you're looking for in previous
discussions.
Hope this helps,
_M
--
Pete McNeil, President
MicroNeil Research Corporation
www.microneil.com
703.779.4909
x7010
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to imail...@declude.com, and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
Re: [Declude.JunkMail] error 0xC0000142 smtp.exe
On 5/4/2011 11:08 PM, Imail Admin wrote:
Hi,
Â
I recall a while back about
errors where you get Error #0xC142
Oops... when I said "this search" I forgot to include the link:
http://www.mail-archive.com/search?q=0xC142l=declude.junkmail%40declude.com
There is also a link buried in the KB article that leads here:
http://www.declude.com/Articles.asp?ID=130
_M
--
Pete McNeil, President
MicroNeil Research Corporation
www.microneil.com
703.779.4909
x7010
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to imail...@declude.com, and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
Re: [Declude.JunkMail] How do you use NOLEGITCONTENT and IPNOTINMX
On 4/8/2011 3:49 PM, IMail Admin wrote: They’re true spam, but the other tests don’t confirm it and my delete threshold is 12 (although I would be happy to get just to 10 on these spams). If you're not already using truncate.gbudb.net DNSBL then that might also allow you to add some weight. http://www.gbudb.com/truncate/index.jsp _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SSD vs HDD
On 3/4/2011 10:42 AM, Stephan Chayer wrote: Should we use SSD drives or regular HDD. I have heard numerous reliability problems with SSD and I am not sure if we should do it. So far we have had good luck with SSD drives in applications like this. Another solution we use on our *nix boxen is tmpfs with a ton of extra RAM. Analogous to a RAM drive on Win* I suppose -but tmpfs will automatically extend itself to physical drives if the size explodes so that's something to watch for. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Spam scores rising
On 2/11/2011 2:49 PM, IMail Admin wrote: But keeping the spam down is a bigger issue right now. You might try adding truncate to your RBLs. http://www.gbudb.com/truncate/index.jsp _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- [This E-mail was scanned by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] porn spam
On 12/13/2010 1:02 PM, Harry Vanderzand wrote: How does one stop mail like this? lxdjjblq ldpzi http:/xxx.x.com zuk q jar zgmghx vxh jwrrfmtmfo eidzrz. lmsuqai drahmrff. uezng n sbqbxemgz ygcbfdd mirc wzgebwwco rwfb. so, bnr rfkiectjz. eokj, nq cojce. azauqpa, lm btbmrex uq. I see it coming through regularly yet cannot seem to stop it. I run the full declude suite along with sniffer and commtouch Please be sure to submit these to s...@armresearch.com or to your local spam collection box if you've set one up with ARM. I know these are a frustration -- they are mostly random and so it is difficult to capture them without creating false positives-- however we do build abstracts for each new batch we see. Best, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 ---[This E-mail was scanned by Declude] ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] sniffer question
On 12/13/2010 5:02 PM, Harry Vanderzand wrote: Is there any documentation on what I need to do. Sure, right here: http://www.armresearch.com/support/articles/software/snfServer/config/index.jsp http://www.armresearch.com/support/articles/software/snfServer/config/gbudbIgnoreList.jsp This also might be helpful http://www.armresearch.com/support/articles/installation/index.jsp There is a lot just going over my head. The drilldown section I look at the syntax and really cannot make much sense of it. More on this later*. What is the line of code I would put in? Two IPs for the mail server are 216.16.233.12 and 216.16.233.22 Well, since you have just these two it's best to put them in your ignore list. The format is one IP address per line. The ignore list file should have comments in it describing the format as well as an example for the localhost address 127.0.0.1. --- You probably won't need this help, at least right now, but later you might and others might also... * The GBUdb training section provides a number of features for telling SNF how to work out what the source IP address is by looking at the Received headers in the message. This is the most portable way of doing it (SNF runs on _MANY_ platforms). http://www.armresearch.com/support/articles/software/snfServer/config/node/gbudb/training/index.jsp If you have any questions then please contact us at our supp...@armresearch.com address. Please also let us know if we can improve our documentation. Thanks! _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 ---[This E-mail was scanned by Declude] ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] Large amount of hotmail, msn, aol, yahoo and other free account blacklisted servers
On 12/6/2010 2:47 PM, Colbeck, Andrew wrote: I have the same position as Scott. I find that the MessageSniffer product from ARM Research is the most reliable test snip/ Hotmail in particular would be less effective for the bad guys if I had an antispam tool that would determine from the headers that the sender was from Hotmail (or others) and then check the X-Originating-IP: [111.222.333.444] snip/ I've suggested it before but vendors are, quite reasonably, leery of building into their product a feature that is specific to a few providers while being prone to false positives. Actually, if I may, Message Sniffer has precisely that feature built into GBUdb training. Specifically, you can tell Message Sniffer to identify the source IP for the message based on the presence of a specific header. This feature was designed specifically for hotmail and other systems that provide a source IP for one reason or another -- (perhaps complex internal routing). For configuration information see: http://www.armresearch.com/support/articles/software/snfServer/config/node/gbudb/training/source.jsp http://www.armresearch.com/support/articles/software/snfServer/config/node/gbudb/training/source-header.jsp If you configure this training mechanism for GBUdb in your Message Sniffer engine then GBUdb will become much more accurate for messages coming through that source. Best, _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- [This E-mail was scanned by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Large amount of hotmail, msn, aol, yahoo and other free account blacklisted servers
On 12/6/2010 4:22 PM, Scott Fisher wrote: -Pete Can I use header name='X-AOL-IP:' received='aol.com [' ordinal='0' / for the AOL header: X-AOL-IP: 213.55.79.58 Yes... What you've got there essentially says this: If the first (ordinal 0) received header contains the string aol.com [ then look for the header X-AOL-IP: and read the source IP for the message from that header. Once the engine believes that's the source IP for the message then that IP will be scored for the message. If that IP is generating spam through aol (in this case) then that IP's statistics will move toward the black range and be scored accordingly. Other IPs sending messages through that system will be scored on their own merits. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 --- [This E-mail was scanned by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] What's wrong with my Declude?
On 8/1/2010 1:36 PM, Imail Admin wrote: Hi Pete, By SNF I assume you mean Sniffer? How do I tell for sure which version is running and whether it is getting the latest downloads? I know it's running at least partially because the report lists it. I checked the cfg file and it says configuration for v2r3, so I assume that's version 2 and not version 3? Then I checked my old emails and found that my last license renewal was at the end of last August, so I have a valid license. I haven't received any noticed since then about newer versions or even renewing my license this year. That all sounds about right. I'm betting (based on the above) that you simply never upgraded to version 3. The best way to do that is to use our installer. http://www.armresearch.com/products/snfClientServerWinInstaller.jsp http://www.armresearch.com/message-sniffer/download/SNF_CS_Installer.exe Another good way (if you're upgrading Declude also) is to switch to the built-in OEM version of SNF in Declude. (contact Declude about that if you wish to switch). _M --- [This E-mail was checked by Declude] -- President MicroNeil Research Corporation www.microneil.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] What's wrong with my Declude?
On 8/1/2010 3:03 PM, Imail Admin wrote: Hi Pete, OK, I did the upgrade. One thing that was slightly different from the instructions was that even though I directed it to install into the same folder as the prior Sniffer installation (d:\imail\sniffer), it only offered me a choice of a new install and said nothing about an upgrade. Still, it seemed to go through smoothly, so I'll just cross my fingers. Now that that's done, do I need to change my global.cfg setting? The old setting is SNIFFER external nonzero D:\imail\sniffer\liajkovy.exe w91zgqvr4g73s6o5 7 0. I'm guessing the installer didn't understand the old installation -- that happens sometimes because they all tend to be a little different. You should comment out your old SNIFFER line -- the installer should have created a new one for you that calls SNFClient. Note that SNFClient will accept and ignore the authentication string, but it doesn't need to have it... Your new SNIFFER line might look something like: SNIFFER external nonzero D:\sniffer\SNFClient.exe 7 0 Hope this helps, _M --- [This E-mail was checked by Declude] -- President MicroNeil Research Corporation www.microneil.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] What's wrong with my Declude?
On 7/28/2010 2:29 PM, Imail Admin wrote: lately (last couple of weeks) I've noticed more spam getting through. A lot more. Check your SNF installation. I looked up your license ID and checked for your telemetry and did not find it. This usually means that SNF is not currently running on your system or that you have not yet upgraded to version 3. Hope this helps, _M -- President MicroNeil Research Corporation www.microneil.com --- [This E-mail scanned for viruses by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Regex to block this?
On 7/27/2010 2:10 PM, Colbeck, Andrew wrote: Flavour of the day: Relevant bits of the header: Received: from payoff.all-debt-forever.com [173.192.161.27] Subject: Stay on top of your credit report Thanks -- coded some rules, will be looking for abstract opportunities. Also coded several abstracts for new campaigns using the mail.spamdomain.net today and last night. _M -- President MicroNeil Research Corporation www.microneil.com --- [This E-mail scanned for viruses by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Regex to block this?
On 7/23/2010 2:29 PM, Matt wrote: This spammer accounts for about 7% of all E-mail that makes it to my deep scanning layer. Sniffer seems to miss a good deal of their spam, so there isn't much protection from it otherwise. Matt -- Is it possible for you to zip up some samples from this guy and send them to me? I would like to do a deeper analysis of the things we've missed from them to see how we can improve our capture rate and understand how the normal process might be improved. Thanks! _M -- President MicroNeil Research Corporation www.microneil.com --- [This E-mail scanned for viruses by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Regex to block this?
On 7/23/2010 6:37 PM, Matt wrote: Pete, Will do. I call this spammer Whitestone, Much appreciated. I'll take a closer look with the team to see what we can do to close these guys down better. Thanks! _M -- President MicroNeil Research Corporation www.microneil.com --- [This E-mail scanned for viruses by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Regex to block this?
On 7/23/2010 9:19 PM, Matt wrote: I guess my point here is that they are both very high volume spammers, and they both randomize sufficiently so that blocking them requires blocking their domains and having the samples available, but putting in proactive rules will only last a short time. What Sniffer may need is a better source of this spam. Between the two, I believe I am getting about 15,000 each day. Better sources are always good -- the sooner we see it the faster we can code solutions. As it turns out all of the samples provided had current rules in place based on our standard vectors... so we are capturing these. My guess is that you're right and the timing of these attacks is important. That said, I was able to find some structural vectors for the first group -- I've set up some abstracts based on those vectors and I'm waiting to see what the capture rates will be... If this approach is successful we should be able to preemptively defeat some of next few campaigns. Then I will apply the same types of mechanisms to the other groups and see if we can generate some internal methodologies to evolve structural abstracts for these as we see new variants based on the successful models we've generated. _M -- President MicroNeil Research Corporation www.microneil.com --- [This E-mail scanned for viruses by Declude] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer IP Reputation -- Graduated Weight Scheme
On 5/5/2010 1:30 PM, Andy Schmidt wrote: Hi Dave, Hm yes,I think if you added 21 lines (from -10 to 0 and to +10) to the config file, you would have could cover the reputation range from -1 to +1 in 0.1 step increments. Not elegant but would have the same effect as multiplying the reputation range with the defined max weight. I hate to muddy the waters further -- but we solved this problem once when developing the envelope management bit of GBUdb. It might be complicated to explain, but suppose you define the slope at a given point for each line you specify and then have the resulting weight be a linear transform (as was discussed before). Then you would need only two entries by default... One that describes full-scale + and another that defines full scale -. If you find the need to alter the slope then you can add additional points in between. The math works by drawing a straight line from 0 to the next defined point, and from that point to the extreme, and so on. Personally I think it is overkill -- but if you're going to talk about making many many lines for this then the multi-point curve interpolation is the way to go. In practice the best way _seems_ to be to provide only two slopes -- one positive going, one negative going -- and to establish a weight based on those slopes. Theoretically that could be defined on a single Declude test definition line. Is there some constraint that I don't know about causing folks to consider more complexity? Hope this is helpful, _M -- President MicroNeil Research Corporation www.microneil.com ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer Integration - Multiple Exit Codes
Title: Release 4.10.42 On 5/5/2010 3:24 PM, Andy Schmidt wrote: Hi Dave (just in case this got overlooked or I missed the answer), Also even though there are multiple entries the test only runs once and the resulted exit code is the triggered. I know that all 18 SNF rule lines only require one invocation of Sniffer which are then evaluated 18 different way. Fair enough. I also know that the 3 SNFIP rule lines are only one invocation which is evaluated 3 different ways. And then there is the SNFIPREP rule. So I need to clarify this in my head. Will all 22 SNF rules (even though they are using 3 different commands) evaluate ONE invocation of Sniffer (just different return fields) or is EACH of these 3 command groups (SNF, SNFIP, SNFIPREPS) a separate entity that requires additional overhead? If I may -- I'm not completely sure what you are asking -- but if your concern is that the test for SNFIP and SNFIPREPS represent additional overhead then I can answer that. The amount of code that is run to execute these tests is vanishingly small. You should consider the overhead required to run all three tests as being no more than running the SNF pattern scan. The other two (SNFIP and SNFIPREPS) require so little work that their overhead is virtually impossible to measure. _M -- President MicroNeil Research Corporation www.microneil.com ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer Integration - Multiple Exit Codes
Title: Release 4.10.42 On 5/5/2010 4:05 PM, Andy Schmidt wrote: snip/ The golden rule for external tests and for RBLs is if you have multiple lines using the SAME command (e.g., the 18 SNF lines), or referring to the same external program (e.g., 5 invURIBL lines), or referring to the same blacklist (10 lines checking different return values), THEN only the FIRST line will actually run the test against that resource (e.g., run the external program, lookup the IP in the RBL). The OTHER lines will just evaluate the return code differently without rerunning the test. Now with the internal Sniffer implementation, we have three DIFFERENT commands (SNF, SNFIP, SNFIPREP). So its worthwhile confirming whether the same golden rule applies here even though these are NOT multiple lines of the SAME command. The same rule applies --- Run the test once, use the results of the test many times. However in the case of SNFIP and SNFIPREP the cost of the test is so small that it cannot be measured. The IP reputation database is local (in memory) and immediately accessible (there is no delay or network traffic involved). The only work that gets done is a little bit of math. Best, _M -- President MicroNeil Research Corporation www.microneil.com ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer IP Reputation for white listing
On 4/30/2010 9:32 PM, Andy Schmidt wrote: snip/ But your documentation of the reputation system has a graph that shows that there is yet another category: WHITE. I don't know the details of Declude's impelementation. Presumably they could (or maybe even do) implement WHITE. The SNFIPREP tests does offer the ability to define at what decimal value (between -1 and +1, in .1 increments) a weight can be subtracted. But the question is - is that SENSIBLE use of your reputation database? Per example, could -0.8 be a sensible threshold to give an email credit for coming from a reputable IP source? I'm guessing on how that test is implemented, but if I've guessed correctly then -0.8 would certainly be a good WHITE set point. My guess is based on using a combined score value from the IP reputation that combines the confidence figure and the probability figure. In that case only a strongly negative p coupled with a strong c would result in a -0.8. Or is it better to let the good reputation be considered AFTER the content scan and then use the combined exit code? As I understand it Declude uses a wheighting system --- except for some short-circuit abilities that means all tests are run, their scores are added together, and then the total is used to determine the disposition of the message. I don't think there is an 'AFTER' in this case. The IP reputation test is useful in cases where a message might be too new to hit a pattern match and where the IP reputation is not quite strong enough to be in one of the GBUdb envelopes. In such a case it might be useful to combine the 'analog' reputation score with the scores from other tests to push the message over the fence one way or another... at least that's how the test was designed to work in the API we provide. It sounds like you're describing the IP Reputation test as having thresholds. That's an interesting way to do it (I haven't looked to see if it is actually that way)... a better way to do it would be to scale the result so that from 0 to -1 the negative weight (let's pick a factor of 5) would rise linearly from 0 to -5 and similarly a positive going reputation would scale linearly from 0 to +5 as the API result scaled from 0 to +1. The API result holds 0 as meaning I don't know --- either because the confidence figure (c) is 0 or because the probability figure (p) is 0 (meaning a 50% chance of spam or ham). The farther away from 0 you get the more certain the statistics. Hope this helps, _M --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer IP Reputation for white listing
On 5/1/2010 1:51 PM, Andy Schmidt wrote:
snip/
Right - that's the same scheme I just pointed
out to Dave
myself - except in my case you could pick a distinct factor for the
"-" vs. the "+" side of the scale (because Declude already
has that option anyhow)
I was trying to provide a simple example. In practice it would probably
be better to have separate positive and negative going weights.
snip/
Heres an important question, though:
Do you have a distribution chart for the
reputation scale?
It of course makes a HUGE different, whether the distribution of
reputations reported
for the inflow of email is evenly distributed between -1.0 and 0.1, or
whether
it is a bell curve where 80% are in the center area, or whether
its some sort of exponential curve that has very few with good
reputation, a modest amount around the 0 point, and then expentionally
increasing
towards the bad and turn reputations?
This way one could decide what factors to use
for the +
and sides and where to set the mid point (Declude allows
you to shift the mid-point left and right.
The research we have shows that the curve is largely bipolar and
heavily weighted toward the black. Supposedly "good" ISP's frequently
produce 90% spam from their systems!! Indeed one of the mistakes
we made during early testing was to assume that anybody producing more
than 80% spam was probably not to be trusted and that the remaining 20%
might be explained largely by false negatives --- we were very wrong
about that. (SCIENCE!)
On the other hand, good reputation values do occur and when there is a
strong confidence value they can often be trusted. BUT NOT ALWAYS...
When one of the new pre-tested campaigns hits a fresh bot-net some of
the sources can gain strong positive reputations for a short time. Our
real-time IP conflict instrumentation has shown us a clearer picture of
this -- while we knew it was possible (even likely) we were surprised
to see how often solid new rules for these campaigns will be met with
auto-panics in the field when first deployed.
For this reason we chose a nonlinear curve to boil the statistics down
to a single value. R = sign(p) * sqr(abs(p) * c)
From:
https://svn.microneil.com/websvn/filedetails.php?repname=PKG-SNF-SDK-WINpath=%2Ftrunk%2FSNFMultiDll%2Fsnfmultidll.cpp
default: { // Ugly means we calculate the reputation
Reputation = // figure from the statistics. Start by
sqrt(fabs(Tester.G.Probability() * Tester.G.Confidence())); // combining the c p figures then
if(0 Tester.G.Probability()) Reputation *= -1.0; // flip the sign if p is negative.
}
I recommend a softer weight for "good looking" IP reputations --
something calculated to negate "iffy" tests and avoid false positives.
For "bad looking" IP reputations a strong weight is generally sound
provided there are some countering weights to balance it off when one
of those "Good" ISPs is delivering the message in the midst of their
80% spam flood.
I'm guessing on how that test is
implemented,
but if I've guessed correctly then -0.8 would certainly be a good
WHITE
set point.
Thank you that means in their default
(sample) config file, they really should adjust the midpoint away from
0
to -8 (they multiply the reputation scale by 10 to be able to
work with integers)
You know -- a lot of the professional filtering houses that started
with (or still use) Declude adjusted their scales up to 100 or higher
in order to give more room for fine adjustments. When we were
developing MDLP we preferred that as well. The choice of scale is a
matter of opinion and application -- and in a weight driven system it's
always up for adjustment as every weight interacts with every other
weight.
Best,
_M
--
President
MicroNeil Research Corporation
www.microneil.com
---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] We have opened up truncate.gbudb.net
On 4/29/2010 10:06 PM, Andy Schmidt wrote: Thanks I activated it in my gateway and will report back after a day or so. Question: a) Does it have TXT records that holds additional info that can be returned in the 5.7.1 message to the sender? Right now all of the TXT records say "GBUdb Cloud Truncate c 0.2, p 0.9" As we continue to develop this that may change to provide other (better?) information. b) Is there a lookup URL that can be included in the 5.7.1 message that people can use to learn about your service, learn about the listing/de-listing policy (and determine the status of their IP address in case of a false positive)? When we bring the gbudb.com site online we will explain how the IPs are listed. We may develop a link mechanism to look up specific data on each IP after a time. As for listing and de-listing -- that is automatic and is generally described in the Message Sniffer documentation about GBUdb. If the general population of Message Sniffer nodes are reporting that a message source produces virtually nothing but spam then it will be listed. If those reports go away or their character changes then the listing will change also - and fairly quickly: days if traffic for the IP disappears; hours or perhaps minutes if the character of the traffic from the source changes. Best, _M ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] We have opened up truncate.gbudb.net
I wasn't aware 127.0.0.1 would cause trouble (does it?) It's easy enough to change, but everyone will need to know about the change and will need to change their setup. Please point me to "the standard" so I can understand where the problem is. Thanks! _M On 4/30/2010 1:17 PM, Andy Schmidt wrote: It is and I agree with you! From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Matt Sent: Friday, April 30, 2010 12:53 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] We have opened up truncate.gbudb.net Is the result code really 127.0.0.1? That is totally non-standard. It should be 127.0.0.2 or higher. ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] We have opened up truncate.gbudb.net
On 4/30/2010 1:17 PM, Andy Schmidt wrote: It is and I agree with you! From: supp...@declude.com [mailto:supp...@declude.com] On Behalf Of Matt Sent: Friday, April 30, 2010 12:53 PM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] We have opened up truncate.gbudb.net Is the result code really 127.0.0.1? That is totally non-standard. It should be 127.0.0.2 or higher. Per RFC5782 I see: The A record contents conventionally have the value 127.0.0.2, but MAY have other values as described below in... So it is by convention that the result code would be 127.0.0.2 -- not a rule. I have no problem with this... I will make the change... better to do it now than later. Odd that nobody complained about it before. I will post another note when the change is made. _M ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
[Declude.JunkMail] Changing result code for truncate.gbudb.net to 127.0.0.2 effective immediately.
Hello Declude Folks, RFC 5782 states: IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1. and also states: The A record contents conventionally have the value 127.0.0.2 So we will be changing the result code for truncate.gbudb.net to 127.0.0.2 effective immediately. Thanks! _M -- President MicroNeil Research Corporation www.microneil.com --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Sniffer IP vs. Sniffer IP Reputation vs. Sniffer Truncate
On 4/30/2010 5:16 PM, Andy Schmidt wrote: Hi Pete, I'm look over Decludes recommended Sniffer configuration and trying to understand how much overlap there is between these options: IPREPUTATIONSNFIPREPx 0 10 -5 SNFIPCAUTIONSNFIP x 4 5 0 SNFIPBLACK SNFIP x 5 10 0 SNFIPTRUNCATE SNFIP x 6 10 0 SNFTRUNCATE SNF x 20 10 0 SNIFFER-IP-RULESSNF x 63 10 0 Looking at the Sniffer documentation IP test result codes http://www.armresearch.com/support/articles/software/snfClient/resultCodes.j sp it seems that the SNFIP tests for 4, 5 and 6 (SNFIPCAUTION, SNFIPBLACK, SNFIPTRUNCATE) might coincide with 40, 63 and 20. I am not intimately familiar with Declude's configuration and SNF integration --- not like I used to be anyway (s many platforms now). I _think_ these tests work like this: The SNFIPREP test gives you a variable weight based on the IP reputation in GBUdb. This allows you to get some weighting positively or negatively based on the reputation even when that reputation is not in one of the defined GBUdb envelopes. It's a subtle nudge in the right direction. The SNFIP test gives you a hard result code based only on the IP reputation when that reputation is within one of the envelopes defined for GBUdb. So if the IP reputation is in the Caution, Black, or Truncate range then that test will fire. Presumably all of the IP tests happen before SNF scans the message -- because they can -- I don't know that they do, but I know that IP reputations can be queried before and separately from a scan. (Scans MUST happen in order for GBUdb to build up reputation data however). Finally the SNF test responds to the normal blended result codes that SNFClient would return. So result code 20 is Truncate- meaning that the IP reputation was so bad that SNF stopped the scan and returned the result code. Result code 63 is Black which could mean that an SNF IP rule fired (rare these days) or that no pattern matched but the IP was in the Black range in GBUdb so GBUdb took over and forced the result code from 0 (no pattern found) to 63 (Black). Other result codes are also possible: http://www.armresearch.com/support/articles/software/snfClient/resultCodes.jsp#msgScan David -- if I got any of this wrong please correct me. However, Declude ALSO tests for your Rule Group Result Codes 20 and 63 which are documented here: http://www.armresearch.com/support/articles/software/snfServer/core.jsp 1. It seems to me, as if their SNFTRUNCATE is the same as their SNFIPTRUNCATE, and their SNIFFER-IP-RULES is the same as their SNFIPBLACK -- effectively artificially inflating (doubling) the weights for these tests? Yes -- if you have them configured that way. Some of the results are predictable. If SNFIP is Black or Caution then you are virutally guaranteed to get a Black or Caution result from SNF -- Unless SNF matches a pattern in which case you will get a pattern result code from the SNF test. If SNFIP is Truncate then SNF should also return Truncate. The weights you assign to these should be set accordingly. 2. How do those Caution/Black/Truncate exit codes relate to SNFIPREP. There, any reputation 0 (up to 1) is given an extra weight of 10. But doesn't SNFIPREP report from the same reputation data as the SNFIP (and possibly even group result codes 20 and 63)? In other words, are those IP addresses that generate a reputation factor of 0 ALSO reported as Caution/Black or Truncate - if so, we'd now TRIPLE count that score. That's not quite true... I presume the SNFIPREP test uses a sliding numeric value that combines the probability factor and the confidence factor for the IP. This is not the same thing as Caution, Black, and Truncate. The SNFIPREP result is a sliding value that will work even when the reputation is not in the (White) Caution, Black, and Truncate ranges. When an IP's reputation is in one of those ranges then the appropriate result from SNFIP will either be returned or not (On or Off). Now-- I presume that even when SNFIP does return Caution, Black, or Truncate that SNFIPREP continues to work and in that case will provide some shading to those values... so, if you will, more or less Black, etc. I don't think that I would necessarily use all of these together -- though it is possible to do so. It seems to be that it might become very complicated since there is some overlap. That said -- I do think that some of these tests can be combined successfully without too much confusion... it's just a matter of knowing how they interact. Hopefully my description is helpful (and my assumptions are correct). Best, _M -- President MicroNeil Research Corporation
[Declude.JunkMail] We have opened up truncate.gbudb.net
Hi Declude folks, We have been testing a blacklist based on real-time GBUdb data (generated from Message Sniffer). We have decided to experiment with opening up the blacklist for a wider audience and so as of now you can use truncate.gbudb.net as an ip4r test. You should get a result of 127.0.0.1 if the IP is well into the truncate range -- That is: truncate.gbudb.net is designed to be ultra-conservative so that it should be safe to reject connections based on the test in most cases. This also means that it won't block everything -- only the worst of the worst. That said, the folks who have been testing it have reported that it did drop a significant amount of traffic from their systems on average. Please keep us all posted about how it's working for you. Thanks, _M --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] We have opened up truncate.gbudb.net
On 4/29/2010 5:50 PM, Nick Hayer wrote: Hi Pete, Question - is this blacklist info already contained withing any Sniffer test? I am wondering about double dipping so to speak - if the info is within Sniffer which rulebase? That's not an easy question -- If you are using SNF then your GBUdb node may agree with truncate.gbudb.net --- If it does then the message will be truncated by SNF if it gets through. However, truncate.gbudb.net is a "cloud's view" of GBUdb -- so much of the time the data in truncate.gbudb.net is bigger than what you will have in your GBUdb node. That means that truncate.gbudb.net will be able to stop some traffic that your system has not yet seen. So -- to summarize: * If your system has a particular IP in truncate in your GBUdb node then it is very likely truncate.gbudb.net will also agree. * If you system has no information on a particular IP then truncate.gbudb.net may be able to help you reject the connection anyway. Think of truncate.gbudb.net as a very conservative "big picture" list of very bad IPs. Truncate will almost always know more than your system does for newer IPs. Let me know if that answers the question. Best, _M ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to imail...@declude.com, andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re: [Declude.JunkMail] multistage filtering [OT]
Bonno Bloksma wrote: Hi, With the amount of spam I have to throw away each day no reaching consistant levels of over 90%... I can of course get an even faster mailserver but I think I would be better of with an extra smtp server in front of my mailserver which filters the most blatant spam mail purly based on session info. What passes that server can go on to my IMail server and have more contect based filtering using Declude, Sniffer, InvURIBL etc. What would be a good first step server? I have experience with (Debian) Linux so a Linux based solution is no problem. A couple of things pop into my mind: eWall can live on your mail server and kill off most connections while being trained by SNF. (for example, block IP connections for an hour after an SNF hit). Postfix on a linux box makes a good front-end and can also run SNFMilter in real-time during SMTP. _M --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] truncate.gbudb.net looking for testers.
Hello Declude folks, I asked DB if I could post about this. We're testing a dns based black list derived from Message Sniffer's GBUdb IP reputation system. We will eventually be offering subscriptions to this BL for a modest (really) fee. The list contains IPs that are generalized in the truncate range in the GBUdb cloud. It is updated every 10 minutes. This could be helpful for safely knocking down connections on systems that receive messages first and scan them later. If you are interested in testing this on your system then please send us a note (support@ armresearch.com) and let us know the IP address of your resolver so that we can add it to the ACL. When we go live with this we will prefer that subscribers configure their resolver (Bind 9.3+) as a slave so that it can receive IXFR updates as they occur. If you are interested in testing this functionality please let us know that too. We have a limited number of slots open for testing. We look forward to hearing from you. Best, _M Pete McNeil (Madscientist) Chief Scientist ARM Research Labs --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Help Me Add Weight
Robert Grosshandler wrote: Sounds like a spam headline, doesn't it? Anyway, we're getting obvious spam, but we're not able to weight it enough to block it. Any tests you might suggest. The following came to us BCC'd, I believe. Nothing about it was appropriate for us. snip/ X-RBL-Warning: SNIFFER: Message failed SNIFFER: 60. X-Declude-Sender: scp...@yahoo.com.ar [173.15.150.165] X-Declude-Spoolname: Dccef01a2279a.smd X-Declude-RefID: str=0001.0A010203.498BCCF8.0197,ss=1,fgs=0 X-Declude-Scan: Incoming Score [11] at 23:39:07 on 05 Feb 2009 X-Declude-Fail: UCEPROTECT-1 [4], SNIFFER [12], WEIGHT9 [9], WEIGHTMID [10], ZEROHOUR [0] I'm biased, but you might increase the weight you add for SNF -- I note it did fail the message. Most systems seem to weight SNF so that SNF + any other test will hold a message. Many hold on SNF alone. Given that general practice, adding weight to SNF might solve this problem for you. _M --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] False positive -- Declude + Sniffer
Katie LaSalle-Lowery wrote: I have a situation I haven't seen before. Declude logs show that the message failed Sniffer, which caused the message to exceed our weight threshold and be deleted. Sniffer logs show that the message did not fail Sniffer. Actually that is not correct. The message did fail SNF with a Caution result. s u='20090206143433' m='c:\IMAIL\spool\proc\work\D4a6d019b50e3.smd' s='40' r='0'/ p s='0' t='31' l='61394' d='37'/ g o='0' i='63.118.171.179' t='u' c='0.142858' p='0.5' r='Caution'/ /s The caution result (symbol 40) will resolve itself almost immediately in most cases because the caution range in GBUdb is very thin. When a caution result is produced it indicates that there was no pattern match but the IP is suspicious. Since the message did not match a pattern result code the statistics for the IP are usually moved out of the caution range on the first event. How do I prevent recurrence of this false positive deletion? Note that the statistics show this IP has produced spam about 75% of the time (probability figure = 0.5). You may want to look into what other messages this IP has sent to you that were filtered out - and why. If you would like to be more lenient on your system (especially during spam storms) then you could turn off the caution range or you could adjust it's envelope settings. Hope this helps, _M --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] SPF Issue
It's a tiny thing - but it might matter: When I dig for your spf record dig @ns1.cefib.com cefib.com -t txt I get: ;; ANSWER SECTION: cefib.com. 3540IN TXT v=spf1 mx ip4:217.64.107.106 -all On the surface it looks correct, but the -all should be ~all That is - it should be a tilde not a dash. Seems like a little thing, but that's also the only thing that doesn't look right when compared to what I get approximating this at openspf.org. Hope this helps, _M On Monday, September 1, 2008, 7:15:35 PM, Serge wrote: S Here is what i get from DNSSTUFF S Not sure what else to do to find out what is going on S How I am searching: S Searching for cefib.com SPF record at f.root-servers.net [192.5.5.241]: Got S referral to D.GTLD-SERVERS.NET. (zone: com.) [took 59 ms] S Searching for cefib.com SPF record at D.GTLD-SERVERS.NET. [192.31.80.30]: S Got referral to ns1.cefib.com. (zone: cefib.com.) [took 31 ms] S Searching for cefib.com SPF record at ns1.cefib.com. [217.64.107.100]: S Reports that no SPF records exist. [took 301 ms] Response: No SPF records S exist for cefib.com. [Neg TTL=3540 seconds] Details: ns1.cefib.com. (an S authoritative nameserver for cefib.com.) says that there are no SPF records S for cefib.com. The E-mail address in charge of the cefib.com. zone is: S [EMAIL PROTECTED] S There is no need to refresh the page -- to see the DNS traversal, to make S sure that all DNS servers are reporting the same results, you can Click S Here. Note that these results are obtained in real-time, meaning that these S are not cached results. These results are what DNS resolvers all over the S world will see right now (unless they have cached information). S - Original Message - S From: Andy Schmidt [EMAIL PROTECTED] S To: declude.junkmail@declude.com S Sent: Monday, September 01, 2008 12:41 PM S Subject: RE: [Declude.JunkMail] SPF Issue What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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 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. S --- S This E-mail came from the Declude.JunkMail mailing list. To S unsubscribe, just send an E-mail to [EMAIL PROTECTED], and S type unsubscribe Declude.JunkMail. The archives can be found S at http://www.mail-archive.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] SPF Issue
Ooops. I take that last post back I found something else looking more closely: ;; ANSWER SECTION: cefib.com. 3540IN TXT v=spf1 mx ip4:217.64.107.106 -all The mx should not be naked. Presumably what you wanted was this: v=spf1 mx:cefib.com ip4:217.64.107.106 ~all Hope this helps, _M On Monday, September 1, 2008, 7:15:35 PM, Serge wrote: S Here is what i get from DNSSTUFF S Not sure what else to do to find out what is going on S How I am searching: S Searching for cefib.com SPF record at f.root-servers.net [192.5.5.241]: Got S referral to D.GTLD-SERVERS.NET. (zone: com.) [took 59 ms] S Searching for cefib.com SPF record at D.GTLD-SERVERS.NET. [192.31.80.30]: S Got referral to ns1.cefib.com. (zone: cefib.com.) [took 31 ms] S Searching for cefib.com SPF record at ns1.cefib.com. [217.64.107.100]: S Reports that no SPF records exist. [took 301 ms] Response: No SPF records S exist for cefib.com. [Neg TTL=3540 seconds] Details: ns1.cefib.com. (an S authoritative nameserver for cefib.com.) says that there are no SPF records S for cefib.com. The E-mail address in charge of the cefib.com. zone is: S [EMAIL PROTECTED] S There is no need to refresh the page -- to see the DNS traversal, to make S sure that all DNS servers are reporting the same results, you can Click S Here. Note that these results are obtained in real-time, meaning that these S are not cached results. These results are what DNS resolvers all over the S world will see right now (unless they have cached information). S - Original Message - S From: Andy Schmidt [EMAIL PROTECTED] S To: declude.junkmail@declude.com S Sent: Monday, September 01, 2008 12:41 PM S Subject: RE: [Declude.JunkMail] SPF Issue What is the issue? What error message? Was it bounced mail? What did the NDR say? I could be a recipient trying to forward mail to another server, or an end-user trying to send email from home using their local ISP... etc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Sunday, August 31, 2008 10:18 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] SPF Issue Hi all I have som SPF issues It was working fine some times back I use Mixrosoft dns I have (same as parent)Text v=spf1 mx ip4:217.64.107.106 -all mailText v=spf1 mx ip4:217.64.107.106 -all What is wrong with above ? TIA --- 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 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. S --- S This E-mail came from the Declude.JunkMail mailing list. To S unsubscribe, just send an E-mail to [EMAIL PROTECTED], and S type unsubscribe Declude.JunkMail. The archives can be found S at http://www.mail-archive.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] RE: Thoughts on running DNS on the IMail (declude) server ???
We've done this in the past also -- it made quite a difference, especially on underpowered hardware. _M On Thursday, July 10, 2008, 5:18:30 PM, Fox,Thomas wrote: FT We do, it works really well. Quite Speedy!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ferrell Ard Sent: Thursday, July 10, 2008 4:38 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] RE: Thoughts on running DNS on the IMail (declude) server ??? Hey David What would your thoughts be on running a Caching ONLY DNS on the IMail (declude) server ??? Thanks very much Ferrell - Original Message - From: Todd Richards [EMAIL PROTECTED] To: declude.junkmail@declude.com Sent: Thursday, July 10, 2008 4:26 PM Subject: X-IMail-SPAM RE: [Declude.JunkMail] Overnight Spam Increase? OK, that was it. I went onto my mail server and tried to ping my DNS server. No go. I rebooted my DNS server, flushed the cache from my mail server, then all was well. It looks like things are working again. Quick question - can I add a second DNS server (which I have) so that it looks there if the primary is unavailable? I never thought of that but I guess anytime I have to reboot the primary server, then I am effectively leaving the mail server unprotected. Thanks, David! Todd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Thursday, July 10, 2008 2:01 PM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Overnight Spam Increase? ISSUE: Spam is slipping past Declude that hasn't normally passed any filtering. Spam is not being weighted high enough for actionable thresholds to take effect. Place your LOGLEVEL in DEBUG, let it run for several minutes and then open the log. What we are trying to do is identify a possible DNS issue. Packets not making it to the DNS server or not making it back from the DNS server can be an issue if you are running Declude Security Suite. The reason is we rely heavily on these queries to be successfully resolved in order to trigger certain test and assign spam a high enough weight. If you see the following in the log, find out where these queries are going because they aren't getting back to the application. 02/07/2007 13:48:34.640 35958831 Test #2 [ADNSBL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #3 [BLITZEDALL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #4 [CBL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #5 [CSMA-SBL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #6 [DSBL-CONFIRMED] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #7 [FIVETEN-SRC] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #7 [FIVETEN-SRC]didn't get a response 02/07/2007 13:48:34.640 35958831 Test #8 [JAMMDNSBL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #9 [INTERSIL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #10 [IPWHOIS] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #11 [IMP-SPAM] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #12 [MXRATE-BLOCK] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #12 [MXRATE-BLOCK] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #12 [MXRATE-BLOCK] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #14 [NJABL] is same as Test #14 [NJABL=127.0.0.2]. Answer=? 02/07/2007 13:48:34.640 35958831 Test #15 [SBL] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #16 [SORBS-HTTP] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #16 [SORBS-HTTP] didn't get a response 02/07/2007 13:48:34.640 35958831 Test #16 [SORBS-HTTP] didn't get a response RESOLUTION: Check your diags.txt, if you see an IP address next to the DNS field and you see the above in your DEBUG log, that DNS server has either stopped responding or connectivity has been lost between the email server and the DNS machine. If no IP address has been identified in this field then Declude is having an issue reading it from your mail server itself. Open up your Global.cfg and specify an alternate address to another DNS server next to the DNS directive near the top of the file. Make sure to save your file, rename or delete the old DEBUG log and start a new one. You should see that these didn't get a response goes away. If you do not have an alternate DNS server try use the following. DNS 208.67.222.222 Also check your firewall to make sure it is not blocking DNS queries. David B -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Richards Sent: Thursday, July 10, 2008 11:05 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Overnight
Re[2]: [Declude.JunkMail] form spam filter
On Wednesday, April 9, 2008, 10:01:56 AM, Craig wrote: Hi Darin, I guess what I am looking for from Declude (or a third party) is to provide me a filter that will phrase filter the incoming form mail and determine if its a spammy one or not. We may be able to help you. Please send some samples (zipped) off list --[EMAIL PROTECTED] _M --- 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 came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] multiple simultaneous problems
All of that is good advice -- but one extra thing drew my attention -- IMAP running 99% CPU -- in my mind that points to possible file system issues - What shape your file system is in: Is it badly fragmented? Are any of your drives performing badly? Also - has someone suddenly changed what they are doing in IMAP that could cause heavy IO loads? One system I helped on recently was slowly sucking itself into it's own private circle of hell along with it's admin. I followed the performance trail to the IO and found that a couple of large log files were very badly fragmented -- I moved those files to a new location and everything perked up right away. * File moves often evaporate fragmentation. * Files that grow slowly over a long period on a mail server on NTFS tend to get badly fragmented. My $0.02. _M On Friday, February 29, 2008, 3:38:53 AM, John wrote: 1) Are they just q files or d files or both? 2) Tripple check the DNS server(s) being used for problems. 3) Do you have a lot of large mailboxes? Has the amount of email flowing in increased? 4) Review information on the Sniffer list about updating to the new service model. Also, what version of Imail, what version of Declude? John T eServices For You -Original Message- From: "David Dodell" [EMAIL PROTECTED] Sent 2/28/2008 9:10:02 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] multiple simultaneous problems After running Declude / Imail smoothly for years ... the last few days have been the pits (1) Multiple files showing up in the /spool/proc directory and not leaving (2) Declude is failing to make connections on RBL tests about 10 to 20% of the time. Running in debug mode will show one message running against multiple DBL tests, and then the message will show the first 5 DBL tests running, and the rest fail with "no connection" (3) IMAP4d32.exe services are running 99% of the cpu time ... (4) Multiple instances of the sniffer exe program Any thoughts on where to start ... I've rebooted, stopped services, restarted services ... works fine for about 8 hrs then starts up all over again David --- 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 archivehttp://www.mail-archive.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 came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] multiple simultaneous problems
On Friday, February 29, 2008, 8:14:41 AM, David wrote: snip/ 4) Review information on the Sniffer list about updating to the new service model. DD I should be on the latest version of Sniffer ... just renewed my DD contract ... haven't made any changes to the configuration in months. I've checked and I don't see telemetry from your SNF installation... It's a good bet that you are running version 2.5 -- which is ok, but the latest version is 2-9b1.5 - a late beta. The beta is production ready -- it is only still beta because we are adding a few features before calling it a release candidate -and shortly after that - version 3. The newest version is faster, more efficient, and more accurate. Based on your description of the problem, moving to the newest version of SNF will probably not solve your problem - but it may reduce the system load enough to make a dent. For scientific reasons (not changing too many things at once) you may want to resolve your IMAP issue first, but that done-- upgrading to the latest version of SNF is highly recommended. One key reason that it might help in this case is that the 2.x version of SNF uses the NTFS file system to track scan jobs and the new version uses local TCP connections. With the older version, when under extreme load conditions, the file system can become so slow that SNF can't process messages quickly-- SNF scan jobs get killed off before they are completed, and the message job files build up making the problem worse. This can be... trouble ;-) The new version does not use the file system at all except to access the message files so it is immune to the overload problem described above. Hope this helps, _M --- 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] multiple simultaneous problems
On Friday, February 29, 2008, 11:26:58 PM, David wrote: snip/ Short of installing a new network card / drive ... any other thoughts what to try It's a long shot - but if it were my server I would try it: Shut down IMAP. Temporarily shut down SMTP so that new mail doesn't go in to those boxes. Remove the mailbox files from all of the users who use IMAP. Restart IMAP. See if it acts normal. If it does, proceed. If not - this is fubar - try something else. Put back one mailbox file at a time and observe IMAPs behavior. As long as IMAP seems normal continue. At some point - presumably - one of the mailbox files will cause IMAP to go crazy -- if we're lucky. When you find that one -- move it off again to avoid the problem (probably restart IMAP to do it). Replace the other IMAP users' mailbox files. If this procedure works as expected we may discover a corrupted mailbox file that is causing a problem with IMAP. If we're that lucky then we will be able to decide what to do with that mailbox file later and in the mean time go back to normal. Let me know if this works (hope it does). If it doesn't work I hope we learn something new at least. Best, _M ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] Any Known issues Inv-URIBL today?
On Wednesday, February 6, 2008, 2:09:23 PM, Herb wrote: Hi Randy; We have seen that often, in fact what we do is swap that test in on nights and weekends and out during weekdays (by just renaming the declude conf files with a schedule). It is a nice tool but will bog things down. I'm curious - (I don't use this but many of my customers do) Is it possible to run Inv-URIBL only on messages that have not yet reached a hold (or other appropriate) weight? Perhaps using weightgate? If SNF is running ahead of it then would that have the effect of only running inv-URIBL on messages that have not already been tagged as spam by SNF? What are the limits of conditional test triggers in the Declude environment (aside from AVAFTERJM)? _M ---This E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] Spam Increase?
Spam has significantly increased in the past 7 days due to new bot nets (from old friends) and a number of new tactics for generating pdf and related spam and their mutations. I've attached a new-spam/leakage analysis from our primary spamtraps- you can see that new traffic quite literally more than doubled (like a vertical wall) 7 days ago. Hope this helps, _M On Friday, August 3, 2007, 6:19:30 PM, John wrote: JTl I actually saw it ramping up since last weekend and every day there have JTl been a change or 2 in the spam to keep it from being caught. JTl John T -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Richards Sent: Friday, August 03, 2007 2:35 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] Spam Increase? Anyone else noticing an increase in spam today? It seems like stuff that was normally being caught before is showing up in my Inbox. Todd --- 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. JTl --- JTl This E-mail came from the Declude.JunkMail mailing list. To JTl unsubscribe, just send an E-mail to [EMAIL PROTECTED], and JTl type unsubscribe Declude.JunkMail. The archives can be found JTl at http://www.mail-archive.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.attachment: 2007080330daySnapshotVerticalWall.png
Re[2]: [Declude.JunkMail] Fidelity Independent Adviser
We are processing the FPs on this right now. The rule has been in place for 866 days without prior FP reports. It's going away now. Thanks, _M On Wednesday, July 18, 2007, 9:15:13 PM, Darin wrote: DC We had one that was definitely an FP last week. Submitted and received a DC response that the rule had already been removed. DC Darin. DC - Original Message - DC From: John T (lists) [EMAIL PROTECTED] DC To: declude.junkmail@declude.com DC Sent: Wednesday, July 18, 2007 9:03 PM DC Subject: [Declude.JunkMail] Fidelity Independent Adviser DC First time I am seeing this one, caught by Sniffer. DC Any one have experience with their newsletters? Legit? Ham? Spam? DC John T DC --- DC This E-mail came from the Declude.JunkMail mailing list. To DC unsubscribe, just send an E-mail to [EMAIL PROTECTED], and DC type unsubscribe Declude.JunkMail. The archives can be found DC at http://www.mail-archive.com. DC --- DC This E-mail came from the Declude.JunkMail mailing list. To DC unsubscribe, just send an E-mail to [EMAIL PROTECTED], and DC type unsubscribe Declude.JunkMail. The archives can be found DC at http://www.mail-archive.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] Re: PDF spam detection
Use caution. The first part of the PDF file is common to many PDF files and coding for that will lead to false positives.
The PDFs we're seeing are essentially boiler plate up to the first 12 lines (or so) of base64 encoded data, then there are some variable segments where the image display size and other parameters are randomized, then you will find another consistent segment which is the header of the encoded image file -- here again that segment will cause false positives for any similar type of image. After the image header you will find the usual obfuscated image in ordinary image spam.
Hope this helps,
_M
On Friday, June 29, 2007, 9:08:02 AM, David wrote:
Just a quick question I have noticed that these PDF files all have the following string in the first line is there something I am missing ? I have been using it to catch these spams any thoughts ?
BODY 3 PCRE (JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmo)
From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf OfDarin Cox
Sent:Thursday, June 28, 2007 12:49 PM
To:declude.junkmail@declude.com
Subject:Re: [Declude.JunkMail] Re: PDF spam detection
I was thinking Regex wasn't available since I'm still using 2.0.6, but forgot I could use an external test and the regex available in the windows Findstr command.
Darin.
- Original Message -
From:Matt
To:declude.junkmail@declude.com
Sent:Thursday, June 28, 2007 12:37 PM
Subject:Re: [Declude.JunkMail] Re: PDF spam detection
Here's a piece of RegEx code that should work for blank bodies with a PDF and this particular spammer so long as he is forging Thunderbird:
-+[0-9]+\r\n(?:[a-zA-Z\-]+: [^\r]+\r\n)+(?:\r\n){1,}-+[0-9]+\r\n(?:[a-zA-Z\-]+: [^\r]+\r\n)*Content-Type: application/pdf;
Note that I have not tested this, but the code is in fact fairly simple and it should work.
Matt
Darin Cox wrote:
So far all that I've seen have a blank body with the pdf attachment.
Anyone have any ideas as to how to test for a blank body, or one with only whitespace characters? The new PCRE function can do it, but we're still on 2.0.6 at the moment, waiting until IMail 2006.21 comes out and passes testing.
I'm thinking a blank body test with PDF attachment detection should result in very few FPs. Still possible, but hopefully enough to hold on until a better detection method can be found.
Darin.
_
Test footer
---
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
athttp://www.mail-archive.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 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 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 came from the Declude.JunkMail mailing list. Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail". The archives can be foundat http://www.mail-archive.com.
Re[2]: [Declude.JunkMail] Declude/Sniffer Issues
On Monday, February 19, 2007, 1:39:39 PM, Darrell ([EMAIL PROTECTED]) wrote: If I might add to this... Declude is topping SNF instances before they have time to work -- This causes job files (.XXX and so forth) to build up and cause other SNF instances to relax their timing - in theory to compensate for a high system load. The relaxed timing causes even more instances to be killed off by Declude exacerbating the problem. When you have a high rate of messages and many concurrent instances of SNF it can take a while for a batch to complete. If Declude kills them off before they are done, this starts the ball rolling on a cascade failure. You will need to adjust the amount of time that SNF is allowed to run and extend it. I've heard of this setting but I don't know precisely where it is. Someone here probably does. Hope this helps, _M PS: To see what the job file extensions look like please go here: http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.Peer-Server#What_file_extensions_that_are_used_for_the_various_temporary_files_that_are_created_in_the_Sniffer_folder.3F Note that when you are running a persistent instance of SNF, you are actually in peer-server mode, but your persistent instance has been tricked into staying alive as a server indefinitely -- so all of the other instances always let the persistent instance do the scanning. Chris, I am gathering that you are running Sniffer in persistant mode? I would stop your declude and Sniffer services. Than go into the sniffer directory and remove all of the *.fin, *.svr files. I am not sure what the .xxx files are. I have yet to see those. Than I would check your Sniffer log for any errors. After making sure there are no errors I would restart the Sniffer persistant service and Declude and see if the issue is resolved. It's possible Sniffer could be stepping on itself trying to weed through all those files. Darrell Check outhttp://www.invariantsystems.comfor utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From:Chris Patterson To:declude.junkmail@declude.com Sent:Monday, February 19, 2007 1:03 PM Subject:RE: [Declude.JunkMail] Declude/Sniffer Issues I get this in logs: 02/19/2007 05:16:12.213 23859386 ERROR: External program SNIFFER didn't finish quick enough; terminating. 02/19/2007 05:16:12.213 23859386 Couldn't get external program exit code At this point I see thousands of .xxx and .fin files built up in the sniffer directory. Usually forcing a sniffer update (normally done every hour automatically). From:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf OfDarrell ([EMAIL PROTECTED]) Sent:Monday, February 19, 2007 9:32 AM To:declude.junkmail@declude.com Subject:Re: [Declude.JunkMail] Declude/Sniffer Issues What are you seeing the logs that indicates this? Declude will terminate long running external processes and log that it terminated it. Are you seeing those entries? Also, during these times when you look at task manager do you see a bunch of idle sniffer processes? Typically from my experience when you see all the threads being used with very little to no CPU usage it tends to be a DNS issue (i.e slow or not responding DNS server). Darrell Check outhttp://www.invariantsystems.comfor utilities for Declude And Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. - Original Message - From:Chris Patterson To:declude.junkmail@declude.com Sent:Monday, February 19, 2007 8:47 AM Subject:[Declude.JunkMail] Declude/Sniffer Issues I am running 2 versions of Smartermail Declude both running Sniffer and InvURIBL. One is Smartermail4/Declude4.3.3 Other is Smartermail2/Declude3. These servers can run perfectly for weeks but for the past few weeks we have been sporadically seeing Declude back up files in the Proc directory. At this time all Declude threads are being used with no processing power being used. It appears Sniffer is not finishing and hogging up all the threads after reviewing the logs. Anyone else experiencing this? Thanks, Chris Patterson, CCNA Network Engineer/Support Manager Rapid Systems --- 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 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 came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe
Re: [Declude.JunkMail] How Accurate is Sniffer?
On Thursday, November 30, 2006, 10:25:25 PM, David wrote: DD I'm doing my 30 day trial of Message Sniffer .. at the moment it is 5 DD points out of 10 needed to mark something as spam. DD How accurate is Sniffer?Something that I can raise my weight on? These days many folks are setting SNF to their hold weight. A conservative approach has been to set SNF just below your hold weight so that SNF plus one other test will hold a message. The newest spam campaigns have made things very difficult to filter so we have been recommending that at least some result codes should be weighted high enough to hold a message - especially group 60 and 61 since they are often the only test that will fire. Hope this helps, _M --- 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] Flooded with spam
If this year goes like last year then much worse is yet to come. See the bottom of this chart: http://reports.messagesniffer.com/Performance/FlowRatesByDay.jsp _M On Wednesday, August 30, 2006, 9:24:34 PM, gbirdsall wrote: gsc I've seen a 100-130% increase since Sunday. An average day used to be gsc around 500k-550k Spam messages, the past two days have been 950k and 1.2 gsc million, respectivly. gsc One thing we implemented was session based blocking in our firewall, we gsc were getting between 200 and 4000 (not a typo) simultanious sessions from gsc IP addresses. We now grab that and block IPs based on this information. gsc It has helped already today. gsc - greg Just checking with the list if they have seen an increase in the amount of spam messages caught. Last monday and tuesday my mail servers are flooded with spam. My smartermail server that usually process 30 to 40 K per day, processed on monday 120K and 94K of them where caught as spam. On tuesday processed aprox 110K, and 85K where spam. My spool and forward server processed over 140K yesterday. Reviewing the spool I would say that almost all spam, a lot of them trying to relay on my backup server Do you guys saw this spam increase?. btw. message sniffer, INVURIBL and declude worked fine.. I am happy I have them. regards Luis Arango --- 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. gsc --- gsc This E-mail came from the Declude.JunkMail mailing list. To gsc unsubscribe, just send an E-mail to [EMAIL PROTECTED], and gsc type unsubscribe Declude.JunkMail. The archives can be found gsc at http://www.mail-archive.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] Ping
Polo On Friday, August 11, 2006, 11:30:36 AM, David wrote: DB Ping DB --- DB This E-mail came from the Declude.JunkMail mailing list. To DB unsubscribe, just send an E-mail to [EMAIL PROTECTED], and DB type unsubscribe Declude.JunkMail. The archives can be found DB at http://www.mail-archive.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] How to get support from sniffer....
Chuck, I stepped away for a while (started work today at midnight). I've found your FPs and I will address them immediately. I note you did not leave a message on the support line (that I can see). I'll take the rest of this off list. Thanks, _M On Wednesday, May 24, 2006, 2:12:39 PM, Chuck wrote: CS It appears in the sniffer rulebase updated yesterday one of the rules trips CS the getrich test on sniffer when emails are sent from or to our domain name. CS I have identified the rule and made a panic rule entry. But it appears the CS problem is more wide spread. I have sent messages to CS [EMAIL PROTECTED], [EMAIL PROTECTED], and have submitted several CS examples to [EMAIL PROTECTED] with absolutely no response. I am CS concerned that my emails are not getting through because of the bad rule - CS when I sent a message to the sniffer list it never shows up making me CS suspect the bad rule is torpedoing my email correspondence. CS This is a big catch-22. I wish that sortmonster had a web based ticketing CS system. Anybody have a non email way of getting ahold of sortmonster. The CS tech support phone number on the armresearch web site just goes to voice CS mail. CS Sorry to post this here but I want to get this resolved. CS Chuck Schick CS Warp 8, Inc. CS (303)-421-5140 CS www.warp8.com CS --- CS This E-mail came from the Declude.JunkMail mailing list. To CS unsubscribe, just send an E-mail to [EMAIL PROTECTED], and CS type unsubscribe Declude.JunkMail. The archives can be found CS at http://www.mail-archive.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] Spam
On Friday, May 19, 2006, 1:33:06 PM, Kevin wrote: KB Has anyone else seen an increase of spam since Blue Security wet offline?? KB We have seen an increase and we did not even use the software/service. We've noted a few bursts today but nothing completely out of the ordinary. _M --- 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] Spam
One thing that we noticed a few hours ago was a new image spam that has quite a bit of bandwidth behind it and all new zombies - perhaps that's a piece of it. _M On Friday, May 19, 2006, 3:30:33 PM, Rick wrote: RB Same here RB Rick RB -Original Message- RB From: [EMAIL PROTECTED] RB [mailto:[EMAIL PROTECTED] On Behalf Of Dave Doherty RB Sent: Friday, May 19, 2006 12:01 PM RB To: Declude.JunkMail@declude.com RB Subject: Re: [Declude.JunkMail] Spam RB I have noticed more stuff has been getting through. I don't know whether RB that represents a general increase or new spammer techniques. RB -d RB - Original Message - RB From: Kevin Bilbee [EMAIL PROTECTED] RB To: JunkMail Declude declude.junkmail@declude.com RB Sent: Friday, May 19, 2006 1:33 PM RB Subject: [Declude.JunkMail] Spam Has anyone else seen an increase of spam since Blue Security wet offline?? We have seen an increase and we did not even use the software/service. Kevin Bilbee Network Administrator Standard Abrasives, Inc. [EMAIL PROTECTED] (805) 520-5800 x7332 Changing the way industry works. --- 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. RB --- RB This E-mail came from the Declude.JunkMail mailing list. To RB unsubscribe, just send an E-mail to [EMAIL PROTECTED], and RB type unsubscribe Declude.JunkMail. The archives can be found RB at http://www.mail-archive.com. RB --- RB This E-mail came from the Declude.JunkMail mailing list. To RB unsubscribe, just send an E-mail to [EMAIL PROTECTED], and RB type unsubscribe Declude.JunkMail. The archives can be found RB at http://www.mail-archive.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] How would you create a filter for this?
I added an abstract for this text pattern to Message Sniffer today. We regularly create similar rules for other variations - these patterns are independent from the URI. _M On Tuesday, April 25, 2006, 11:59:20 AM, Scott wrote: SF SF SF I might suggest something to target the links of the emails, SF like Sniffer or INVURIBL as a good attack vector. SF SF Combo that test with a CBL result, since these often come from CBL lists. SF SF SF SF Dealing with all of the combinations would result in a painfully long filter. SF SF SF - Original Message - SF SF From: Michael Graveen SF SF To: Declude.JunkMail@declude.com SF SF Sent: Tuesday, April 25, 2006 10:22AM SF SF Subject: [Declude.JunkMail] How would youcreate a filter for this? SF SF Hello, SF I have checked through the archives and I have notbeen able SF to find anything on creating a filter to block something like V p SF I t A p G i R h A g ( where every other letter isused to spell SF a word). The capital letters stay the same from email to SF email, but the lower case letters change. Is there a way to set SF up afilter line to catch this? I am using Declude JunkMail Pro 2.0.6.16 SF Thanks in advance, SF Mike SF --- 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] Sniffer in Persistent Mode using Windows Resource Kit Tools
On Wednesday, January 18, 2006, 9:28:16 AM, Dean wrote: DL Markus, DL DL You still point to the executable in your global config file, DL but since sniffer is running in persistant mode, it doesn't DL automatically launch a new instance. That's almost correct... What happens is that the new instance recognizes that there is a persistent instance running and hands off the job to that service rather than processing it on it's own. _M --- [This E-mail was scanned for viruses by Declude EVA 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] Sniffer Invuribl
On Sunday, October 2, 2005, 1:23:21 PM, Serge wrote: S Hi all, S S I have been using sniffer for a year and recently add INVURIBL. S i am trying to find the corrolation between the 2 test to set the weight. S I tag at 10 and delete at 30.. S I had sniffer at 14. S now i added invuribl with a max weight of 14. S i have spamcop at 9. S and a set of negative weight filter to compensate for most FP. S Should i lower sniffer now that I added Invuribl ? S (this is an isp setting) I'm pretty sure the only reason to decrease a weight would be if a test became less accurate... so you should probably leave it as it is. Presumably, if both tests hit you would be _very sure_ it was spam. MHO Hope this helps, _M --- 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] Sniffer error in Declude log
On Sunday, September 11, 2005, 11:46:12 PM, Kim wrote: KP Over the weekend, a lot of spam has been getting through. KP Checking the Declude JunkMail log file shows the following: KP09/10/2005 00:01:41.906 q84a2205001d48c60 ERROR: External KP program SNIFFER didn't finish quick enough; terminating. KP Can anyone shed some light on this? That is, what would cause KP Sniffer to not complete in a timely manner? I responded to you directly also, but forgot to mention, please check the SNF logs for errors and also check to see what they say about how long the messages are taking to setup and to scan. If you see setup times and you have a persistent instance running then that indicates either that the persistent instance crashed for some reason or that (more likely) your system is heavily overloaded - this can cause client instances to give up waiting for SNF to finish other jobs--- they then begin processing their jobs themselves (and loading the rulebase) which further loads the system so that it can't recover. --- An experimental fix for systems that are this overloaded is to reduce the number of concurrent threads (normally 30, try 20 or even 10 in extreme cases depending upon your conditions). If you are not running a persistent instance then this would be a good time to begin :-) hope this helps, _M PS: There may be many other things I don't know about this case -- the above is an intuitive guess... --- 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] Sniffer Question
Sorry to but in - can't resist... ;-) The test will run only once, but it will be evaluated for each possible result (Declude is smart that way). You might even have more than one test use SNF and add weight.. for example, SNIFFER ... nonzero and SNFSPECIFIC ... result. Many folks and the AI system's we've been experimenting with tend to put the SNF weight at about 70% of the hold weight. Hope this helps, _M On Friday, September 2, 2005, 8:19:11 PM, Dave wrote: DD John, does that mean sniffer runs 17 times on each mesage, or does it return DD multiple codes? DD - Original Message - DD From: John Tolmachoff (Lists) [EMAIL PROTECTED] DD To: Declude.JunkMail@declude.com DD Sent: Friday, September 02, 2005 8:02 PM DD Subject: RE: [Declude.JunkMail] Sniffer Question Best thing is to ask on the Sniffer List. I actually have 17 Sniffer tests based upon exit code, with weights ranging from 15 to 35. I hold at 25 and delete at 35. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Kevin Rogers Sent: Friday, September 02, 2005 4:37 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Sniffer Question I just setup Sniffer for the first time and I'm wondering what people have their external test weight set to. My global.cfg came with a sniffer test already configured (though it was commented out) to have a weight of 7, which actually gives it a weight of 8 for some reason I couldn't figure out. If you haven't made up your own weighting system (some people have their weights go up to 300 or more), what's a good weight for a failed sniffer test? At 10, I put messages into a bulk folder, at 17 I hold them. Thanks --- [This E-mail was scanned for viruses.] --- 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 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. DD --- DD This E-mail came from the Declude.JunkMail mailing list. To DD unsubscribe, just send an E-mail to [EMAIL PROTECTED], and DD type unsubscribe Declude.JunkMail. The archives can be found DD at http://www.mail-archive.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] Deleting emails based solely on Sniffer?
On Thursday, April 14, 2005, 8:50:12 AM, Joey wrote: JP Can someone please explain to me why, if an email is flagged as spam by JP Sniffer, I shouldn't just delete it outright? Are there instances where JP Sniffer is wrong? Or is this the way you all use it already? JP Reason I ask is that I have Sniffer setup with a weight of 10...and I hold JP messages with a weight of 10-14. This morning I got a Nigerian-type scam JP that sniffer flagged, but it only scored a total weight of 5. I'll have to JP check through my global.cfg when I get back from my 9am meeting, but JP something added a weight of -5 somewhere, meaning the email got JP through. If I had deleted all Sniffer-found spam outright, this would not JP have happened. JP Thoughts? ... Just adding to the thread... First, I agree with Nick Don ... As much as we try to make SNF perfect, the definition of it's design, and the fact of any spam test dictate that there will be some error rate. For example, our false positive handling process is based on our best guess about the consensus of all of our customers Do most of the people we serve agree with this rule? Is that agreement worth the risk of a false positive? These questions are answered primarily by statistics... The point is that there is a gray area where some folks will always find a false positive (and we generally will adjust their rulebase accordingly). That somebody could be you :-) So it is safest NOT to delete on SNF, or for that matter any single test - even if that will lead to some spam getting through. This is one of the key benefits of Declude is it's weighting system. That said, the best practice (as I observe it) is to always hold on SNF and to delete on a specific weight that is high enough to include at least two other tests. Using this strategy, any FP generated by SNF will still be around to be noticed if it is discovered - either by review or by a customer asking why some message appears to be missing. The message can then be recovered, a false positive report made, and appropriate adjustments implemented. In your scenario you might want to set the weight of SNF higher so that the -5 might still keep the message in your hold range. This might force you to adjust your upper limit on the hold weight, but it's a decent compromise I think. In the end only you can know for sure what is the best strategy for your system. All of this is a balance of resources and risks. There are many happy systems out there that do regularly delete messages on a single test - for example IMGate which has been debated widely. While I would not recommend deleting a message solely on SNF as a general practice, clearly there is room for this strategy on some systems. Hope this helps, _M --- 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] Running declude from another program
On Monday, April 11, 2005, 5:15:59 PM, David wrote: DHM Does anybody know if you have to do something special to DHM call declude from another program? I need to run a program DHM before declude is run. I'm pretty sure that you can get away with this as long as your program is thin enough, passes everything correctly (including the environment), and calls declude for each pass. I'm sure I'll be corrected if I'm wrong. Why do you want to do this? _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster - www.sortmonster.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] Huge reduction in hold queue
On Wednesday, March 30, 2005, 10:35:52 PM, Darin wrote: DC Pete, DC DC Have you make significant changes to the sniffer rulebase in the past couple of days? DC DC I'm seeing a _huge_ reduction in hold queue messages... DC roughly down 65%... while total message volume is steady. Only DC thing I can figure is that the rulebase is suddenly identifying DC most of the messages that fail other tests as well, pushing most DC over the delete limit or other tests like SpamCop, DC Mailpolice, etc. have made significant changes... I've checked a DC few sites for news, but am not seeing anything new. DC DC The sudden change has me a wee bit concerned...cautiously optimistic, but concerned. THis might be better asked on the Sniffer forum rather than Declude's though I'm sure they don't mind. The only thing I can think of is that there has been a greater use of message fragment rules over the past few days in response to some of the newer campaigns. I wouldn't call that a radical change - but it has been a moderately heavy shift. In particular there is a new snake oil campaign that is using a number of randomized obfuscated segments in their message and we've been capitalizing on that. I don't see any significant shifts in the statistics. What I do see is a subtle change in the shape of the new rule capture curve (see the left side of this chart): http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp I have also seen higher spam rates and SNF capture rates in recent MDLP data on our system: http://www.sortmonster.com/MDLP/MDLP-Example-Short.html What counts in cases like these are false positive rates... If it seems that we're catching a lot more spam then lets be sure it really is spam. So far FP rates are nominal though there is a spike yesterday in the number (this appears to be an automated system that submits FPs from users -- the batch contains a larger than usual number of duplicate submissions -- this happens from time to time with this customer). http://www.sortmonster.com/MessageSniffer/Performance/FalseReportsRates.jsp Hope this helps, _M --- 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] Huge reduction in hold queue
On Thursday, March 31, 2005, 9:50:05 AM, Darin wrote: DC That is very significant, and could explain what I'm seeing. I'm going to DC increase my delete weight a bit for a while to make sure there are no high DC FPs. DC I do see the following detection rates from yesterday (3/30) DC AHBL 97.4% DC CBL 99.9% DC CSMA 97.1% DC CSMA-SBL 93.4% DC JAMMDNSBL 76.0% DC PSBL 96.9% DC SBL 99.5% DC SENDERDB-BL 96.4% DC SNIFFER 98.7% DC SPAMCOP 99.7% DC UCEPROTECT1 100% DC UCEPROTECT2 97.2% DC rates for all seem to have increased significantly over the past couple of DC days. WOW! That's weird. I do not show that at all and I've never seen those tests throw those kinds of numbers (except SNF looks about right): http://www.sortmonster.com/MDLP/MDLP-Example-Short.html For example (a quick spot check) - Data through last noon to midnight-- AHBL shows up at about 22% (21.8409) SPAMCOP shows up at about 64% (63.5114) UCEPROTECCMUL sows up at about 42% (41.6237) UCEPROTECRDO shows up at about 48% (48.0324) Long range data through last midnight-- AHBL shows up at about 16% (16.111) SPAMCOP shows up at about 62% (62.3942) UCEPROTECCMUL shows up at about 42% (41.7421) UCEPROTECRDO shows up at about 49% (48.6102) All in all these indicate nominal performance. Most likely there is something special about the mix of spam you are getting, something wrong with your reporting process, or something else going on that we haven't thought of. To be thorough I also checked some of the MDLP reports from other systems that are beta testing it. With few exceptions they show numbers similar to mine w/ regard to these tests. If I were you I would not make any substantive changes until I tracked down what was going on. No need to introduce additional variables by changing things ;-) DC BTW, I sent to the Junkmail in part so others could comment on DC other tests that may have significantly changed. It's all good :-) _M --- 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] Declude performance question
On Monday, March 21, 2005, 11:00:49 AM, Chase wrote: snip/ CS Looking at our test list (posted bellow), we likely have WAY too CS many dns blacklists. That will be the first thing I look at. Any CS other suggestions? I have had luck running a DNS server (resolver - bind) locally on the IMail box using the loopback address for the primary DNS (127.0.0.1) to speed things up. YMMV Also, take a look at this data to see which tests are performing best and perhaps weed out some of the others: http://www.sortmonster.com/MDLP/MDLP-Example-Long.html Hope this helps, _M --- 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] Declude performance question
On Monday, March 21, 2005, 11:00:49 AM, Chase wrote: CS I need some help tuning Declude for performance. Up until One other thought (pushed send too fast). You may have a test or two in there that is not responding --- causing things to time out and slow things down. If you can find it and drop it things should speed up quite a bit. _M --- 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] Declude performance question
On Monday, March 21, 2005, 11:29:09 AM, Chase wrote: CS I don' have UCEPROTECRDO, XBL-DYNA, BLKLST-SURBL CS and HELOISIP. Can you post your definitions for those? Can I get CS them off the declude website somehow (I couldn't find them)? UCEPROTECRDOip4rdnsbl-1.uceprotect.net 127.0.0.2 30 0 UCEPROTECCMUL ip4rdnsbl-2.uceprotect.net 127.0.0.2 32 0 UCEPROTECCVIR ip4rdnsbl-3.uceprotect.net 127.0.0.2 30 0 I didn't find the others. _M --- 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[6]: [Declude.JunkMail] Automated requeuing
On Tuesday, March 15, 2005, 3:33:36 PM, Darin wrote: DC I'll gladly try it and pass whatever data back for study. Thanks. I will contact you later off list. Best, _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] Hard time with Drugs SPAM
On Monday, March 14, 2005, 4:40:26 PM, Darin wrote: DC Yep...It does seem to be getting worse. Sniffer is catching a lot, but a DC lot is still slipping through, due mostly to constantly changing domain DC names of various ages. DC We're just supplementing Sniffer and blacklists with internal body filters DC and SURBL lists, so after the first report of one slipping through they're DC being blocked, but since they're sending in waves I imagine most of a new DC wave goes through before we're filtering. DC Body filters and SURBL lists are helping, but it is very slow and DC reactionary on a daily basis. Be sure to keep forwarding variants to spam@ we are slowly but surely surrounding the patterns. (Back to work with me) _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] Automated requeuing
On Monday, March 14, 2005, 5:59:15 PM, Markus wrote: MG 2.) Log file processing with MDLP (Modular Declude Logfile MG Processor) written by Pete McNeil This tool does extremely fast MG parsing of declude jm logfiles. Pete's primary intention was to MG write a tool that's able to analyze results of each declude test MG and based on the determined reliability adapt automatically the MG weighting system. Due to a lot of other work I haan't had time to MG test this part of the tool. I concentrated on the other part of MG MDLP. It can write CSV-files containing all processed messages, MG mailfrom, mailto, datetime, subject and the total weight of the MG weighting system. Then I've setup up some MS-SQL DTS packages that MG are able to import this csv-sources in a very fast way into a MG MS-SQL database. MDLP allows to process only e certain timerange MG of a daily logfile, so we import the processed message results on MG a hourly base. Just following on to the thread here... I'm putting together a page for MDLP showing test results from our system and, eventually (under construction), documentation etc. http://www.sortmonster.com/MDLP/ _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] Log Corruption
On Tuesday, March 1, 2005, 5:38:54 PM, Darrell wrote: Dsic I though Pete had some locking mechanism built in to prevent overlapping. Dsic Pete? Yes. This is it. (quite a lot of locking actually) This is a pet peeve of mine so I'm going to go just slightly off topic - it might help someone else out there writing code like this... There are a number of things in Win32 land that are not atomic like they should be. (Atomic meaning - they complete all at once before anything else can happen.) One of these that caused a lot of extra work in SNF peer-server code is rename(). The other is appended writes to a file. As a result, it is possible for more than one thread to believe it has renamed a single file successfully - which is supposed to be impossible. Thread A tries to rename file JOB.QUE to JOB.AAA and succeeds. Thread B tries to rename file JOB.QUE to JOB.BBB and succeeds!!! The actual file name at the end - flip a coin and pick one - JOB.BBB or JOB.AAA. Appended writes work the same way. Thread A opens a file for Append and writes Thread A stuff and only thread A stuff so there!\n Thread B opens the same file for Append and writes: Thread B, thread B, what a silly thread I B!\n Both writes succeed happily. Unfortunate sleep deprived programmer sure that he is going stark raving mad opens up the file and sees: Thread A stufead B, what a silly th\n I B! there... where ... is following on to some other unrelated log entry... (sigh) Luckily, it seems that creating a file is atomic, so there is a way out. This is what I use for some simple inter-process locking (that, by the way, is cross-platform [posix] compatible): open(LockName.c_str(),O_WRONLY|O_CREAT|O_EXCL); --- The actual code I use for locking is bigger than this of course. I'm attaching an excerpt from logger.cpp that takes care of it. Hope this helps, _M win32lock.cpp Description: Binary data
Re[2]: [Declude.JunkMail] Log Corruption
On Tuesday, March 1, 2005, 5:48:17 PM, Andrew wrote: CA (Pete isn't here much) :-( I do usually lurk though... I'll try to post more often... ;-) _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] Log Corruption
On Tuesday, March 1, 2005, 7:14:31 PM, Darin wrote: DC I disagree with the struggling server logic. We saw the log corruption in a DC test environment a year ago that had minimal traffic, say a couple thousand DC messages a day. It was a dual 1.4GHz processor with 1 GB RAM and 10k RPM DC SCSI drives. Load was only about 1-5% during testing. Heavier loads will cause more processes to collide and so log corruption is likely to be more pronounced in those situations. _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] casino spam
On Friday, February 25, 2005, 5:50:45 PM, Glenn wrote: GW I've seen several kinds of spam increase in the last day. We're seeing a new porn campaign, a new kiddie porn campaign, a ramp-up of the current M$ software rip-off (media-theft) spam. We've seen a bit of a pick-up in the casino stuff too - particularly a campaign that encourages you to make a boatload of money running your own online casino etc... Almost enough to call it a spam storm but not quite... http://www.sortmonster.com/MessageSniffer/Performance/ChangeRates.jsp _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] casino spam
On Friday, February 25, 2005, 6:11:58 PM, David wrote: DB Which can under certain circumstances be correct. If you had DB signed up with the website then declude is correct in identifying DB them as legitimate email. It is possible we could set up some DB additional filters to help with a specific type of Spam. Most of the time what is happening is that the IPs for these (and often even the URI) have not been picked up by other services yet so the total weight doesn't get pushed over the threshold. We see these events as apparent false positives in our MDLP analysis (the red mark at the end of the SNIFFER test is mostly new spam that only SNF is seeing, not actually FPs) http://www.sortmonster.com/MDLP/MDLP-Example-Long.html An interesting test that might help is to keep track of connect (source) IPs that are new - or relatively new. This same mechanism is part of the requested Delay New IPs feature... but even before then, our research suggests that a test that provides a weight based on how new an IP source is could be quite helpful... So, for example: Days --- Weight 0 --- 64 1 --- 32 2 --- 16 4 --- 8 5 --- 4 6 --- 2 7 --- 1 8+--- 0 Based on a spam threshold of 100. On many systems a Day Zero IP along with SNF would be enough to filter the message out. After a couple of days other BLs are likely to take over. Just a thought ;-) _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] Anyone with an updated Global.cfg?
Just adding to the end of the thread here... The demo of SNF is meant more to help you get things working on your system than to prove it can capture spam. The demo rulebase is behind the registered version quite a bit -- Folks have already told you that though :-) For a look at BLs to try and weights you might take a peek at a pet project we're running. MDLP (Modular Declud Log Processing) is a utility we currently have in beta that measures test accuracy. It also includes an AI component to automatically adjust the weights of the tests on a Declude system for best performance (with a little human help occasionally). You can see the HTML output of MDLP at the following link: http://www.sortmonster.com/MDLP/ The page is under construction (really just a placeholder right now). Report 1 is based on a small amount of data. Report 2 is based on a larger amount of data. This runs and auto-tunes the tests on our NT/Declude test bed which processes mostly spam, but a few user accounts also to keep things honest. You might use these reports to help evaluate some of the tests that are out there and perhaps to suggest where the weights should be. Best, _M (below retained for context) On Tuesday, February 22, 2005, 7:13:23 PM, Darrell wrote: Dsic Ben, Dsic FYI - The full (licensed) version of Sniffer is incredible. It grabs 95%+ Dsic of spam we get right off the bat. I highly recommend Sniffer. The trial Dsic version's rule base lags the rule base you get when you are a licensed Dsic customers. snip/ Hi, I've noticed in the last couple of weeks a huge upsurge in junk mail Dsic getting through our system with lower weights (i.e., ending up in the InBox Dsic instead of the spam folder or being deleted). We don't do a lot of tweaking with our configuration files, so we normally expect a certain small percentage snip/ --- [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[4]: [Declude.JunkMail] Anyone with an updated Global.cfg?
On Wednesday, February 23, 2005, 3:06:03 PM, Scott wrote: SF -Mad, SF Will there be an MDLP page explaining some of the columns? SF SQ= Spam Test Quality? SF SI = Spam Test Result Important Count? SF avgSD = Average Spam Test Dominance? Yes. Once I get a few minutes to rub together I'll make fire and get that MDLP page populated :-) In the mean time here is this little bit... SQ = SA^2 ... This expands the accuracy fraction and eliminates the sign. SQ is how the tests compete for high weights in the AI. Think of it as the square of the distance to the goal... that goal being a perfect score. SI = Spam test importance count. Each time a message is scanned it is an event. With each event some number of tests will fire. The tests that fire together during a scan event each contribute a to the total weight. Any single test which has a weight high enough to swing the total weight across the spam/ham threshold is important. In a highly accurate system we would like to see many tests appear important during a scan event because this ensures that the tests involved are not swamping the result. For example, suppose we scan a message and we get 5 tests answering: TEST1 = 50 TEST2 = 35 TEST3 = 10 TEST4 = 64 TEST5 = 26 TOTAL = 185 None of the tests are important because no single test is enough of the total weight for the weight to cross the threshold. Take away TEST4, for example, and the total only falls to 121 which is still above 100. This might be perfectly fine... that is, the message may simply be so spammy that we would be happy if only half of the tests agreed about it... But, that way of thinking isn't very sensitive to error, and since the system must evaluate the test accuracy based on the aggregate results of many tests it is very important that the system be as sensitive as possible. This way it's not likely to fool itself into believing a handful of tests and then evaluating all others against them. (We don't want any emperors sporting new outfits ;-) Now suppose we use lesser weights on the bigger tests --- TEST1 = 35 TEST2 = 30 TEST3 = 10 TEST4 = 44 TEST5 = 23 TOTAL = 142 Now we can see that by scaling back the weights a bit we raise the sensitivity for TEST4. If you take away TEST4 in this case then the total drops to 98 which is below the threshold - so in this even TEST4 was important. SI is a count of the number of events in the data set where the test in question was important. This leads us to avgSD. Once we start down the road of looking for this sensitivity we find we want more of it. Consider the following: TEST1 = 30 TEST2 = 25 TEST3 = 8 TEST4 = 40 TEST5 = 20 TOTAL = 123 Now we can see that there are 3 important tests. TEST1, TEST2, and TEST4 are all big enough to tip the scale. As a result, if any of these tests don't agree then the message would be passed as non-spam (in this event anyway). Tests dominance is a measure of how many other important tests are present when a given test is important. In the case with a total of 142, TEST4 was completely dominant so it's test dominance number for that event would be 1.0. Put in other words, the only thing that mattered in this case was TEST4. The other tests were present, but they would have had to gang up in order for them to effectively disagree with TEST4. This can be a dangerous thing since it means that TEST4 can buy itself a high accuracy score very easily. In the event with the total weight 123, TEST1, TEST2, and TEST4 would all receive a test dominance score of .333 --- that is to say, the test is one of three (1/3) of the important tests during that event. This is much better. Every one of these tests now has to work hard in order to get a high accuracy score - and that's what we want. avgSD is the average of the test dominance numbers that are given to a particular test. The AI is sensitive to this number so that the instinct of a test with a very high avgSD is to reduce it's weight so that it plays well with the other tests. There are many other instincts given to the AI creatures that live on (represent) these tests also --- but this is how these particular numbers get their meaning. One way you can think of it is that these numbers (and many of the others you see on the page) are how the creatures feel/see their world. 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[2]: [Declude.JunkMail] Spam tests by months
On Wednesday, February 9, 2005, 5:55:48 AM, Markus wrote: MG Hi Scott, MG MG great stat's ! MG MG A question about SNIFFER MG It seems you have a much longer list of different SNIFFER return codes then I MG Is there somewhere a complete list? MG MG Markus Is this what you are looking for? http://www.sortmonster.com/MessageSniffer/Help/ResultCodesHelp.html _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] domain name a name
On Friday, February 11, 2005, 8:51:46 AM, Darin wrote: DC Most of what slips through our filters is exactly this. Unfortunately I DC know of no way to block this short of reacting to the first one seen and DC adding a body filter for the URL...the same thing Message Sniffer or any DC SURBL list would do. DC I'm add maybe 1-4 of these per day. DC Sometimes there's enough other text for additional body filters, which can DC cut down on the number of edits. This is an area we concentrate on... usually these kinds of campaigns have some kind of script running behind them. If we can reverse engineer the scripting (by reviewing many copies) then we can create a compound rule that matches enough static components to avoid legit messages and block all (or most) of the variants of the spam campaign. _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[4]: [Declude.JunkMail] domain name a name
On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC Hi Pete, DC Right... but the first few typically slip through before they're added to DC your filters (like they would for anyone)...so we add them on the first DC report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker activates shields at full power. --- [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] inserting Sniffer log info into header
On Monday, February 7, 2005, 7:14:03 PM, Andy wrote: AS Interesting sounds like someone would have to write an AS External Filter. Unless Declude is willing to integrate this AS in their Sniffer support. AS AS When you turn this one - where do this XHDR files appear? AS In the regular spool folder together with the queue and data AS file? If so, one could probably write a command script to insert AS the content of the XHDR file into the message file and then AS delete the XHDR? This kind of thing could be done... The .xhdr file should show up right where the message file is. However, since Declude is already adding headers ( most likely ) it would be more efficient if Declude could do the job. Otherwise, the whole message would have to be copied at least once for the .xhdr addition, and then again for any headers or other modifications done by Declude. If Declude does the editing, then all of the headers and mods can be handled at one time. I haven't talked with Declude very much about adding a feature like this, but it would be a good trick if they added it. If done right then other external tests would be able to talk back to the message in the same way... that's more complexity though. _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] OT - Outsourcing email
On Friday, February 4, 2005, 7:06:04 PM, Matt wrote: M John Tolmachoff (Lists) wrote: Yeah, but a little birdie told me that the president can get a little hot some times. M Where's that birdie located? I'll shoot it if it has been saying bad M things about me :) You have to keep the birdies in their favorite bird seed - that's the trick. _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] OT - Outsourcing email
There are a bunch in this list I think... http://www.sortmonster.com/MessageSniffer/Referrals.html _M On Friday, February 4, 2005, 6:27:07 PM, Danny wrote: D Looking for a email provider that includes email services, D spam, virus detection, all in one package that has an excellent up D time, and excellent data recovery network and excellent tech D support. I need to know the cost per mailbox but with which allows D multiple domains. D John Tolmachoff (Lists) wrote: D Well, being that some of us on this list provide e-mail services to clients, D what exactly do you mean? D John Tolmachoff D Engineer/Consultant/Owner D eServices For You D -Original Message- D From: [EMAIL PROTECTED] D [mailto:[EMAIL PROTECTED] On Behalf Of Danny D Sent: Friday, February 04, 2005 2:42 PM D To: [EMAIL PROTECTED]: [Declude.JunkMail] OT - Outsourcing email D Can anyone recommend any email outsourcing companies other then D everyone.net? D TIA D --- D [This E-mail was scanned for viruses by Declude Virus D (http://www.declude.com)] D --- D This E-mail came from the Declude.JunkMail mailing list. To D unsubscribe, just send an E-mail to [EMAIL PROTECTED], and D type unsubscribe Declude.JunkMail. The archives can be found D at http://www.mail-archive.com. D --- D [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] D --- D This E-mail came from the Declude.JunkMail mailing list. To D unsubscribe, just send an E-mail to [EMAIL PROTECTED], and D type unsubscribe Declude.JunkMail. The archives can be found D at http://www.mail-archive.com. D --- [This E-mail was scanned for viruses by Declude Virus D (http://www.declude.com)] --- This E-mail came from the D Declude.JunkMail mailing list. To unsubscribe, just send an E-mail D to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. D 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] DNSSTUFF.COM Web Site Down?
On Friday, January 28, 2005, 7:32:39 AM, Kim wrote: KP It's 4:30A PST, and I cannot access the 'dnsstuff.com' web KP site. Is anyone else having the same problem? Works fine from here. _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.
[Declude.JunkMail] ping
Hello declude, ping Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.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] High smtp traffic
On Monday, January 10, 2005, 12:10:32 PM, Markus wrote: MG Anyone else can see an abnormal high smtp traffic this minutes? MG I haven't identified completely but something strnage is going one here. Lot MG of NDR's We have been seeing what I would classify as a severe spam storm today starting at about 0100 EST. 553 new rules so far today (and it is early). This might be related. _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] FW: [sniffer] Sniffer Notifications now failing declude spamheaders test
On Monday, January 3, 2005, 11:30:22 AM, Marc wrote: MC I don't mean to be a nag but this was just posted to the MC sniffer forum and is exactly what I was talking about. It is MC almost 48 hours after the first post discussing this bug and MC there is still no e-mail from Declude that I am aware of that has MC gone out. I saw a note from Barry... maybe you don't have it yet? _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] URI Blacklist External Program Beta Now Posted For Download
Since URI are a subset of the SNF rulebase it's not unlikely that there would be quite a bit of overlap. The key differences would be that SNF does not use any network resources to look up the URI and SNF does not waste any time examining URI that are not known to be seen in spam -- One of the countermeasures spammers use against SURBL is to include a large number of URI that point to legitimate sources. SURBL type mechanisms have no way of knowing which URI are legitimate and which ones may be payload so they waste a good deal of effort looking up URI that don't matter (often with ratios of 10:1 or more). SNF already knows what it is looking for and it ignores the rest. The use of URI data for tagging spam is always very effective. We've used it since the beginning :-) _M On Tuesday, December 28, 2004, 10:14:47 AM, Markus wrote: MG based on 10, 100 or 1000 messages? MG MG Markus MG From: [EMAIL PROTECTED] MG [mailto:[EMAIL PROTECTED] On Behalf Of Frederick MG Samarelli MG Sent: Tuesday, December 28, 2004 4:03 PM MG To: Declude.JunkMail@declude.com MG Subject: Re: [Declude.JunkMail] URIBlacklist External MG Program Beta Now Posted For Download MG It looks like it may be a redundant test tosniffer. MG MG Everything INV-URIBL catches so doesSNIFFER. MG MG Fred MG - Original Message - MG From: Darrell ([EMAIL PROTECTED]) MG To:Declude.JunkMail@declude.com MG Sent: Monday, December 27, 2004 10:32 PM MG Subject: [Declude.JunkMail] URI Blacklist External MG Program Beta Now Posted For Download MG We have released a public beta of our URI lookup tool at MG http://www.invariantsystems.com/invuribl/default.htm. In MG addition, we have posted some stats on how effective the tool is MG on our system at MG http://www.invariantsystems.com/invuribl/stats.htm. MG MG For a more detailed description on the tool please see MG the below message or send me a note with any questions. MG Darrell MG - Original Message - MG From: Darrell([EMAIL PROTECTED]) MG To:Declude.JunkMail@declude.com MG Sent: Wednesday, December 22, 200411:13 PM MG Subject: URI Blacklist ExternalProgram MG We have wrote an external application thatextracts MG URI's from a message and checks them against a URI MG Blacklist. For those not familar withURI blacklists here MG is how the folks at surbl.org describe it. MG MG Surbl blacklists differ from most other RBLs in that MG they're used to detect spam based on message body URIs (usually MG websites). Unlike most other RBLs, SURBLs are not used to MG block spam senders. Instead they allow you to block messages that MG havespam domains which occur in message bodies. MG MG We have been running this application inproduction MG for the last week against multi.surbl.org. We havealso MG tested the application against several of the other SURBL lists MG withthe same level of sucess. MG MG If you are interested in testing or runningthe MG software please join the following list MG [EMAIL PROTECTED]During the MG beta period this is where we will be communicating about the MG application. For some of the applications basic features and MG implementation requirements please see MG http://www.invariantsystems.com/invuribl/default.htm. We MG expect to release a beta version within the next couple MG days. MG MG If you would like any additional informationprior to MG joining the list please let me know, MG Darrell MG MG --- MG Check out http://www.invariantsystems.com for utilities for MG Declude And Imail. IMail/Declude Overflow Queue MG Monitoring, MRTG Integration, and LogParsers. --- [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[4]: [Declude.JunkMail] SURBL vs. Sniffer?
On Tuesday, December 28, 2004, 11:06:59 AM, Andy wrote: AS Hi Pete, AS Is Sniffer performing URI checks as part of certain return codes only - AS e.g., if I were to use SURBL to augment Sniffer, are there certain Sniffer AS Return Codes that are likely to overlap with SURBL lookups - or have all AS Sniffer return codes the potential of having been triggered by URI checks? Experiemental Received IP (Result=63), Obfuscation Techniques (Result=62), and Experimental Abstract (Result=61) are not likely to include any URI data - Experimental Abstract may include generalized versions of URI. All of the other result codes are likely to overlap with URI data. _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[4]: [Declude.JunkMail] SURBL vs. Sniffer?
On Tuesday, December 28, 2004, 11:06:59 AM, Andy wrote: AS Hi Pete, AS Is Sniffer performing URI checks as part of certain return codes only - Sorry to respond twice but I want to clear up some potential confusion - SNF includes URI as part of it's pattern matrix. It does not do any specific URI checking. Rather, it simply recognizes known URI as patterns of data in the message - there is no special mechanism for it. We code URI regularly as part of our rule generation process so URI are commonly included in the pattern matrix. When scanning a message, the entire pattern matrix is matched against the message at one time so all recognized patterns are evaluated at once no matter what kind of pattern they may be. _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] tools/weights
On Thursday, December 23, 2004, 7:36:15 PM, Bennie wrote: B OK... I have downloaded the trail of sniffer and installed per the B instructions... added the lines to my Declude.cfg and $default$.junkmail. B Now I am getting no warnings in the headers... how can I look to see if the B test is running... Check for a sniffer log file. _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.
