RE: Re[2]: [sniffer] YAhoo mails failing sniffer?
When we report these to false what kind of time frame should we get notifications back from AFF? I sent one of these from yahoo yesterday morning and haven't received anything. I can read it on the list before I receive anything from AFF. Thanks, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, September 22, 2005 3:10 AM To: Matt Subject: Re[2]: [sniffer] YAhoo mails failing sniffer? That is the one. That rule is already gone. Again, I apologize. It is all fixed now. Thanks, _M On Thursday, September 22, 2005, 12:29:27 AM, Matt wrote: M> Quick follow-up. The bad rule appears to be 497585. M> Matt M> Marc Catuogno wrote: >>I'm seeing a few legit e-mails from Yahoo failing sniffer. Anyone else? >> >>--- >>[This E-mail scanned for viruses by Declude Virus] >> >> >>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 >> >> >> >> M> This E-Mail came from the Message Sniffer mailing list. For M> information and (un)subscription instructions go to M> 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 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] YAhoo mails failing sniffer?
That is the one. That rule is already gone. Again, I apologize. It is all fixed now. Thanks, _M On Thursday, September 22, 2005, 12:29:27 AM, Matt wrote: M> Quick follow-up. The bad rule appears to be 497585. M> Matt M> Marc Catuogno wrote: >>I'm seeing a few legit e-mails from Yahoo failing sniffer. Anyone else? >> >>--- >>[This E-mail scanned for viruses by Declude Virus] >> >> >>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 >> >> >> >> M> This E-Mail came from the Message Sniffer mailing list. For M> information and (un)subscription instructions go to M> 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] YAhoo mails failing sniffer?
We are training some new folks... We had an issue where part of a tag line used by yahoo was captured from an AFF spam. We discovered in within a very short time and pulled the rule (we do very close review when training). During that short time, unavoidably, some rulebases would have been compiled. If you're describing the same issue then it's definitely fixed. Apologies for this slipping through at all. Thanks, _M On Thursday, September 22, 2005, 12:23:33 AM, William wrote: WVH> I got a record number of false-positives from Sniffer yesterday. The WVH> category was always "Scam Patterns". Two of them were from Yahoo! as well. WVH> Although the total was low (something like four FP's total), that is more in WVH> one day than I usually see in a month with Sniffer. There must have been WVH> some incredibly-badly written code that slipped though, as they were WVH> personal e-mails that should never have been tagged. Personal e-mails are WVH> really the only ones that I truly consider false positives. I get dozens of WVH> mailing list messages trapped each month, but I don't consider those a big WVH> deal. Customers rarely miss these. I very, very rarely see any truly WVH> personal e-mails get trapped by Sniffer though. Hopefully, they have already WVH> fixed the problem. I haven't seen any as of this afternoon. WVH> William Van Hefner WVH> Network Administrator WVH> Vantek Communications, Inc. WVH> 555 H Street, Ste. C WVH> Eureka, CA 95501 WVH> 707.476.0833 ph WVH> 800-331.4638 fx >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Marc Catuogno >> Sent: Wednesday, September 21, 2005 9:09 PM >> To: sniffer@SortMonster.com >> Subject: [sniffer] YAhoo mails failing sniffer? >> >> >> I'm seeing a few legit e-mails from Yahoo failing sniffer. >> Anyone else? >> >> --- >> [This E-mail scanned for viruses by Declude Virus] >> >> >> 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 >> WVH> This E-Mail came from the Message Sniffer mailing list. For WVH> information and (un)subscription instructions go to WVH> 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] Damn viagra spam
We've been head-to-head with these guys for a while now. For example, they have pioneered a new form of obfuscation that we have been developing abstract rules for since their first campaign a few weeks ago. The obfuscation technique is column obfuscation which involves using CSS float left styles and fixed width fonts along with line breaks to accomplish the same effect that rowspan table obfuscation allows. Today (really the last couple of days) they have been prolific with new variants countering our rules within a few hours of our responses and so on. They are also using a high-intensity burst mode for delivery so any time they can get through a filter you are likely to see a bunch of them. At the moment we seem to have them covered, though I expect at least a few more rounds with them over the next couple of days. Sorry for the leakage -- we are on it. The samples do help - Thanks! _M On Wednesday, September 14, 2005, 3:39:52 PM, Darin wrote: DC> We just reported one to Sniffer support for analysis as well. DC> Darin. DC> - Original Message - DC> From: "Heimir Eidskrem" <[EMAIL PROTECTED]> DC> To: DC> Sent: Wednesday, September 14, 2005 3:34 PM DC> Subject: [sniffer] Damn viagra spam DC> We are getting tons of spam for viagra and other drugs. DC> Not being stopped by sniffer. >>From - Wed Sep 14 14:23:59 2005 DC> X-Account-Key: account2 DC> X-UIDL: 397213080 DC> X-Mozilla-Status: 0011 DC> X-Mozilla-Status2: DC> Received: from chartcourse.com [200.152.123.222] by deepspace.i360.net DC> (SMTPD-8.20) id A7660304; Wed, 14 Sep 2005 14:17:58 -0500 DC> Received: from [192.168.232.240] (helo=elevator) DC> by chartcourse.com with smtp (Paradisaic kw 5.29 (Jactation)) DC> id lBCMAK-xJNrNU-Ty DC> for [EMAIL PROTECTED]; Wed, 14 Sep 2005 14:17:22 -0500 DC> Message-ID: <[EMAIL PROTECTED]> DC> Reply-To: "Shayna Riffe" <[EMAIL PROTECTED]> DC> From: "Shayna Riffe" <[EMAIL PROTECTED]> DC> To: "Ealdgyth Rancourt" <[EMAIL PROTECTED]> DC> Subject: Re: Really Works Very Good Pharmaceu tical DC> Date: Wed, 14 Sep 2005 14:17:20 -0500 DC> MIME-Version: 1.0 DC> Content-Type: multipart/alternative; DC> boundary="=_NextPart_000_0047_01C5B937.04839800" DC> X-Priority: 3 DC> X-MSMail-Priority: Normal DC> X-Mailer: Microsoft Outlook Express 6.00.2800.1106 DC> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 DC> X-RBL-Warning: CBL: "Blocked - see DC> http://cbl.abuseat.org/lookup.cgi?ip=200.152.123.222"; DC> X-RBL-Warning: IPNOTINMX: DC> X-RBL-Warning: COUNTRYFILTER: Message failed COUNTRYFILTER test (line 29, DC> weight 20) DC> X-Declude-Sender: [EMAIL PROTECTED] [200.152.123.222] DC> X-Declude-Spoolname: D776501961CDF.SMD DC> X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for DC> spam. DC> X-Spam-Tests-Failed: CBL, IPNOTINMX, COUNTRYFILTER, CATCHALLMAILS [50] DC> X-Country-Chain: BRAZIL->destination DC> X-Note: This E-mail was sent from recreio.speednetrj.com DC> ([200.152.123.222]). DC> X-IMAIL-SPAM-STATISTICS: (776501961cdf, 0.9721) DC> X-RCPT-TO: <[EMAIL PROTECTED]> DC> Status: U DC> X-UIDL: 397213080 DC> X-IMail-ThreadID: 776501961cdf DC> This is a multi-part message in MIME format. DC> --=_NextPart_000_0047_01C5B937.04839800 DC> Content-Type: text/plain; DC> charset="us-ascii" DC> Content-Transfer-Encoding: quoted-printable DC> LeViAmCiXaVa DC> viagbi= DC> alnali DC> trraenisxum DC> a &= DC> nbsp; DC> $3$1$3 DC> .33.21.75 DC> Our Website DC> FaBeToEa DC> st st talsy DC> DeliPric&nbs= DC> p;ConOrde DC> veryesfide= DC> ring DC> nti DC> ality= DC> ball go? writing represented an incoherent chain of certain utterances, = DC> certain DC> --=_NextPart_000_0047_01C5B937.04839800 DC> Content-Type: text/html; DC> charset="us-ascii" DC> Content-Transfer-Encoding: quoted-printable DC> DC> DC> DC> DC> DC> DC> DC> DC> face=3DCourier>LeViAm>CiXaVa DC> face=3DCourier>viagbi= DC> alnali DC> face=3DCourier>trraen<= BR>>isxum DC> face=3DCourier>a &= DC> nbsp; DC> face=3DCourier>$3>$1$3 DC> face=3DCourier>.33>.21.75 DC> DC> http://www.amyslate.com";>Our Website DC> DC> face=3DCourier>FaBeToEa> DC> face=3DCourier>st st <= BR>>talsy DC> face=3DCourier>DeliPric&nbs= DC> p;ConOrde DC> face=3DCourier>veryesfide= DC> ring DC> face=3DCourier>nti DC> face=3DCourier>ality= DC> DC> --=_NextPart_000_0047_01C5B937.04839800-- 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: Re[2]: [sniffer] False positive
Pete, other than database update e-mails, I see know e-mails from "@microneil.com" or [EMAIL PROTECTED] in the last 2 days received by my server. John T eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Pete McNeil > Sent: Tuesday, September 13, 2005 4:45 AM > To: John Tolmachoff (Lists) > Subject: Re[2]: [sniffer] False positive > > I have your response in my sent folder. > > I will send it again.. > > _M > > On Monday, September 12, 2005, 8:37:52 PM, John wrote: > > JTL> I also have sent some false positives in the last 2 weeks with no response, > JTL> the lastest being at 09/10/05 at 9:49 AM PDT. > > JTL> John T > JTL> eServices For You > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > JTL> On > >> Behalf Of Pete McNeil > >> Sent: Friday, September 09, 2005 5:08 AM > >> To: Ali Resting > >> Subject: Re: [sniffer] False positive > >> > >> On Friday, September 9, 2005, 2:17:31 AM, Ali wrote: > >> > >> AR> Hi Peter, > >> > >> AR> I have submited 3 email to [EMAIL PROTECTED] with all the required > >> AR> fields as per you instaructions on the website, I have not received > JTL> any > >> AR> feedback whether this request has been effected. > >> > >> I cleared the false positives queue last night. I don't see any > >> messages in there from you today. You should have received a response > >> for each submission. I will review my responses and get back to you > >> off list. > >> > >> Thanks, > >> > >> _M > >> > >> > >> > >> This E-Mail came from the Message Sniffer mailing list. For information > JTL> and > >> (un)subscription instructions go to > >> http://www.sortmonster.com/MessageSniffer/Help/Help.html > > > JTL> This E-Mail came from the Message Sniffer mailing list. For > JTL> information and (un)subscription instructions go to > JTL> 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 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] False positive
I have your response in my sent folder. I will send it again... _M On Monday, September 12, 2005, 8:37:52 PM, John wrote: JTL> I also have sent some false positives in the last 2 weeks with no response, JTL> the lastest being at 09/10/05 at 9:49 AM PDT. JTL> John T JTL> eServices For You >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] JTL> On >> Behalf Of Pete McNeil >> Sent: Friday, September 09, 2005 5:08 AM >> To: Ali Resting >> Subject: Re: [sniffer] False positive >> >> On Friday, September 9, 2005, 2:17:31 AM, Ali wrote: >> >> AR> Hi Peter, >> >> AR> I have submited 3 email to [EMAIL PROTECTED] with all the required >> AR> fields as per you instaructions on the website, I have not received JTL> any >> AR> feedback whether this request has been effected. >> >> I cleared the false positives queue last night. I don't see any >> messages in there from you today. You should have received a response >> for each submission. I will review my responses and get back to you >> off list. >> >> Thanks, >> >> _M >> >> >> >> This E-Mail came from the Message Sniffer mailing list. For information JTL> and >> (un)subscription instructions go to >> http://www.sortmonster.com/MessageSniffer/Help/Help.html JTL> This E-Mail came from the Message Sniffer mailing list. For JTL> information and (un)subscription instructions go to JTL> 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] Forwarding Spam
On Wednesday, September 7, 2005, 9:55:16 PM, Keith wrote: KJ> Pete, KJ> Perfect. I will work on setting up this account for KJ> you. What email address can I use to send over the POP info? Please send that or any private support correspondence to [EMAIL PROTECTED] 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[2]: [sniffer] Sniffer Resources
SBL30856 I'm coding rules now. _M On Wednesday, September 7, 2005, 10:52:58 AM, Richard wrote: RF> Much of the spam I am getting is coming from here RF> Yipes Communications, Inc. YIPES-BLK7 (NET-66-17-128-0-1) RF> 66.17.128.0 - 66.17.255.255 RF> Leasing World, LLC YIPS-A06172005 (NET-66-17-180-0-1) RF> 66.17.180.0 - 66.17.183.255 RF> Is anyone else seeing this...I have blocked in IMAIL all the IPs for Leasing RF> World.. RF> Richard Farris RF> Ethixs Online RF> 1.270.247. Office RF> 1.800.548.3877 Tech Support RF> "Crossroads to a Cleaner Internet" RF> - Original Message - RF> From: "Richard Farris" <[EMAIL PROTECTED]> RF> To: RF> Sent: Tuesday, September 06, 2005 10:07 AM RF> Subject: [sniffer] Sniffer Resources >> When I turn off sniffer my server acts normally on rescources..but when I >> turn it on it goes to 100% and stays there most of the time...I have tried >> updating the sniffer and rebooting the server but does not help...it has >> been doing this for about a month...has anyone else seen this..if not what >> can I do to resolve it..right now I have sniffer turned off so I can just >> send mail thru the server.. >> >> Richard Farris >> Ethixs Online >> 1.270.247. Office >> 1.800.548.3877 Tech Support >> "Crossroads to a Cleaner Internet" >> >> - Original Message - >> From: "Pete McNeil" <[EMAIL PROTECTED]> >> To: "Andy Schmidt" >> Sent: Monday, September 05, 2005 9:43 AM >> Subject: Re: [sniffer] Integration with today's new ORF version: >> >> >>> On Monday, September 5, 2005, 9:26:38 AM, Andy wrote: >>> >>> AS> http://www.vamsoft.com/orf/agentdefs.asp >>> AS> >>> AS> It says to contact vendor. Here I am . >>> >>> Yes indeed. >>> >>> How may I help you? >>> >>> _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 >>> >>> >> >> >> 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 >> >> RF> This E-Mail came from the Message Sniffer mailing list. For RF> information and (un)subscription instructions go to RF> 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: Re[2]: [sniffer] can auto-forward be disabled when spam is detected?
I'm afraid I'm not that up on my email standards. What exactly does forwarding by main.fwd do and how does one implement that type of solution? I know how forwarding by IMA (simple text file) works. Rick Robeson getlocalnews.com [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig Deal Sent: Friday, September 02, 2005 7:34 AM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] can auto-forward be disabled when spam is detected? Thanks for pointing out that option. I didn't know you could forward based on *.mbx. I'm not sure how this solution is any less complex, but I do like the idea of having individual spam mailbox's instead of a central quarantine. Craig > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman > Sent: Friday, September 02, 2005 12:44 AM > To: Craig Deal > Subject: Re[2]: [sniffer] can auto-forward be disabled when > spam is detected? > > > You can change your rules to forward spam to > separate user > > quarantine mailbox (not a subfolder or sub-mailbox) that > does not > > have forwarding setup. You just cannot make the rules > forward (or > > move)the spam to a sub-mailbox like > [EMAIL PROTECTED] on an > > account that is forwarded. > > That's an overly complex solution. Just put a forward on the > main.mbx by using a main.fwd -- do not use forward.ima. > Unless you have users regularly using direct mailbox > subaddressing (which is not common), you won't need to deploy > any other .fwd. > > --Sandy > > > > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > e-mail: [EMAIL PROTECTED] > > > > 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 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: Re[2]: [sniffer] can auto-forward be disabled when spam is detected?
Thanks for pointing out that option. I didn't know you could forward based on *.mbx. I'm not sure how this solution is any less complex, but I do like the idea of having individual spam mailbox's instead of a central quarantine. Craig > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman > Sent: Friday, September 02, 2005 12:44 AM > To: Craig Deal > Subject: Re[2]: [sniffer] can auto-forward be disabled when > spam is detected? > > > You can change your rules to forward spam to > separate user > > quarantine mailbox (not a subfolder or sub-mailbox) that > does not > > have forwarding setup. You just cannot make the rules > forward (or > > move)the spam to a sub-mailbox like > [EMAIL PROTECTED] on an > > account that is forwarded. > > That's an overly complex solution. Just put a forward on the > main.mbx by using a main.fwd -- do not use forward.ima. > Unless you have users regularly using direct mailbox > subaddressing (which is not common), you won't need to deploy > any other .fwd. > > --Sandy > > > > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > e-mail: [EMAIL PROTECTED] > > > > 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] can auto-forward be disabled when spam is detected?
> You can change your rules to forward spam to separate user > quarantine mailbox (not a subfolder or sub-mailbox) that does not > have forwarding setup. You just cannot make the rules forward (or > move)the spam to a sub-mailbox like [EMAIL PROTECTED] on an > account that is forwarded. That's an overly complex solution. Just put a forward on the main.mbx by using a main.fwd -- do not use forward.ima. Unless you have users regularly using direct mailbox subaddressing (which is not common), you won't need to deploy any other .fwd. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] 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] Arm Research Labs is officially launched!
On Thursday, September 1, 2005, 10:54:12 AM, Joe wrote: JW> I'm not sure what this means. JW> Is SortMonster being acquired by ARM Research Labs? Vice versa? Just joint JW> venture? ARM Research Labs is a joint venture between AppRiver and MicroNeil, thus AR - from AppRiver and M - from MicroNeil Research. :-) JW> Sure hope that a plugin to SmarterMail is just around the corner! Me too ;-) _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[2]: [sniffer] Subscription expired ?
On Sunday, August 28, 2005, 9:27:51 AM, Palle wrote: PNWHD> Can everyone mail to your mailinglist ??? @ sniffer@SortMonster.com PNWHD> maby you should take a look at your security settings. PNWHD> (i guess everyone gets this message as well) :-) The list is not open -- so you must send your mail from the subscribed address. Subscription help is here: http://www.sortmonster.com/MessageSniffer/Help/Help.html _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[2]: [sniffer] MailEnable+sniffer?
On Tuesday, August 23, 2005, 5:31:00 AM, Nick wrote: NM> It would be great if there were plans to introduce NM> Sniffer/MessageExchange to MailEnable (any plans Pete?!) as it's a NM> great simple-to-use mail server - and the entry level version is NM> free! However I would recommend SmarterMail for any large scale NM> installations - MailEnable does suffer slightly under heavy load NM> (not so much as iMail though!). That's one that's on the list. Ultimately we want SNF to be available on every possible platform... right now we're working on a lot of back-end stuff, but soon we'll get back to focusing on new platforms. I'll make sure this one is closer to the top of the list than the bottom ;-) _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: Re[2]: [sniffer] Headers showing up in message body after switching to Mdaemon
Yes, something is going on weird in Mdaemon. The strange thing is I got both copies of your message, the one to me direct and the one to the sniffer list. The strange thing is the one Pete sent to the list I had to pull out of the bad message directory as it did not make it to me. I'm not sure what the difference is. I also found I get the following errors in the Mdaemon log for these messages: Fri 2005-08-19 11:10:33: Error parsing Fri 2005-08-19 11:10:33: Message moved to Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Alberto Santoni" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Friday, August 19, 2005 11:15 AM Subject: RE: Re[2]: [sniffer] Headers showing up in message body after switching to Mdaemon Hello I received messages of this kind me too. Then I must understand that the cause is MDaemon and not iMail? Alberto -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: venerdì 19 agosto 2005 20.03 To: Jim Matuska Cc: [EMAIL PROTECTED] Subject: Re[2]: [sniffer] Headers showing up in message body after switching to Mdaemon On Friday, August 19, 2005, 12:53:39 PM, Jim wrote: JM> Pete, JM> The switch in question was from Imail to Mdaemon, so far so I was almost hoping this was a switch to a new version of MDaemon since this seems to be a new phenomena. Thanks for the data! JM> good other than a few misc bugs, I like the Mdaemon Sniffer JM> integration much better than the declude integration. We're hoping to go this route with other systems too-- but change is slow. The MDaemon folks are very aggressive in seeking new improvements :-) JM> Also Pete for some reason your message to the list got stuck JM> in the bad message queue but I recieved my original post to the JM> list. Any thoughts? Please cc: me direct [EMAIL PROTECTED] if JM> you can so I don't have to read the response from my bad message JM> queue when it comes from the list. Can you check the headers for the SNF results and any other tests which might have cause the message to get captured? There's something there that needs to be fixed. 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 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: Re[2]: [sniffer] Headers showing up in message body after switching to Mdaemon
Hello I received messages of this kind me too. Then I must understand that the cause is MDaemon and not iMail? Alberto -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: venerdì 19 agosto 2005 20.03 To: Jim Matuska Cc: [EMAIL PROTECTED] Subject: Re[2]: [sniffer] Headers showing up in message body after switching to Mdaemon On Friday, August 19, 2005, 12:53:39 PM, Jim wrote: JM> Pete, JM> The switch in question was from Imail to Mdaemon, so far so I was almost hoping this was a switch to a new version of MDaemon since this seems to be a new phenomena. Thanks for the data! JM> good other than a few misc bugs, I like the Mdaemon Sniffer JM> integration much better than the declude integration. We're hoping to go this route with other systems too-- but change is slow. The MDaemon folks are very aggressive in seeking new improvements :-) JM> Also Pete for some reason your message to the list got stuck JM> in the bad message queue but I recieved my original post to the JM> list. Any thoughts? Please cc: me direct [EMAIL PROTECTED] if JM> you can so I don't have to read the response from my bad message JM> queue when it comes from the list. Can you check the headers for the SNF results and any other tests which might have cause the message to get captured? There's something there that needs to be fixed. 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 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] Headers showing up in message body after switching to Mdaemon
On Friday, August 19, 2005, 12:53:39 PM, Jim wrote: JM> Pete, JM> The switch in question was from Imail to Mdaemon, so far so I was almost hoping this was a switch to a new version of MDaemon since this seems to be a new phenomena. Thanks for the data! JM> good other than a few misc bugs, I like the Mdaemon Sniffer JM> integration much better than the declude integration. We're hoping to go this route with other systems too-- but change is slow. The MDaemon folks are very aggressive in seeking new improvements :-) JM> Also Pete for some reason your message to the list got stuck JM> in the bad message queue but I recieved my original post to the JM> list. Any thoughts? Please cc: me direct [EMAIL PROTECTED] if JM> you can so I don't have to read the response from my bad message JM> queue when it comes from the list. Can you check the headers for the SNF results and any other tests which might have cause the message to get captured? There's something there that needs to be fixed. 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: Re[2]: [sniffer] Sniffer taking a long time?
Thanks, I will do that. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew > Sent: Wednesday, August 03, 2005 3:17 AM > To: sniffer@SortMonster.com > Subject: RE: Re[2]: [sniffer] Sniffer taking a long time? > > > So basically, what you are saying is that my volume is > really too low > > to take advantage of the persistent sniffer (and such may actually > > decrease my performance), and I should stick with the non-service > > version. Is that right? That is about what I thought (without the > > details of how sniffer works, I just wanted to be sure). > > Well, Dan, for the inevitable rush of traffic, I'd stick with > the persistent sniffer implementation now that you have it working. > > If the 2 second wait time galls you, then use your **.cfg > file and specify the > > MaxPollTime: 500 > > value at 500 ms or whatever you'd like your maximum wait time > to be instead of 2 seconds (2000 ms). > > Andrew 8) > > > > > 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: Re[2]: [sniffer] Sniffer taking a long time?
> So basically, what you are saying is that my volume is really > too low to take advantage of the persistent sniffer (and such > may actually decrease my performance), and I should stick > with the non-service version. Is that right? That is about > what I thought (without the details of how sniffer works, I > just wanted to be sure). Well, Dan, for the inevitable rush of traffic, I'd stick with the persistent sniffer implementation now that you have it working. If the 2 second wait time galls you, then use your **.cfg file and specify the MaxPollTime: 500 value at 500 ms or whatever you'd like your maximum wait time to be instead of 2 seconds (2000 ms). Andrew 8) 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: Re[2]: [sniffer] Sniffer taking a long time?
So basically, what you are saying is that my volume is really too low to take advantage of the persistent sniffer (and such may actually decrease my performance), and I should stick with the non-service version. Is that right? That is about what I thought (without the details of how sniffer works, I just wanted to be sure). Thanks, Pete. Dan Horne > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil > Sent: Tuesday, August 02, 2005 4:09 PM > To: Dan Horne > Subject: Re[2]: [sniffer] Sniffer taking a long time? > > After following through all of this and looking at the .stat > file, I think I see what's going on. > > Now that it is running and producing a .stat file, the flow > rate is very low. According to the stat data, about 6 msgs / minute. > > Note the poll and loop times are in the 450 - 550 ms range. > > SNF with the persistent engine is built for high throughput, > but it's also built to play nice. > > The maximum poll time gets up to 2 seconds or so (sound familiar?) > > If there are no messages for a while, then everything slows > down until the first message goes through. For that first > message, the SNF client will probably wait about 2 seconds > before looking for it's result because that's what the stat > file will tell it to do. > > Since the next message probably won't come around for a few > seconds, that next message will probably wait about 2 seconds also. > > If you were doing 6 messages a second then all of the times > would be much lower and so would the individual delays. > > When you turn off the persistent instance, each new message > causes a client to look and see if there are any other peers > acting a servers... Since the messages are far and few > between, the client will elect to be a server (momentarily), > will find no work but it's own, will process it's own message > and leave. -- This is the automatic peer-server mode. It will > always work like this unless more than one message is being > processed at the same moment. > > In peer-server mode, since there is nothing else going on and > no persistent instance to coordinate the operations, each > message will get processed as fast as the rulebase can be > loaded and then the program will drop. > > When the persistent instance is introduced, it sets the pace > - and sicne there are no other messages, each client will > wait about 2 seconds (or half a second or so with the .stat > file contents you show) before it begins looking for it's results. > > The server instance will also wait a bit before looking for > new jobs so that the file system isn't constantly being scanned. > > Of course, if a burst of messages come through then the > pacing will speed up as much as necessary to keep up with the volume. > > Hope this helps, > > _M > > On Tuesday, August 2, 2005, 3:38:52 PM, Dan wrote: > > DH> No, I followed your instructions exactly (and not for the first > DH> time). I didn't add those extra values until today. Prior to > DH> adding the AppDirectory value, the service was taking a minute to > DH> scan emails; after adding it the scan time went to around 2 > DH> seconds. I can't get it any lower than that. Initially > mine was > DH> set up exactly as you said, with only "Application" > containing the > DH> path, authcode and persistent. Today after hearing no > suggestions > DH> from the list, and based on recent list messages > mentioning the home > DH> directory for the service, I looked at the srvany.exe > doco to find > DH> out how to give it a home directory. > DH> That's when I added AppDirectory. I also saw and added > DH> AppParameters at the same time and added those as well, > though they > DH> seem not to be needed. > DH> > DH> Prior to adding the AppDirectory value, I never got any > .stat file > DH> or any .SVR file in my sniffer dir. After adding that value and > DH> starting the service those files appeared. > DH> > DH> > > > DH> From: [EMAIL PROTECTED] > DH> [mailto:[EMAIL PROTECTED] On Behalf Of Matt > DH> Sent: Tuesday, August 02, 2005 3:24 PM > DH> To: sniffer@SortMonster.com > DH> Subject: Re: [sniffer] Sniffer taking a long time? > > > > > DH> Dan, > > DH> There is no AppDirectory value on my servereither. The > DH> Parameters key has only one value under it besides Default > DH> which is "Application", and it contains exactly what I provided > DH> below.
Re[2]: [sniffer] Sniffer taking a long time?
After following through all of this and looking at the .stat file, I think I see what's going on. Now that it is running and producing a .stat file, the flow rate is very low. According to the stat data, about 6 msgs / minute. Note the poll and loop times are in the 450 - 550 ms range. SNF with the persistent engine is built for high throughput, but it's also built to play nice. The maximum poll time gets up to 2 seconds or so (sound familiar?) If there are no messages for a while, then everything slows down until the first message goes through. For that first message, the SNF client will probably wait about 2 seconds before looking for it's result because that's what the stat file will tell it to do. Since the next message probably won't come around for a few seconds, that next message will probably wait about 2 seconds also. If you were doing 6 messages a second then all of the times would be much lower and so would the individual delays. When you turn off the persistent instance, each new message causes a client to look and see if there are any other peers acting a servers... Since the messages are far and few between, the client will elect to be a server (momentarily), will find no work but it's own, will process it's own message and leave. -- This is the automatic peer-server mode. It will always work like this unless more than one message is being processed at the same moment. In peer-server mode, since there is nothing else going on and no persistent instance to coordinate the operations, each message will get processed as fast as the rulebase can be loaded and then the program will drop. When the persistent instance is introduced, it sets the pace - and sicne there are no other messages, each client will wait about 2 seconds (or half a second or so with the .stat file contents you show) before it begins looking for it's results. The server instance will also wait a bit before looking for new jobs so that the file system isn't constantly being scanned. Of course, if a burst of messages come through then the pacing will speed up as much as necessary to keep up with the volume. Hope this helps, _M On Tuesday, August 2, 2005, 3:38:52 PM, Dan wrote: DH> No, I followed your instructions exactly (and not for the DH> first time). I didn't add those extra values until today. Prior DH> to adding the AppDirectory value, the service was taking a minute DH> to scan emails; after adding it the scan time went to around 2 DH> seconds. I can't get it any lower than that. Initially mine was DH> set up exactly as you said, with only "Application" containing DH> the path, authcode and persistent. Today after hearing no DH> suggestions from the list, and based on recent list messages DH> mentioning the home directory for the service, I looked at the DH> srvany.exe doco to find out how to give it a home directory. DH> That's when I added AppDirectory. I also saw and added DH> AppParameters at the same time and added those as well, though DH> they seem not to be needed. DH> DH> Prior to adding the AppDirectory value, I never got any DH> .stat file or any .SVR file in my sniffer dir. After adding that DH> value and starting the service those files appeared. DH> DH> DH> From: [EMAIL PROTECTED] DH> [mailto:[EMAIL PROTECTED] On Behalf Of Matt DH> Sent: Tuesday, August 02, 2005 3:24 PM DH> To: sniffer@SortMonster.com DH> Subject: Re: [sniffer] Sniffer taking a long time? DH> Dan, DH> There is no AppDirectory value on my servereither. The DH> Parameters key has only one value under it besides Default DH> which is "Application", and it contains exactly what I provided DH> below. Could it be that you tried to hard to get everything DH> right by tweaking theseadditional keys? DH> Something else. Did you make sure that theSniffer DH> service that you created was started? No doubt it will work if DH> you follow those directions to a T, and there aren't any issues DH> with yourserver apart from this. DH> Matt DH> Dan Horne wrote: DH> I removed the AppParameters value and put the authcode DH> and persistent back in the Application value where it was before. DH> It didn't make any difference at all in the processing time, DH> still right around 2 seconds. I don't know how your setup is DH> working without at least the AppDirectory value, because mine DH> didn't start working until I put that in, but if it is, I DH> can't argue. My server load isn't anywhere near yours, so I DH> don't see what the problem could be with mine. Oh well, unless DH> Pete responds with a suggestion, I guess I'll just keep using the DH> non-service version. DH> DH> Thanks anyway. DH> From:[EMAIL PROTECTED] DH> [mailto:[EMAIL PROTECTED] On Behalf Of Matt DH> Sent: Tuesday, August 02, 2005 2:37PM DH> To:sniffer@SortMonster.com DH> Subject: Re: [sniffer] Sniffer taking a longtime? DH> Dan, DH>
RE: Re[2]: [sniffer] Sniffer taking a long time?
I replied to an off-list message from Pete, but for completeness, I will repost it to the list. We can keep it on the list, Pete, if that does ya'. It looks like Pete is probably right in that the service is probably not loading correctly for some reason. There is no .stat file in my sniffer directory. Here are my responses to Pete's questions: > Can you please tell me the content of your .stat file. There is no .stat file in my sniffer directory. No file ending with .stat, either. > > Can you estimate the number of messages per minute that you are > processing? Fairly low volume, I guess, around 10 messages per minute. > Do you have a lot of extra files in your sniffer directory? Yes, there are tons of old *.FIN files, *.WRK files, *.XXX files, *.ERR files, and a few *.ABT files. However they are mostly old files. Sorting by date, I can see several *.FIN files, but they don't hang around long. There are several still there from each day though (I assume due to daily scheduled reboots according to the timestamp). The last occurrences of the other files by extension are: *.XXX - 7/24/2005 *.ERR - 4/27/2005 *.ABT - 2/4/2005 *.WRK - 12/14/2004 I assume it is ok to delete all these? > Does you have a lot of fragmentation in your file system? How do you > mitigate the fragmentation you do have? No, we defrag daily after hours using Diskeeper's smart scheduling. > This information will help. > > Thanks, > > _M > NP. I'm sure you saw my other posts to the list, but I'll recap. When I stop the service, processing time goes down to milliseconds. Reenabling the sniffer service (installed per the archived instructions using srvany.exe) causes the processing time to go back up into the minute per message range. I have the service disabled for now. We moved our Imail/Declude install off to a weaker machine a couple weeks ago in prep for replacing it with Suse Linux ES running postfix (and sniffer, of course) on the more powerful hardware. Because the current computer is not as powerful and has become backed up a few times, I was looking at ways to lower the CPU cost per message when I found this. 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] Sniffer taking a long time?
It seems that we'll need more information to understand what's happening here. In some cases, for example, a message might give up waiting for the persistent instance to handle it's message - then it will load the rulebase and process the message itself. I can't be completely sure based on the information you've provided so far, but it seems like that might be the case. That is - for the message in question - it waited close to a minute and then processed the message itself. The persistent instance should be publishing a .stat file if it is working properly. You can periodically "type" this file at the dos command line to see real-time data on the load and timing parameters. This information would help. Thanks, _M On Monday, August 1, 2005, 3:40:18 PM, Dan wrote: DH> More info: When I stop the Sniffer service, processing time goes to DH> milliseconds. Start the service back and it is back up to a minute. >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Dan Horne >> Sent: Monday, August 01, 2005 11:58 AM >> To: sniffer@SortMonster.com >> Subject: RE: [sniffer] Sniffer taking a long time? >> >> Here are the sniffer log entries for each of the messages, if >> that helps >> any: >> >> >> > 08/01/2005 11:32:51.747 Q40a201cc1a59 SNIFFER: External program >> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe >> > mysnifferauthcode S:\imail\spool\D40a201cc1a59.SMD >> > 08/01/2005 11:33:46.751 Q40a201cc1a59 SNIFFER: External program >> > reports exit code of 61 >> >> 20050801153252D40a201cc1a59.SMD 70 20 >> Match 266707 >> 61343 358 50 >> 20050801153252D40a201cc1a59.SMD 70 20 >> Match 426427 >> 611915192950 >> 20050801153252D40a201cc1a59.SMD 70 20 >> Final 266707 >> 610 502050 >> >> >> > 08/01/2005 11:30:53.757 Q402b01b61a28 SNIFFER: External program >> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe >> > mysnifferauthcode S:\imail\spool\D402b01b61a28.SMD >> > 08/01/2005 11:31:48.210 Q402b01b61a28 SNIFFER: External program >> > reports exit code of 52 >> >> 20050801153054D402b01b61a28.SMD 80 10 >> Match 372669 >> 522745286060 >> 20050801153054D402b01b61a28.SMD 80 10 >> Match 423177 >> 612695303660 >> 20050801153054D402b01b61a28.SMD 80 10 >> Match 372652 >> 612695313860 >> 20050801153054D402b01b61a28.SMD 80 10 >> Final 372669 >> 520 495260 >> >> > 08/01/2005 11:30:56.561 Q402a01cc1a27 SNIFFER: External program >> > started: M:\IMail\Sniffer2\Distribution\Winx\mysniffer.exe >> > mysnifferauthcode S:\imail\spool\D402a01cc1a27.SMD >> > 08/01/2005 11:31:51.074 Q402a01cc1a27 SNIFFER: External program >> > reports exit code of 0 >> >> 20050801153056D402a01cc1a27.SMD 190 40 >> White 137999 >> 0 2256228544 >> 20050801153056D402a01cc1a27.SMD 190 40 >> Final 137999 >> 0 0 24419 44 >> >> 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 >> DH> This E-Mail came from the Message Sniffer mailing list. For DH> information and (un)subscription instructions go to DH> 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] New, but broken worm?
On Friday, July 22, 2005, 7:17:48 PM, Andrew wrote: >> Please send me another note with a few of these as attachments CA> Sure thing, Pete. CA> I think the formatting survived ok, and even took the time to review the CA> submission guideline on your support web page. CA> It looks like Tito's submission survived intact, but I'll send a follow CA> up as per your request, it's dead easy (but will include my standard CA> Declude headers). I've coded a complex rule for it. I'll be watching for variants. The rule id is 416945 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: Re[2]: [sniffer] Declude and Sniffer
Hi Pete, Ok. First I'd heard of it. Do you want us to change the process? If so let me know how to proceed. Darin. - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Darin Cox" Sent: Thursday, July 21, 2005 1:44 PM Subject: Re[2]: [sniffer] Declude and Sniffer On Thursday, July 21, 2005, 12:01:32 PM, Darin wrote: DC> I thought we were supposed to just forward these as attachments to the spam@ DC> address? We're trying to move away from that :-) poping the messages is more scalable. _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 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] Declude and Sniffer
On Thursday, July 21, 2005, 1:12:18 PM, Dan wrote: DH> That helps to tune the overall rulebase, but this tunes MY rulebase to DH> the types of spam that we receive. If I send it to the spam@ address it DH> may or may not get added to the rulebase. Done this way, I KNOW it is DH> going to be added to MY rulebase. Oh gosh... I'm sorry but that's not really true... slightly more likely, but the messages we pop are used generally. Sorry if I gave you the wrong impression. 99+ % of the time the effect is the same however. _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[2]: [sniffer] Declude and Sniffer
On Thursday, July 21, 2005, 12:01:32 PM, Darin wrote: DC> I thought we were supposed to just forward these as attachments to the spam@ DC> address? We're trying to move away from that :-) poping the messages is more scalable. _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: Re[2]: [sniffer] Declude and Sniffer
My bad. Trying to multi-task isn't working today. :-) John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, July 20, 2005 11:13 AM To: John Carter Subject: Re[2]: [sniffer] Declude and Sniffer On Wednesday, July 20, 2005, 12:05:29 PM, John wrote: JC> Thanks, that helps a lot. Didn't understand the replace "nonzero" JC> with the weight number in the Global file. Minor correction... Actually -- you replace "nonzero" with the result code. You adjust the weights at the end of the line as usual. _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 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] Declude and Sniffer
On Wednesday, July 20, 2005, 12:05:29 PM, John wrote: JC> Thanks, that helps a lot. Didn't understand the replace "nonzero" with the JC> weight number in the Global file. Minor correction... Actually -- you replace "nonzero" with the result code. You adjust the weights at the end of the line as usual. _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[2]: [sniffer] Upgrades...
On Tuesday, July 19, 2005, 9:34:58 AM, Jamie wrote: JM> For some reason my definitions are not in my ftp directory. JM> I can manually grab them from the http link. JM> Any help would be appreciated. JM> Jamie. Thanks for the heads-up. During the upgrade a step was missed in the FTP configuration. It's fixed now. Best, _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: Re[2]: [sniffer] Spam blocks loading me up with spam
Today I saw hits from this campaign on another IP block as well, and plugging that into SenderBase.org gives me: http://www.senderbase.org/search?searchString=200.49.37.130 Note in the top right that they list: 200.49.36.0/22 belonging to "Network Access Point S.R.L.", and following that link shows 19 domains, many of which follow Scott's spam campaign sample domains. Weirdly, plugging in that CIDR format back into SenderBase reveals little joy. I've submitted to "spam@" multiple samples from today of spam that I caught with and without Sniffer so that Pete can see what is common. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Thursday, June 16, 2005 3:58 PM To: Chuck Schick Subject: Re[2]: [sniffer] Spam blocks loading me up with spam Additional info (justifying the IP block rules just added): http://www.senderbase.org/search?searchString=200.49.48.0%2F20 I wonder why nobody else is listing these IPs yet. Could we just be the first? (This exercise has given me some ideas for new research tasks-- :-) ) Interesting. _M On Thursday, June 16, 2005, 6:46:13 PM, Chuck wrote: CS> We have been seeing these. CS> Chuck Schick CS> Warp 8, Inc. CS> (303)-421-5140 CS> www.warp8.com CS> -Original Message- CS> From: [EMAIL PROTECTED] CS> [mailto:[EMAIL PROTECTED] CS> On Behalf Of Scott Fisher CS> Sent: Thursday, June 16, 2005 4:04 PM CS> To: sniffer@SortMonster.com CS> Subject: [sniffer] Spam blocks loading me up with spam CS> Am I the only one getting blasted by these spam from these IP CS> blocks? Sniffer seems a little behind on catching these. CS> 200.49.48.0/24 200.49.48.0/24 CS> 200.49.49.0/24 200.49.49.0/24 mowz2.com CS> 200.49.50.0/24 200.49.50.0/24 qckcstmr.com CS> 200.49.51.0/24 200.49.51.0/24 srvdupfrsh.com CS> 200.49.52.0/24 200.49.52.0/24 aahtv.com CS> 200.49.53.0/24 200.49.53.0/24 aakai.com CS> 200.49.54.0/24 200.49.54.0/24 aakib.com CS> 200.49.55.0/24 200.49.55.0/24 aakli.com CS> 200.49.56.0/24 200.49.56.0/24 aafix.com CS> 200.49.57.0/24 200.49.57.0/24 e.com CS> 200.49.58.0/24 200.49.58.0/24 CS> 200.49.59.0/24 200.49.59.0/24 CS> Domain names and links seem to be five chars beginning with aa. They CS> also seem to be progressing through the IP blocks. CS> i think they started in on the June 15th and have been spamming CS> pretty consistantly. CS> This E-Mail came from the Message Sniffer mailing list. For CS> information and (un)subscription instructions go to CS> 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 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] Spam blocks loading me up with spam
Additional info (justifying the IP block rules just added): http://www.senderbase.org/search?searchString=200.49.48.0%2F20 I wonder why nobody else is listing these IPs yet. Could we just be the first? (This exercise has given me some ideas for new research tasks-- :-) ) Interesting. _M On Thursday, June 16, 2005, 6:46:13 PM, Chuck wrote: CS> We have been seeing these. CS> Chuck Schick CS> Warp 8, Inc. CS> (303)-421-5140 CS> www.warp8.com CS> -Original Message- CS> From: [EMAIL PROTECTED] CS> [mailto:[EMAIL PROTECTED] CS> On Behalf Of Scott Fisher CS> Sent: Thursday, June 16, 2005 4:04 PM CS> To: sniffer@SortMonster.com CS> Subject: [sniffer] Spam blocks loading me up with spam CS> Am I the only one getting blasted by these spam from these IP blocks? CS> Sniffer seems a little behind on catching these. CS> 200.49.48.0/24 200.49.48.0/24 CS> 200.49.49.0/24 200.49.49.0/24 mowz2.com CS> 200.49.50.0/24 200.49.50.0/24 qckcstmr.com CS> 200.49.51.0/24 200.49.51.0/24 srvdupfrsh.com CS> 200.49.52.0/24 200.49.52.0/24 aahtv.com CS> 200.49.53.0/24 200.49.53.0/24 aakai.com CS> 200.49.54.0/24 200.49.54.0/24 aakib.com CS> 200.49.55.0/24 200.49.55.0/24 aakli.com CS> 200.49.56.0/24 200.49.56.0/24 aafix.com CS> 200.49.57.0/24 200.49.57.0/24 e.com CS> 200.49.58.0/24 200.49.58.0/24 CS> 200.49.59.0/24 200.49.59.0/24 CS> Domain names and links seem to be five chars beginning with aa. They also CS> seem to be progressing through the IP blocks. CS> i think they started in on the June 15th and have been spamming pretty CS> consistantly. CS> This E-Mail came from the Message Sniffer mailing list. For CS> information and (un)subscription instructions go to CS> 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] Spam blocks loading me up with spam
I found this: IP-Whois 200.49.48.0: (ARIN/LACNIC-200)[Querying whois.lacnic.net] [whois.lacnic.net] % Copyright LACNIC lacnic.net % The data below is provided for information purposes % and to assist persons in obtaining information about or % related to AS and IP numbers registrations % By submitting a whois query, you agree to use this data % only for lawful purposes. % 2005-06-16 19:33:19 (BRT -03:00) inetnum: 200.49.48/20 status: allocated owner: FritzWare S.R.L. ownerid: AR-FRSR-LACNIC responsible: NOC Fritzware address: Av. San Martin, 6465, PB address: 1419 - Buenos Aires - country: AR phone: +54 911 5008 0447 [] owner-c: NOF tech-c: NOF created: 20050420 changed: 20050420 - Looks like this might have been created for this purpose just a short time ago. I've added rules for this /20 --- we'll see how that works out. _M On Thursday, June 16, 2005, 6:37:51 PM, Andrew wrote: CA> Also, the domains in the body text are not hitting on SURBL tests. CA> CA> Andrew 8) CA> -Original Message- CA> From: [EMAIL PROTECTED] CA> [mailto:[EMAIL PROTECTED] OnBehalf Of Colbeck, CA> Andrew CA> Sent: Thursday, June 16, 2005 3:34PM CA> To: sniffer@SortMonster.com CA> Subject: RE: [sniffer] Spamblocks loading me up with spam CA> Ihaven't noticed this spam leaking through, but at your prompting I did a: CA> CA> egrep ".+From: .+To: .+IP: 200\.49\." dec0616.log CA> CA> andsaw about 46. A glance through these to:from:ip: CA> lines definitely showsmessages that fit your description, CA> along with messages that don't (I'mdeliberately looking at CA> the 16 bit subnet) and I see messages todayfrom: CA> CA> 200.49.37.0/24 CA> 200.49.44.0/24 CA> CA> in addition to the blocks you listed, anda spot check of CA> two of them did not turn up any hits with sniffer. Total CA> volume was low, at less than 50 messages. CA> CA> One other interesting comment that I canadd is that I'm CA> seeing them use VERP like MAILFROM addresses,e.g.: CA> CA> [EMAIL PROTECTED] CA> CA> Of course, jsmith and example.com are notthe actual text, CA> but the recipient at my domain. CA> CA> Andrew8) CA> -Original Message- CA> From: [EMAIL PROTECTED] CA> [mailto:[EMAIL PROTECTED] On Behalf Of Scott CA> Fisher CA> Sent: Thursday, June 16, 2005 3:04 PM CA> To: sniffer@SortMonster.com CA> Subject: [sniffer] Spam blocks loading me up with spam CA> CA> Am I the only one getting blasted by these spam from CA> these IP blocks? Sniffer seems a little behind on catching CA> these. CA> CA> 200.49.48.0/24 200.49.48.0/24 CA> 200.49.49.0/24 200.49.49.0/24 mowz2.com CA> 200.49.50.0/24 200.49.50.0/24 qckcstmr.com CA> 200.49.51.0/24 200.49.51.0/24 srvdupfrsh.com CA> 200.49.52.0/24 200.49.52.0/24 aahtv.com CA> 200.49.53.0/24 200.49.53.0/24 aakai.com CA> 200.49.54.0/24 200.49.54.0/24 aakib.com CA> 200.49.55.0/24 200.49.55.0/24 aakli.com CA> 200.49.56.0/24 200.49.56.0/24 aafix.com CA> 200.49.57.0/24 200.49.57.0/24 e.com CA> 200.49.58.0/24 200.49.58.0/24 CA> 200.49.59.0/24 200.49.59.0/24 CA> CA> Domain names and links seem to be five chars beginning CA> with aa. They also seem to be progressing through the IP CA> blocks. CA> CA> i think they started in on the June 15th and have been spamming pretty consistantly. 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: Re[2]: [sniffer] New Spam/Virus?
New target ip: 205.138.199.146 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Matuska Sent: Monday, June 06, 2005 3:01 PM To: sniffer@SortMonster.com Subject: Re: Re[2]: [sniffer] New Spam/Virus? Thanks Pete, What Return code will this be under? Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Dave Koontz" Sent: Monday, June 06, 2005 3:00 PM Subject: Re[2]: [sniffer] New Spam/Virus? > On Monday, June 6, 2005, 5:50:38 PM, Dave wrote: > > DK> Same exact IP here! > > We've got a couple of rules for this now -- making the rounds as new > compiles go out. > > _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 > 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: Re[2]: [sniffer] New Spam/Virus?
Thanks Pete, What Return code will this be under? Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Dave Koontz" Sent: Monday, June 06, 2005 3:00 PM Subject: Re[2]: [sniffer] New Spam/Virus? On Monday, June 6, 2005, 5:50:38 PM, Dave wrote: DK> Same exact IP here! We've got a couple of rules for this now -- making the rounds as new compiles go out. _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 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] New Spam/Virus?
On Monday, June 6, 2005, 5:50:38 PM, Dave wrote: DK> Same exact IP here! We've got a couple of rules for this now -- making the rounds as new compiles go out. _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: Re[2]: [sniffer] Sniffer and SmarterMail?
If you have a current SA with Declude, you can move from iMail Declude to SmarterMail Declude for free. I suggest that you contact Declude about this - that is, assuming you are completely shutting down your iMail server. -Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 8:31 PM To: Joe Wolf Subject: Re[2]: [sniffer] Sniffer and SmarterMail? Hi Joe, Yeah, we had talked about buying the low cost Declude Virus/JM versions and then letting Sniffer hook into those as well as then hooking with SmarterMail... That's an option for you too. -jason - - - - - - - - - - - - - - - - - - > Wednesday, June 1, 2005, 7:02:30 PM, you wrote: JW> Mdaemon may be great, but it's out of my budget. I can't afford $2500 for JW> the mail server and then another $1600 for the anti-virus. Especially when JW> I compare it to SmarterMail at $600. JW> I would love to continue to use Sniffer... I respect it more than Imail and JW> Declude combined! But the fact is that it's time to move on. Ipswitch has JW> completely lost their mind and just doesn't give a damn about their JW> customers, failed to fix major problems, and raised their prices thru the JW> roof. JW> It may be very simple to plug in Sniffer to SmarterMail, but I'm not a JW> developer. I don't really want to run a non-supported implementation. JW> If there's a better option than SmarterMail I'd love to hear it, but I can't JW> compare a $4000+ server to a $600 one. 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: Re[2]: [sniffer] Sniffer and SmarterMail?
I currently own and use Declude, but want NOTHING to do with Declude from here on out. Since Scott left I nothing good to say about them. -Joe - Original Message - From: <[EMAIL PROTECTED]> To: "Joe Wolf" Sent: Wednesday, June 01, 2005 7:31 PM Subject: Re[2]: [sniffer] Sniffer and SmarterMail? Hi Joe, Yeah, we had talked about buying the low cost Declude Virus/JM versions and then letting Sniffer hook into those as well as then hooking with SmarterMail... That's an option for you too. -jason - - - - - - - - - - - - - - - - - - > Wednesday, June 1, 2005, 7:02:30 PM, you wrote: JW> Mdaemon may be great, but it's out of my budget. I can't afford $2500 for JW> the mail server and then another $1600 for the anti-virus. Especially when JW> I compare it to SmarterMail at $600. JW> I would love to continue to use Sniffer... I respect it more than Imail and JW> Declude combined! But the fact is that it's time to move on. Ipswitch has JW> completely lost their mind and just doesn't give a damn about their JW> customers, failed to fix major problems, and raised their prices thru the JW> roof. JW> It may be very simple to plug in Sniffer to SmarterMail, but I'm not a JW> developer. I don't really want to run a non-supported implementation. JW> If there's a better option than SmarterMail I'd love to hear it, but I can't JW> compare a $4000+ server to a $600 one. 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] Sniffer and SmarterMail?
Hi Joe, Yeah, we had talked about buying the low cost Declude Virus/JM versions and then letting Sniffer hook into those as well as then hooking with SmarterMail... That's an option for you too. -jason - - - - - - - - - - - - - - - - - - > Wednesday, June 1, 2005, 7:02:30 PM, you wrote: JW> Mdaemon may be great, but it's out of my budget. I can't afford $2500 for JW> the mail server and then another $1600 for the anti-virus. Especially when JW> I compare it to SmarterMail at $600. JW> I would love to continue to use Sniffer... I respect it more than Imail and JW> Declude combined! But the fact is that it's time to move on. Ipswitch has JW> completely lost their mind and just doesn't give a damn about their JW> customers, failed to fix major problems, and raised their prices thru the JW> roof. JW> It may be very simple to plug in Sniffer to SmarterMail, but I'm not a JW> developer. I don't really want to run a non-supported implementation. JW> If there's a better option than SmarterMail I'd love to hear it, but I can't JW> compare a $4000+ server to a $600 one. 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] Rule file not testing ok
On Thursday, May 26, 2005, 3:05:45 PM, Jason wrote: JP> I have not downloaded anything. Do I down load the demo then enter an JP> authorization key? Yes. Generally you start with the Demo rulebase and the current distribution. Once you have that up and running you download your registered license file and modify your configuration to match: (update notifications will tell you which file it is and your authentication code). You can find the files you need on this page: http://www.sortmonster.com/MessageSniffer/Try-It.html or if you are using MDaemon you may also want to visit this page for the plugin: http://www.sortmonster.com/MessageSniffer/Installation/MDaemon.html The instructions on our site are generally keyed to the demo rulebase to avoid confusion. Hope this helps, _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[2]: [sniffer] New Spam Storm
On Tuesday, May 17, 2005, 3:27:13 PM, Matt wrote: M> Pete, M> Your memory fails you :) I reported one just yesterday, M> however it was understandable. The rule is below (slightly M> obfuscated for public consumption). MB>> Final MB>> RULE 349776-055: User Submission, 13 days, 3.1979660500 MB>> NAME: Account and Password Information are MB>> attached!%+account_info(dot)zip MB>> CODE: Account and Password Information are MB>> attached!%+account\_info\(dot)zip MB>> No prior False Positive Reports. I stand corrected :-) (I think I subconsciously omitted it because in the end we decided to keep the rule and white-rule the list that contained the traffic.) You are correct that presently all malware group rules are coded manually. _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: Re[2]: [sniffer] New Spam Storm
Thanks Pete, would you be able to provide the current false positive rates for the return codes? Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Jim Matuska" Sent: Tuesday, May 17, 2005 11:54 AM Subject: Re[2]: [sniffer] New Spam Storm On Tuesday, May 17, 2005, 1:44:30 PM, Jim wrote: JM> Pete, JM> Is there a possibility of setting up another return code for JM> situations such as this such as a blacklist rulecode that only has JM> rules for messages such as these that should be blacklisted JM> immediately. I wouldn't mind setting certain high priority rules JM> to block immediately. A couple of things --- When we first saw this we didn't know it was a virus, so we were blocking the messages as normal spam. Once we did know it was malware we coded it to the malware group. No filters are perfect (even ours ;-) but I believe the code you are looking for is our malware result code: 55 That's as close as I can come to this requests without doing something new and therefore less reliable. Hope this helps, _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 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] New Spam Storm
On Tuesday, May 17, 2005, 1:44:30 PM, Jim wrote: JM> Pete, JM> Is there a possibility of setting up another return code for JM> situations such as this such as a blacklist rulecode that only has JM> rules for messages such as these that should be blacklisted JM> immediately. I wouldn't mind setting certain high priority rules JM> to block immediately. A couple of things --- When we first saw this we didn't know it was a virus, so we were blocking the messages as normal spam. Once we did know it was malware we coded it to the malware group. No filters are perfect (even ours ;-) but I believe the code you are looking for is our malware result code: 55 That's as close as I can come to this requests without doing something new and therefore less reliable. Hope this helps, _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[2]: [sniffer] Spam Question
On Sunday, May 15, 2005, 8:07:30 PM, Computer wrote: CHS> Thanks for the info. That would explain why my questions were not replied CHS> too. Thought no one was checking. I will resume sending spam. CHS> Can you explain what you meant by: "This is to prevent any kind of "social CHS> engineering" that might be attempted". Contrary to popular belief, most important security violation hacks are based on social engineering rather than technical means (spyware, breaking firewalls, worms, etc). Since it is very important that our services remain secure, we implement a number of protocols to prevent ourselves from being "tricked" by social engineering. A well known example of social engineering these days is the phishing spam --- the message appears to be from your bank, which you trust, and so when your "bank" asks you to refresh their memory about your information you are tricked into giving it to them --- that is, unless you are hep to the scam. Similar scams happen all the time in larger support organizations where a fake technician or user might call in to support, pretend to be "one of the guys" and ask for a quick password reminder or some other important technical tidbit. Often enough this stranger pretending to be a friend will walk away from the phone call with the password or technical detail they want -- then they can then gain access to the system at their leisure. Along these lines, if someone pretending to be one of our users asks us a question in a spamtrap then we will ignore that content - just in case it is some black-hat trying to trick us. Another aspect of this protocol is that it helps us avoid false positives -- if the text appears to be a legitimate technical question to anyone then by definition it is "not spam" so we will skip it (unless we notice a trend...) Similarly - our false positive process includes software and procedures that check the authentication of the sender to verify that they are really a customer before we respond with any potentially secure information. Hope this helps, _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[2]: [sniffer] Rule 353039 - .comcast.net
On Tuesday, May 10, 2005, 1:03:18 PM, Matt wrote: M> Pete, M> My config file was completely unedited, i.e. every setting was commented M> out. I verified that one and a half hours after the config change this M> rule was still hitting until I had restarted the service. Maybe there M> is a bug in the persistent engine reloading the config without M> intervention... Hrmm... That's very odd. I will look into that and see if I can repeat it here. Thanks for the heads up. Best, _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[2]: [sniffer] Rule 353039 - .comcast.net
On Tuesday, May 10, 2005, 12:41:42 PM, Matt wrote: M> Warning! M> When you add a RulePanic entry and are running Sniffer in persistent M> mode, you have to restart the service for it to take effect. You can also issue ".exe reload" M> Pete, when you send out these notifications, would you please add a M> few instructions to them, including the file name that needs to be M> modified, i.e. .cfg, the format of the line, and the M> instructions to restart the service. Those are good ideas --- this is so rare that I'm making up the procedure on the fly and I skipped those parts. I've posted another message with these details. M> Another important piece of M> information would be the time that the bad rule was created, M> otherwise we need to search our logs for it. My first hit on this M> was yesterday at 9 p.m. EST, but some probably hit it earlier by up M> to a couple of hours I would imagine. I will hunt that down shortly. _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[2]: [sniffer] Rule 353039 - .comcast.net
On Tuesday, May 10, 2005, 12:45:53 PM, Computer wrote: CHS> Mail from Comcast is still getting caught, even with the panic rule in CHS> place. Any suggestions? * be sure you have updated .cfg * be sure your entry is in the correct format. You will find examples at the bottom of your .cfg file with each example commented out. The easiest way to make the entry is to change the number in one of the examples and remove the # and any spaces in front of it. An active rule-panic entry will being on the first character of the line. The persistent engine should reload and pick up your change within no more than 10 minutes unless you have altered your timing settings. For immediate results you should issue ".exe reload" from your command line, Or you could restart your persistent instance service. Hope this helps, _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[2]: [sniffer] Rule 353039 - .comcast.net
On Tuesday, May 10, 2005, 12:31:18 PM, Erik wrote: E> Pete, E> Is this in the "beta"/"free" release of Sniffer rules? It may not be --- it's new enough that it may have been excluded from the demo rulebase. To make sure you should make a quick scan of your SNF log file for that rule number. In any case it will be gone from all rulebases shortly. Best, _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[2]: [sniffer] Rule 353039 - .comcast.net
On Tuesday, May 10, 2005, 12:12:40 PM, Computer wrote: CHS> Comcast messages still getting caught. Even after adding the panic rule. CHS> Even this mail from the list got caught. Can you update my rulebase? Hmmm... Be sure the format is correct and that it is not commented out. All rulebases are being updated as quickly as possible. I have added an additional rulebase compiler and modified part of the database to improve the speed. The bad rule should be gone from everyone shortly. Best, _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[2]: [sniffer] False Positives.
On Tuesday, May 10, 2005, 9:37:29 AM, Judy wrote: JB> Pete, JB> Can you send these kinds of emails to Hamed instead of me please. JB> thanks I have changed your subscription. Please note you can alter your sniffer@ list subscription at any time. Information is on our help page: http://www.sortmonster.com/MessageSniffer/Help/Help.html Best, _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: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo
Do you configure rules similar to in the previous versions, or by using this as a plug in is there a GUI for configuration. Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Dave Koontz" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 20, 2005 12:36 PM Subject: RE: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo Pete, I've been using this plugin for the last couple of months and can say it's been rock solid. Nice work! One little feature request though would be to add an option to auto prune the sniffer log file to so many days, or "X" killobytes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, April 20, 2005 1:45 PM To: Jim Matuska Subject: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo On Wednesday, April 20, 2005, 1:15:37 PM, Jim wrote: JM> Pete, JM> Should we change the license info in the plugin.cfg file to match JM> our license info or should we wait to do so until the release version comes out? Please go ahead and make the change. The current code is considered to be production ready. Any changes prior to release will be minor additions, and it is likely there will be no changes... that is, unless someone reports a bug ;-) The new plugin is clearly the preferable Message Sniffer implementation for MDaemon. Best, _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 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: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo
Pete, I've been using this plugin for the last couple of months and can say it's been rock solid. Nice work! One little feature request though would be to add an option to auto prune the sniffer log file to so many days, or "X" killobytes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, April 20, 2005 1:45 PM To: Jim Matuska Subject: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo On Wednesday, April 20, 2005, 1:15:37 PM, Jim wrote: JM> Pete, JM> Should we change the license info in the plugin.cfg file to match JM> our license info or should we wait to do so until the release version comes out? Please go ahead and make the change. The current code is considered to be production ready. Any changes prior to release will be minor additions, and it is likely there will be no changes... that is, unless someone reports a bug ;-) The new plugin is clearly the preferable Message Sniffer implementation for MDaemon. Best, _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: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo
Pete, Is there a difference between the normal .snf files I have been downloading and the one for the plugin? I have setup my script to download the .snf file and noticed it is a couple mb's smaller than the included demo .snf file. Jim Matuska Jr. Computer Tech2, CCNA Nez Perce Tribe Information Systems [EMAIL PROTECTED] - Original Message - From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Jim Matuska" Sent: Wednesday, April 20, 2005 10:45 AM Subject: Re[2]: [sniffer] Message Sniffer Plugin for MDaemon Wide Beta & Promo On Wednesday, April 20, 2005, 1:15:37 PM, Jim wrote: JM> Pete, JM> Should we change the license info in the plugin.cfg file to match our JM> license info or should we wait to do so until the release version comes out? Please go ahead and make the change. The current code is considered to be production ready. Any changes prior to release will be minor additions, and it is likely there will be no changes... that is, unless someone reports a bug ;-) The new plugin is clearly the preferable Message Sniffer implementation for MDaemon. Best, _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 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] Message Sniffer Plugin for MDaemon Wide Beta & Promo
On Wednesday, April 20, 2005, 1:15:37 PM, Jim wrote: JM> Pete, JM> Should we change the license info in the plugin.cfg file to match our JM> license info or should we wait to do so until the release version comes out? Please go ahead and make the change. The current code is considered to be production ready. Any changes prior to release will be minor additions, and it is likely there will be no changes... that is, unless someone reports a bug ;-) The new plugin is clearly the preferable Message Sniffer implementation for MDaemon. Best, _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: Re[2]: [sniffer] Notice: Potential outages tonight...
Yes but that really seems strange when I was getting 4 to 10 messages every day. Now I did not get any since the 3rd of March right after you announced that there would be the outage? You may want to check into this closer. Rick Hogue Intent.Net - Web Hosting 3802 Handley Avenue Louisville, KY 40218 1-502-459-3100 1-800-866-2983 Toll Free New Books Available "Prosperity Or Better Times Ten" "Hot Slot Secrets" "The Incredible Inman's Louisville Trivia Challenge" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, April 09, 2005 1:34 PM To: Rick Hogue Cc: sniffer@SortMonster.com Subject: Re[2]: [sniffer] Notice: Potential outages tonight... On Saturday, April 9, 2005, 1:27:51 PM, Rick wrote: RH> I have not had any messages from the list since the 3rd of March. What is RH> happening on the list? The list has been very quiet. I got your message twice - once from you directly and once from the list. This seems correct based on your headers ;-) _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 --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] 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] Notice: Potential outages tonight...
On Saturday, April 9, 2005, 1:27:51 PM, Rick wrote: RH> I have not had any messages from the list since the 3rd of March. What is RH> happening on the list? The list has been very quiet. I got your message twice - once from you directly and once from the list. This seems correct based on your headers ;-) _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: Re[2]: [sniffer] Persistent Sniffer
Pete, Thanks for the reply. Running on an IBM Xseries 225 Dual Xeon 2.4Ghz w/ 1GB RAM - running IBM's ServerRAID 5i in IBM's RAID 10 config (4 73GB 10K drives) - O/S is Windows 2000 Standard Server SP4 Running Imail 8.15HF1 with Declude JM/Virus 1.82 - BIND DNS Server is 1 hop away (on switch backbone). I had to drop back to the non-persistent mode, thus the .stat file disappeared. I will run it again tonight and copy the file away and post it here tonight. Thanks again for the time and aid. Keith Johnson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, April 01, 2005 11:17 AM To: Keith Johnson Subject: Re[2]: [sniffer] Persistent Sniffer On Friday, April 1, 2005, 8:04:27 AM, Keith wrote: KJ> I have read forum results that this behavior is the reverse of what KJ> should happen, I should get a reduction in CPU. I did this around KJ> 11pm last night, usually during peak times this server would stay at KJ> 65% load. Is there anything I can tweak to install the Sniffer KJ> persistent server and achieve desired results? Thanks for the aid. Can you share more about your server's configuration and can you also post the .stat file that was produced? Server OS? Server CPU(s)? Drive System(s)? Mail Server SW? _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 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] Persistent Sniffer
On Friday, April 1, 2005, 8:04:27 AM, Keith wrote: KJ> I have read forum results that this behavior is the reverse of KJ> what should happen, I should get a reduction in CPU. I did this KJ> around 11pm last night, usually during peak times this server KJ> would stay at 65% load. Is there anything I can tweak to install KJ> the Sniffer persistent server and achieve desired results? Thanks KJ> for the aid. Can you share more about your server's configuration and can you also post the .stat file that was produced? Server OS? Server CPU(s)? Drive System(s)? Mail Server SW? _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[2]: [sniffer] Persistent Sniffer
On Wednesday, March 30, 2005, 10:50:36 PM, Keith wrote: KJ> Pete, KJ>Thanks for the follow-up. I was monitoring the KJ> filename.persistent.stat file that yields stats as messages are KJ> processed. Is it normal for it to every now and then flash [File KJ> is Empty], thus no stats at all. Usually within a few seconds KJ> stats would appear again. Thanks again, This usually means that you were reading the file just as it was being written. When the file is output it is opened with O_TRUNC to truncate the file so it can be replaced. If you read it at that moment you will see nothing so this is normal. Hope this helps, _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[2]: [sniffer] mini-obfuscation
On Wednesday, March 23, 2005, 6:04:10 PM, Darrell wrote:
Dsic> Pete,
Dsic> Doesnt Sniffer have a certain level of support for regex's? I know we
have
Dsic> had good luck with regex's like this which catch obfuscation techniques
with
Dsic> viagra with Declude. We found it easier to use regex's than to list all
of
Dsic> the different variations.
Dsic>
(?:\b|\s)[_\W]{0,3}(?:\\\/|V)[_\W]{0,3}[ij1!|l\xEC\xED\xEE\xEF][_\W]{0,3}[a4
Dsic> [EMAIL PROTECTED],3}[xyz]?[gj][_\W]{0,3}r[_\W]{0,[EMAIL PROTECTED],
Dsic> 3}x?[_\W]{0,3}(?:\b|\s)
The compiler and scanner we use has a limited regex capability. Some
of the features you've used here were kept out of the engine on
purpose. Later versions of the engine (under development) will have
some more of these features - eventually including all of the features
found on most regex systems, and then moving beyond them.
Slick regex patterns like the one you have here are often useful for
describing patterns, but not always as useful for rapidly developing
and modifying dynamic pattern matching schemes.
For example - the regex you have stated here will match a wide range
of permutations in a single statement. That is, after all, a strength
of regex. However in practice it is often found that most of the
possible patterns simply are never seen "in the wild" or that some
specific variations might be problematic... In these cases it is
better to use a small catalog of simpler patterns because they can be
implemented and understood incrementally, and they can be very easily
excluded on a one-by-one basis if needed. Adding that kind of
flexibility to the regex you have here could make it even more
difficult to understand and correctly encode --- since we have a very
small staff creating and modifying hundreds of rules per day seconds
count. I have to admit that it would take me a few minutes to
completely understand what the above regex really does - and chances
are that if I modified it I would be much more likely to introduce an
error than I would using our more simplified coding scheme.
That's not to say that we won't be introducing more complex pattern
matching capabilities - we certainly will. However, the syntax for
these rules will be less concerned with an economy of keystrokes and
more concerned with reliable, rapid generation and modification.
For example, the coding system we have planned will be able to break
down the pattern you've represented into a number of functional units
that can be mixed and re-used in a hierarchical structure. This will
allow both the robots and the humans to understand and manipulate the
patterns very easily.
Regex (as written) is a good way to represent some patterns
efficiently - but it has the down side that the syntax can be
arbitrarily difficult and that does not naturally represent conceptual
structures that might be found in the patterns to be matched and
readily reused.
Best,
_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: Re[2]: [sniffer] RAID Levels for Spool Folder
Matt and Charles, Thank you for your insight and comments. Now I just have to go and get the money to get something that I want :) Goran Jovanovic The LAN Shoppe 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] RAID Levels for Spool Folder
Hello Matt, Wednesday, March 16, 2005, 11:44:08 PM, you wrote: M> I would just RAID 5 the whole setup. With your 6 drives, you M> get the read performance of 4 drives on any partition in this M> setup, plus you have a hot spare, and the write performance of M> close to 4 drives as well. This is a lot better than your config M> with a mirrored set of drives and a RAID 5 array that reads and M> writes at about the capacity of two. You will definitely get more M> bang for your buck with it all being one RAID 5 array, and you get M> much better redundancy that way as well. M> As far as splitting things up, there are only 4 things that I feel need to be separate: M> 1) OS and Executables M> 2) Spool M> 3) Mail Boxes M> 4) Log File Archive I have to agree with Matt, I run a single RAID 5 array with 7, 7200 RPM SATA disks for my mail server, and I see between 250K and 325K daily messages. My main differences are, I use a 3Ware EIDE RAID card for a RAID 1 on two 80GB disks for OS and Software, the big RAID is for Spool, Mailboxes and Logs, and I delete logs after 10 days. In almost 9 years of running an ISP, I have had only a couple of instances of needing logs beyond 3 or 4 days. When you only have a 3 disk RAID 5 I can definately see that there is a write performance hit, but that is why your RAID controller has a processor and cache, a good RAID controller can minimize the hit. On a larger array, say 6 drives, your data is split into 4 data blocks and 2 parity blocks, so the same write operation is twice as fast, you have twice as many spindles, no major disadvantage to the original proposal of a 3 disk RAID 5, 2 disk RAID 1, and single store disk, but you gain an added level of redundancy. I would throw a little bit of money into RAM and forget worrying so much about a paging partition, I have 2GB of RAM and only use a total of about 250MB RAM and Paging, with a very occasional jump to 500MB when things go wrong. Most anything in the Page file will not have any critical performance impact on your system. If you don't already have the drives and controller, you can also look at the Western Digital Raptor SATA disks, they are the only 10,000 RPM SATA disks. I also like the #Ware controllers, mine is the 8000 series, but 9000 series should be out now, and have a considerable performance edge. -- Best regards, Charlesmailto:[EMAIL PROTECTED] 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: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
> Now does anyone know how much overhead Windows 2000/2003 software RAID 1 > on dynamic disks produces over hardware level RAID 1? > > I am assuming it would be substantial. I have never noticed an issue, and I would only assume there would be an issue in higher end databases or where the CPU was already being tasked and near or at saturation by other processes. John Tolmachoff Engineer/Consultant/Owner eServices For You > - 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: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
OK that is for hardware level RAID. I had thought that you would offset the extra processing time by being able to write less to each drive. Now does anyone know how much overhead Windows 2000/2003 software RAID 1 on dynamic disks produces over hardware level RAID 1? I am assuming it would be substantial. Goran Jovanovic The LAN Shoppe > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Pete McNeil > Sent: Wednesday, March 16, 2005 11:43 AM > To: Goran Jovanovic > Subject: Re[2]: [sniffer] Moving Sniffer to Declude/SmarterMail > > On Wednesday, March 16, 2005, 11:25:46 AM, Goran wrote: > > > > GJ> I guess this is going against what I think should be happening. In a > GJ> RAID 5 array the write to the drives is broken into many smaller > writes > GJ> along with the data protection/CRC info and then those writes are > GJ> written to different drives. It seems to me that it should be faster > to > GJ> do a bunch of small writes rather than 1 big write. > > GJ> What am I missing? > > Writing data to a single hard drive takes x amount of work. > > Writing data to more than one drive takes x+y amount of work where y > is breaking up the data into chunks. > > Writing data to a raid 5 takes x+y+z amount of work where y is > described above and z is calculating a CRC stripe which must now also > be saved to a hard drive. > > So, writing to raid5 is relatively very expensive compared to writing > to a plain old hard drive, or a less complex raid (such as mirroring). > > IMO, the best strategy for email servers is to use an ordinary, single > fast HD for all spool operations, and place mailboxes on a raid 1 or > raid 10. > > Hope this helps, > > _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 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] Moving Sniffer to Declude/SmarterMail
On Wednesday, March 16, 2005, 11:25:46 AM, Goran wrote: GJ> I guess this is going against what I think should be happening. In a GJ> RAID 5 array the write to the drives is broken into many smaller writes GJ> along with the data protection/CRC info and then those writes are GJ> written to different drives. It seems to me that it should be faster to GJ> do a bunch of small writes rather than 1 big write. GJ> What am I missing? Writing data to a single hard drive takes x amount of work. Writing data to more than one drive takes x+y amount of work where y is breaking up the data into chunks. Writing data to a raid 5 takes x+y+z amount of work where y is described above and z is calculating a CRC stripe which must now also be saved to a hard drive. So, writing to raid5 is relatively very expensive compared to writing to a plain old hard drive, or a less complex raid (such as mirroring). IMO, the best strategy for email servers is to use an ordinary, single fast HD for all spool operations, and place mailboxes on a raid 1 or raid 10. Hope this helps, _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[2]: [sniffer] Moving Sniffer to Declude/SmarterMail
On Wednesday, March 16, 2005, 9:01:34 AM, Nick wrote: NM> Pete NM> OK, I now have much more information on this problem with NM> Declude/Sniffer/SmarterMail. NM> It seems the current version of Declude does not have an Overflow Directory NM> for SmarterMail, which therefore allows unlimited Declude processes to be NM> spawned at any time. At our peak we were seeing a surge of more than 1,000 NM> declude.exe instances running at the same time! This of course flattened the NM> server, and seems the reason why Sniffer was dropping out of its perpetual NM> mode, unfortunately compounding the problem when the server had least NM> resources. Thanks for this --- I think this proves one of my theories on the problem. This is what I think happened to SNF... A burst of 1000 or more active requests arrives which is more than the server can really handle at one time. The persistent server queues (internally) all of the jobs and begins processing them all at once. As a result, it does not report to the .stat file for an extended period. Also, due to the very large number of jobs, many of the client instances do not hear back from the server instance until their maximum wait time has expired. As a result, they abandon the wait and begin processing the messages themselves, each one now loading the rulebase. The clients loading the rulebase individually further slows the server and accelerates the problem until an insurmountable backlog is in place. Once the backlog is cleared (requiring manual intervention) the persistent instance (which has not died) is able to respond to client requests quickly enough so that they do not "give up" and so the system operates normally. --- If this fits the profile (and I think it does) then it would be possible to adjust SNF with an alternate fail-safe mode which would solve the problem at the expense of letting more spam through. Specifically, once a particular threshold is reached then the clients would abandon a job and fail safe rather than loading the rulebase and processing the message. This would cause spam to "leak" but it would also provide for a more rapid, automatic recovery. Think of it as a safety pressure valve on a boiler. It's not a great solution, but it's better than an "explosion". The best answer is proper overflow control and since Declude is working on that I'm inclined to let that solution develop. Not only because it's a better solution, but also because the "safety valve" mechanism on SNF doesn't solve the whole problem - for example virus scanning would still potentially cause the same problem along with other things that might be running in Declude. Thanks Nick! _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: Re[2]: [sniffer] SPAM
I currently forward all spam from my email account can I add a second address that will be able to forward spam as well? Jonathan SchoemannNetwork Systems EngineerInformation ServicesSt. Agnes HealthCare / CSC[EMAIL PROTECTED]410-368-3110>>> [EMAIL PROTECTED] 03/07/05 07:09PM >>>On Monday, March 7, 2005, 7:00:40 PM, Frederick wrote:FS> No errors. Just SPAM showing as clean.Be sure to forward / redirect them to the spam@ address if you haven'talready. I'll be making another run in an hour or so - I'll lookclosely at anything that doesn't get tagged on the way to me._MThis 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 MESSAGE IS INTENDED ONLY FOR OFFICIAL BUSINESS USE BY THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivery of the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
Re[2]: [sniffer] SPAM
On Monday, March 7, 2005, 7:00:40 PM, Frederick wrote: FS> No errors. Just SPAM showing as clean. Be sure to forward / redirect them to the spam@ address if you haven't already. I'll be making another run in an hour or so - I'll look closely at anything that doesn't get tagged on the way to me. _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: Re[2]: [sniffer] Seperate Lists?
Thanks Matt for clarifying my point, and Pete for considering this. Oddly enough, I would likely subscribe to BOTH lists, but the seperation would allow me to filter, target and respond to more 'important' emails notices, and review discussions *IF* and/or when I have time. As an Email/Network Admin and IT Manager, I receive hundreds of emails per day, and so I must be able to automatically prioritize those messages via filters as they arrive so I can focus on "Critical" information. Thanks again for your consideration! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Saturday, February 19, 2005 2:25 PM To: Matt Subject: Re[2]: [sniffer] Seperate Lists? On Saturday, February 19, 2005, 2:05:09 PM, Matt wrote: M> Pete, M> Being guilty of being 'chatty' myself, I still second this idea. I M> would much prefer to pick through an occasional message dealling with M> global announcements regarding the service than picking through both M> discussions as well as announcements. I'm not always up to date on M> this list and others that I follow and I probably will pay less M> attention to them over time as I get buried in other things as many of us do. M> Please consider a separate announcement-only list for this purpose. M> Alternatively, having both mixed will both overwhelm users not M> interested in the more general discussion and it may also cause those M> of us that are more 'chatty' to quiet down which stifles the M> discussion and the benefit that can be gleamed from it. Point taken. This seems to be a popular idea so I will look into it. This list, however, will remain "chatty". The "announcements only" list will only be used for that purpose. I would hate to see the discussions on this list "quieted". 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 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] Seperate Lists?
On Saturday, February 19, 2005, 2:05:09 PM, Matt wrote: M> Pete, M> Being guilty of being 'chatty' myself, I still second this idea. I M> would much prefer to pick through an occasional message dealling with M> global announcements regarding the service than picking through both M> discussions as well as announcements. I'm not always up to date on this M> list and others that I follow and I probably will pay less attention to M> them over time as I get buried in other things as many of us do. M> Please consider a separate announcement-only list for this purpose. M> Alternatively, having both mixed will both overwhelm users not M> interested in the more general discussion and it may also cause those of M> us that are more 'chatty' to quiet down which stifles the discussion and M> the benefit that can be gleamed from it. Point taken. This seems to be a popular idea so I will look into it. This list, however, will remain "chatty". The "announcements only" list will only be used for that purpose. I would hate to see the discussions on this list "quieted". 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[2]: [sniffer] IIS SMTP Integration
On Saturday, February 19, 2005, 1:20:39 AM, ron wrote: rdc> Hi folks, rdc> I think I have ended up on some sort of private email list. Can you please rdc> remove [EMAIL PROTECTED] and [EMAIL PROTECTED] from your mail list. I found and removed [EMAIL PROTECTED] from the Message Sniffer support list. Our customers are automatically subscribed to this list when they purchase Message Sniffer since it is an important part of our support program for the product. If you want to subscribe or unsubscribe later please see our help page for instructions. This list is a valuable support resource for your message sniffer subscription and it is usually pretty quiet. Sorry for any confusion or inconvenience. http://www.sortmonster.com/MessageSniffer/Help/Help.html 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: Re[2]: [sniffer] IIS SMTP Integration
Hi Andrew: >> The idea being that you don't want any more content searching than is necessary << The content searching happens at the very end of the protocol conversation. By that time you already have processed your IP, HELO, SENDER etc. policies (e.g. DNS BL, local BLs, etc.) Or are you saying you want to only search for content when there is NO dictionary attack - but if you happen to be under dictionary attack you want to let all the spam go through unchecked? Seems counterintuitive to me. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M> Sanford Whiteman wrote: >>Incidentally, it is a transport sink, not a protocol sink, meaning >>that envelope rejection is not possible. I can't defend this as solely >>a choice made for stability, as it was also a choice necessitated by >>my prototyping in VB (and, though it's been in production, it's not >>much more than a prototype due to the lack of docs). >> >> M> Yes, that really is a key issue. It needs to be a transport sink, or M> at least work with one in order to prevent ongoing issues with brute M> force spam floods. I'm not sure that Peter from VamSoft understands M> the large market out there for non-Exchange based setups, or even for M> going the extra mile that is necessary for this stuff, though that M> might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _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 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: Re[2]: [sniffer] IIS SMTP Integration
>> The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. << Okay, but if you wait until the message is stored in the queue and NOW you have to scan each one with a command-line process - how is THAT better (that's the transport sink scenario). What you want to do is: A) upon connection, check DNS BLs - if matches, add points B) upon HELO, check HELO rules - if matches, add points C) upon MAIL FROM - check for <>, if it matches, set a flag (there should only be ONE recipient) check DNS BLs for blacklisted recipients, if matches, add points D) upon RCPT TO - check for valid recipient - if more than 2 invalid recipients, drop connection. If sender is <> and more than 1 recipient, drop connection If recipient is Postmaster@ or Abuse@ or Root@ (etc) and more than 1 recipient, drop connection (with proper return code "too many recipients) E) at EOD (after the CR.CR), - check for SMTP AUTH (so you can skip scanning) - otherwise scan the content with Sniffer (and Virus Scanner) - add points If the points exceed your threshold at ANY time, drop connection. No bounce message necessary, no need to store the message in the queue, etc. Whenever you drop connection, add IP to your "tarpit/graylist" list. Use that for subsequent "upon connections" >> Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. << You can do that by processing the log file. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 08:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M> Sanford Whiteman wrote: >>Incidentally, it is a transport sink, not a protocol sink, meaning >>that envelope rejection is not possible. I can't defend this as solely >>a choice made for stability, as it was also a choice necessitated by >>my prototyping in VB (and, though it's been in production, it's not >>much more than a prototype due to the lack of docs). >> >> M> Yes, that really is a key issue. It needs to be a transport sink, or M> at least work with one in order to prevent ongoing issues with brute M> force spam floods. I'm not sure that Peter from VamSoft understands M> the large market out there for non-Exchange based setups, or even for M> going the extra mile that is necessary for this stuff, though that M> might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _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 This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sort
RE: Re[2]: [sniffer] IIS SMTP Integration
Oh, crap. Did I just put words in Matt's mouth? Now we'll never hear the end of it. Have a good weekend, guys. Especially you, Sandy. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew Sent: Friday, February 18, 2005 5:06 PM To: sniffer@SortMonster.com Subject: RE: Re[2]: [sniffer] IIS SMTP Integration Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M> Sanford Whiteman wrote: >>Incidentally, it is a transport sink, not a protocol sink, meaning >>that envelope rejection is not possible. I can't defend this as solely >>a choice made for stability, as it was also a choice necessitated by >>my prototyping in VB (and, though it's been in production, it's not >>much more than a prototype due to the lack of docs). >> >> M> Yes, that really is a key issue. It needs to be a transport sink, or M> at least work with one in order to prevent ongoing issues with brute M> force spam floods. I'm not sure that Peter from VamSoft understands M> the large market out there for non-Exchange based setups, or even for M> going the extra mile that is necessary for this stuff, though that M> might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _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 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: Re[2]: [sniffer] IIS SMTP Integration
Pete, Matt was specifically referring to envelope rejection (as well as other info gathering actions) based on address validation (and any other criteria based on information as it can be tested, like a local blacklist against the sending IP). The idea being that you don't want any more content searching than is necessary, particularly when a recipients-dictionary-attack is underway. Me, I like the idea of accruing a weight against the sending IP when a recipient lookup fails. I get a lot of spam that is a single message which is CC'ed and BCC'ed against a lot of addresses that are simply guessed, and I want to punish those, and ideally, share that news with other mailservers. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 18, 2005 4:33 PM To: Matt Subject: Re[2]: [sniffer] IIS SMTP Integration On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M> Sanford Whiteman wrote: >>Incidentally, it is a transport sink, not a protocol sink, meaning >>that envelope rejection is not possible. I can't defend this as solely >>a choice made for stability, as it was also a choice necessitated by >>my prototyping in VB (and, though it's been in production, it's not >>much more than a prototype due to the lack of docs). >> >> M> Yes, that really is a key issue. It needs to be a transport sink, or M> at least work with one in order to prevent ongoing issues with brute M> force spam floods. I'm not sure that Peter from VamSoft understands M> the large market out there for non-Exchange based setups, or even for M> going the extra mile that is necessary for this stuff, though that M> might be an issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _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 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] IIS SMTP Integration
On Friday, February 18, 2005, 7:23:03 PM, Matt wrote: M> Sanford Whiteman wrote: >>Incidentally, it is a transport sink, not a protocol sink, meaning >>that envelope rejection is not possible. I can't defend this as solely >>a choice made for stability, as it was also a choice necessitated by >>my prototyping in VB (and, though it's been in production, it's not >>much more than a prototype due to the lack of docs). >> >> M> Yes, that really is a key issue. It needs to be a transport sink, or at M> least work with one in order to prevent ongoing issues with brute force M> spam floods. I'm not sure that Peter from VamSoft understands the large M> market out there for non-Exchange based setups, or even for going the M> extra mile that is necessary for this stuff, though that might be an M> issue with resources and not just simply understanding. Please give some more detail on this... When I researched this before it seemed that a transport sink is good when you want the file, but if at all possible you'd really want a protocol sink. I had sketched out the idea of putting SNF up at the protocol level right after CR.CR so that any mods could happen in RAM and so that if the message were to be rejected it could be. SNF is up to the challenge because if you can avoid all of the file system coordination stuff that the command line version does you're down to periodically checking for a new rulebase file and then running the scanner. That part of what SNF does usually happens very, very fast. Faster, in fact, than most ping return times!! If it could be done at that point in the process then why would you not want to do it there? (Not a rhetorical question - I don't know enough about this and want to learn.) _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[2]: [sniffer] IIS SMTP Integration
On Friday, February 18, 2005, 1:55:00 PM, Andy wrote: AS> Hi, AS> You know of this one: AS> http://www.mailmage.com/products/software/freeutils/MilterSink/webhelp/milte AS> rsink_help.htm ? Well, yes, and I'd love to put it out there. Perhaps I'm missing something obvious but there doesn't seem to be a place do download this, and the site is incomplete. I would really love to see it all get done and I'd like to have it to play with too - after all, I'm going to get a lot of questions about how it works and how it gets set up etc... plus I will want to make adjustments to sniffer to support it better (such as rewriting the message file etc...). AS> Exchange server is NOT required to test SMTP sinks - just standard Windows AS> with IIS SMTP (you can probably even test it on XP Pro - although I have not AS> tried). True ... Exchange is not strictly required, but I'm going to get support questions that will probably require that I have a simulation in the lab. I hate to do things half way. Even so, I'd be happy with a workable solution and a place to send users for help when they need it. AS> Yes, there ARE "_EOD" sinks in the field. ORF from VamSoft uses them to AS> support RegEx checks against the MIME content. In fact, ORF would be a great AS> partner for Sniffer (if only they could be convinced). That's worth a shot. AS> I'm in the process of deploying IIS/SMTP with ORF and a custom sink as a AS> gateway for Imail - and would LOVE to get Sniffer in there as well. Maybe we can team up to make this work. _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[2]: [sniffer] Changes - another reminder.
On Wednesday, February 16, 2005, 3:55:57 AM, Bonno wrote: BB> Hi, BB> [...] >> This is a _special_ reminder that we are in the process of migrating >> our servers and applications to a new facility. BB> [] >> See you on the other side ;-) BB> Looks like sniffer is now "on the other side". ;-) Yes, expect for some minor tweaks and adjustments, all of the heavy stuff has been moved and appears to be working fine. Any reports to the contrary are welcome and encouraged. Best, _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[2]: [sniffer] Changes - another reminder.
On Monday, February 14, 2005, 2:37:20 PM, Andy wrote: AS> If I may suggest: AS> - at least 24 hours before the cut-over, change DNS timeout for "A" and AS> CNAME records to 4 hours. AS> - on the day of the cutover, change DNS timeouts to 1 hour AS> That will minimize any impact. AS> - after the cutover was successful, change DNS timeouts for the updated AS> records to longer values. Almost what we have planned. _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[2]: [sniffer] Simple SpamAssassin 3.x Plugin for Sniffer
On Friday, February 4, 2005, 12:01:19 AM, Aaron wrote: AM> And committing the sin of replying to myself, AM> I'll post the cf and pm file since it looks like the list ate my formatting. AM> http://arcadium.org/millisa/snfilter.pm AM> http://arcadium.org/millisa/snfilter.cf Thanks - I'll grab them from there. _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: Re[2]: [sniffer] The next round in the SPAM war?
Hijack keeps track of the number of recipients per originating IP. So, an e-mail to a list as it is received by Imail will have only one recipient, the list address. John Tolmachoff Engineer/Consultant/Owner eServices For You > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Thursday, February 03, 2005 9:48 AM > To: Mike Wiegers > Subject: Re[2]: [sniffer] The next round in the SPAM war? > > Hi, > > How does hijack handle listserv's? > > Thanks, > Andrew Baldwin > > [EMAIL PROTECTED] > http://www.thumpernet.com > 315-282-0020 > > Thursday, February 3, 2005, 12:21:54 PM, you wrote: > > > The item that works for this is Decludes HiJack. > > > http://www.declude.com/SearchResults.asp?Cat=10 > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf Of Shaun Sturby, MCSE Optrics Engineering > > Sent: Thursday, February 03, 2005 10:09 AM > > To: sniffer@SortMonster.com > > Subject: [sniffer] The next round in the SPAM war? > > > Just an FYI and another good reason to have a service like Sniffer. > > > From: News.com.com > > According to the SpamHaus Project--a U.K.-based antispam compiler of > > blacklists that block 8 billion messages a day--a new piece of malicious > > software has been created that takes over a PC. This "zombie" computer is > > then used to send spam via the mail server of that PC's Internet service > > provider. This means the junk mail appears to come from the ISP, making it > > very hard for an antispam blacklist to block it. > > > Antispam company MessageLabs confirmed Linford's findings. > > > More at the following URL. > > > http://news.com.com/Experts+Zombie+trick+set+to+send+spam+sky-high/2100- > 7349 > > _3-5560664.html?tag=nefd.top > > > Shaun Sturby, MCSE > > Manager - Technical Services > > > Optrics Engineering - Solution Partners & Network Specialists > > Email: [EMAIL PROTECTED] Website: www.Optrics.com > > United States: 1740 S 300 West #10 Clearfield, UT, 84015 > > Phone: 1-877-430-6240 Fax: (801) 705-3150 > > Canada: 6810 104 St. Edmonton, AB Canada T6H 2L6 > > Phone: 1-877-463-7638 Fax: (780) 432-5630 > > Optrics Engineering and FundSoft are divisions of Optrics Inc. > > > _ > > > Anti-virus & Anti-SPAM control solutions provided by www.Optrics.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 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] The next round in the SPAM war?
Hi, How does hijack handle listserv's? Thanks, Andrew Baldwin [EMAIL PROTECTED] http://www.thumpernet.com 315-282-0020 Thursday, February 3, 2005, 12:21:54 PM, you wrote: > The item that works for this is Decludes HiJack. > http://www.declude.com/SearchResults.asp?Cat=10 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Shaun Sturby, MCSE Optrics Engineering > Sent: Thursday, February 03, 2005 10:09 AM > To: sniffer@SortMonster.com > Subject: [sniffer] The next round in the SPAM war? > Just an FYI and another good reason to have a service like Sniffer. > From: News.com.com > According to the SpamHaus Project--a U.K.-based antispam compiler of > blacklists that block 8 billion messages a day--a new piece of malicious > software has been created that takes over a PC. This "zombie" computer is > then used to send spam via the mail server of that PC's Internet service > provider. This means the junk mail appears to come from the ISP, making it > very hard for an antispam blacklist to block it. > Antispam company MessageLabs confirmed Linford's findings. > More at the following URL. > http://news.com.com/Experts+Zombie+trick+set+to+send+spam+sky-high/2100-7349 > _3-5560664.html?tag=nefd.top > Shaun Sturby, MCSE > Manager - Technical Services > Optrics Engineering - Solution Partners & Network Specialists > Email: [EMAIL PROTECTED] Website: www.Optrics.com > United States: 1740 S 300 West #10 Clearfield, UT, 84015 > Phone: 1-877-430-6240 Fax: (801) 705-3150 > Canada: 6810 104 St. Edmonton, AB Canada T6H 2L6 > Phone: 1-877-463-7638 Fax: (780) 432-5630 > Optrics Engineering and FundSoft are divisions of Optrics Inc. > _ > Anti-virus & Anti-SPAM control solutions provided by www.Optrics.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] A lot of Porn Spam getting through.
Gonzo and I just blasted through them. Another campaign by the "mad lib porn spammers". Looks like the robots got most of it. Now they're pushing Huge Size DVD ... well, you know. I'll be looking for abstracts on them too. Thanks! _M On Wednesday, February 2, 2005, 4:15:02 PM, Chuck wrote: CS> I have been. CS> Chuck Schick CS> Warp 8, Inc. CS> (303)-421-5140 CS> www.warp8.com CS> -Original Message- CS> From: [EMAIL PROTECTED] CS> [mailto:[EMAIL PROTECTED] CS> On Behalf Of Pete McNeil CS> Sent: Wednesday, February 02, 2005 2:01 PM CS> To: Chuck Schick CS> Subject: Re: [sniffer] A lot of Porn Spam getting through. CS> On Wednesday, February 2, 2005, 3:09:27 PM, Chuck wrote: CS>> Anyone else seeing this? CS> Be sure to submit them. CS> _M CS> This E-Mail came from the Message Sniffer mailing list. For information and CS> (un)subscription instructions go to CS> http://www.sortmonster.com/MessageSniffer/Help/Help.html CS> This E-Mail came from the Message Sniffer mailing list. For CS> information and (un)subscription instructions go to CS> 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] Spam Storm Alert...
On Monday, January 31, 2005, 12:28:00 PM, Landry wrote: LW> Well, after a second look (reviewing the headers), it looks like the message LW> got hung-up in the convoluted mess of internal mail gateways that Siemens LW> maintains (which I have no control over). Sorry for the noise...! Whew! Thought I was slipping for a minute. 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[2]: [sniffer] Spam Storm Alert...
On Saturday, January 29, 2005, 9:15:23 PM, Glenn wrote: GR> This is question is a little off subject, but do you have any GR> recommendations for Imail queue manager settings? We are running Sniffer GR> with declude 1.82 under Imail 8.15 and the server seems to bog down GR> sometimes. It is likely that your system is being pushed to it's limits. While I don't have any recommendations for queue manager settings I can recommend the following to help ease performance issues (these things work here in the lab anyway... ymmv) * In Declude AV (if you use it) use: AVAFTERJM PRESCAN ON * Be sure you're using a persistent instance of Sniffer: http://www.sortmonster.com/MessageSniffer/Help/PersistentHelp.html * It often helps to run a DNS resolver on your MTA and use the loopback address (127.0.0.1) to attach to it. I recommend BIND. It sounds counterintuitive at first - since this is yet another program running on the server, however in practice I find that things go much faster this way... theoretically because: -- Using the loopback address _may_ allow your system to skip some of the network stack - particularly NIC drivers etc thus eliminating some hardware and network related system loads and resource contention. -- Using the DNS server on your MTA eliminates all network delays / queueing. * Have plenty of RAM in the system. * Be sure your storage system is regularly defragmented and that you have sufficient free space. NTFS "REALLY HATES" a crowded and/or fragmented drive. * Be sure your spool is on it's own physical drive(s) if possible. If you haven't done this already, you'd be surprised how much performance a cheap, fast hard drive can add to your MTA when dedicated to your spool. The spool is constantly being read and written for what amount to temporary files. In addition, files from the spool are frequently going to be rewritten in your mailbox directories. If both of these operations are on the same physical device then you are guaranteed to impose the drive's seek time (and related OS queue related delays) to the processing of each message because the two operations will consistently compete with each other for the physical position of the drive head. Also, this particular mix of activity can effectively defeat any caching the drive may have by exceeding it's capacity and causing frequent cache flushing. Separating these operations on different physical drives results in far less drive head movement and a dramatic increase in the effectiveness of caching mechanisms in each of the separate drive systems. ___ I'm sure there are many additional opinions and hints floating around on this list both in general and also specifically for Imail/Declude installations. Hope this helps, _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[2]: [sniffer] DMLP
On Friday, January 28, 2005, 7:42:54 PM, Goran wrote: GJ> OK I will ask. What is MDLP? Slowly but surely, the cat is peeking out of the bag. MDLP = Modular Declude Log Processing. It is an analysis tool and AutoTune AI for Declude that I've been working on for some time --- there are a number of users on this list who are on the beta list. The program is close to completion. You can peek at the analysis out from one of my test servers here (though the data is skewed quite a bit since this server gets almost exclusively spam): http://reports.microneil.com/mnr0mdlp.html At the present time the AI appears to be "sane" with regard to how it adjust the weights of the individual tests and I am watching it closely to see if it continues to be "sane". I hope we will be able to release version 1 of this soon, but I do not have a timetable yet. In addition to optionally tuning the weights in Declude's Global.cfg file, this program can produce a number of XML and CSV formatted summaries of a Declude log suitable for a input to your favorite database and a wide range of analysis. I am not taking additional beta testers right now except on a case by case basis. Hope this helps, _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: Re[2]: [sniffer] Sniffer seems to be causing false positives.
Pete: Thanks for looking. It was very strange because it was such varied messages from general correspondence, quotes. and personal correspondence. I put a little negative weight in for statefarm.com which should keep it from getting caught. Chuck Schick Warp 8, Inc. (303)-421-5140 www.warp8.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, January 19, 2005 7:05 PM To: Pete McNeil Subject: Re[2]: [sniffer] Sniffer seems to be causing false positives. On Wednesday, January 19, 2005, 9:02:02 PM, Pete wrote: PM> On Wednesday, January 19, 2005, 8:00:41 PM, Chuck wrote: CS>> It appears that emails from statefarm.com are all being failed by CS>> SNIFFER-OBFUSCATION code 61. It appears from multiple senders and CS>> to multiple recipient domains. Any thoughts?? PM> I will check though I doubt seriously that we would create this kind PM> of rule - - a show of hands says we all recognize statefarm. Most PM> likely this is an IP rule that got picked up by a robot, or perhaps PM> something incidental. PM> Please be sure to post a false positive report and if you can PM> identify the rule in your log files then you can add the ID as a PM> rule panic in your .cfg to alleviate the problem immediately while PM> we take the time to understand things further. Just to follow up --- there are no rules that contain "statefarm" - so we must be looking for something incidental. _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 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] Sniffer seems to be causing false positives.
On Wednesday, January 19, 2005, 9:02:02 PM, Pete wrote: PM> On Wednesday, January 19, 2005, 8:00:41 PM, Chuck wrote: CS>> It appears that emails from statefarm.com are all being failed by CS>> SNIFFER-OBFUSCATION code 61. It appears from multiple senders and to CS>> multiple recipient domains. Any thoughts?? PM> I will check though I doubt seriously that we would create this kind PM> of rule - - a show of hands says we all recognize statefarm. Most PM> likely this is an IP rule that got picked up by a robot, or perhaps PM> something incidental. PM> Please be sure to post a false positive report and if you can identify PM> the rule in your log files then you can add the ID as a rule panic in PM> your .cfg to alleviate the problem immediately while we take the time PM> to understand things further. Just to follow up --- there are no rules that contain "statefarm" - so we must be looking for something incidental. _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: Re[2]: [sniffer] Still having problems
put this on the logs page? -- Original Message -- From: Pete McNeil <[EMAIL PROTECTED]> Reply-To: sniffer@SortMonster.com Date: Sat, 8 Jan 2005 13:04:24 -0500 >On Saturday, January 8, 2005, 12:47:21 PM, Kirk wrote: > >KM> Is there any tool available with which to analyze sniffer logs to get any >KM> kind of count on the number of hits, etc? > >Here's one way > >http://www.sawmill.net/formats/Message_Sniffer.html > >_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 > __ Systems Support and Hosting Services by MicroNeil Research 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: Re[2]: [sniffer] Sniffer and SURBL
Thanks, Pete. I was thinking that Sniffer's l33t ninja skillz would be well-used for searching a large corpus of URIs, particularly the current bout of spammers you and I mentioned before Xmas (the ones that are specifying the domain name, not a URL, and which Sniffer is catching because of the consistent instructions, regardless of the dynamically changing domain names), as a URI filter might miss them because of obfuscation, or might miss the real payload. Sniffer would catch these URIs, because it only cares about tokenized text, not whether that text was detected in a URL. There would still be a place for both SURBL lookups and Sniffer in that scenario, because they are refreshed on different schedules and have independent spamtraps feeding them. I wasn't thinking about Sniffer incorporating a real-time lookup; I agree with your direction for the product. For the reason you cited, I'll go a little further and say that Sniffer would have to really break out in a new direction to be worth implementing a real-time lookup of some sort. Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Monday, January 10, 2005 4:58 PM To: Colbeck, Andrew Subject: Re[2]: [sniffer] Sniffer and SURBL On Monday, January 10, 2005, 7:17:29 PM, Andrew wrote: CA> Pete, I thought that you had said at one point that SortMonster CA> fetches one or more SURBL zones and incorporates those as spam data CA> for Message Sniffer? CA> It seems like a great idea to me. But then, from my distance, a lot CA> of things look like a good idea for someone else to implement! That's not exactly how it works - What we do is that our robots will look at some of the messages that hit our spamtraps and if they find a URI that looks like a good choice they will cross check it with SURBL. More often than not we've already got the URI coded from our manual work, but this robotic mechanism allows the rulebase to keep up minute by minute - and since the email triggering this work has come in through one of our spamtraps, it acts like an extra check - so those listings that we do have tend to be very solid. At some point we may bolt on some additional real-time lookups like SURBL etc... but we don't have plans for that just yet, and most installations already have these tools employed in other mechanisms they are running, so it would be redundant for us to add it - at least at this point. Hope this helps, _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 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] Sniffer and SURBL
On Monday, January 10, 2005, 7:17:29 PM, Andrew wrote: CA> Pete, I thought that you had said at one point that SortMonster fetches CA> one or more SURBL zones and incorporates those as spam data for Message CA> Sniffer? CA> It seems like a great idea to me. But then, from my distance, a lot of CA> things look like a good idea for someone else to implement! That's not exactly how it works - What we do is that our robots will look at some of the messages that hit our spamtraps and if they find a URI that looks like a good choice they will cross check it with SURBL. More often than not we've already got the URI coded from our manual work, but this robotic mechanism allows the rulebase to keep up minute by minute - and since the email triggering this work has come in through one of our spamtraps, it acts like an extra check - so those listings that we do have tend to be very solid. At some point we may bolt on some additional real-time lookups like SURBL etc... but we don't have plans for that just yet, and most installations already have these tools employed in other mechanisms they are running, so it would be redundant for us to add it - at least at this point. Hope this helps, _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[2]: [sniffer] Still having problems
On Monday, January 10, 2005, 11:34:44 AM, Matt wrote: M> I just wanted to add some stats that I thought might be of M> some use here. I gathered info on my block rates over the past M> three days and compared my Sniffer hits to them. There has been no M> measurable change to my system with an average of 96% of spam M> getting tagged by Sniffer. I'm at least not seeing any issues. Thanks for all of this. I don't think there are any SNF issues - save a current spam storm: 545 new rule already and the day is very young! Some systems see more spam than others, have special needs, or a lower tolerance for leakage. The bursting order of spam sources changes constantly -- so the spam received at any given system can at times see sudden bursts of new spam activity with no apparent cause. This can also happen any time a given system begins to receive new spam sufficiently early when compared to when we see it, or when an update can go out. There are many mechanisms like this in play all the time and they give rise to random peaks and valleys in spam flow on every system -- often these events go un-noticed, but occasionally it can seem as though the dam has burst. In this case I think that a combination of things are happening. Thankfully - a failure in the SNF system doesn't appear to be one of them. _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: Re[2]: [sniffer] Still having problems
At 12:48 AM 1/10/2005 -0500, you wrote: > >Earlier today I coded a number of rules that are based on some of the >subjects you submitted. > >If you can think of any black rules that you would feel comfortable >coding on your system please let me know and I will add them. For >example, you may be willing to accept single words or word pairs that >we could not normally code into the core rulebase. > >I am open to any ideas you have and I will help you to create rules >that meet your criteria. Thanks, I'll toss this around and see what particulars I can come up with. -- Kirk Mitchell-General Manager[EMAIL PROTECTED] Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net 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] Still having problems
On Monday, January 10, 2005, 12:38:45 AM, Kirk wrote: KM> I would like to attack this more aggressively. The increase we've seen in KM> spam getting through over the last week has brought on a dramatic increase KM> in customer complaints. What different approaches might I be able to take? I'm sorry to hear that. Spam is an increasing problem. I have adjusted your rulebase to the new rule strength threshold 0.5. Earlier today I coded a number of rules that are based on some of the subjects you submitted. If you can think of any black rules that you would feel comfortable coding on your system please let me know and I will add them. For example, you may be willing to accept single words or word pairs that we could not normally code into the core rulebase. I am open to any ideas you have and I will help you to create rules that meet your criteria. Hope this helps, _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: Re[2]: [sniffer] Still having problems
At 01:04 PM 1/8/2005 -0500, Pete McNeil wrote: >On Saturday, January 8, 2005, 12:47:21 PM, Kirk wrote: > >KM> Is there any tool available with which to analyze sniffer logs to get any >KM> kind of count on the number of hits, etc? > >Here's one way > >http://www.sawmill.net/formats/Message_Sniffer.html That's the only one I found in the searching I've done. I'll probably give the trial version a shot but can't see paying $139 for it. I was hoping maybe someone on the list had developed something, maybe a simple perl script or similar. -- Kirk Mitchell-General Manager[EMAIL PROTECTED] Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net 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] Still having problems
On Saturday, January 8, 2005, 12:47:21 PM, Kirk wrote: KM> Is there any tool available with which to analyze sniffer logs to get any KM> kind of count on the number of hits, etc? Here's one way http://www.sawmill.net/formats/Message_Sniffer.html _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[2]: [sniffer] Still having problems
On Saturday, January 8, 2005, 12:45:50 PM, Kirk wrote: KM> I've gone through some and haven't found any commonality by sender, etc, KM> but it seems that some are getting through that I'd have expected to get KM> triggered on the subject line alone. For example: KM> Tadalafil Soft Tabs - Great results! KM> ready for the sex life you dreamed about? KM> Buy medications from the net .Pay 1/2 the price of anywhere else KM> Need your prescripiton? We have them KM> VIAGRA $2.99Ljk5 KM> CARTIER, PIAGET, ROLEX Replicas - Expensive Look, Not Expensive Price We do create some filters on subjects, but we try to do that sparingly since they easily cause false positives. A couple of the subjects you've listed above might be in normal conversations on some lists (surprizing as that might be) so we avoid them. Also, many of these subjects change frequently during these campaigns - they coding estimates are that there are more than 50,000 variations on some of the ones you've listed--- and a generalized rule on the subject alone would open up the potential for false positives. That said, I have been coding complex rules for these - the analysis takes a bit longer, but the rules are coming. KM> I've sent numerous examples of each of these in the last week or so yet KM> messages with identical subject lines are still getting through classed as KM> LOW or CLEAN. This just doesn't seem to match the performance that I've KM> become accustomed to, which is why I started questioning whether or not I KM> may have messed up something at my end. Thanks for bringing this to our attention and please do keep pushing us and sending us samples. The more information we have the more quickly we can close in on a set of viable heuristics for these campaigns. _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[2]: [sniffer] Vircom Vopmail and Sniffer
On Friday, January 7, 2005, 6:34:15 AM, Phillip wrote: PC> Pete, PC> It does run from the command line, creates the log file. I didn't give it a PC> file to check so it gave and error so at least it does something. PC> For some reason it won't run the sniffer program from the batch file. PC> I put in a pause and ran it, it is returning an error code of 65 with no PC> file given when running it in the batch file. however it does not create a PC> log file. A result code of 65 indicates that the command line was incorrect. From your description this is most likely because you didn't provide a file. If you give it any text file to look at you will get past this error - and if it's working ok otherwise you will see a log file generated. http://www.sortmonster.com/MessageSniffer/Help/ResultCodesHelp.html PC> I have permissions on the file and the folder as loose as it gets, everyone PC> full control. still nothing. PC> I tried using CALL in front of the line and it gave me the same thing. CALL is not appropriate here. PC> Any ideas on why it wont run in a batch file? Been so long since I have PC> played with DOS, it is embarassing. It actually is running. It's just complaining that you didn't provide the file to scan when you launched your .bat file. That's actually good because it means we're getting somewhere. Pick a file and run the batch file at the command line with it. This should give you a log file. Once that's done, you just need to get VopMail to do the same thing. Hope this helps, _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[2]: [sniffer] Tweaking our rule base
On Thursday, January 6, 2005, 4:49:33 PM, Matt wrote: M> If this person is using Declude, Mdaemon or SpamAssassin, they might M> want to consider just using the blackholes.us zones that list every M> known IP delegated to certain countries that are known to have spam M> problems (in addition to some providers as well). This stuff can be set M> up as a simple IP4R tests and weighted accordingly in one's config. M> http://www.blackholes.us/ Agreed... this is a good starting point. Beyond that it can still sometimes be helpful to add rules that block matches to certain ISO character sets just in case the message comes from a non-foreign source. 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: Re[2]: [sniffer] reporting spam in bulk
I would be interested in the script if you are willing to share. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, January 05, 2005 7:50 PM To: Matt Subject: Re[2]: [sniffer] reporting spam in bulk On Wednesday, January 5, 2005, 7:16:50 PM, Matt wrote: M> Pete, M> I've been meaning to add a link to a script from within Killer M> WebMail that will allow me to report things to you with a single M> click. If I do this, am I correct in assuming that I should just use M> something like CDONTS to construct a mail and place the original M> source as the body? If not, what would be the preferred method? I think that should work fine for reporting spam. M> Note that I have original D*.SMD files for everything in the range of M> E-mails that I would consider reporting (using Declude's COPYFILE). M> Generally speaking, this would be a customized setup, although M> achievable by anyone with IMail and Declude. The hack to KWM is just M> some JavaScript to extract the spool data file name from my message M> headers that I insert (full headers must be turned on in Web mail), M> and this links to an ASP script on my server that handles everything M> else. This all sounds like a good idea. There are likely to be a few IMail/WebMail folks around for a while. This sounds like it's not for the technically timid though. 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 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
