Re: [sniffer] Change in coding policies
OK, being a new (and very happy) customer ... 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 ... What is a joe-job? Spam from Billy Bob? Send coffee... Chris 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
Title: Message -Original Message-From: Chris Ulrich [mailto:[EMAIL PROTECTED]] OK, being a new (and very happy) customer ... 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 ... What is a joe-job? Spam from Billy Bob?http://catb.org/~esr/jargon/html/J/joe-job.html Send coffee... ---This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
[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
