[sniffer] why?
Pete, Our subscribers can forward spam they receive to our [EMAIL PROTECTED] address, which gets forwarded to you guys. Some spammers have been sending e-mail messages directly to the [EMAIL PROTECTED] address (cutting out the middle men I guess). One spammer, www. c a s i n o b a r .com, has sent 5 messages directly to the [EMAIL PROTECTED] address this month (one message every 3 - 4 days) and yet their messages still don't get caught by sniffer. Why? Greg This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] why?
On Tuesday, December 21, 2004, 6:20:40 AM, System wrote: SA Pete, SA Our subscribers can forward spam they receive to our [EMAIL PROTECTED] SA address, which gets forwarded to you guys. Some spammers have been sending SA e-mail messages directly to the [EMAIL PROTECTED] address (cutting out the SA middle men I guess). One spammer, www. c a s i n o b a r .com, has sent 5 SA messages directly to the [EMAIL PROTECTED] address this month (one message SA every 3 - 4 days) and yet their messages still don't get caught by sniffer. SA Why? The first why is - they're not paying attention and this was probably due to some dictionary attack that picked up the address. The second why is - I don't know, yet. I would need to see the message to figure that out. Please zip up a raw copy of the message and send it to support@ so that I can research it. Most likely we've just not seen the message here for some reason. For example, we may have filtered it with some rule that you are not getting or are not using. In that case, it would get blocked here but not on your system. The second possibility is that we've skipped the message for some safety reason (trying to avoid false positives) though it seems unlikely in this case. Once I see it I will be able to tell more. Thanks, _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] why?
on 12/21/04 8:21 AM, Pete McNeil wrote: The second possibility is that we've skipped the message for some safety reason (trying to avoid false positives) though it seems unlikely in this case. Once I see it I will be able to tell more. Would adding direct to spam in the subject make these types of messages any more meaningful/important to you guys? Greg This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
[sniffer] Change in coding policies
Hello Sniffer Folks, Backscatter from rejected virii and joe-jobs has become a very significant problem. Up to now we have tried as much as possible to avoid coding for NDRs and other such backscatter - though some pattern matches have been unavoidable. Generally it is a very bad idea these days for a server to send a response of any kind when a virus is captured since most virii forge the sender information. Similarly, bounces from joe-jobs and dictionary attacks are also a problem. These kinds of messages tend to be more of a problem than a solution and the volume has now reached extreme levels (IMO). From now on, we are going to start coding rules to capture these kinds of messages. The rules that we do code for these messages will go into the malware group. For example, we will be introducing rules that watch for bounces that contain large numbers of failed addresses - indicating a probable dictionary attack / joe-job; and we will be coding rules for most virus bounces when they reach our spamtraps or are submitted to us as spam - since clearly the return address on the bounce indicates that the sender information must have been forged (bounce going to a spamtrap). If there is some need on your system to receive these messages then the best strategy will be to create local white rules to let these through. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Change in coding policies
It sounds good to me, Pete. May I humbly suggest that this be a new result code, e.g. 046? Until now, Message Sniffer has been very parsimonious with the new categories, but this looks like one that will be here for a long time. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Tuesday, December 21, 2004 6:38 AM To: [EMAIL PROTECTED] Subject: [sniffer] Change in coding policies Hello Sniffer Folks, Backscatter from rejected virii and joe-jobs has become a very significant problem. Up to now we have tried as much as possible to avoid coding for NDRs and other such backscatter - though some pattern matches have been unavoidable. Generally it is a very bad idea these days for a server to send a response of any kind when a virus is captured since most virii forge the sender information. Similarly, bounces from joe-jobs and dictionary attacks are also a problem. These kinds of messages tend to be more of a problem than a solution and the volume has now reached extreme levels (IMO). From now on, we are going to start coding rules to capture these kinds of messages. The rules that we do code for these messages will go into the malware group. For example, we will be introducing rules that watch for bounces that contain large numbers of failed addresses - indicating a probable dictionary attack / joe-job; and we will be coding rules for most virus bounces when they reach our spamtraps or are submitted to us as spam - since clearly the return address on the bounce indicates that the sender information must have been forged (bounce going to a spamtrap). If there is some need on your system to receive these messages then the best strategy will be to create local white rules to let these through. Thanks, _M Pete McNeil (Madscientist) President, MicroNeil Research Corporation Chief SortMonster (www.sortmonster.com) This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Change in coding policies
On Tuesday, December 21, 2004, 12:51:19 PM, Andrew wrote: CA It sounds good to me, Pete. CA May I humbly suggest that this be a new result code, e.g. 046? Until CA now, Message Sniffer has been very parsimonious with the new categories, CA but this looks like one that will be here for a long time. I thought about making a new rule group for this, but talked myself out of it: 1. I don't want to give this group priority over other rules (lower symbol values get priority within a given scan). 2. Many bounces like this are already being captured by existing rules - especially those that include parts or (ghasp) all of the bounced message. 3. Many of the rules we will be coding will be dual-use... That is, when we get a bounce message that shows us the subject of the original, and the name of the file that was rejected (or some similar group of features) we will be coding a malware rule to block both the original content and the bounces --- rather than trying to code a good malware rule that avoids tagging bounces which is sometimes hard or impossible to do. -- After thinking about all of these it seems simpler and more consistent to code these rules inside the existing malware group. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Change in coding policies
Given that the precision is difficult to assign under the single result framework, I don't doubt the choice. Might I suggest creating a sub-group for the three main types of backscatter so that individuals can turn them off as a group instead of one rule at a time. Note that the three groups that I have defined personally are as follows: - Joe-Job NDR's. - Challenge/Response Idiots - AntiVirus Notifications Matt Pete McNeil wrote: On Tuesday, December 21, 2004, 12:51:19 PM, Andrew wrote: CA It sounds good to me, Pete. CA May I humbly suggest that this be a new result code, e.g. 046? Until CA now, Message Sniffer has been very parsimonious with the new categories, CA but this looks like one that will be here for a long time. I thought about making a new rule group for this, but talked myself out of it: 1. I don't want to give this group priority over other rules (lower symbol values get priority within a given scan). 2. Many bounces like this are already being captured by existing rules - especially those that include parts or (ghasp) all of the bounced message. 3. Many of the rules we will be coding will be dual-use... That is, when we get a bounce message that shows us the subject of the original, and the name of the file that was rejected (or some similar group of features) we will be coding a malware rule to block both the original content and the bounces --- rather than trying to code a good malware rule that avoids tagging bounces which is sometimes hard or impossible to do. -- After thinking about all of these it seems simpler and more consistent to code these rules inside the existing malware group. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re[2]: [sniffer] Change in coding policies
On Tuesday, December 21, 2004, 1:13:15 PM, Matt wrote: M Given that the precision is difficult to assign under the single result M framework, I don't doubt the choice. Might I suggest creating a M sub-group for the three main types of backscatter so that individuals M can turn them off as a group instead of one rule at a time. Note that M the three groups that I have defined personally are as follows: M - Joe-Job NDR's. M - Challenge/Response Idiots M - AntiVirus Notifications I'm thinking in this direction - but I'm not sure yet what our coding rules will allow since there tends to be a lot of overlap. I don't think we'll be creating C/R related rules, at least not yet. That's a category where zealots are everywhere and we have learned to avoid filtering anything that even looks like part of a C/R system unless specifically asked to do so. If we get a lot of call for it then I _might_ create a project to code those rules as an optional add-in on request. For now we're going to stick to the safe stuff that can be applied broadly. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
Re: [sniffer] Change in coding policies
FYI, I'm still debating myself about what to do with this stuff. I'm hoping that it will go away, albeit slowly, and I presently rarely take action to correct any issues with this E-mail, though I do reprocess some individual messages. Seems that many of the C/R providers have gotten better at filtering spam prior to the challenge, and that also helps...but they're still idiots :) If I implement something, I will probably make it an optional filter for my domains. I already isolate the bounce stuff that is held in it's own folder for each client. The NDR issue has grown much bigger recently because of one single spammer that will use the same real address for about a week at a time (sporadically), and I have been contacted by clients about 3 or 4 times in the past two months about high volumes of bounces to single accounts. We do catch most of it already, but not most of the stuff as generic as what IMail would send (no content), and there is unfortunately no good way to tell the good from the bad. Right now I can only offer to block all NDR's, but I suggest that they just wait a week and the issue will clear up, and thankfully it always has so far. Matt Pete McNeil wrote: On Tuesday, December 21, 2004, 1:13:15 PM, Matt wrote: M Given that the precision is difficult to assign under the single result M framework, I don't doubt the choice. Might I suggest creating a M sub-group for the three main types of backscatter so that individuals M can turn them off as a group instead of one rule at a time. Note that M the three groups that I have defined personally are as follows: M - Joe-Job NDR's. M - Challenge/Response Idiots M - AntiVirus Notifications I'm thinking in this direction - but I'm not sure yet what our coding rules will allow since there tends to be a lot of overlap. I don't think we'll be creating C/R related rules, at least not yet. That's a category where zealots are everywhere and we have learned to avoid filtering anything that even looks like part of a C/R system unless specifically asked to do so. If we get a lot of call for it then I _might_ create a project to code those rules as an optional add-in on request. For now we're going to stick to the safe stuff that can be applied broadly. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
