Re: [Declude.JunkMail] Major SPF Kick!
Consider this to be constructive as I'm still on the fence about the whole thing. I've been seeing more and more zombie spam that is coming from the client computer using an address on their ISP, and sent through the ISP's mail server. I'm not seeing a lot of it, but it is most definitely happening. It's my belief that they are doing this in order to degrade the effectiveness of spam traps by getting ISP mail servers listed. There is certainly evidence of that in both SORBS and FIVETEN. Before it was generally things like ISP gateways used only for forwarding E-mail, like ATT's gateways which seem perma-listed in some RBL's, but now that trend is growing. I think that DSBLMULTI also suffers from this by marking the ISP's servers as multi-hop open relays for accepting E-mail from their own customers. I would imagine that SMTP Auth might mitigate this, but that's not generally how ISP's work. Spammers know that the safest IP is a big ISP mailserver's IP, because if you block that, you are primarily blocking legitimate traffic, and therefore it will avoid RBL detection for the most part. So despite the issues with human nature where individuals can post whatever blocks they want for SPF, and as has occurred, those blocks have been utilized unknowingly which listed client computer addresses on broadband and dial-up service providers, there are also issues with zombies relaying E-mail through legitimate mail hosts, and this could become a much bigger problem (I expect it to). Am I missing something here? Could SPF not only be ill advised, but also detrimental as a whole? Inquiring minds want to know. Matt Bill Landry wrote: AOL has signed on to SPF, and as a result I have seen a huge jump in the pass/fail entries in my spf.log today associated with aol.com addresses. Also, Postfix will be adding support for SPF in its soon to be released 2.1 version. These kind of things will certainly accelerate SPF adoption. Bill --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Scott, It took about 1 minute to figure out that this will be a very valuable test as I'm seeing similar hit rates. What matters most though is the type of thing that will FP, and what other tests will generally fail along with it. I'm guessing that an FP with CMDSPACE will probably also tend to FP with BADHEADERS, and I might need to balance that out. Could you describe that one FP that you found so that I know what to look out for? Was this an instance where some small-time newsletter sender was using the same bad software that the spammers use, or was it something else like some Web script? If it's really rare and tied to an X-Mailer, maybe we could counterbalance it with a filter??? Regardless, it appears that the FP rate of this thing will far out perform any other technical tests as well as the hit rate. That's HUGE! Thanks, Matt R. Scott Perry wrote: We've just added a new test to the latest interim release, called CMDSPACE. This one looks for spaces in SMTP commands where there shouldn't be any. It is catching about 75% of the spam to the spamtraps here, and since we started using it, only 1 of the approximately 500 legitimate E-mails that came in was caught. It looks like this could be a good test until spammers change their spamware. To use it, you need the latest interim release (from http://www.delude.com/interim ), and need to use the following line in your \IMail\Declude\global.cfg file to define the test: CMDSPACEcmdspacex x 8 0 (where 8 is the weight you want to assign to the test). -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
BADHEADERS will FP a whole lot more, even on Outlook and other Microsoft mailers if they don't include a To address, and it only hits about 35% of the time. With it being over 99% accurate, I still only score it at 40% of my hold weight, and that's what I'm applying to this test...to start. The difference here is that this hits almost every piece of spam coming into my system this morning. If Joe Developer messes up the SMTP commands, but manages to get other things right, then no problem, even if he messes up the headers and fails BADHEADERS as well, no problem, but if he also fails SPAMHEADERS, problem. What I can't afford to do is add weight to legitimate bulk mail because that's 95% of my FP's right now, so this is what I'm watching for primarily (BADHEADERS is also an issue with this sometimes). If something passes easily but FP's on this test, I'm not concerned, in fact, I may drop BADHEADERS another point and raise this one up depending on the results. It would help if others would report their FP's to the list considering that this is totally new functionality. I'm setting up a capture account for this test so that I can monitor everything that fails and doesn't get deleted by my system. Matt Jonathan wrote: To be honest, I'm not sure how a test like this could be safe at all. It seems like a good idea, but in my mind, there's just as good of chance of Joe Developer writing a listserv, mail component, or open source email app or such, as there is of Joe Dev writing a mass mailing tool. Both could be written by either novices or professionals -- both could make the same typos. The world doesn't run on Outlook Express. :) Hopefully some use in production will prove me wrong. It's a good idea, I'm just not sure how much we can rely on the everyone using perfectly-formatted stuff like that .. *shrugs* Jonathan At 05:06 AM 1/7/2004, you wrote: Scott, It took about 1 minute to figure out that this will be a very valuable test as I'm seeing similar hit rates. What matters most though is the type of thing that will FP, and what other tests will generally fail along with it. I'm guessing that an FP with CMDSPACE will probably also tend to FP with BADHEADERS, and I might need to balance that out. Could you describe that one FP that you found so that I know what to look out for? Was this an instance where some small-time newsletter sender was using the same bad software that the spammers use, or was it something else like some Web script? If it's really rare and tied to an X-Mailer, maybe we could counterbalance it with a filter??? Regardless, it appears that the FP rate of this thing will far out perform any other technical tests as well as the hit rate. That's HUGE! Thanks, Matt R. Scott Perry wrote: We've just added a new test to the latest interim release, called CMDSPACE. This one looks for spaces in SMTP commands where there shouldn't be any. It is catching about 75% of the spam to the spamtraps here, and since we started using it, only 1 of the approximately 500 legitimate E-mails that came in was caught. It looks like this could be a good test until spammers change their spamware. To use it, you need the latest interim release (from http://www.delude.com/interim ), and need to use the following line in your \IMail\Declude\global.cfg file to define the test: CMDSPACEcmdspacex x 8 0 (where 8 is the weight you want to assign to the test). -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] IP4 Tests
Yes. XBL integrates CBL now, and maybe more. Matt Kami Razvan wrote: Matt: Is CBL this: CBL:*:cbl.abuseat.org Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Wednesday, January 07, 2004 6:01 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] IP4 Tests BONDEDSENDER doesn't catch much, maybe 0.5% at best on my system, probably more like 0.2% though. I'm not getting anything on XBL, and I just found that the test entry returned 127.0.0.4 instead of the 2 in my config. That's not that I read on their site originally, but it now says to use that. XBL ip4rxbl.spamhaus.org127.0.0.480 Note: don't use SBL-XBL or CBL if you use XBL and SBL separately, which is advisable. Matt Markus Gufler wrote: BONDEDSENDERip4rquery.bondedsender.org 127.0.0.10-50 XBLip4rxbl.spamhaus.org127.0.0.280 Am I missing something or why I can't find nearly zero positive results in our logfile for this two tests? I've running this tests now for 7 days: BONDEDSENDER catches at max. 2 messages per day (from over 2500 incomming messages/day) XBL has never had any positive result. My entries in the global.cfg are exact as those above. Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Please share the config line, headers, and the server software involved between your users and your server (unless you and Scott are already dealing with this off-line). No problems thus far on my end, only 1 out of about 400 tagged has managed to avoid being deleted by my system. It was from a zombie. It's hitting about 62% of my total mail volume. Matt System Administrator wrote: on 1/7/04 6:35 AM, Matthew Bramble wrote: BADHEADERS will FP a whole lot more, Over 95% of the outgoing messages from our subscribers are failing the CMDSPACE test (75+ messages in about 50 minutes of use). The only pattern I can see is messages from IMail web are not failing the test. Greg --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Major Change in Declude Log File Format? Effects Reporting Applications?
Also, please add the score in on the low setting, preferrably at the beginning of the line. Note that this reduced my log file size by 80% :) Matt Andy Schmidt wrote: Hi Scott: With this latest build, the log file no longer has single line entries for each failed test? I don't have a big problem with that - but we need to make sure that the various makers of Declude Reporting applications (such as DLANALZYER) are made aware of it so that they can re-write their log-parsing! My log file entries now just look like this: 01/07/2004 09:23:36 Q1665125201ac31f9 BADHEADERS:5 HELOBOGUS:3 SPAMHEADERS:3 . Total weight = 11. 01/07/2004 09:23:36 Q1665125201ac31f9 Subject: Godfrey Rockefeller refill notification from medlinerx.com 01/07/2004 09:23:36 Q1665125201ac31f9 From: [EMAIL PROTECTED] To: [privacy/deleted] IP: 64.135.12.84 ID: 01/07/2004 09:23:36 Q1665125201ac31f9 BADHEADERS=WARN HELOBOGUS=WARN SPAMHEADERS=WARN WEIGHT10=BOUNCEONLYIFYOUMUST The biggest loss I see is for badheaders/spamheaders and other non-IP based test. The IP based stuff is easy to reconstruct from other sources - but the badheaders/spamheaders reason codes were helpful when investigating false-positive reports. 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 R. Scott Perry Sent: Tuesday, January 06, 2004 06:54 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] New CMDSPACE test in latest interim release We've just added a new test to the latest interim release, called CMDSPACE. This one looks for spaces in SMTP commands where there shouldn't be any. It is catching about 75% of the spam to the spamtraps here, and since we started using it, only 1 of the approximately 500 legitimate E-mails that came in was caught. It looks like this could be a good test until spammers change their spamware. To use it, you need the latest interim release (from http://www.delude.com/interim ), and need to use the following line in your \IMail\Declude\global.cfg file to define the test: CMDSPACEcmdspacex x 8 0 (where 8 is the weight you want to assign to the test). -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Second FP to report. Also, the last FP was from that company using software better associated with spamware than for legit server apps. This FP was automated from a server doing a small mail blast: Received: from nbc_cmg_srv1.xx [xx] by mx1.mailpure.com (SMTPD32-7.15) id AE7913B02A8; Wed, 07 Jan 2004 09:58:01 -0500 Message-ID: [EMAIL PROTECTED] newmsg.cgi?mbx=Main[EMAIL PROTECTED] From: [EMAIL PROTECTED] To: xx newmsg.cgi?mbx=Main[EMAIL PROTECTED] Subject: Daily Wake-Up Call Date: Wed, 7 Jan 2004 08:51:56 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_01BC2B74.89D1CCC0 X-MailPure: == X-MailPure: IPNOTINMX: Failed, IP is not listed in MX or A records (weight 0). X-MailPure: NOLEGITCONTENT: Failed, no legitimate content detected (weight 0). X-MailPure: HELOBOGUS: Failed, bogus connecting server name (weight 4). X-MailPure: CMDSPACE: Failed, improperly formatted SMTP commands (weight 4). X-MailPure: ATTACHMENT: Message failed ATTACHMENT test (line 8, weight -3) (weight capped at -3). X-MailPure: == X-MailPure: Spam Score: 5 X-MailPure: Scan Time: 09:58:19 on 01/07/2004 X-MailPure: Spool File: D1e79013b02a878a3.SMD X-MailPure: Server Name: nbc_cmg_srv1.xx X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: [xx] X-MailPure: == X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: == X-RCPT-TO: xx newmsg.cgi?mbx=Main[EMAIL PROTECTED] Status: U X-UIDL: 373475499 R. Scott Perry wrote: It took about 1 minute to figure out that this will be a very valuable test as I'm seeing similar hit rates. What matters most though is the type of thing that will FP, and what other tests will generally fail along with it. I'm guessing that an FP with CMDSPACE will probably also tend to FP with BADHEADERS, and I might need to balance that out. Actually, that's one reason why this test should be so useful. An E-mail should only fail both CMDSPACE and BADHEADERS if [1] the MUA and MTA are the same, and *seriously* broken (as is the case with spamware), or [2] the MUA and MTA are separate, but both broken. #1 is the case with some web mailers, but time should tell whether or not E-mail is likely to fail both tests. Could you describe that one FP that you found so that I know what to look out for? Was this an instance where some small-time newsletter sender was using the same bad software that the spammers use, or was it something else like some Web script? If it's really rare and tied to an X-Mailer, maybe we could counterbalance it with a filter??? It was sent with Lotus Notes, but connecting to the IP of their mailserver shows 220 SMTP Proxy Server Ready, so they are likely running a special proxy server. Interestingly, the only Google hits for SMTP Proxy Server Ready appear to be on servers run by spammers. :) Regardless, it appears that the FP rate of this thing will far out perform any other technical tests as well as the hit rate. That's HUGE! It does appear to be huge. Let's hope it really is, and that it lasts. :) -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Markus, Something is happening because you're also failing SPAMHEADERS on Scott's server. I think that's Outlook 2003. Scott??? If those #*$(#@ ruin our tests...grrr. Matt Markus Gufler wrote: Do you have a firewall that interferes with SMTP transactions (such as Cisco)? No, not under my control or with my knowledge. Is it possible that our bandwith provider can interfere in such a connection? Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
What's this from in your headers? Microsoft-Entourage/10.1.4.030702.0 Could it be this: http://www.microsoft.com/mac/products/entouragex/entouragex.aspx?pid=entouragex If so, maybe this is a Mac thing, or maybe this is a Microsoft and Eudora thing on the Mac??? Patterns??? Matt System Administrator wrote: on 1/7/04 9:39 AM, Matthew Bramble wrote: FP to report. Here's what I'm seeing. The Outlook, Outlook Express and Eudora programs are all on the same XP computer. New message from Outlook to me. Failure. Reply message from Outlook to me. Failure. New message from Outlook Express to me. Failure. Reply message from Outlook Express to me. Failure. New message from Eudora to me. No failure. Reply message from Eudora to me. No failure. New message from Outlook to Eudora forwarded to me. No failure. New message from Outlook to Outlook Express forwarded to me. Failure. Greg --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Another FP. This one also has the X-EM headers which is related to something most often used in spamware, though it appears to be commonly used for mailer software on legit companies. Received: from progressive.com [67.39.105.65] by mx1.mailpure.com with ESMTP (SMTPD32-7.15) id A5E08FC01DA; Wed, 07 Jan 2004 10:29:36 -0500 Received: from ([192.168.45.243]) by acmrcp03.progressive.com with SMTP ; Wed, 07 Jan 2004 10:24:29 -0500 (EST) Message-ID: [EMAIL PROTECTED] newmsg.cgi?mbx=Main[EMAIL PROTECTED] X-EM-Version: 4, 0, 0, 0 X-EM-Registration: #3193410514110A039430 From: WebTracker.Progressive.com [EMAIL PROTECTED] newmsg.cgi?mbx=Main[EMAIL PROTECTED] To: SAM DELL COLLISION CENTER xx newmsg.cgi?mbx=Main[EMAIL PROTECTED],,, ,,, ,,, ,Cc:,,, ,,, ,,, ,Subject: TOTALPRO - NEW REFERRAL Date: Wed, 7 Jan 2004 10:29:1 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SMTPExp-Version: 1, 0, 2, 10 X-SMTPExp-Registration: 3193410514110A039430 X-MailPure: == X-MailPure: IPNOTINMX: Failed, IP is not listed in MX or A records (weight 0). X-MailPure: BADHEADERS: Failed, non-RFC compliant headers [804e] (weight 4). X-MailPure: CMDSPACE: Failed, improperly formatted SMTP commands (weight 4). X-MailPure: == X-MailPure: Spam Score: 7 X-MailPure: Scan Time: 10:29:44 on 01/07/2004 X-MailPure: Spool File: D25e008fc01da6443.SMD X-MailPure: Server Name: progressive.com X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: acmrcp03.progressive.com [67.39.105.65] X-MailPure: == X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: == X-RCPT-TO: x newmsg.cgi?mbx=Main[EMAIL PROTECTED] Status: R X-UIDL: 373475502 R. Scott Perry wrote: Second FP to report. Also, the last FP was from that company using software better associated with spamware than for legit server apps. This FP was automated from a server doing a small mail blast: FYI, the important information for FPs on the CMDSPACE test is the software being used to send out the E-mail. Unlike almost all spam tests, this one relies on information in the SMTP envelope, so the headers are only useful to help identify the software causing the problem. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
4th FP, they're starting to flow now. This is the first personal E-mail, though I think it came by way of Exchange's Web mail if I'm not mistaken??? Received: from recreation.bombardier.com [207.236.181.3] by igaia.com with ESMTP (SMTPD32-7.15) id A9F2D92023A; Wed, 07 Jan 2004 10:46:58 -0500 Received: from ([172.16.41.250]) by vlironm1.recreation.bombardier. with ESMTP ; Wed, 07 Jan 2004 10:46:13 -0500 (EST) Received: by vlmsexc2.recreation.bombardier.com with Internet Mail Service (5.5.2653.19) id YYZ9TVH5; Wed, 7 Jan 2004 10:46:10 -0500 Message-ID: [EMAIL PROTECTED] newmsg.cgi?mbx=Main[EMAIL PROTECTED] From: [EMAIL PROTECTED] To: x newmsg.cgi?mbx=Main[EMAIL PROTECTED] Subject: SDi throttle bodies Date: Wed, 7 Jan 2004 10:46:08 -0500 Return-Receipt-To: [EMAIL PROTECTED] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-MailPure: == X-MailPure: NOLEGITCONTENT: Failed, no legitimate content detected (weight 0). X-MailPure: CMDSPACE: Failed, improperly formatted SMTP commands (weight 4). X-MailPure: == X-MailPure: Spam Score: 2 X-MailPure: Scan Time: 10:47:05 on 01/07/2004 X-MailPure: Spool File: D29f20d92023a4a93.SMD X-MailPure: Server Name: recreation.bombardier.com X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: recreation.bombardier.com [207.236.181.3] X-MailPure: == X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: == X-Declude-Date: 01/07/2004 15:46:08 [0] X-RCPT-TO: x newmsg.cgi?mbx=Main[EMAIL PROTECTED] Status: U X-UIDL: 373475503 R. Scott Perry wrote: Second FP to report. Also, the last FP was from that company using software better associated with spamware than for legit server apps. This FP was automated from a server doing a small mail blast: FYI, the important information for FPs on the CMDSPACE test is the software being used to send out the E-mail. Unlike almost all spam tests, this one relies on information in the SMTP envelope, so the headers are only useful to help identify the software causing the problem. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] New CMDSPACE test in latest interim release
Just a thought...if this is primarily a Microsoft thing, affecting several of their products, then maybe the pattern can be excluded. For the most part, WHITELIST AUTH should resolve issues with mail clients connecting directly to your server, but it's these Web scripts and Web mail programs that will prove to be more problematic. Matt Andy Schmidt wrote: Okay - so if it fails every Outlook 2003 user, it can only be used with a minimum weight. 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 R. Scott Perry Sent: Wednesday, January 07, 2004 10:25 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] New CMDSPACE test in latest interim release As with any test, it does have some false positives. But it appears that they are very low. How does it work? From my initial posting about the test: This one looks for spaces in SMTP commands where there shouldn't be any. Why it can be triggered by an message sent from Outlook 2003? Because Outlook 2003 is junk. :) There are several things that Outlook 2003 does that are not RFC-compliant. I'm guessing that soon lots of people will start whitelisting E-mail sent from Outlook 2003, and then soon after that spammers will add Outlook 2003 headers to their spams. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Existential crisis
Kami, If you're asking for a fool proof way to add a lot of points for randomized TLD's, then I don't think it can be done reliably with a lot of weight. You have to hit this from every end possible, and this is where custom filters come in. I can't think of current functionality that would allow for something more accurate though that could manage three pieces of data in the way that you are looking for. I don't think that's a total loss though. DYNAMIC, FOREIGN, TLD-EASTERNEUROPEAN, TLD-MIDDLEEASTERN would all hit this just based on 3 pieces of information that I can see here. On my system, that would be 90% of my hold weight, which isn't bad for just the HELO, MAILFROM and REVDNS. I'm not sure that you would want to add more points than that though because it's quite possible for all three things to have different TLD's, though less common that they are three different gTLD's. I separated out the TLD filters by region so that I could pick up on this stuff. You could potentially split them into 250 or so different files which would allow for you to catch all three :) Not very realistic though. I'm sure that functionality will be improved over time that will allow for a more exact test without the kludge of filters, but we've made a ton of progress in this department if you ask me. Maybe there are some other custom filters that could help with spammy body content or other things involving the headers. Most of the stuff that randomizes like this is from a zombie, and there's always something else going on there. Post the full message and let's tear it apart :) Matt Kami Razvan wrote: Hi; There has to be a way to identify this without much overhead.. == X-Note: Spam Score: 26 [BLOCKED ON 20+ DELETED ON 60+] X-Note: Scan Time: 13:21:32 on 01/07/2004 X-Note: Spool File: D4e220fc7018c094f.SMD X-Note: Server Name: skrzynka.pl X-Note: SMTP Sender: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-Note: Reverse DNS IP: cbl62-0-175-24.bb.netvision.net.il [62.0.175.24] X-Note: Recipient(s): * X-Note: Country Chain: ISRAEL-destination X-Note: == X-Note: This E-mail was scanned filtered by Declude [1.77i12] for SPAM virus. this is borderline (weight 26) - this email has not failed a single IP4R test. Reverse dns is IL, email ends with .ch and the HELO is .pl What are the chances for this? How can a legal email have so much existential crisis? Matt's TLD test gives this weight but there has to be a faster test to pick this up.. Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Strange Looking Headers
Not really garbled, though I'm not sure if it's compliant. =2E is the same thing as a period. I think they call this MIME encoding, though I'm not sure. I also see that they are marking the To, From and Subject as US-ASCII, which is totally useless, possibly non-compliant, and very, very spammy. I've seen other Declude tests fail with this E-mail component as well, BADHEADERS for instance, and maybe SPAMHEADERS as well. Based on this stuff, I would dump the product for fear of messages not getting delivered. Seriously. Matt Dan Geiser wrote: Hello, All, I have a question that's unrelated to DJM but related to e-mail. We do some web hosting for a handful of customers. One of our web hosting customers has a form on their web site which their web developers have set up to send an e-mail whenever the form is filled out. On our web server we have a e-mail component called JMail setup which creates and sends the e-mail. According to our customer, our customer's customer and our web developers, somewhere along the way the message is getting garbled text in the headers. Here's the header for an example message that they sent to me... - Date: Fri, 02 Jan 2004 09:51:37 -0500 From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: =?US-ASCII?Q?OSU_Bid_Information_Log_In_Information?= Sender: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Reply-to: [EMAIL PROTECTED] X-Mailer: JMail 4.3.1 by Dimac X-USER_IP: 128.146.195.238 X-Declude-Sender: [EMAIL PROTECTED] [199.218.9.36] X-Note: Sent from: [EMAIL PROTECTED] ([199.218.9.36]) X-Note: Sent from Reverse DNS: mail.nexustechgroup.com X-Note: This E-mail was scanned by Declude [1.75] for viruses. - I _sort of_ see what they mean. Although to me it doesn't look garbled. Just different. Specifically in the From, the Subject and the To. When the web site user fills out a form they are seeing this in the header of the confirmation mail that they receive. I personally don't think this is being sent in the original e-mail but instead is how the receipients e-mail client is choosing to display the e-mail message. Does anyone know what causes the above to occur? Thanks In Advance, Dan Geiser [EMAIL PROTECTED] --- Sign up for virus-free and spam-free e-mail with Nexus Technology Group http://www.nexustechgroup.com/mailscan --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Major Change in Declude Log File Format? Effects Reporting Applications?
Scott, Forgive me for being repetitive, I think that you might have missed this request. If you could add the total score in at the low setting, that would provide a critical piece that I think everyone would like to have without bloating the line excessively. If not, I can always use an different level of course. Thanks, Matt R. Scott Perry wrote: Is the log file going to stay in its current format (v1.77i12) or is it going to change again soon. I just don't want to waste my time figuring out this format only to have it change again. It changes to some extent in most interim releases (usually very minor, though). However, we do not expect any major changes in the near future (unless we go back to having the one-line-per-test in LOGLEVEL LOW, but I would prefer not to see that happen). --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Major Change in Declude Log File Format? Effects Reporting Applications?
Thanks again :) R. Scott Perry wrote: Forgive me for being repetitive, I think that you might have missed this request. If you could add the total score in at the low setting, that would provide a critical piece that I think everyone would like to have without bloating the line excessively. If not, I can always use an different level of course. I did miss that. :) For the next interim release, the line will begin with Tests failed [weight=X]: . -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Atriks - Pt.2
Forgive me for repeating myself on this one, but I'm a proponent of blocking outright on SBL. There's a good reason for spammers to be in their list, and it's not some community project where anyone and everyone makes nominations, so it's practically flawless. Another trick for Green Horse is the following lines in a custom filter somewhere: # Green Horse Corporation (SBL12495) BODY28CONTAINS/img/c.0/ BODY28CONTAINS/img/o.0/ BODY28CONTAINS/img/v.0/ This is just in case they break out into new address space. 28 is my delete weight plus Declude's negative weight tests (because they tend to get added in after custom filters and I use SKIPIFWEIGHT functionality). Matt Fritz Squib wrote: Amazing, I knew that I saw a lot more spam coming from individual cable/dsl modems, but I had no idea... http://www.spamhaus.org/SBL/sbl.lasso?query=SBL12495 http://groups.google.com/groups?scoring=dq=atriks.com+group:*abuse* Fritz Frederick P. Squib, Jr. Network Operations/Mail Administrator Citizens Telephone Company of Kecksburg http://www.wpa.net () ascii ribbon campaign - against html mail /\- against microsoft attachments --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] IP4 Tests
Just a quick follow up to this message. Today I removed DSBLMULTI after two days of testing. Seemingly they consider lots of ISP mail servers to be spam relays for inclusion in this list. I think I made the mistake in adding them before... DSBL is on the other hand very reliable IMO. Matt Matthew Bramble wrote: I fail on a weight of 10, only score the last hop, and use the following (see notes below, config updated yesterday for new weights and tests): BONDEDSENDERip4rquery.bondedsender.org 127.0.0.10-50 AHBL-RELAYSip4rdnsbl.ahbl.org127.0.0.2 40 AHBL-PROXIESip4rdnsbl.ahbl.org127.0.0.3 40 AHBL-SOURCESip4rdnsbl.ahbl.org127.0.0.4 50 AHBL-PROVISIONALip4rdnsbl.ahbl.org127.0.0.5 40 AHBL-FORMMAILip4rdnsbl.ahbl.org127.0.0.6 40 AHBL-DULip4rdnsbl.ahbl.org127.0.0.920 BLITZEDALLip4ropm.blitzed.org*70 BOGUSMXrhsblbogusmx.rfc-ignorant.org127.0.0.8 50 DSBLip4rlist.dsbl.org127.0.0.270 DSBLMULTIip4rmultihop.dsbl.org127.0.0.250 DSNrhsbldsn.rfc-ignorant.org127.0.0.2 10 FIVETEN-SPAMip4rblackholes.five-ten-sg.com 127.0.0.230 FIVETEN-BULKip4rblackholes.five-ten-sg.com 127.0.0.430 FIVETEN-MULTISTAGEip4rblackholes.five-ten-sg.com 127.0.0.540 FIVETEN-SPAMSUPPORTip4rblackholes.five-ten-sg.com 127.0.0.740 FIVETEN-MISCip4rblackholes.five-ten-sg.com 127.0.0.940 MAILPOLICE-BULKrhsblbulk.rhs.mailpolice.com 127.0.0.280 MAILPOLICE-PORNrhsblporn.rhs.mailpolice.com 127.0.0.280 NJABL-DYNABLOCKip4rdynablock.njabl.org 127.0.0.340 NJABL-RELAYSip4rdnsbl.njabl.org127.0.0.2 40 NJABL-DULip4rdnsbl.njabl.org127.0.0.3 20 NJABL-SOURCESip4rdnsbl.njabl.org127.0.0.4 70 NJABL-MULTIip4rdnsbl.njabl.org127.0.0.5 50 NJABL-FORMMAILip4rdnsbl.njabl.org 127.0.0.880 NJABL-PROXIESip4rdnsbl.njabl.org127.0.0.9 80 NOABUSErhsblabuse.rfc-ignorant.org 127.0.0.410 NOPOSTMASTERrhsblpostmaster.rfc-ignorant.org 127.0.0.310 ORDBip4rrelays.ordb.org*70 SBBLip4rsbbl.they.com127.0.0.240 SBLip4rsbl.spamhaus.org127.0.0.2280 SOLIDip4rdnsbl.solid.net127.0.0.2 50 SORBS-DULip4rdnsbl.sorbs.net127.0.0.10 30 SORBS-HTTPip4rdnsbl.sorbs.net127.0.0.2 60 SORBS-MISCip4rdnsbl.sorbs.net127.0.0.4 60 SORBS-SOCKSip4rdnsbl.sorbs.net127.0.0.3 60 SORBS-SPAMip4rdnsbl.sorbs.net127.0.0.6 40 SPAMCOPip4rbl.spamcop.net127.0.0.2 80 XBLip4rxbl.spamhaus.org127.0.0.280 I dropped ABHL-EXEMPT, a whitelist, because it tended to have ISP mail servers in it, and I definitely get a noticeable amount of spam from ISP mail servers and don't need to be giving them credit unless there is a problem. BONDEDSENDER was dropped to 1/10th of my original weight after I learned that they don't really have the best standards for listing companies, for instance, a mailing list/group site doesn't have to do confirmed memberships which has been a fairly common issue with abuse, and spam houses that lead a double life can still have certain IP's included as long as those IP's don't spam. In dropping them from 50 to 5, I haven't seen any FP's result, and I'm looking to remove them out of my configuration as the next change because I don't want to support something that is membership based in this sense (members have to pay for inclusion and post a small bond). I highly doubt they let in a measurable amount of spam, but I got very concerned when I saw Topica listed in both Spamhaus and Bonded Sender, and figured out that Spamhaus was correct because Topica leads a double life as a spam house, tpca.net for instance: http://www.senderbase.org/search?searchString=66.180.244.0%2F25 FIVETEN-SPAM, FIVETEN-BULK and SORBS-SPAM all have very common issues with false positives on ad related content and even some mail servers. I'm monitoring closely for an opportunity to drop
[Declude.JunkMail] OBFUSCATION v2.0.1 for JunkMail Pro v1.77i7+
I found that the OBFUSCATION filter can FP on UNICODE attachments (which are uncommon). The new version of this filter fixes this problem. Note that I'm only updating the version that uses functionality introduced and fully supported in JunkMail Pro v1.77i7 or higher. For users of the older versions of this filter you can fix the issue by adding the following line: BODY -8 CONTAINS begin 666 The 2.0.1 version of the filter that makes use of END, SKIPIFWEIGHT and MAXWEIGHT functionality can be downloaded from the following location: http://www.mailpure.com/software/decludefilters/obfuscation/Obfuscation_v2-0-1.zip Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Atriks - Pt.2
SPEWS and SBL are two opposite extremes. The only time that SBL will false positive is when they list a hosting company that primarily engages in providing facilities to spammers. For the most part, these hosting companies are only fronts that they use to avoid being fully listed. SBL doesn't ratchet up to larger blocks without proof of spamming from those blocks. SPEWS tactics are more so for intimidation of hosting companies when they do this. It's not that I disagree with intimidation of this type in general, but I wouldn't make use of it on my own server since my main job is to deliver good E-mail and not spammer intimidation. If a block of IP's gets onto SBL, the value of those IP's as a mail source is greatly diminished, and any legitimate company would take action to fix any problems that were impacting other customers. SBL will list only static sources and will go all the way down to a single IP on occasions. SBL should tag about 20% to 25% of your mail volume (if you have an average mix of traffic), and their FP rate should be 0.01% if not better (people do make mistakes). Note my rant about Topica which is listed in SBL. Topica would be blocked if you did this, but Topica also operates a spam network and uses hundreds and hundreds of domain names. I wouldn't be surprised to see them getting demographic information as well as valid addresses from the Topica site. This is kind of like protecting your users from something they aren't aware could happen. Topica is also a frequent source of spam from their lists because they don't confirm memberships, so spammers can just opt you in. It took me a while to figure out that SBL was correct on this one...but they are no doubt. Maybe someone else can chime in with their opinion on SBL. I'd be curious to see if anyone has ever seen a clear false positive from them. Matt Darrell LaRock wrote: How aggressive is SBL compared to SPEWS? I know with SPEWS they list a lot of adjacent net blocks of the spammers... Does SBL employ the same tactics? Darrell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Tuesday, January 06, 2004 6:59 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Atriks - Pt.2 Forgive me for repeating myself on this one, but I'm a proponent of blocking outright on SBL. There's a good reason for spammers to be in their list, and it's not some community project where anyone and everyone makes nominations, so it's practically flawless. Another trick for Green Horse is the following lines in a custom filter somewhere: # Green Horse Corporation (SBL12495) BODY28CONTAINS/img/c.0/ BODY28CONTAINS/img/o.0/ BODY28CONTAINS/img/v.0/ This is just in case they break out into new address space. 28 is my delete weight plus Declude's negative weight tests (because they tend to get added in after custom filters and I use SKIPIFWEIGHT functionality). Matt Fritz Squib wrote: Amazing, I knew that I saw a lot more spam coming from individual cable/dsl modems, but I had no idea... http://www.spamhaus.org/SBL/sbl.lasso?query=SBL12495 http://groups.google.com/groups?scoring=dq=atriks.com+group:*abuse* Fritz Frederick P. Squib, Jr. Network Operations/Mail Administrator Citizens Telephone Company of Kecksburg http://www.wpa.net () ascii ribbon campaign - against html mail /\- against microsoft attachments --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Two small bugs
Scott, Virus Bug == The first bug is more straightforward, however it is related to Declude Virus, so please forgive me for not joining that group. In an E-mail that was forwarded from monstor.com, it tripped on a banned extension of .com because a cookie reference was attached by Outlook Express as follows: --=_NextPart_000_0001_01C3D1D2.DEDBF400 Content-Type: application/octet-stream; name=nojavascriptdcssip=jobsearch.monster.com Content-Transfer-Encoding: base64 Content-Location: http://cookie.monster.com/DCS03_6D4Q/njs.gif?dcsuri=/nojavascriptdcssip=jobsearch.monster.com R0lGODlhAQABAIAAAP8A/wAAACH5BAEALAABAAEAAAICRAEAOw== --=_NextPart_000_0001_01C3D1D2.DEDBF400-- I'm not sure if there is anything that can be done about this easily, but it was legitimate, and the attachment wasn't an executable, just a cookie. This is the first time that I have ever seen such a thing, so I'm sure it's rare, and maybe a bug with Outlook where it gets confused and attaches cookies coded this way thinking they are COM files??? JunkMail Bug == The small bug with JunkMail is as follows. I've seen the following several times across a number of days with at least v1.77i7 and v1.77i10. I'm using the warn action and it always shows up with the same recipient (%ALLRECIPS%) repeated at least three or four times. The first example is unique, and the last three examples are from a dictionary attack coming from one spammer sent to addresses that never existed on the same domain. The X-MailPure: RECIPIENTS line is related to a weightrange test so that it only displays the recipients when it fails. The IPNOTINMX test generally shows up first, but appears below that line when this happens along with the associated errors. Another thing related is the fact that I have a colon in the WARN action for RECIPIENTS listed with a colon, but it always appears with a space then dash in every message. Here's how that is defined: - Global.cfg - HIGH-RECIPSweightrangexx1024 - $Default$.junkmail - HIGH-RECIPSWARN X-MailPure: RECIPIENTS: %ALLRECIPS% This is not a big deal to me, but I thought that I would let you know about it. Four examples follow: Received: from mail.com [216.234.126.149] by domain.tld (SMTPD32-7.15) id A570704020A; Tue, 06 Jan 2004 10:34:08 -0500 Reply-To: [EMAIL PROTECTED] From: BPD [EMAIL PROTECTED] Subject: [23] Sales Leads --$1,525 Savings Date: Tue, 6 Jan 2004 10:34:23 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1251 Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600. X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600. Message-Id: [EMAIL PROTECTED] X-MailPure: == X-MailPure: NJABL-DYNABLOCK: Failed, listed in dynablock.njabl.org (weight 4). X-MailPure: NOABUSE: Failed, listed in abuse.rfc-ignorant.org (weight 1). X-MailPure: SORBS-DUL: Failed, listed in dnsbl.sorbs.net (weight 3). X-MailPure: SPAMCOP: Failed, listed in bl.spamcop.net (weight 8). X-MailPure: IPNOTINMX: Failed, IP is not listed in MX or A records (weight 0). X-MailPure: NOLEGITCONTENT: Failed, no legitimate content detected (weight 0). X-MailPure: CONCEALED: Failed, concealed message (weight 1). X-MailPure: BADHEADERS: Failed, non-RFC compliant headers [840a] (weight 4). X-MailPure: WORDFILTER-SUBJECT: Message failed WORDFILTER-SUBJECT test (line 63, weight 2). X-MailPure: RECIPIENTS - [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] X-MailPure: IPNOTINMX: Failed, IP is noX-MailPure: IPNOTINMX: Failed, no legitimate content detected (weight 0). X-MailPure: [Unknown Var]TESTNAME X-MailPure: IPNOTINMX: Failed, IP is noX-MailPure: [Unknown Var]TESTNAME X-MailPure: [Unknown Var] sign in the SMTP From address (weight 2). X-MailPure: == X-MailPure: Spam Score: 23 X-MailPure: Scan Time: 10:34:15 on 01/06/2004 X-MailPure: Spool File: Dd5700704020a2dd9.SMD X-MailPure: Server Name: mail.com X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: 3639246484.mi.dial.hexcom.net [216.234.126.149] X-MailPure: == X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: == X-Declude-Date: 01/06/2004 15:34:23 [0] X-RCPT-TO: [EMAIL PROTECTED] Status: R X-UIDL: 372975289 From [EMAIL PROTECTED] Tue Jan 06 09:35:58 2004 Received: from ecardica.net [66.246.175.2] by domain.tld (SMTPD32-7.15) id A7C4324022A; Tue, 06 Jan 2004
Re: [Declude.JunkMail] IP4 Tests
I fail on a weight of 10, only score the last hop, and use the following (see notes below, config updated yesterday for new weights and tests): BONDEDSENDERip4rquery.bondedsender.org 127.0.0.10-50 AHBL-RELAYSip4rdnsbl.ahbl.org127.0.0.240 AHBL-PROXIESip4rdnsbl.ahbl.org127.0.0.3 40 AHBL-SOURCESip4rdnsbl.ahbl.org127.0.0.4 50 AHBL-PROVISIONALip4rdnsbl.ahbl.org127.0.0.5 40 AHBL-FORMMAILip4rdnsbl.ahbl.org127.0.0.6 40 AHBL-DULip4rdnsbl.ahbl.org127.0.0.920 BLITZEDALLip4ropm.blitzed.org*70 BOGUSMXrhsblbogusmx.rfc-ignorant.org127.0.0.8 50 DSBLip4rlist.dsbl.org127.0.0.270 DSBLMULTIip4rmultihop.dsbl.org127.0.0.250 DSNrhsbldsn.rfc-ignorant.org127.0.0.210 FIVETEN-SPAMip4rblackholes.five-ten-sg.com 127.0.0.230 FIVETEN-BULKip4rblackholes.five-ten-sg.com 127.0.0.430 FIVETEN-MULTISTAGEip4rblackholes.five-ten-sg.com 127.0.0.540 FIVETEN-SPAMSUPPORTip4rblackholes.five-ten-sg.com 127.0.0.740 FIVETEN-MISCip4rblackholes.five-ten-sg.com 127.0.0.940 MAILPOLICE-BULKrhsblbulk.rhs.mailpolice.com 127.0.0.280 MAILPOLICE-PORNrhsblporn.rhs.mailpolice.com 127.0.0.280 NJABL-DYNABLOCKip4rdynablock.njabl.org 127.0.0.340 NJABL-RELAYSip4rdnsbl.njabl.org127.0.0.2 40 NJABL-DULip4rdnsbl.njabl.org127.0.0.320 NJABL-SOURCESip4rdnsbl.njabl.org127.0.0.4 70 NJABL-MULTIip4rdnsbl.njabl.org127.0.0.5 50 NJABL-FORMMAILip4rdnsbl.njabl.org 127.0.0.880 NJABL-PROXIESip4rdnsbl.njabl.org127.0.0.9 80 NOABUSErhsblabuse.rfc-ignorant.org 127.0.0.410 NOPOSTMASTERrhsblpostmaster.rfc-ignorant.org 127.0.0.310 ORDBip4rrelays.ordb.org*70 SBBLip4rsbbl.they.com127.0.0.240 SBLip4rsbl.spamhaus.org127.0.0.2280 SOLIDip4rdnsbl.solid.net127.0.0.250 SORBS-DULip4rdnsbl.sorbs.net127.0.0.1030 SORBS-HTTPip4rdnsbl.sorbs.net127.0.0.260 SORBS-MISCip4rdnsbl.sorbs.net127.0.0.460 SORBS-SOCKSip4rdnsbl.sorbs.net127.0.0.3 60 SORBS-SPAMip4rdnsbl.sorbs.net127.0.0.640 SPAMCOPip4rbl.spamcop.net127.0.0.280 XBLip4rxbl.spamhaus.org127.0.0.280 I dropped ABHL-EXEMPT, a whitelist, because it tended to have ISP mail servers in it, and I definitely get a noticeable amount of spam from ISP mail servers and don't need to be giving them credit unless there is a problem. BONDEDSENDER was dropped to 1/10th of my original weight after I learned that they don't really have the best standards for listing companies, for instance, a mailing list/group site doesn't have to do confirmed memberships which has been a fairly common issue with abuse, and spam houses that lead a double life can still have certain IP's included as long as those IP's don't spam. In dropping them from 50 to 5, I haven't seen any FP's result, and I'm looking to remove them out of my configuration as the next change because I don't want to support something that is membership based in this sense (members have to pay for inclusion and post a small bond). I highly doubt they let in a measurable amount of spam, but I got very concerned when I saw Topica listed in both Spamhaus and Bonded Sender, and figured out that Spamhaus was correct because Topica leads a double life as a spam house, tpca.net for instance: http://www.senderbase.org/search?searchString=66.180.244.0%2F25 FIVETEN-SPAM, FIVETEN-BULK and SORBS-SPAM all have very common issues with false positives on ad related content and even some mail servers. I'm monitoring closely for an opportunity to drop these test scores further or even altogether. Some of these have also cheated by adding in all of China to their blacklists. Essentially, the higher the score, the more reliable the test is. MAILPOLICE and SPAMCOP are at 80% of my hold weight, and they are seen as unreliable, however they score a ton of traffic and don't tend
Re: [Declude.JunkMail] Message Not Processed by Declude
Burzin, My experience is that this happens while the services are shutting down and not while they are coming back up. I don't think there is anything that you can do except to contact IMail. I'm using IMail 7.15r3, but this also apparently (hearsay) happens with IMail 8.05 still, though they appear to have fixed an issue where the queue would steal E-mail that was being processed in that latest release. Matt Burzin Sumariwalla wrote: Hi, I received an email that appears not to have been scanned by Declude. I checked the DecMMDD.log and the SysMMDD.txt logs. I think this happened because of a scheduled reboot of the server. Short of not rebooting the server, should I stop SMTP and Queue Manager prior to reboot in order to prevent a similar occurrence? Thanks, Burzin -- Burzin Sumariwalla Phone: (314) 994-9411 x291 [EMAIL PROTECTED] Fax: (314) 997-7615 Pager: (314) 407-3345 Networking and Telecommunications Manager Information Technology Services St. Louis County Library District 1640 S. Lindbergh Blvd. St. Louis, MO 63131 --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- === Matthew S. Bramble President and Technical Coordinator iGaia Incorporated, Operator of NYcars.com --- Office Phone: (518) 862-9042 Cellular: (518) 229-3375 Fax: (518) 862-9044 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] === --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] attachments
Check out my GIBBERISH filter for a bunch of counterbalances that are used to detect base64 and UNICODE attachments or other things that use base64 encoding, and disable the filter when found. Alternatively, when you have short words, follow them by a space. Base64 encoding doesn't utilize spaces. If you really care about these words, also list them with periods and commas, but don't list something this short without something following it unless you score it very low and have no problems. Words that are longer than 5 characters should rarely on base64. I have a filter that looks for MIME types and credits a few points for certain kinds (not JPEG's, but applications for instance). It's only there just in case and because I've yet to see any issues since spammers don't attach applications. Matt DLAnalyzer Support wrote: Dan, One problem I have is that when Declude Junkmail processes a message that has attachments it process the attachment how it was encoded typically base 64 (of couse assuming it is under the limit of what declude scans). When you have a filter with a small word like c u m or s e x it tends to be easily triggered in the base64 encoding. I asked this question a while back if there was an easy way to detect attachments to possibly apply a little reverse weight, but never really got anything back concrete. Darrell Dan Geiser writes: Scan attachments? Since when does Declude JunkMail scan attachments? Dan [EMAIL PROTECTED] - Original Message - From: Gene Head [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 05, 2004 1:34 PM Subject: [Declude.JunkMail] attachments Is there any way to not scan attachments? Most of my false positives are all emails with spreadsheets, word docs... as attachments. Thanks Gene --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- Sign up for virus-free and spam-free e-mail with Nexus Technology Group http://www.nexustechgroup.com/mailscan --- Sign up for virus-free and spam-free e-mail with Nexus Technology Group http://www.nexustechgroup.com/mailscan --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. Check Out DLAnalyzer a comprehensive reporting tool for Declude Junkmail Logs - http://www.dlanalyzer.com --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- === Matthew S. Bramble President and Technical Coordinator iGaia Incorporated, Operator of NYcars.com --- Office Phone: (518) 862-9042 Cellular: (518) 229-3375 Fax: (518) 862-9044 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] === --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam?
I think that Markus is mostly on the same page as I am on this issue. So far today, I have managed to catch 22 bounces from a Joe Job on one customer's account that started late last night, and this is only what my server caught due to the bounces containing the original content that tripped my filters. The previous one seems to have died down. The one that's going on right now can be stopped by killing messages handled by the nobody alias since this one uses a fake address on my customer's domain. The issue with writing a filter for this is that it might be very hard to just target undeliverable messages due to spam is that it would probably be impossible to target just one subset as opposed to all of it. I'm thinking that I should write a filter for basically all bounces and virus notifications, and upon request, use a ROUTETO action (or whatever is appropriate) in the domain specific file, so that these messages are delivered to a sub-directory to where we are placing their held spam. I'm also definitely going to start redirecting unaddressable stuff to a sub-directlry by default as several of these Joe Jobs have used fake addresses, and that will take care of the problem. So the course of action will be: 1) Give a choice to redirect the nobody alias to a sub-directory (for local accounts only). 2) Give a choice to have a filter redirect system generated messages to a sub-directory. I would prefer not to have to turn this stuff off and on on a regular basis, so we'll see how receptive my clients are to this. Matt Markus Gufler wrote: my customers are looking to me for a solution, imperfect as it may be in the end. I'm not by far sure about what to do. Matt, In this case maybe it's a solution to define a separated filter file (BLOCKBOUNCES) and put in this filter file as much bounce error strings as you can find. Then if a customer asks you if it's possible to block all this bounces you can explain him that this is possible, but this can also block real error messages. If your customer agree's you can create a per-user or per-domain junkmail file that does something with it. (add weight, block, routeto, ...) Maybe it would be an idea to create something between John's Autowhite and Scott's Hijack: Hold any messages identified as NDR in a separated user directory. Then requeue them only if there are not more then X such messages in a certain time range. This would allow regular error reports going trough and dinamically filter all of them during Joe-Job periods. Maybe a problem can occur if a customer sends out a large number of e-mails and there are several bounces. But if this happens I assume that the addresses was not aquired regulary ;-) Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam?
With about 60 domains currently, I'm seeing these on a regular basis now and it's been steadily increasing, so I expect it to get worse. I believe that I have also seen spam sent with some error information forged, probably to bypass filters, so I definitely don't want to whitelist it. If there's content in there that fails my filters, then it's good that I catch the bounce because it's almost definitely spam related. I don't have any filters currently set up for bounces, just a few related to the SoBig outbreak which aren't hitting on these messages. The one guy getting Joe Jobbed today is now up to 34 bounces from just four asian domains, and that's only what I'm catching based on them returning the original content, and they would be passing if these were being bounced by senders that don't fail my FOREIGN filter because they score very low for my hold. He could be getting hundreds of these just today. I wouldn't be surprised if I get a call about this one on Monday, thankfully he's a friend of mine and won't blame me :) The Joe Job from last week which is still winding down was passing through my server without getting caught at all. It was being sent to the person's contact record for their domain name registration, and it's configured as an off-server alias in IMail. I'm wondering if spam blocking works for this without me setting up a separate directory under Declude??? I'll have to test that out, seems strange that when he forwarded them back to me they were caught, but not caught when they were coming through my system. I'm surprised that I haven't been hearing more people talking about this issue. Matt Markus Gufler wrote: An idea: Unfortunately NDRs are somewhat of undefined that it's not a general solution, but why not block NDRs (only during rush hours) and whitelist NDRs containing the original header with some declude specific X-Header lines? Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Saturday, January 03, 2004 6:49 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? I think that Markus is mostly on the same page as I am on this issue. So far today, I have managed to catch 22 bounces from a Joe Job on one customer's account that started late last night, and this is only what my server caught due to the bounces containing the original content that tripped my filters. The previous one seems to have died down. The one that's going on right now can be stopped by killing messages handled by the nobody alias since this one uses a fake address on my customer's domain. The issue with writing a filter for this is that it might be very hard to just target undeliverable messages due to spam is that it would probably be impossible to target just one subset as opposed to all of it. I'm thinking that I should write a filter for basically all bounces and virus notifications, and upon request, use a ROUTETO action (or whatever is appropriate) in the domain specific file, so that these messages are delivered to a sub-directory to where we are placing their held spam. I'm also definitely going to start redirecting unaddressable stuff to a sub-directlry by default as several of these Joe Jobs have used fake addresses, and that will take care of the problem. So the course of action will be: 1) Give a choice to redirect the nobody alias to a sub-directory (for local accounts only). 2) Give a choice to have a filter redirect system generated messages to a sub-directory. I would prefer not to have to turn this stuff off and on on a regular basis, so we'll see how receptive my clients are to this. Matt Markus Gufler wrote: my customers are looking to me for a solution, imperfect as it may be in the end. I'm not by far sure about what to do. Matt, In this case maybe it's a solution to define a separated filter file (BLOCKBOUNCES) and put in this filter file as much bounce error strings as you can find. Then if a customer asks you if it's possible to block all this bounces you can explain him that this is possible, but this can also block real error messages. If your customer agree's you can create a per-user or per-domain junkmail file that does something with it. (add weight, block, routeto, ...) Maybe it would be an idea to create something between John's Autowhite and Scott's Hijack: Hold any messages identified as NDR in a separated user directory. Then requeue them only if there are not more then X such messages in a certain time range. This would allow regular error reports going trough and dinamically filter all of them during Joe-Job periods. Maybe a problem can occur if a customer sends out a large number of e-mails and there are several bounces
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? spam? spam?
Oh, BTW, IMail generated NDR's don't pass through Declude (I believe), so my hosted accounts would still get these for locally sent E-mail just as long as long as they are using my SMTP server (not the case when ISP's block outgoing port 25), and the receiving server rejects the message at the HELO, which doesn't happen with larger ISP's that gateway without address verification, or some other types of bounces possibly (like account full). Matt Markus Gufler wrote: An idea: Unfortunately NDRs are somewhat of undefined that it's not a general solution, but why not block NDRs (only during rush hours) and whitelist NDRs containing the original header with some declude specific X-Header lines? Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Saturday, January 03, 2004 6:49 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? I think that Markus is mostly on the same page as I am on this issue. So far today, I have managed to catch 22 bounces from a Joe Job on one customer's account that started late last night, and this is only what my server caught due to the bounces containing the original content that tripped my filters. The previous one seems to have died down. The one that's going on right now can be stopped by killing messages handled by the nobody alias since this one uses a fake address on my customer's domain. The issue with writing a filter for this is that it might be very hard to just target undeliverable messages due to spam is that it would probably be impossible to target just one subset as opposed to all of it. I'm thinking that I should write a filter for basically all bounces and virus notifications, and upon request, use a ROUTETO action (or whatever is appropriate) in the domain specific file, so that these messages are delivered to a sub-directory to where we are placing their held spam. I'm also definitely going to start redirecting unaddressable stuff to a sub-directlry by default as several of these Joe Jobs have used fake addresses, and that will take care of the problem. So the course of action will be: 1) Give a choice to redirect the nobody alias to a sub-directory (for local accounts only). 2) Give a choice to have a filter redirect system generated messages to a sub-directory. I would prefer not to have to turn this stuff off and on on a regular basis, so we'll see how receptive my clients are to this. Matt Markus Gufler wrote: my customers are looking to me for a solution, imperfect as it may be in the end. I'm not by far sure about what to do. Matt, In this case maybe it's a solution to define a separated filter file (BLOCKBOUNCES) and put in this filter file as much bounce error strings as you can find. Then if a customer asks you if it's possible to block all this bounces you can explain him that this is possible, but this can also block real error messages. If your customer agree's you can create a per-user or per-domain junkmail file that does something with it. (add weight, block, routeto, ...) Maybe it would be an idea to create something between John's Autowhite and Scott's Hijack: Hold any messages identified as NDR in a separated user directory. Then requeue them only if there are not more then X such messages in a certain time range. This would allow regular error reports going trough and dinamically filter all of them during Joe-Job periods. Maybe a problem can occur if a customer sends out a large number of e-mails and there are several bounces. But if this happens I assume that the addresses was not aquired regulary ;-) Markus --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? spam? spam?
Matthew Bramble wrote: I'm wondering if spam blocking works for this without me setting up a separate directory under Declude??? I'll have to test that out, seems strange that when he forwarded them back to me they were caught, but not caught when they were coming through my system. FYI, it does get scanned. I just figured out though that there were 5 different local domains getting Joe Jobbed last week though...at least 5 that is. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? spam? spam? spam? spam?
That ain't all of it by far actually. A very common one is also mailer-daemon@, however these are often customized, for instance [EMAIL PROTECTED], or bounce@, postmaster@, etc. To have a complete filter, you would need to figure out the body text that is unique to each of the mail servers and some ISP's as well. Time to start testing. This is problematic because a good filter for this can't FP on legit E-mail, and you can't make use of weighting for it to work if you are going to try to put this stuff in a sub-directory. Matt John Tolmachoff (Lists) wrote: I'm surprised that I haven't been hearing more people talking about this issue. I have been seeing it, but have been extremely busy with other stuff. Right now, those are being caught to HOLD with filtering on MAILFROM CONTAINS . John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam?
John, let me correct myself. The MAILFROM does in fact most always end up being the null sender (RFC compliant I believe). I'll share what I can find if in fact I can get something to work. I had IMail refuse null senders for a very long time until late Summer, but then I noticed that my system didn't handle all of the bounces itself (I knew much less back then). Now I'm wondering if I should have just left it off :) Matt John Tolmachoff (Lists) wrote: Well, I have not seen a full blown joe job yet, but it does need to be looked into. My problem, time. There is none. :(( John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Saturday, January 03, 2004 3:44 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam? spam? spam? spam? spam? spam? spam? spam? That ain't all of it by far actually. A very common one is also mailer-daemon@, however these are often customized, for instance [EMAIL PROTECTED], or bounce@, postmaster@, etc. To have a complete filter, you would need to figure out the body text that is unique to each of the mail servers and some ISP's as well. Time to start testing. This is problematic because a good filter for this can't FP on legit E-mail, and you can't make use of weighting for it to work if you are going to try to put this stuff in a sub-directory. Matt John Tolmachoff (Lists) wrote: I'm surprised that I haven't been hearing more people talking about this issue. I have been seeing it, but have been extremely busy with other stuff. Right now, those are being caught to HOLD with filtering on MAILFROM CONTAINS . John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Another scam
The payload on this goes to a site that pops up a window using Zap The Ding Bat URL obfuscation to make the URL look like it is the real Citibank site. Very dangerous and because it's being redirected on that site, you can't catch the technique in the E-mail. I contacted the hosting provider as a community service. Matt John Tolmachoff (Lists) wrote: I wonder how many people will actually fall for this: --=_579b51922d72e436946615fa16088dbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --=_579b51922d72e436946615fa16088dbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable body bgcolor=3D#FF text=3D#00 DIVDear Citibank Member,/DIV= DIVBRThis email was sent by the Citibank server to verify your E-mailB= Raddress. You must complete this process by clicking on the linkBRbelow = and entering in the small window your Citibank ATM/DebitBRCard number and= PIN that you use on ATM.BRThis is done for your protection -- because so= me of our membersBRno longer have access to their email addresses and we = mustBRverify it./DIV DIVBRTo verify your E-mail address and access your bank account,BRcli= ck on the link below:/DIV DIVBRA href=3Dhttp://65.246.58.14/baluci/scripts/email_verify.htm;ht= tps://web.da-us.citibank.com/signin/citifi/scripts/email_verify.jsp/A/DI= V DIVBR-/DIV DIVThank you for using Citibank/DIV DIV-/DIV /body --=_579b51922d72e436946615fa16088dbb-- John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Another scam
The site's down now. The hosting provider said it was probably signed up with a stolen credit card. He had it down within just a minute of me sending the message. Good deed done for the day :) Matt Matthew Bramble wrote: The payload on this goes to a site that pops up a window using Zap The Ding Bat URL obfuscation to make the URL look like it is the real Citibank site. Very dangerous and because it's being redirected on that site, you can't catch the technique in the E-mail. I contacted the hosting provider as a community service. Matt John Tolmachoff (Lists) wrote: I wonder how many people will actually fall for this: --=_579b51922d72e436946615fa16088dbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --=_579b51922d72e436946615fa16088dbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable body bgcolor=3D#FF text=3D#00 DIVDear Citibank Member,/DIV= DIVBRThis email was sent by the Citibank server to verify your E-mailB= Raddress. You must complete this process by clicking on the linkBRbelow = and entering in the small window your Citibank ATM/DebitBRCard number and= PIN that you use on ATM.BRThis is done for your protection -- because so= me of our membersBRno longer have access to their email addresses and we = mustBRverify it./DIV DIVBRTo verify your E-mail address and access your bank account,BRcli= ck on the link below:/DIV DIVBRA href=3Dhttp://65.246.58.14/baluci/scripts/email_verify.htm;ht= tps://web.da-us.citibank.com/signin/citifi/scripts/email_verify.jsp/A/DI= V DIVBR-/DIV DIVThank you for using Citibank/DIV DIV-/DIV /body --=_579b51922d72e436946615fa16088dbb-- John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] CONSECUTIVECHAR test!
It also won't catch things like: Your Amazon.com order has shipped (#101-4385494-1223513) or ORDER NO.B1093613-RFGDEF-01 HAS BEEN SHIPPED OUT The last thing that I want to do is FP on ecommerce things. There's some of this stuff with all consonants as well, in very long strings. I'm not saying it would be a bad test because it wouldn't catch certain things, I'm saying it would be a unreliable test because of what it might catch which isn't intended. Non-gibberish strings like the one in your example are also fairly uncommon. There are other obfuscation techniques though that use punctuation to separate letters which would probably be fairly safe to target as long as you only included only counted them when they are surrounded on both sides by letters. Something like the following: E.N.L.A^R.G.E A derivative of the COMMENTS test for the subject. The only issue here is that this stuff is otherwise easy to target with a bunch of other filters and therefore it almost never avoids deletion on my system. I'm watching this one though because it could become much worse. With the new functionality it's also possible to write a filter for this although it's a bit kludgey. Matt John Tolmachoff (Lists) wrote: GIBBERSHSUB would not catch things like BestProductEver and ImportantPleaseReadNow and so forth. I have seen a number of spam where the words are run together without spaces to by pass filters. Being about to count consecutive characters and add a weight of say nor more that 5 would help. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, January 02, 2004 9:14 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] CONSECUTIVECHAR test! John, This would FP on messages that include ID's in the subject such as receipts, and also base64 encoded subjects, some of which are perfectly valid and Declude doesn't decode subjects at this time. I also tend to see receipts with more characters than I tend to see in spam that appends gibberish. I don't think this could be made reliable without a good deal of error detection. GIBBERISHSUB actually would be a lot more reliable. Matt John Tolmachoff (Lists) wrote: Test suggestion. This would be like SUBJECTSPACES, instead would count consecutive characters other than spaces in the subject line. CONSECUTIVECHAR consecutivechar 20 x 5 0 John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Another scam
Care to share the headers? BTW, I was wrong about the Zap The Dingbat thing, he hid the address bar and used HTML to make a fake address bar. It was all done in PHP and very nicely coded. Maybe there aren't enough real jobs out there for Web designers :) Matt John Tolmachoff (Lists) wrote: FYI, I did add this for it: HEADERS 15 CONTAINS citibanksecure John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, January 02, 2004 9:30 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Another scam The payload on this goes to a site that pops up a window using Zap The Ding Bat URL obfuscation to make the URL look like it is the real Citibank site. Very dangerous and because it's being redirected on that site, you can't catch the technique in the E-mail. I contacted the hosting provider as a community service. Matt John Tolmachoff (Lists) wrote: I wonder how many people will actually fall for this: --=_579b51922d72e436946615fa16088dbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --=_579b51922d72e436946615fa16088dbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable body bgcolor=3D#FF text=3D#00 DIVDear Citibank Member,/DIV= DIVBRThis email was sent by the Citibank server to verify your E- mailB= Raddress. You must complete this process by clicking on the linkBRbelow = and entering in the small window your Citibank ATM/DebitBRCard number and= PIN that you use on ATM.BRThis is done for your protection -- because so= me of our membersBRno longer have access to their email addresses and we = mustBRverify it./DIV DIVBRTo verify your E-mail address and access your bank account,BRcli= ck on the link below:/DIV DIVBRA href=3Dhttp://65.246.58.14/baluci/scripts/email_verify.htm;ht= tps://web.da- us.citibank.com/signin/citifi/scripts/email_verify.jsp/A/DI= V DIVBR-/DIV DIVThank you for using Citibank/DIV DIV-/DIV /body --=_579b51922d72e436946615fa16088dbb-- John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] CONSECUTIVECHAR test!
GIBBERISHSUB will catch maybe 80% of this stuff with just 25 or so two character combinations. Some day I may add in some more strings slowly, but Declude's custom filtering environment wasn't designed for this type of thing. Scott could build in functionality for counting characters, but it's much more difficult than just counting, he would first have to start decoding base64 and only match on decoded text for instance, and then there's the question of what to do with alphabetic character combinations in auto-generated codes. It's a bit kludgey no matter what way you approach it. Even a full-scale gibberish detector would have to have a lot of counterbalances and FP's would still occur, though one could match more than just 25 two letter strings. Again, it's not the spam that this would catch which is at issue, it's the legit stuff that would FP. Maybe if you mapped out a more fool-proof method as a blueprint that might help. Bill's suggestion was an improvement, but it probably would have about the same overall results as GIBBERISHSUB because you would have to set a threshold high enough (say 5) so that it would miss some combinations of consonants, and it wouldn't likely hit merged words. I think that you'll find that an improvement would be quite complex, though certainly possible. Matt John Tolmachoff (Lists) wrote: Examples: UtahNlawydycn daysOiwswvcm HoustonGruqrb 1iving?Bnx lfrmztzlvudgxulzhlc ehrcbaarornrmnfpubke Hereistheinfoyou usefu1Nnputywatn None were caught by GIBBERISHSUB. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists) Sent: Friday, January 02, 2004 9:40 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] CONSECUTIVECHAR test! GIBBERSHSUB would not catch things like BestProductEver and ImportantPleaseReadNow and so forth. I have seen a number of spam where the words are run together without spaces to by pass filters. Being about to count consecutive characters and add a weight of say nor more that 5 would help. John Tolmachoff Engineer/Consultant/Owner eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, January 02, 2004 9:14 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] CONSECUTIVECHAR test! John, This would FP on messages that include ID's in the subject such as receipts, and also base64 encoded subjects, some of which are perfectly valid and Declude doesn't decode subjects at this time. I also tend to see receipts with more characters than I tend to see in spam that appends gibberish. I don't think this could be made reliable without a good deal of error detection. GIBBERISHSUB actually would be a lot more reliable. Matt John Tolmachoff (Lists) wrote: Test suggestion. This would be like SUBJECTSPACES, instead would count consecutive characters other than spaces in the subject line. CONSECUTIVECHAR consecutivechar 20 x 5 0 John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] CONSECUTIVECHAR test!
BADCOUNTRYNOREVDNS would have stopped this. http://www.mailpure.com/software/decludefilters/badcountrynorevdns/BadCountryNoREVDNS_v1-0-0.zip This was sent from an IP block where at least the entire class C belongs to spammers that host in China. Even before I added this filter, over 99% of spam coming from China was being deleted on my system. A lot of this stuff either originates from China, North Korea, or a zombie somewhere, and the MAILFROM and HELO are often randomized and fail SPAMDOMAINS as well as my FOREIGN/TLD filter set. The zombies also don't do very well with the various DUL lists. NJABL's version of the old EASYNET-DYNA also lists this IP, though I don't believe it is a DUL line, some of the RBL's have simply chosen to include Chinese blocks in their lists because they are almost always spam (FIVETENSRC is another one that blacklists China for instance). This E-mail would have scored at least 300% of my hold weight based on just the IP (and been deleted). There's more clues in that E-mail than just that one thing. So go after a group of things and almost always, enough of them end up sticking. Matt John Tolmachoff (Lists) wrote: E.N.L.A^R.G.E A derivative of the COMMENTS test for the subject. The only issue here is that this stuff is otherwise easy to target with a bunch of other filters and therefore it almost never avoids deletion on my system. I'm watching this one though because it could become much worse. With the new functionality it's also possible to write a filter for this although it's a bit kludgey. That is just it, I am seeing more and more of this, and in trying to avoiding using expensive body filters as much as possible, am looking for ways to trap these. Example, this one 1iving?Bnx was caught by these tests: X-RBL-Warning: SORBS-DUL: Dynamic IP Address See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=218.79.217.52; X-RBL-Warning: CBL: Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=218.79.217.52; X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 218.79.217.52 with no reverse DNS entry. X-RBL-Warning: SPAMCHECK: Message failed SPAMCHECK: 8. X-RBL-Warning: Total weight: 30 X-RBL-Warning: TESTS FAILED: SORBS-DUL, CBL, IPNOTINMX, REVDNS, NOLEGITCONTENT, SPAMCHECK I am holding at 30 and deleting at 35. (Currently, I am seeing about 5% legit in that range, and that is too high for delete action.) SORBS-DUL gets 7 and CBL gets 10. REVDNS gets 5. John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] AUTOWHITELIST issue
Scott, I just noticed that one of my users has listed his own address in his Web address book, and I'm thinking this could become an occasional circumstance with unintended consequences. Since I turned AUTOWHITELIST ON, this means that anything with a MAILFROM that forges his personal address will end up whitelisted, and that definitely happens with a lot of spam. I could police my users and educate them, but would it make sense to make a change to AUTOWHITELIST so that it would only work on addresses other than the recipient's own? That way they don't end up whitelisting a good deal of spam. Thanks, Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] AUTOWHITELIST issue
R. Scott Perry wrote: I'll see if we can do this. It may get a bit tricky with the various combinations of user aliases, host aliases, and forwarding, but we could probably get it to work in most cases. I'll bet that you could fix 95% or more of the potential issue with just the real account being excluded, but if you can figure out all the other stuff, all the better. Thanks a bunch. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] AUTOWHITELIST issue
Glenn \\ WCNet wrote: Yes, that happened to me. I had entered my address in the WebMail addy book for one of my accounts (don't recall why), and I started getting spam that showed as WHITELISTED. It wasn't obvious why at first because I wasn't the primary To recipient on the spam, but I finally figured it out. Doh! I just found that on my server, 7 out of 28 users that had a Web mail address book, had their own address listed in it. Needless to say, it's fixed for the moment. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] [BUMP] Files locked but not process ed ed
Andrew,
Did you reboot SMTP or the server? There's an issue where it doesn't
seem to call Declude while it is in the process of shutting down, but
it's only a matter of a few seconds. I'm not sure if this has been
reported to Ipswitch either, although Scott and Kami are aware of it.
Matt
Colbeck, Andrew wrote:
FWIW, I've been running v8.05 since it came out; I was getting at least one
spam per day that was not getting Decluded and thus made it to my own Inbox,
and today I received my first non-Decluded spam.
Not scientific, but it's another data point.
Andrew 8)
-Original Message-
From: Sanford Whiteman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 31, 2003 2:49 PM
To: R. Scott Perry
Subject: Re[4]: [Declude.JunkMail] [BUMP] Files locked but not processed
Given the information, it looks like the most likely culprit here is
IMail.
Yes, it does seem like IMail is not calling Declude.
What concerns me for everyone's sake is that while this may have been
happening for a while, many people may have been deleting the orphaned
files as unexplained leftovers (you see something in the queue from a
few weeks back, but you think the server has been processing mail in
that period flawlessly without a restart, so you just trash it).
I've taken to running this primitive batch file every 15 minutes using
Task Scheduler. It uses the good 'ol Archive bit to lok for files that
stay locked in the _~ state and therefore are skipped by IMail.
--BEGIN BATCH FILE--
@echo off
echo These files were marked earlier...
for /f %%i in ('dir /b /x /a:-a c:\imail\spool\*.~md') do echo
c:\imail\spool\%%i
for /f %%i in ('dir /b /x /a:-a c:\imail\spool\*.~md') do echo
c:\imail\spool\%%i C:\imail\spool\FoundFiles.TXT
for /f %%i in ('dir /b /x /a:-a c:\imail\spool\*.~md') do
C:\IMAIL\SMTP32.EXE C:\imail\spool\%%i
echo These files are now marked...
for /f %%i in ('dir /b /x /a:a c:\imail\spool\*.~md') do echo
c:\imail\spool\%%i
for /f %%i in ('dir /b /x /a:a c:\imail\spool\*.~md') do attrib
c:\imail\spool\%%i -a
--END BATCH FILE--
I would *greatly* appreciate it if a few others could put this in
place on their servers and let me know how fast (or if) FoundFiles.TXT
fills up. NOTE: this batch file will not be usable by anyone who
doesn't use an outbound gateway, however, as it expects a very short
queue lifetime, with all all retries done by the gateway.
--Sandy
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail. The archives can be found
at http://www.mail-archive.com.
Re: [Declude.JunkMail] Any thoughts on blocking bounce messages from spam? spam?
Sanford Whiteman wrote: Do I target all bounces for deletion? Not if you want to retain your customers. Well, that's what this is about. I'm starting to get calls about people wanting me to block this stuff. I'm not getting any calls asking about where one's message went. In another thread, you've argued (unconvincingly, to my mind, and in the face of best practices) against having MXs reject unknown users--and in that same thread, you seemed proud of your policy of swallowing all misaddressed mail at the MX. I'm worried about being attacked, and if I show everyone that I have nothing to steal (i.e. not confirming individual addresses) they won't bother with pounding on my server. Before this type of thing existed, naturally swallowing such E-mail and deleting it would be a bad idea, but right now, I have to leave the nobody aliases on, and people have complained about getting bad addressed spam directed at their accounts. So I have two problems...1) the nobody aliases have to stay on in order to prevent dictionary attacks, and 2) people have complained, and will do so with more frequency as the problem gets worse, that this bad addressed spam (including some bounces), are hitting their account. I could stick this stuff in a sub-directory of their spam hold account, but almost no one would ever check that because that's the way it is. There is no perfect answer here, but most of my customers will not have their nobody aliases pointed at someone's real accounts for much longer. So hacks and spammers have compromised our ability to handle unaddressable E-mail. Such a practice now comes with an expense. Either you leave your server open to an obvious DOS flaw, or you deal with the consequences of trying to deal with it. Ipswitch will eventually fix this problem with attack detection and rejection, and then I will be able to turn the nobody alias off, and my gatewayed customers can deal with the unadressable stuff on their own servers. Regarding the topic of this thread, hacks and spammers have also compromised our ability to handle error's. My lawyer for instance is getting about 10 per day (not per week), and that doesn't include the stuff that probably gets eaten at my delete weight. My own web mail account (which I don't really use for obvious reasons), gets about 25 of these every day. I expect for this to get far worse just like everything else with spam. My spam volume has more than tripled now in the last year, in fact, yesterday it hit 93.3% of all messages that got past virus scanning. Worse yet, Congress just legalized the practice, and a publicly traded company, ValueClick, just bought out the notorious spam house Hi-Speed Media. Hacks and spammers have compromised our ability to bounce messages that we consider to be unwanted. It would be nice to do a little list cleansing in order to lighten our load by letting the VERP bounces get sent back, and even nicer to notify those that are falsely rejected, but by swallowing all of this stuff, we create a different, though smaller problem. This obviously compelled Scott to change BOUNCE to BOUNCEONLYIFYOUMUST as a way of educating us. All I know is that I have problems that need a solution, and that solution is going to be imperfect no matter how I approach it. I came here to ask for some advice, and it appears that your recommendation is to leave it alone, but I don't really consider that to be an option, at least where this problem is being seen. I expect for it to get a lot worse also, just like everything else. It's a Catch-22 for sure. I'd rather this not get too personal, so I'm going to skip addressing some of the rest, but I will say that yes, I don't have a problem changing my opinion as I learn and experience more things, and it's not unreasonable to hold different but associated beliefs that appear to be in opposition to one another where they overlap. The people that devised SMTP certainly didn't think about the potential of what has become an obvious reality that we now have to deal with, and my customers are looking to me for a solution, imperfect as it may be in the end. I'm not by far sure about what to do. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GoodAOL
I think this is something that good use could be made of in general with your conditional statements, i.e. NOTCONTAINS, NOTIS, NOTENDSWITH, etc. I would have to really rethink filtering again though :) I've been trying not to ask you for too much, but since the topic came up and you agreed, I thought I'd throw my two cents in, for all it's worth. Certainly there's no immediate need planned on my part, but I have thought countless times in the past that this could have achieved something that wasn't possible otherwise. Matt R. Scott Perry wrote: You posted a filter that was a great idea.. namely GoodAOL. I have not seen the filter you indicated: NOTENDSWITH Is that a filter.. I searched the archives but could not find anything. I implemented it and am getting strange results. Just trying to make sure the NOTENDSWITH is not an idea you were asking for.. NOTENDSWITH will be added to the next release. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Filter for CIDR's
Ahh, great! Thanks again. This will work nicely with the whitelisting capability that you discussed as well. Matt R. Scott Perry wrote: I'm sure this might have come up before, but it would be real nice, especially with the new functionality, to have the ability to match IP's to CIDR ranges in custom filters as opposed to blacklist files or ipfile types. Something like the following, though I understand that the architecture might require something different: REMOTEIP 10 CIDR 24.107.232.0/24 This would allow us to work with END and MAXWEIGHT statements along with appropriate IP ranges, we could combine scoring of CIDR ranges and other types of filters, and it would allow us to use variable scoring according to the hit as opposed to having a different file for every desired score. This will be in the next release. :) -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- === Matthew S. Bramble President and Technical Coordinator iGaia Incorporated, Operator of NYcars.com --- Office Phone: (518) 862-9042 Cellular: (518) 229-3375 Fax: (518) 862-9044 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] === --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GoodAOL
It was a suggestion though...or more like a request :) I really wasn't assuming this was his plan, though I'm sure it crossed his mind and he might have already decided to do it. How could he not you know :) But seriously, I've gotten my money's worth out of Declude and I can't complain. Things are coming along. Matt Kami Razvan wrote: Matt I like the way you bring topics up. Scott agrees to NOTENDSWITH you state: ..with your conditional statements, i.e. NOTCONTAINS, NOTIS, NOTENDSWITH, etc. :) I am no legal expert but I don't see Scott saying he is going for conditional statements.. He just agreed to one. I think you are making hidden subliminal suggestions :) Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 29, 2003 10:03 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] GoodAOL I think this is something that good use could be made of in general with your conditional statements, i.e. NOTCONTAINS, NOTIS, NOTENDSWITH, etc. I would have to really rethink filtering again though :) I've been trying not to ask you for too much, but since the topic came up and you agreed, I thought I'd throw my two cents in, for all it's worth. Certainly there's no immediate need planned on my part, but I have thought countless times in the past that this could have achieved something that wasn't possible otherwise. Matt R. Scott Perry wrote: You posted a filter that was a great idea.. namely GoodAOL. I have not seen the filter you indicated: NOTENDSWITH Is that a filter.. I searched the archives but could not find anything. I implemented it and am getting strange results. Just trying to make sure the NOTENDSWITH is not an idea you were asking for.. NOTENDSWITH will be added to the next release. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] man, what the heck?
Here's what I've done. A subject filter for three points, a body filter for 1 point, my FOREIGN/TLD filters (most of this comes from China), and some body filters for about 4 different domain names. I had the body and subject filters in the first day that I heard about the video :) This was bound to happen. Here's a nice trick for those that have Declude's all_list.dat installed for COUNTRY functionality and are running Declude JunkMail Pro v1.77i7+. If you want to score anything Korean or Chinese which doesn't have a reverse DNS entry (which should allow most legit stuff through from those countries), download the following: BADCOUNTRYREVDNS http://www.mailpure.com/software/decludefilters/badcountrynorevdns/BadCountryNoREVDNS_v1-0-0.zip Please read the instructions, pay attention to the version and extra capabilities needed, and search the archives for old discussions of COUNTRY and COUNTRIES functionality. It should all be there. Matt paul wrote: Geez, am I the only one who's gotten a bunch of spam about a certain 'video'? Sheesh. What are you guys doing to block these? They're all Base64 coded, so regular body tests don't apply. I normally get 1 or 2 spams to my inbox, but over the weekend I got almost 20 of these, all different IPs, mostly cable, and different addresses. I added a couple of header tests for certain phrases, but that's about all I can think of. What is everyone else doing? Paul --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Filter for CIDR's
Scott, I'm sure this might have come up before, but it would be real nice, especially with the new functionality, to have the ability to match IP's to CIDR ranges in custom filters as opposed to blacklist files or ipfile types. Something like the following, though I understand that the architecture might require something different: REMOTEIP 10 CIDR 24.107.232.0/24 This would allow us to work with END and MAXWEIGHT statements along with appropriate IP ranges, we could combine scoring of CIDR ranges and other types of filters, and it would allow us to use variable scoring according to the hit as opposed to having a different file for every desired score. BTW, just in case you or others were wondering, the SKIPIFWEIGHT, END, MAXWEIGHT and MINWEIGHT functionality, along with reordering my filters, has made an absolutely huge difference on my system and I still have a few filters to convert over with END functionality. I'm guessing that I'm saving over 75% of the processing power required before the modifications. Thanks, Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Comments - revisited
Kami, Anything in these days is a legit HTML tag unfortunately. At the same time, most of these patterns aren't used and can be filtered for. If this one spammer wants to keep using that one pattern, nail him with the following: BODY 30 CONTAINS alt=3D I've been coding since 1996, and never once have I seen someone start a tag with alt, and the =3D part just makes it safer to use since that will only happen as a result of an E-mail program doing conversion on the content for MIME compliance (or something like that). That's what's great about these spammers. They are too fixated on words, and not aware of the patterns they create. BTW, my experience is that BODY filters don't parse out the HTML tags before matching, only the comment tags, though I'd have to confirm the latter. Matt Kami Razvan wrote: Hi Scott: I just did a test.. in our filter files we have: BODY 20 CONTAINS Banned CD Here is an email I sent to myself from Hotmail. The filter is not triggered. == X-OriginalArrivalTime: 26 Dec 2003 12:21:25.0569 (UTC) FILETIME=[C7EEA310:01C3CBAA] X-IMAIL-SPAM-DNSBL: (BLARS,45416796,127.1.8.17) X-RBL-Warning: NOABUSE: Not supporting [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: NOPOSTMASTER: Not supporting [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: IPNOTINMX: X-RBL-Warning: FREEEMAILS: X-RBL-Warning: FILTER-HEADER-XMAIL: Message failed FILTER-HEADER-XMAIL test (line 20, weight 5) X-Declude-Sender: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [207.68.165.8] X-Declude-Spoolname: D27c602b5015c4bff.SMD X-Note: This E-mail was scanned filtered by Declude [1.77i8] for SPAM virus. X-Spam Score: 5 [Blocked on 20+] X-Note: Sent from Reverse DNS: sea2-f8.sea2.hotmail.com X-Hello: hotmail.com X-Spam-Tests-Failed: NOABUSE, NOPOSTMASTER, IPNOTINMX, FREEEMAILS, FILTER-HEADER-XMAIL X-Note: Recipient(s): [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-Country-Chain: UNITED STATES-destination X-Declude-Date: 12/26/2003 12:21:25 [0] X-RCPT-TO: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Status: U X-UIDL: 331473289 Ban/manifestationned C/palindromeD! == then I sent one without the /.. tags it was caught. == X-IMAIL-SPAM-DNSBL: (BLARS,47317340,127.1.8.17) X-RBL-Warning: NOABUSE: Not supporting [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: NOPOSTMASTER: Not supporting [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: IPNOTINMX: X-RBL-Warning: FREEEMAILS: X-RBL-Warning: FILTER-HEADER-XMAIL: Message failed FILTER-HEADER-XMAIL test (line 20, weight 5) X-RBL-Warning: FILTER-PORN: Message failed FILTER-PORN test (line 64, weight 20) X-Declude-Sender: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [207.68.165.25] X-Declude-Spoolname: D287b02d2015c0fa4.SMD X-Note: This E-mail was scanned filtered by Declude [1.77i8] for SPAM virus. X-Spam Score: 25 [Blocked on 20+] X-Note: Sent from Reverse DNS: sea2-f25.sea2.hotmail.com X-Hello: hotmail.com X-Spam-Tests-Failed: NOABUSE, NOPOSTMASTER, IPNOTINMX, FREEEMAILS, FILTER-HEADER-XMAIL, FILTER-PORN, WEIGHT20s, WEIGHT20r X-Note: Recipient(s): [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-Country-Chain: UNITED STATES-destination X-Declude-Date: 12/26/2003 12:24:26 [0] X-RCPT-TO: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Status: U X-UIDL: 331473290 Banned CD The first time I posted my notes about comments was based on this observation but this time I did a test. Look at the new type of insertions .. a totally legitimate HTML tag. === imest Genalt=3Dhas comeeric Viagalt=3Di wantra noalt=3Dmonitorw!/abrbrOalt=3Dsignaturer te= alt=3Dfatherst onalt=3Dmothere oalt=3Dbrotherf oalt=3Dsisterur othalt=3Dtalk to meer alt=3Dwhen u = canpharmaalt=3Dgo aroundcy products:alt=3Dand check alt=.. we are seeing a ton of emails with these inserted in the middle of each text and not detected with the filters. Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Web-O-Trust or ?
Kami, This guy also links to the following: http://users.adelphia.net/~equalizer/web-o-trust.txt Which includes what appears to be all of Adelphia. I'm not sure if people are paying attention, but I pointed both of these files out when the topic first came up. Now the mistakes have managed to propagate through to a great deal of those here. Matt Kami Razvan wrote: Scott: This guy is out of his mind... Look at his comments: version: http://web-o-trust.org/1.01.html # http://www.web-o-trust.org/ - version: correction needed in the example ;) # Note: comments are under their respective ip: # Note: IPv6 addresses may or may not be supported...remains to be seen # Note: F-sharp # Note: This file should stay here: http://home.teleport.com/~amurph/web-o-trust.txt # Note: This is my first-level trust. I also have web-o-trust-2.txt; see below. # Note: These are, respectively, Earthlink, sccrmxc14.comcast.net, rwcrmhc13.comcast.net, # Note: ...and one you can spot with rDNS. ip: 207.217.120.0/24 ip: 204.127.202.0/24 ip: 204.127.198.0/24 ip: 67.89.105.244 Is this what I think it is.. He is listing the entire Earthlink.com? Please visit this and see: http://home.teleport.com/~amurph/web-o-trust.txt Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Friday, December 26, 2003 9:08 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Web-O-Trust or ? Have you checked the filter file to see what IP range matched? The IP entry is: 207.217.120.0/24 In the list of participants, the 5th entry in the list of participants. - http://www.web-o-trust.org/browse.cgi?url=http://web-o-trust.org/everyb ody.t xt I found it here: - http://home.teleport.com/~amurph/web-o-trust.txt In this case, the first thing to do is send an E-mail to their contact address. If they cannot provide a reasonable explanation of how the spam got through, you can use an omit: line (and suggest that others do), to prevent any future spam from getting through from them. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT - What works?
Chuck, All of those products need to be trained by the user, and they work primarily on heuristics instead of the types of things we do with Declude, so they won't be nearly as effective, nor as reliable. I'm not aware of a plug-in for Eudora, but Netscape and new versions of Outlook have some capabilities built in. My only experience was with the Netscape filtering, and IMO, it was unusable. It tagged everything, though I didn't have a big spam problem. I hear it can take a while to learn though. A friend of mine said it was OK. I'm sure you can Google for some reviews of what is out there. I doubt there's a magic bullet at the moment, afterall, that's why we're here. Matt Chuck Cahill wrote: Looking for a solution that will filter SPAM for home and something I can recommend to neighbors. Anyone have any experience on what integrates with Eudora and Outlook, fairly easy to setup and has a high success rate? Thanks Chuck Cahill YFCS, Inc Visit us at www.yfcs.com --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Web-O-Trust or ?
Merry Christmas everyone. Any way...the problem was eluded to before, in fact the listings that caused this problem have always been there: http://www.mail-archive.com/[EMAIL PROTECTED]/msg13918.html We shouldn't be trusting ISP mail servers. If isolated instances like this aren't enough, consider that others such as swbell.net have been tagged as a multistage open relay, and it appears that this might be correct based on the following: http://groups.google.com/groups?scoring=dq=151.164.30.28+group:*abuse* That server has been relaying spam since July of 2000, and the reports might be attributed to this server also handling forwarding. I have to look at this further, but I want to go and play with my choo-choo train and Tickle Me Elmo that Santa brought me. The presents that the spammers brought me won't be opened until tomorrow :) Matt R. Scott Perry wrote: I just noticed a caught spam that shows the Web-O-Trust filter being triggered. This is the filter that I think Bill posted after running the program on the site. Have you checked the filter file to see what IP range matched? The two things to look for are [1] the site that listed the IP (if there is a rogue site, we all need to know -- this is pretty quick for a spammer to get into it), and [2] a poor IP range (someone accidentally adding 192.0.2.0/8, confusing /24 and /8), which would whitelist too large an area. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Bonded Sender
Cyan, Thanks for coming on board. If you don't mind, I would like to jump right into a early Christmas Eve discussion on the topic :) Recently I came across a service that was listed in both Bonded Sender as well as Spamhaus, out003.toptx.com - 38.113.200.23. The company, Topica ( http://www.topica.com/ ) is a large list service basically, serving mostly small and medium sized customers that bring their own lists, which of course is problematic despite any verifiable good intentions of the company itself. Their reputation, as well as my first hand experience, has shown them to be a common proliferator of spam from customers that dig search engines and the like for addresses associated with the industry the list owner is targeting. One example that comes to mind in when I started seeing E-mail from their servers directed at almost every car dealership that I am hosting, and it was all sent to their generic E-mail addresses listed on their sites. Their listing in Spamhaus says, Still hitting loads of addresses that never existed. It's my feeling that both the listing in Bonded Sender as well as Spamhaus are improper. Spamhaus shouldn't be going after mostly legit companies like this without a better reason than they claim. The issue here is really that any large list service that caters to small and medium sized businesses is going to be plagued by small-time spammers. There's no way that they can effectively stop this either except to take a deposit and enforce standards very strictly, which apparently either isn't happening, or it isn't effective. I have relied on Spamhaus to only list blocks that are run by verifiable spammers, and this service is clearly not dedicated to spam, in fact it came to my attention because we were blocking a list using their service which was sent to paying subscribers. On the other hand, I have relied on Bonded Sender to heavily credit points to bulk mailers and large volume commercial organizations that can be verified to practice the strictest standards when it comes to managing their lists. Companies like Ebay, Yahoo and Microsoft for instance have taken up the practice of spamming their customers with off-topic and largely unwanted advertisements through default opt-in schemes, and therefore shouldn't be granted Bonded Sender status from the blocks from which they spam from (and I don't believe that has happened). It should also follow that list services such as Topica which are incapable of proactively managing their customer base should be excluded from consideration based simply on the type of business that they are in (you can't guarantee their messages to be legitimate). To me, this is worse than adding an ISP's mail server's to Bonded Sender, because ISP's can't effectively manage the content that is sent through their servers where as there is a concentration of this activity on list services. So I'm wondering what your take is on the idea of having Topica and possibly other list services on Bonded Sender? So far, I greatly appreciate all the tools that your company provides with the exception of this one known instance. On the other hand, there's fairly widespread skepticism in the community at large about the dangers of having a larger commercial entity maintaining standards in this way, and I'm sure you are aware of the challenges that presents you. Thanks and Happy Holidays, Matt Cyan Callihan wrote: Greetings All! I've been involved in a discussion with Dave Doherty regarding Bonded Sender and he invited me to the Declude list. I hope that I can help address any questions that you may have. If I don't have the answers, I will find someone here who does and we'll help out in any way we can. I look forward to being part of your community. Cyan Callihan Bonded Sender Standards and Compliance Manager IronPort Systems www.bondedsender.com - Guaranteed Delivery of Legitimate Email www.ironport.com - Email Infrastructure Products and Services www.senderbase.com - The Leading Email Reputation Service www.etcevent.com - Email Technology Conference sponsored by IronPort --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SpamCop listing Webtv.net IP
SpamCop and MailPolice both got demoted on my system by a point today, and I hope to bring them down another point soon (after measuring the effect on my system). When I see ISP mail servers listed, it is generally due to one of two things...they either have no controls on someone doing a bulk mailing through their servers, or much more likely, they are forwarding E-mail to an off-server account. I see legit E-mail being tagged by SpamCop and MailPolice all the time because it passed through a server that is used for forwarding such things. ATT for instance has a set of servers for just this purpose which get tagged all the time. The problem is that people are either using spamtraps that forward this forwarded spam, or they are reporting forwarded messages as spam and the systems consider the ATT gateway to be the source (a problem with the design). All of the RBL's need to generate lists of large ISP mail servers, especially the gateways, in order to prevent this from happening. On my own system, I have ATT's gateway's IPBYPASSed primarily because of this issue, though it also helps a great deal with filtering of the accounts forwarded through them since I am only scanning on the last hop still. The issue of course is that IPBYPASS only allows 20 entries since it was designed only to be used on your own gateways and not a large list of servers from other sources (I hope to see this turned into a separate file sometime). Just to repeat so that someone doesn't make a mistake...Declude only accepts the first IPBYPASSed addresses, after that it will ignore the entries. Here's what I'm using for ATT currently for instance: # mtiwgwc11.worldnet.att.net - mtiwgwc18.worldnet.att.net IPBYPASS204.127.131.121 IPBYPASS204.127.131.122 IPBYPASS204.127.131.123 IPBYPASS204.127.131.124 IPBYPASS204.127.131.125 IPBYPASS204.127.131.126 IPBYPASS204.127.131.127 IPBYPASS204.127.131.118 I believe some other ISP's have pages listing the servers from which they forward E-mail on. I generated my list though from looking up one known server from SenderBase, and then doing some follow up reverse DNS digging. It's important to make sure that these servers are never an SMTP server for end users to send E-mail from, otherwise you might be hitting the dial-up IP's instead of another mail server. This has been working for me, but in general, this isn't going to be a fix for forwarded E-mail until either IPBYPASS gets expanded, or the RBL's stop listing ISP gateway mail servers. Matt John Tolmachoff (Lists) wrote: Great, SpamCop is listing WebTV.net mail server IP falsely. Looking at the samples, they look legit to me. Has anyone actually seen spam come from a WebTV.net server? John Tolmachoff Engineer/Consultant/Owner eServices For You --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Suggestions on whitelisting web servers
Scot, The E-mail that comes in for accounts that are no longer hosted on that server can be safely refused after 2 days passes. I believe a lot of mail servers will try the A record when delivery fails to the MX, or the MX can't be resolved. The E-mail should be queued on the sending server and retried if it does fail due to a glitch. It should never default to an A record of course. I believe that when IMail is set up as a gateway server, all of the E-mail will be forwarded by way of the IP of the gateway if you set it up as a host, or by the default domain's IP if you don't have a host set up on the backup MX's address. You can therefore IPBYPASS just that one IP. Your master IMail server should accept all E-mail addressed to a local domain, so you shouldn't have to do anything with the ColdFusion or MS SMTP stuff if I'm correct. FYI, I'm not sure if I followed you perfectly. Matt Scot Desort wrote: I have run across a dilema. We run Imail on the same server as IIS for web sites we host. A normal web hosting customer therefore has DNS records that look like this @INA192.168.1.1 wwwINA192.168.1.1 mailINA192.168.1.1 somedomain.comINMX10mail.somedomain.com. As web hosting customers subscribe to spam filtering with us, we migrate their mail to our Declude server, leaving their web site on the existing server. Assuming the IP address of the declude server is 192.168.1.2, we make the following change to DNS: @INA192.168.1.1 wwwINA192.168.1.1 mailINA192.168.1.2 somedomain.comINMX10mail.somedomain.com. No MX records point to the web server. At the time of migration, DNS changes are obviously not immediate. So we make the following changes to the old server 1. Edit the registry and rename the official host name in the Imail registry key for 192.168.1.1 to something obscure, and change any aliases to something obscure (we don't delete the host in IADMIN just in case something backfires and we need to go back to the old server). 2. We make an entry in the HOSTS file on the old mail server: 192.168.1.2 mail.somedomain.com so any email still coming into the old IP address gets forwarded to the Declude box until DNS refreshes, making the old server function like a relay server for somedomain.com. Now, the web server is IIS, and therefore has Frontpage forms and Coldfusion forms, and other email generated by the web server. This stuff often gets tripped on some declude tests. Customers have leads and other important customer contact forms that need to always get delivered. So, naturally, we make an entry in our global.cfg file: WHITELIST IP 192.168.1.0/24 to whitelist all email coming from our web servers. Here is the problem: Spammers often do not try to connect to the MX record. They are using the A record. So, Imail on the old server stamps it's own IP address (192.168.1.1 in this example) into the header, and forwards the email to the Declude (new) Imail server. Declude sees our IP in the header, and whitelists the spam. Obviously this is a problem. We can't IPBYPASS all of the individual IP addresses in all of our subnets since there is a limit of 20, and we can't IPBYPASS entire subnets like you can with WHITELIST IP. We could set HOPHIGH to 1 to force declude to scan the prior host also. But that would add some additional overhead to declude, and not all email coming into declude is effected by this scenario, possibly creating false positives. So, the answer is to remove the entry in the HOSTS file on the old mail server so it no longer relays to the new server, now that enough time has passed and DNS has completely updated across all root servers. Is there any chance in losing legit email (broken mail servers that don't connect to MX records), or any other consequences of making this change? Or is there some other work-around in declude? Any attempt to whitelist by REVDNS would cause the same problem. I suppose I could negative filter on specific headers inserted by frontpage and coldfusion, but it seems like more work than necessary. I know that there may be a rare occassion where a sending SMTP server tries an A record connection when there is no MX record, or the MX host is unreachable. But I know from experience that spammers often attempt direct A record connections, because we see a lot of email coming in that bypasses the MX record for domains that we do some mail filtering on a front-end Postfix box. The spam never travels through the MX Postfix box - it goes right into the A record host. The Postfix box is NEVER down or unreachable, so there is no reason why a remote SMTP server operating according to RFC should try to connect directly to an A record host in this case, unless I am mistaken. TIA, Scot --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To
Re: [Declude.JunkMail] Suggestions on whitelisting web servers
Scot, If you delete the domain from the old IMail server, and leave the HOSTS entry in there along with the relay settings, I believe that the old IMail server will forward the E-mail from the default domain's IP address. The trick is to delete the domain from IMail, then you can IPBYPASS the single IP of the old server's default domain, that way spam filtering should work perfectly the same as it would if it was received directly. This is basically a backup MX setup when you do it this way. IMail will only use the IP that E-mail is received on if there is a host configured for that IP, otherwise it forwards it from the default domain (if I'm wrong about this, please someone chime in). Matt Scot Desort wrote: The E-mail that comes in for accounts that are no longer hosted on that server can be safely refused after 2 days passes. I believe a lot of mail servers will try the A record when delivery fails to the MX, or the MX can't be resolved. The E-mail should be queued on the sending server and retried if it does fail due to a glitch. It should never default to an A record of course. That's what I was hoping. I don't think there is any need to leave the old Imail server with an entry in the HOSTS file pointing to the new server after, say, a week to be safe. I believe that when IMail is set up as a gateway server, all of the E-mail will be forwarded by way of the IP of the gateway if you set it up as a host, or by the default domain's IP if you don't have a host set up on the backup MX's address. You can therefore IPBYPASS just that one IP. Your master IMail server should accept all E-mail addressed to a local domain, so you shouldn't have to do anything with the ColdFusion or MS SMTP stuff if I'm correct. FYI, I'm not sure if I followed you perfectly. LOL. And I am not sure I followed *you*. IPBYPASS has a 20 IP limit, so it's not practical to bypass the IP address of the old mail host. On the old box, each site has it's own IP (non-virtual) in Imail. Therefore, each domain that goes to Declude would need to have a unique IPBYPASS entry. EVen if the old Imail server forwards all outgoing email to a gateway first (my postfix box, for example), mail being delivered via a HOSTS entry is not forwarded to the gateway. The HOSTS entry takes precedence, and Imail stamps the header with the A record IP address and forwards the email directly to the declude box. I am going to remove those HOSTS entries for one small domain and see if the user complains about not receiving some email. I am fairly confident it will not cause a problem. The old Imail servers, in these cases, have been in service for a long time, back when we kept mail and web on the same box (duh). New sites that we get for hosting have mail and web separate, and there isn't even *any* SMTP running on the A record box. All mail is handled by the MX host alone. And no one has complained about non-receipt of email. Thanks, -- Scot Matt Scot Desort wrote: I have run across a dilema. We run Imail on the same server as IIS for web sites we host. A normal web hosting customer therefore has DNS records that look like this @INA192.168.1.1 wwwINA192.168.1.1 mailINA192.168.1.1 somedomain.comINMX10mail.somedomain.com. As web hosting customers subscribe to spam filtering with us, we migrate their mail to our Declude server, leaving their web site on the existing server. Assuming the IP address of the declude server is 192.168.1.2, we make the following change to DNS: @INA192.168.1.1 wwwINA192.168.1.1 mailINA192.168.1.2 somedomain.comINMX10mail.somedomain.com. No MX records point to the web server. At the time of migration, DNS changes are obviously not immediate. So we make the following changes to the old server 1. Edit the registry and rename the official host name in the Imail registry key for 192.168.1.1 to something obscure, and change any aliases to something obscure (we don't delete the host in IADMIN just in case something backfires and we need to go back to the old server). 2. We make an entry in the HOSTS file on the old mail server: 192.168.1.2 mail.somedomain.com so any email still coming into the old IP address gets forwarded to the Declude box until DNS refreshes, making the old server function like a relay server for somedomain.com. Now, the web server is IIS, and therefore has Frontpage forms and Coldfusion forms, and other email generated by the web server. This stuff often gets tripped on some declude tests. Customers have leads and other important customer contact forms that need to always get delivered. So, naturally, we make an entry in our global.cfg file: WHITELIST IP 192.168.1.0/24 to whitelist all email coming from our web servers. Here is the problem: Spammers often do not try to connect
Re: [Declude.JunkMail] Bypassing User IP addresses
If I recall correctly, when you IPBYPASS a single hop message, this can throw off some of the technical tests that are built into Declude since there will be no data element for the IP, REVDNS and HELO. If that's the case, it's because it wasn't designed for that use. This can be tested by IPBYPASSing your server, and then sending E-mail through it. It might have just looked funny though (blank IP), I can't remember exactly what happened when I made that mistake. Anywho...I remember the days back when I wasn't using any custom filters, and Declude might have used 2% of my processor per typical message. It's very different now. You could probably easily save that amount of processing by paying extra attention to the filter efficiency if you are using them. Matt R. Scott Perry wrote: In this case, it will still cause the DNS tests to be run (just on different IP(s)). That's why I recommend WHITELIST IP in this situation. But that would just prevent action, correct? The DNS tests will still be run. (Unless using PREWHITELIST ON which I do not want to use.) WHITELIST IP with PREWHITELIST ON will prevent the tests from being run. Just WHITELIST IP will not prevent the tests from being run. The intent is to still run other tests on those messages, but since they are from users and not mail servers, wanted to see if there was a way to save processing time by not running DNS based tests on those IPs. Ah, it does appear that you are looking for IPBYPASS or something similar. In this case, you can either use IPBYPASS (with the 20 IP limitation), or you can use HOPHIGH to accomplish this (which will scan more than 1 IP for every E-mail). -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Funny false positives :)
This came to a customer that recently move over to our service from Verizon because they were deluged with spam. I found it to be funny that we blocked it since most of it points to a very poorly configured mail server, and the topic of the announcement from Verizon was E-mail maintenance. They even managed to hit our secondary MX for some reason even though it's on the same damn machine :) From [EMAIL PROTECTED] Wed Dec 24 13:38:44 2003 Received: from mailsrvcs.net [206.46.170.114] by mx2.mailpure.com with ESMTP (SMTPD32-7.15) id AD2D10E016E; Wed, 24 Dec 2003 13:38:37 -0500 Received: (from [EMAIL PROTECTED]) by mailsrvcs.net ; id hBOIcI705138 Wed, 24 Dec 2003 12:38:18 -0600 (CST) X-Authentication-Warning: resdirha.mailsrvcs.net: imail set sender to [EMAIL PROTECTED] using -f Date: Wed, 24 Dec 2003 18:37:50 - Message-ID: [EMAIL PROTECTED] X-Mailer: immsgmassmail 1.5.14.5 From: Verizon Online [EMAIL PROTECTED] To: Verizon Business Mail Customer [EMAIL PROTECTED] Subject: [11] E-Mail System Maintenance This Weekend X-MailPure: == X-MailPure: NOABUSE: Failed, listed in abuse.rfc-ignorant.org (weight 1). X-MailPure: NOPOSTMASTER: Failed, listed in postmaster.rfc-ignorant.org (weight 1). X-MailPure: IPNOTINMX: Failed, IP is not listed in MX or A records (weight 0). X-MailPure: NOLEGITCONTENT: Failed, no legitimate content detected (weight 0). X-MailPure: HELOBOGUS: Failed, bogus connecting server name (weight 4). X-MailPure: CONCEALED: Failed, concealed message (weight 1). X-MailPure: SPAMDOMAINS: Message failed SPAMDOMAINS test (weight 4). X-MailPure: RECIPIENTS: ** X-MailPure: == X-MailPure: Spam Score: 11 X-MailPure: Scan Time: 13:38:44 on 12/24/2003 X-MailPure: Spool File: Ddd2d010e016e5ef9.SMD X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: [No Reverse DNS] [206.46.170.114] X-MailPure: == X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: == X-Declude-Date: 12/24/2003 18:37:50 [0] X-RCPT-TO: ** Status: R X-UIDL: 371659832 On December 28th, between 12:01 AM and 06:00 AM CT, Verizon will be performing maintenance on our Business E-mail servers. Customers will not be able to retrieve their email but will be able to send during this time frame. Also, customers will not be able to make account modifications during this time frame. We thank you for your business and appreciate your patience during the maintenance. All e-mail sent to customer's accounts will be available upon completion of the maintenance. Your Verizon Online Business E-mail Team --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Order of processing various filter types.
Scott, I know this has been discussed at least in pieces in the past, but I was hoping that maybe you could put it all together for me (and maybe also add the order to the manual when the new functionality finds its way into a full release). Could you give me an idea about the order of processing for the following, or indicate which ones might be run according to where they lie in the Global.cfg? This will of course make a difference in performance, and I would like to provide good guidance myself as I comment up my filters for sharing with others. The types that I can come up with off the top of my head are as follows - ipblacklist - fromblacklist - ipfile - fromfile - spamdomains - filter Also, if it's not that big of a deal in modifying the programming, would it be possible to add SKIPIFWEIGHT functionality to the non-filter types? I don't believe that MAXWEIGHT, MINWEIGHT and END though would provide any more functionality to non-filters, but SKIPIFWEIGHT still has potential for saving processing with these other types. Having that in the filter type though is of course 90% or more of the issue, so don't let me appear to be looking a gift horse in the mouth :) Thanks, Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Overflow
These attacks can go on for hours and hours and hours. If you've seen this stuff in your logs, you would see strings like [EMAIL PROTECTED] 26^8 for instance equals ~210,000,000,000 addresses. If they've got a database of names, that could probably be brought down to around 100,000 attempts. The dictionary attacks don't send E-mail of any value, they are just used for harvesting addresses. So if the spammer only gets positive responses to every address, their harvesting time has been completely wasted. The only time when they dictionary attack a server that accepts everything would be when their software is not performing properly, or they are actually trying to DOS a server. So until IMail delivers functionality that can detect a dictionary attack, it seems crucial that we leave the nobody aliases on for every local domain. Personally, I find the drawbacks of having a nobody alias pointed at me to be more harm than good, which is why I would like to auto-delete these messages. You raise an important point though about not having the messages bounced back. I'll have to look into possibly having an auto response set up in addition to the delete action, which would probably require two accounts with a single alias directed at it, or maybe forwarding would work with an autoresponder??? Matt Charles Frolick wrote: I seriously don't think they would bother with the code needed to detect the difference between accepting everything in the dictionary and bouncing some or all addresses. A spammer using dictionary attacks may not be harvesting addresses, they may just be spamming a dictionary of addresses. The best way to handle them is to have some sort of detection routine to temporarily block them with temp errors so that legit mailers will retry. Imail is not capable of doing this, so either process a buch of postmaster bounces or trashcan them. Big drawback to using nobody to trashcan, if someone typoed an important email, they would never know. Thank you, Chuck Frolick ArgoLink.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 22, 2003 9:47 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Overflow Nick, I think I might have been asking the question the other way around, though I'm not positive it was taken the wrong way. The theory here is that domains which accept every E-mail address in the HELO won't be dictionary attacked past a few attempts because the attacker's software will quickly determine that the attack isn't exposing any addresses due to a catch all situation. So maybe adding the nobody alias back in, and redirecting that E-mail to an account that deletes each E-mail automatically will resolve the issue of dictionary attacks? I see this stuff in my logs on occasion, but it never happens for a prolonged period of time. I'm thinking this is because 90% of my domains had nobody aliases. Unless someone only wants to DOS my server, dictionary attacking a domain with a nobody alias is a waste of their processing power just like it is a waste of mine. Matt Nick Hayer wrote: Hi Matt, Is anyone getting dictionary attacked for long periods of time on a domain with a nobody alias or something that is gatewayed? Thanks, Yes. I get hammered everyday..; I got rid of the nobody alias, filter the log files for the ip's that connected - and add them to my Imail Access control list. Currently that list contains nearly 10,000 ip's... -Nick Hayer Matt Fritz Squib wrote: Hey guys, this sounds like same problem that I have been experiencing, however it has been a bunch of spam with c.c. 's to non-existant mail addresses on my server (dictionary attack style) ..My DNS is working fine. I spent the weekend returning mail from the old spool to a new spool that I had to create. I had around 67,000 of these buggers to deal with...no fun. All of the mail seems to be originating from dsl and cable modems with forged return addresses. My server is swamped again today - started again about 2-3 hours ago. Fritz Frederick P. Squib, Jr. Network Operations/Mail Administrator Citizens Telephone Company of Kecksburg http://www.wpa.net () ascii ribbon campaign - against html mail /\- against microsoft attachments --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality.
George, Thanks again for the stats. These do verify that spammers are obfuscating the Yahoo redirection code and those lines need to stay in the filter as a result. At least I wasn't wasting my time when I came up with that stuff :) I didn't get too much else out of the results though. Maybe I'll reorder the test types in the OBFUSCATION filter, and I did make a change to what will become the next version of GIBBERISH where I moved the Words, Acronyms and Stock Market Symbols section below the Auto-generated Codes section, but I don't yet see any need to tweak the files line for line, only section by section because management is important. Matt George Kulman wrote: Matt, Here are two analyses. The 11-15 to 11-30 covers the period from when I implemented your filters until I began using SKIPIFWEIGHT and MAXWEIGHT which obviously has some effect on the stats. The 11-15 to 12-21 expands the prior set to include the additional filters. There's also the weighting effect to consider. While I run the OBFUSCATION and Y!DIRECTED at hold weight (15), I use the GIBBERISH like the COMMENTS test and accumulate weight per hit. Since my SKIPIFWEIGHT is set to my DELETE weight (60), the filters will run until that's reached. These stats aren't a big deal to produce since its all in a SQL database. I'll be implementing your new filter versions this coming weekend (with new names to avoid commingling stats). I do strip out comments since they become meaningless as the filter contents are resequenced by my system. George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 22, 2003 10:32 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. functionality. functionality. George, I think that logic can get you 95% of the way there with something as convoluted as this, that is run only about 1/3 of the time, and considering that you are only battling for about 2% of the processing power required by this filter alone, which shouldn't be too terribly much. Removing the comment blocks would probably have a bigger effect :) Changing to the new version of the filter should definitely help, though this isn't by far my most weighty filter. Here's something that I've very curious about though...the Y!DIRECTED filter contains a bunch of BODY searches for obfuscated strings, something that is almost totally redundant with the OBFUSCATION filter. I would be very curious to see how often those lines are hit because they could be dumped for a measurable performance increase. Any chance you want to take a crack at that? I wouldn't be surprised to see them never hit. Matt George Kulman wrote: Matt, I use LOGLEVEL HIGH for my data collection and analysis stuff and, as Bill pointed out, all hits are reflected. I've started to use SKIPIFWEIGHT. The result of course is that filters are bypassed and the statistics are skewed. For example on Friday 12/19, 15291 emails were processed by Declude on my system. Only 4604 were processed by the GIBBERISH filter. Of these 1328 had a total of 3854 hits. My quandary now is to decide whether to use the new control functions of SKIPIFWEIGHT, MAXWEIGHT and END to reduce processing overhead or to collect a full set of evaluation data by letting everything run. It's truly a catch-22 situation. If I collect all of the data, then I gain no benefit, since all of the processing takes place. If I take advantage of the analysis data, I reduce my processing workload but effectively destroy the validity of the statistical data which is now skewed by my filtering control. George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 22, 2003 3:17 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. George, That's good data to have. I would have to assume that something tagged as gibberish in the main test would be random, and that's fairly well indicated by the somewhat tight range of the two character strings. Unless you are using a logging feature that I'm not aware of, you are only showing the last hit that the filter produces, and that explains why the Z strings are mostly bunched at the top. I've got these ordered alphabetically and will probably leave them there for management purposes. The counterbalances though are definitely something that I will use your information for reordering them. I believe I made an attempt to order these in the 2.0 filter version according to what I thought would be more common as well
[Declude.JunkMail] Wondering about a few features in development.
Scott, I was wondering about the progress of a couple of things. First, has the END functionality been fixed in a recent release, and second, has the weight listed in the WARN action been updated to include the sum of the Global.cfg and filter file weights? Thanks, Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] EASYNET-DYNA replacement, NJABL-DYNABLOCK
I don't recall seeing this posted here, but while doing a little research on the NJABL blocklists, I came upon a page on their site saying that they were integrating the now defunct EASYNET-DYNA: http://njabl.org/dynablock.html The following line should work for integrating this test: NJABL-DYNABLOCKip4rdynablock.njabl.org 127.0.0.340 This was a very important test on my system, and the loss was definitely being felt. Also note, this is a different test than the existing NJABL-DUL test. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Wondering about a few features in development.
Very cool Scott, my test scores now add up :) I'll have to try the END functionality later on today though. Any chance of exposing a %WEIGHT% and a %LINE% or %LINES% variable for the WARN action? I can't say that I've tried these in the last month, but I couldn't get anything like this to work when I did and it seemed like something that makes sense to have. Thanks, Matt R. Scott Perry wrote: I was wondering about the progress of a couple of things. First, has the END functionality been fixed in a recent release... http://www.declude.com/relnotes.htm shows that it was added to 1.77, which is the latest beta. It has, however, been taken care of in the latest interim release (at http://www.declude.com/interim ). ... and second, has the weight listed in the WARN action been updated to include the sum of the Global.cfg and filter file weights? The latest interim release takes care of that as well. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality.
I've made some huge leaps forward recently in terms of the processing power required to run Declude with the custom filters that I have installed. This was done by way of the SKIPIFWEIGHT functionality introduced in the latest beta, but also by way of re-ordering my filters in the Global.cfg file so that the easiest to process custom filters are run first in the hopes of avoiding the need to run more costly ones. This new version of GIBBERISH makes use of functionality introduced in the 1.77 beta, however the most recent interim release, 1.77i7, should be used in order to guarantee proper operation (initial versions would always end processing, and effectively disabled the filters). The END functionality removes the need to have ANTI filters since the filter can be stopped before it gets to the main filter matches, and it also presents another opportunity to save on the processing power required to run such things. This also makes use of the MAXWEIGHT functionality to limit the max score as well as end processing once a single hit has been scored. Note that the filter will only log (at the LOW setting) and show WARN actions when the filter is tripped and an END was not hit...which is great! No more looking at non-scoring custom filters due to counterbalances :D Please read through the file and follow these instructions if you already have GIBBERISH installed: 1) Comment out the ANTI-GIBBERISH custom filter in your Global.cfg 2) Change the score of the GIBBERISH filter to 0 in your Global.cfg. 3) Change the scoring of the filter to match your system (it is scored by default for base 10 systems). This can be done by changing the MAXWEIGHT and Main Filter lines to reflect the multiple of 10 that your system is based on. 4) Change the SKIPIFWEIGHT score to reflect your delete weight, or whatever weight you would like for the filter to be skipped if the system has already reached it before processing the filter. The file can be downloaded from the following location: http://www.mailpure.com/software/decludefilters/gibberish/Gibberish_v2-0-1.zip Please report any issues with the new filter format. As soon as bugs stop being reported, I will move to convert the other dual file filters into single file alternatives which make use of the END functionality. Until the functionality goes into a full release, I'm going to continue to primarily provide the old style filters on my site. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Stupid question
I would use the following: HEADERS 15 CONTAINS quill.com This message was sent through a third-party bulk mailer, and the MAILFROM address may change from server to server, but they are using a Reply-To address that will get picked up with that line. Matt Doug Anderson wrote: I'm setting up a Sender Black list Given the following header, what would I put in my black list file? Is it the reply to or the from I need to look at? In this instance I would like to kill everything from quill.com, so would I just use that? Received: from om-quill.rgc3.net [66.35.244.68] by mail.ameripride.org with ESMTP (SMTPD32-8.04) id A88E1B4014A; Wed, 10 Dec 2003 09:15:26 -0600 Received: by om-quill.rgc3.net (PowerMTA(TM) v2.0r5) id hqss6804faso; Wed, 10 Dec 2003 07:14:44 -0800 (envelope-from [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Dec 2003 07:14:44 -0800 From: Quill.com [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Reply-To: Quill.com [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Quill Values Your Opinion X-cid: quil.954.1 To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [420e]. X-Declude-Sender: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [66.35.244.68] X-Declude-Spoolname: D388e01b4014a4491.SMD X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com http://www.declude.com) for spam. X-Spam-Tests-Failed: IPNOTINMX, NOLEGITCONTENT, SPAMHEADERS [3] X-Note: This E-mail was sent from (timeout) ([66.35.244.68]). X-RCPT-TO: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Status: U X-UIDL: 367773216 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Stupid question
Just another follow-up. This might be dangerous to blacklist anything from quill.com since they are an ecommerce site and you may very well be blocking receipts and other order related information. It would then be safer to go after the MAILFROM, though this won't work if they change the third-party bulk mailer. MAILFROM 15 CONTAINS quill.rsc01.com I generally unsubscribe customers from such lists when they report it as spam since they seem legit and they are probably only being sent E-mail because they have done business with the site. Matt Doug Anderson wrote: I'm setting up a Sender Black list Given the following header, what would I put in my black list file? Is it the reply to or the from I need to look at? In this instance I would like to kill everything from quill.com, so would I just use that? Received: from om-quill.rgc3.net [66.35.244.68] by mail.ameripride.org with ESMTP (SMTPD32-8.04) id A88E1B4014A; Wed, 10 Dec 2003 09:15:26 -0600 Received: by om-quill.rgc3.net (PowerMTA(TM) v2.0r5) id hqss6804faso; Wed, 10 Dec 2003 07:14:44 -0800 (envelope-from [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Dec 2003 07:14:44 -0800 From: Quill.com [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Reply-To: Quill.com [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Quill Values Your Opinion X-cid: quil.954.1 To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] X-RBL-Warning: SPAMHEADERS: This E-mail has headers consistent with spam [420e]. X-Declude-Sender: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [66.35.244.68] X-Declude-Spoolname: D388e01b4014a4491.SMD X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com http://www.declude.com) for spam. X-Spam-Tests-Failed: IPNOTINMX, NOLEGITCONTENT, SPAMHEADERS [3] X-Note: This E-mail was sent from (timeout) ([66.35.244.68]). X-RCPT-TO: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Status: U X-UIDL: 367773216 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Score not being added correctly, very serious...
Scott, I have a feeling that one of the recent changes created a bug in the way that scores are added in combination from the Global.cfg and the custom filter file when combined. Here's an example: X-MailPure: == X-MailPure: IPNOTINMX: Failed, IP is not listed in MX or A records (weight 0). X-MailPure: NOLEGITCONTENT: Failed, no legitimate content detected (weight 0). X-MailPure: HELOBOGUS: Failed, bogus connecting server name (weight 4). X-MailPure: DYNAMIC: Message failed DYNAMIC test (line 342, weight -3). X-MailPure: == X-MailPure: Spam Score: 1 X-MailPure: Scan Time: 13:19:42 on 12/22/2003 X-MailPure: Spool File: D35b701a9017c3a95.SMD X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: 66-109-42-67.ip.reallyfastnet.com [66.109.42.67] The DYNAMIC filter is scored as 3 points for a hit in Global.cfg DYNAMICfilter C:\IMail\Declude\Filters\Dynamic.txtx30 And within the filter file, it should have hit the following lines: REVDNS-3ENDSWITH.reallyfastnet.com REVDNS0CONTAINS-42- REVDNS0CONTAINS-109- The total score should have been 0 points, but it scored a -3 instead. The order of the individual lines in the filter are as they appear above. Naturally this is a serious issue as it affects all counterbalanced filters and I need to change my settings pretty quick otherwise I'm going to be letting a bunch of spam through. Thanks, Matt -- === Matthew S. Bramble President and Technical Coordinator iGaia Incorporated, Operator of NYcars.com --- Office Phone: (518) 862-9042 Cellular: (518) 229-3375 Fax: (518) 862-9044 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] === --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Overflow
Is this all being found on Windows 2003? I'm a couple of months away from adding a new server and this would definitely resolve any questions that I might have about Windows 2003 being an option. I know why John needs to play with the latest and greatest, but I have no such inclination or need. Matt R. Scott Perry wrote: It just happened again. I cleared the Cache and the backup cleared. What does the mean. That means that your DNS server is dying. It sounds like this may be a common problem with Microsoft DNS, where it starts choking if it has too much in its cache. Switching to the latest version of BIND may be the best option. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality.
George, That's good data to have. I would have to assume that something tagged as gibberish in the main test would be random, and that's fairly well indicated by the somewhat tight range of the two character strings. Unless you are using a logging feature that I'm not aware of, you are only showing the last hit that the filter produces, and that explains why the Z strings are mostly bunched at the top. I've got these ordered alphabetically and will probably leave them there for management purposes. The counterbalances though are definitely something that I will use your information for reordering them. I believe I made an attempt to order these in the 2.0 filter version according to what I thought would be more common as well as what would be a faster search (BODY searches are slower than other things and will go lower in general, though a BODY search for base64 goes at the top because it is fairly common). Because of this and along with the above mentioned issue, the hit stats therefore aren't a perfect indication of what would save the most processing power, but it definitely helps if you just make some assumptions. I hadn't gathered any stats myself on the Auto-generated Codes that I added in about a month or so ago, and it's nice to see that they're getting hit since I was really just brainstorming about what types of things might be seen. I might remove some entries though if they aren't showing being hit since they are BODY searches and expensive. I'll probably still leave that list of Auto-generated Codes in alphabetical order though for management purposes. This shouldn't make a big difference considering that the most common one only gets hit about 1-3% of the time (don't know how common the filter fails a later line which ends up getting logged instead). If Declude did log every line that hits in a filter, you would see things like GIBBERISH hitting some attachments thousands of times per message, and I don't think that's worth the trouble. Data like this will make a much bigger impact on performance if you run it against filters where hits can only occur once in a file due to unique data or exact matching. Kami has a bunch of those. Thanks, Matt George Kulman wrote: Matt, I thought you might be interested in the attached data which analyzes the GIBBERISH and ANTI-GIBBERISH filters by number of hits on my system from 11/15 through yesterday. If you're looking for effectiveness you should set the entries in descending order of probability. I use a variation which looks at date of most recent hit as well as hit count, although that's more important with filters that are being modified on a continual rather that a fairly static filter such as these two. George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 22, 2003 9:52 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. I've made some huge leaps forward recently in terms of the processing power required to run Declude with the custom filters that I have installed. This was done by way of the SKIPIFWEIGHT functionality introduced in the latest beta, but also by way of re-ordering my filters in the Global.cfg file so that the easiest to process custom filters are run first in the hopes of avoiding the need to run more costly ones. This new version of GIBBERISH makes use of functionality introduced in the 1.77 beta, however the most recent interim release, 1.77i7, should be used in order to guarantee proper operation (initial versions would always end processing, and effectively disabled the filters). The END functionality removes the need to have ANTI filters since the filter can be stopped before it gets to the main filter matches, and it also presents another opportunity to save on the processing power required to run such things. This also makes use of the MAXWEIGHT functionality to limit the max score as well as end processing once a single hit has been scored. Note that the filter will only log (at the LOW setting) and show WARN actions when the filter is tripped and an END was not hit...which is great! No more looking at non-scoring custom filters due to counterbalances :D Please read through the file and follow these instructions if you already have GIBBERISH installed: 1) Comment out the ANTI-GIBBERISH custom filter in your Global.cfg 2) Change the score of the GIBBERISH filter to 0 in your Global.cfg. 3) Change the scoring of the filter to match your system (it is scored by default for base 10 systems). This can be done by changing the MAXWEIGHT and Main Filter lines to reflect the multiple of 10 that your system is based on. 4) Change the SKIPIFWEIGHT score to reflect your delete weight, or whatever weight you would like for the filter to be skipped if the system has
Re: [Declude.JunkMail] Overflow
I've been rethinking my strategy for dealing with dictionary attacks on my server. While the nobody alias has proved to be problematic, so does not having a nobody alias due to the possibility of being dictionary attacked. I'm thinking of setting up all the nobody aliases to redirect E-mail to an account which deletes the message with an IMail rule. This way, a dictionary attack will find that all the E-mail gets accepted and hopefully stops attacking, while at the same time I'm not sending this E-mail to someone's real account. Is anyone getting dictionary attacked for long periods of time on a domain with a nobody alias or something that is gatewayed? Thanks, Matt Fritz Squib wrote: Hey guys, this sounds like same problem that I have been experiencing, however it has been a bunch of spam with c.c. 's to non-existant mail addresses on my server (dictionary attack style) ..My DNS is working fine. I spent the weekend returning mail from the old spool to a new spool that I had to create. I had around 67,000 of these buggers to deal with...no fun. All of the mail seems to be originating from dsl and cable modems with forged return addresses. My server is swamped again today - started again about 2-3 hours ago. Fritz Frederick P. Squib, Jr. Network Operations/Mail Administrator Citizens Telephone Company of Kecksburg http://www.wpa.net () ascii ribbon campaign - against html mail /\- against microsoft attachments --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. functionality. functionality.
Ick...but thanks for letting me know. Maybe this is better to have in debug. I could see some filters hitting even more than GIBBERISH does on Base64 stuff. Matt Bill Landry wrote: Matt, if you set your JunkMail logging to HIGH, you will see every line item that Declude matches on in the FILTER files Bill - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 22, 2003 12:17 PM Subject: Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. George, That's good data to have. I would have to assume that something tagged as gibberish in the main test would be random, and that's fairly well indicated by the somewhat tight range of the two character strings. Unless you are using a logging feature that I'm not aware of, you are only showing the last hit that the filter produces, and that explains why the Z strings are mostly bunched at the top. I've got these ordered alphabetically and will probably leave them there for management purposes. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- === Matthew S. Bramble President and Technical Coordinator iGaia Incorporated, Operator of NYcars.com --- Office Phone: (518) 862-9042 Cellular: (518) 229-3375 Fax: (518) 862-9044 E-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] === --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. functionality. functionality.
George, I think that logic can get you 95% of the way there with something as convoluted as this, that is run only about 1/3 of the time, and considering that you are only battling for about 2% of the processing power required by this filter alone, which shouldn't be too terribly much. Removing the comment blocks would probably have a bigger effect :) Changing to the new version of the filter should definitely help, though this isn't by far my most weighty filter. Here's something that I've very curious about though...the Y!DIRECTED filter contains a bunch of BODY searches for obfuscated strings, something that is almost totally redundant with the OBFUSCATION filter. I would be very curious to see how often those lines are hit because they could be dumped for a measurable performance increase. Any chance you want to take a crack at that? I wouldn't be surprised to see them never hit. Matt George Kulman wrote: Matt, I use LOGLEVEL HIGH for my data collection and analysis stuff and, as Bill pointed out, all hits are reflected. I've started to use SKIPIFWEIGHT. The result of course is that filters are bypassed and the statistics are skewed. For example on Friday 12/19, 15291 emails were processed by Declude on my system. Only 4604 were processed by the GIBBERISH filter. Of these 1328 had a total of 3854 hits. My quandary now is to decide whether to use the new control functions of SKIPIFWEIGHT, MAXWEIGHT and END to reduce processing overhead or to collect a full set of evaluation data by letting everything run. It's truly a catch-22 situation. If I collect all of the data, then I gain no benefit, since all of the processing takes place. If I take advantage of the analysis data, I reduce my processing workload but effectively destroy the validity of the statistical data which is now skewed by my filtering control. George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, December 22, 2003 3:17 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] GIBBERISH 2.0.1, single file filter with END functionality. functionality. George, That's good data to have. I would have to assume that something tagged as gibberish in the main test would be random, and that's fairly well indicated by the somewhat tight range of the two character strings. Unless you are using a logging feature that I'm not aware of, you are only showing the last hit that the filter produces, and that explains why the Z strings are mostly bunched at the top. I've got these ordered alphabetically and will probably leave them there for management purposes. The counterbalances though are definitely something that I will use your information for reordering them. I believe I made an attempt to order these in the 2.0 filter version according to what I thought would be more common as well as what would be a faster search (BODY searches are slower than other things and will go lower in general, though a BODY search for base64 goes at the top because it is fairly common). Because of this and along with the above mentioned issue, the hit stats therefore aren't a perfect indication of what would save the most processing power, but it definitely helps if you just make some assumptions. I hadn't gathered any stats myself on the Auto-generated Codes that I added in about a month or so ago, and it's nice to see that they're getting hit since I was really just brainstorming about what types of things might be seen. I might remove some entries though if they aren't showing being hit since they are BODY searches and expensive. I'll probably still leave that list of Auto-generated Codes in alphabetical order though for management purposes. This shouldn't make a big difference considering that the most common one only gets hit about 1-3% of the time (don't know how common the filter fails a later line which ends up getting logged instead). If Declude did log every line that hits in a filter, you would see things like GIBBERISH hitting some attachments thousands of times per message, and I don't think that's worth the trouble. Data like this will make a much bigger impact on performance if you run it against filters where hits can only occur once in a file due to unique data or exact matching. Kami has a bunch of those. Thanks, Matt George Kulman wrote: Matt, I thought you might be interested in the attached data which analyzes the GIBBERISH and ANTI-GIBBERISH filters by number of hits on my system from 11/15 through yesterday. If you're looking for effectiveness you should set the entries in descending order of probability. I use a variation which looks at date of most recent hit as well as hit count, although that's more important with filters that are being modified on a continual rather that a fairly static filter
Re: [Declude.JunkMail] Overflow
Nick, I think I might have been asking the question the other way around, though I'm not positive it was taken the wrong way. The theory here is that domains which accept every E-mail address in the HELO won't be dictionary attacked past a few attempts because the attacker's software will quickly determine that the attack isn't exposing any addresses due to a catch all situation. So maybe adding the nobody alias back in, and redirecting that E-mail to an account that deletes each E-mail automatically will resolve the issue of dictionary attacks? I see this stuff in my logs on occasion, but it never happens for a prolonged period of time. I'm thinking this is because 90% of my domains had nobody aliases. Unless someone only wants to DOS my server, dictionary attacking a domain with a nobody alias is a waste of their processing power just like it is a waste of mine. Matt Nick Hayer wrote: Hi Matt, Is anyone getting dictionary attacked for long periods of time on a domain with a nobody alias or something that is gatewayed? Thanks, Yes. I get hammered everyday..; I got rid of the nobody alias, filter the log files for the ip's that connected - and add them to my Imail Access control list. Currently that list contains nearly 10,000 ip's... -Nick Hayer Matt Fritz Squib wrote: Hey guys, this sounds like same problem that I have been experiencing, however it has been a bunch of spam with c.c. 's to non-existant mail addresses on my server (dictionary attack style) ..My DNS is working fine. I spent the weekend returning mail from the old spool to a new spool that I had to create. I had around 67,000 of these buggers to deal with...no fun. All of the mail seems to be originating from dsl and cable modems with forged return addresses. My server is swamped again today - started again about 2-3 hours ago. Fritz Frederick P. Squib, Jr. Network Operations/Mail Administrator Citizens Telephone Company of Kecksburg http://www.wpa.net () ascii ribbon campaign - against html mail /\- against microsoft attachments --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Overflow
John Tolmachoff (Lists) wrote: This is a cache only setup, no domains. Cost is a concern at this time, unless I can prove that would be the answer. However, as I said earlier, the problem was first experienced using BIND DNS servers. I need to follow up on this. Keith had a problem after a Microsoft hotfix a few months back. There are tweaks in the registry which can be done to expand the number of possible connections that a server can make (internal or external). Someone posted a link from another mail server with instructions on tweaking the settings for high volumes. Maybe Keith also came up with something as a result of his issues. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Comments test
R. Scott Perry wrote: The problem is that it is nearly impossible to determine which are valid HTML tags and which are not -- that would require a database of known good HTML tags, which would need to be constantly updated. This was the first filter that I tried writing actually :) I got a list of valid HTML tags and subtracted them from a list of two letter codes that I had, i.e. aa, ab, ac, etc. The problem is that you can define your own tags with XML and call them anything you want (and that might not be all of it). It was of course a fairly hefty filter as well. That led me to the idea of just going after two letter character combinations which were not in the dictionary. Maybe I can revisit that filter now by limiting the characters used to just the 15 most common letters (just 225 combination that cover probably 80% of dictionary words), and counterbalancing with some stuff that detects XML (which I hadn't thought of back then). This would work on both gibberish as well as dictionary randomization. The problem that has been appearing with more frequency as of late though is randomization with punctuation, mostly periods, but other characters as well. Periods of course are problematic because of too many legit uses in domain names and other things which can appear in E-mail. This stuff is all very processor intensive, so I've been avoiding it until I have a better handle on my other filters. Generally I can delete a piece of spam or pass an E-mail with a peak of about 10%-15% of my processor, however a non-spam 32K text message without attachments can drive both processors at an average of 80% for up to 5 seconds. I expect that the END functionality will help a great deal in those situations, but I'm also looking elsewhere to save. Just by reordering my filters, I think I saved about half of the processing power required on average after previously cutting things down with SKIPIFWEIGHT. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Junkmail Tests and Configs
Kami, I'm using a trick to show %ALLRECIPS% only when a message is held. I added an extra weight test as the hold weight and added the WARN action as follows: - Global.cfg - HIGH-RECIPSweightxx100 - $Default$.junkmail HIGH-RECIPSWARN X-MailPure: RECIPIENTS: %ALLRECIPS% This way they never see this in E-mail that passes through, and in the event of a false positive, I can deliver the E-mail correctly. Matt Kami Razvan wrote: Scott .. Just wondering.. Don't you need to have the %ALLRECIPS% in the header before this works? I know we deactivated it because it was defeating the purpose of BCC.. Since anyone looking at the header could see all the people being BCC'd. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Sunday, December 21, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Junkmail Tests and Configs I've tried using the BCC tests, and i sent some email my from an outside webmail server. The tests don't even show up as failing. I'm using one that will trigger when there are 3, 5 and 10 BCCs and I've sent an email with 5 bcc's, and the tests don't show up as failing at all. Is there something I'm missing since I did put the line in exactly as you show it. Are you running v1.75 or later? Are these really Bcc:'s, where the E-mail address of the recipient does not appear in the headers when IMail receives the E-mail? Are the Bcc: addresses addresses on your server (it is impossible to detect Bcc:'s on other servers)? -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Messages not scanned before shutdown...possible solution
I was worried when I saw another message come through last night without Declude headers in it considering that the queue issue has only been fixed in IMail 8.05 and not 7.15H3 which is what I'm using (and I don't yet care to upgrade, though I'm starting to get tempted with that fix). What happened this time is when my server was in the process of a shutdown, and the message that got through had the same exact time stamp on it as Event Viewer logged itself being stopped, and 4 seconds before the last IMail log entry. I'm assuming that as a part of shutdown, IMail must have executed some process that pushed this stuff out, or maybe it never got pushed to Declude and sat in the queue until after the server came back up, effectively bypassing Declude. This is a little worrisome considering that there were two other messages received in the few seconds after that one was passed, and I only get about 5,000 a day. I'm thinking that maybe this needs to be corrected in IMail similar to the queue processing behavior. While I'm still under the belief that the queue processing problem should only be seen about once a year on average, my server gets rebooted far more frequently than that. I wonder if shutting down IMail before a reboot would resolve this issue? A snippet of the log is below. I'm also wondering if maybe I could set something fancy up with IMail rules to check for the Declude headers and reprocess the message if missing. I have a feeling that I would need to create a program alias to handle something like this, and then redirect it through something like MS SMTP with IPBYPASS on for both server addresses? Or maybe I could just call SMTP32.exe or Declude.exe directly from the program alias (which gets passed a file name of the received E-mail, though I don't know that it's ready to be sent in a single file format. Anyone have any thoughts on this? This would probably be a good tool for all IMail users regardless of the version so that such issues are stopped, and it would resolve the queue issue on v7 despite no patch being available. Matt 20031220 044132 127.0.0.1 SMTPD (000A0016) [66.183.6.10] HELO d66-183-6-10.bchsia.telus.net -- This is the one that got through if not others. 20031220 044133 127.0.0.1 SMTPD (000A0016) [66.183.6.10] MAIL FROM: [EMAIL PROTECTED] 20031220 044133 127.0.0.1 SMTPD (033B01CA) [67.161.143.190] HELO c-67-161-143-190.client.comcast.net 20031220 044133 127.0.0.1 SMTPD (033B01CA) [67.161.143.190] MAIL FROM: [EMAIL PROTECTED] 20031220 044133 127.0.0.1 SMTPD (000A0016) [66.183.6.10] RCPT TO: [EMAIL PROTECTED] 20031220 044134 127.0.0.1 SMTPD (033B01CA) [67.161.143.190] RCPT TO: [EMAIL PROTECTED] 20031220 044135 127.0.0.1 SMTP (3316) processing E:\spool\Q1936000600161a3b.SMD 20031220 044135 127.0.0.1 SMTP (3316) ldeliver **.com bpettit-main (1) [EMAIL PROTECTED] 40545 20031220 044135 127.0.0.1 SMTP (3316) finished E:\spool\Q1936000600161a3b.SMD status=1 20031220 044135 127.0.0.1 SMTPD (033B01CA) [67.161.143.190] E:\spool\D194d033b01ca7490.SMD 1805 20031220 044136 127.0.0.1 SMTPD (000A0016) [66.183.6.10] E:\spool\D194d000a00167396.SMD 1577 20031220 044136 127.0.0.1 SMTPD (0002008C) [208.7.179.59] connect 204.127.131.126 port 63674 20031220 044136 127.0.0.1 SMTPD (0002008C) [204.127.131.126] EHLO mtiwgwc16.worldnet.att.net 20031220 044136 127.0.0.1 SMTPD (0002008C) [204.127.131.126] MAIL FROM:[EMAIL PROTECTED] 20031220 044136 127.0.0.1 SMTPD (0002008C) [204.127.131.126] RCPT TO:[EMAIL PROTECTED] 20031220 044137 127.0.0.1 SMTPD (0002008C) [204.127.131.126] E:\spool\D1952008c81b0.SMD 3383 SYSLOGD 7.15, Copyright © 1994-2001, Ipswitch, Inc. 20031220 044427 0.0.0.0:514 Server ready for action --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] 8.05- Declude not seen..
Keith, I would imagine that this affects versions all the way back to 7.0 and quite possibly far before then. The issue is very rare on an IMail 7 server because the window of opportunity for swiping a message by a queue run is so much smaller due to the speed at which something is passed on to Declude. It's even possible to get two copies, one scanned, and one not scanned. I worked out some math figuring 1/5th of a second as the window with 5,000 messages a day with the queue run 24 times a day and literally got a likelihood of 100% at 360 days. Obviously the steal window is something that I've guessed about. BTW, motivation beyond 7.07 would be primarily in the form of DOS patches, though I have found bugs that compelled me along the way :) Matt Keith Anderson wrote: This has never happened while running Imail 7.07, which is the version that has proven to be stable here. I see little motivation to upgrade to anything beyond 7.07 -Original Message- From: Kami Razvan [mailto:[EMAIL PROTECTED] Hi; I think the problem still exists.. The following is the header for an email that I received with no Declude header. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] [IMail Forum] 8.05- Declude not seen..
Bill, This can result in two copies of the file, one passed to Declude, and one stolen by the running of the queue. So it can still appear in the Declude logs, and chances are probably 80% that the Declude copy will at least be held on one of our systems and therefore we may not know about them. When I caught this on my server, the Declude copy was deleted. I'm not sure what the full scope of the errors being experienced are, but the queue thing that was suggested to have been fixed is one easily identified by a line in your log in the middle of the entries for a particular message being received that says the queue is being run. Matt Bill Landry wrote: Kami, I also periodically see messages without any Declude headers, however I find that the messages were processed by Declude because all of the normal log entries appear in the log file for the messages. I reported see this several months ago, but the explanation from Scott was My guess is that there is something incorrect with the original E-mail (perhaps using a CR to end a line rather than CRLF). Check your logs to see if these messages are actually getting processed or not. I suspect that they are being processed by Declude and that for some reason Declude cannot place it's headers in the message. Bill - Original Message - From: Kami Razvan mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Cc: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Saturday, December 20, 2003 7:07 AM Subject: [IMail Forum] 8.05- Declude not seen.. Hi; I think the problem still exists.. The following is the header for an email that I received with no Declude header. == Received: from adsl-68-76-191-150.dsl.akrnoh.ameritech.net [68.76.191.150] by clickandpledge.com (SMTPD32-8.05) id A69515F0046; Sat, 20 Dec 2003 07:54:45 -0500 Received: from [236.246.27.25] by adsl-68-76-191-150.dsl.akrnoh.ameritech.net with ESMTP id 34330738; Sun, 21 Dec 2003 08:51:50 +0600 Message-ID: [EMAIL PROTECTED] From: Albert Estrada [EMAIL PROTECTED] Reply-To: Albert Estrada [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: your vacation k qnkgtyhxvodlqbi Date: Sun, 21 Dec 03 08:51:50 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=_25AA.AC__.0 X-Priority: 3 X-MSMail-Priority: Normal X-RCPT-TO: [EMAIL PROTECTED] Status: U X-UIDL: 362538172 == So the line about 3rd party software having issues is still un-resolved. Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Weight processing
Kami Razvan wrote: I wish we could also skip the tests for negative weight.. Because right now the emails that we want to be delivered by negative weight actually will go through all tests since none can exit on a negative limit. I believe the idea here is to place the negative weight filters before the positive weight ones. Unless you want to totally whitelist something based on a filter (as opposed to pseudo-whitelisting it by crediting just some points), it makes sense that you wouldn't have a minimum weight. I guess I'm not really very trusting of anything not whitelisted on my system. I start my order with pseudo-whitelists, and then pseudo-blacklists, then the highest scoring filters that don't make much use of the body down to the lowest scoring filters that do heavy body searches. When I have ANTI files, I list those before the main tests. The logic is a little sloppy in the middle, but it seems to be the right idea. Naturally, it would also make sense to have absolutely everything else run before the custom filters. I suspect the IPNOTINMX thing is a bug instead of something by design. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SPF support to be added to next beta
Scott, I've been looking over this trying to figure out how to best implement it for my domains. It seems that since they are all on one class C, I should do the following: v=spf1 +a/24 +mx/24 -all Now three very important questions... 1) If I implement this, will intra-server E-mail fail this test? i.e. local mail customer at client IP 123.123.123.123 E-mail's me, where 123.123.123.123 is not a local address, but the address of the border router at the client's location. 2) When my clients who are SMTP blocked by their ISP (port 25), and forced to use their ISP's mail server, am I correct in assuming that this will fail? 3) If the answer is yes to either one of these, does this make more sense to implement against HELO instead of MAILFROM? This would seem to be more problematic than SPAMDOMAINS if it operates on MAILFROM, even if local domains could be excluded. Naturally, I might not be understanding this fully. If I changed the test to +all in order to prevent these issues (if real), then it seems that it would only be useful as a negative weight test when my data is used. Thanks, Matt R. Scott Perry wrote: We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SPF vs. Form Mail
R. Scott Perry wrote: I'm not sure if this is in the RFC, but it would be a lot more accurate if you could compare the HELO to the SPF data. Some scripts to also falsify the HELO, but no where near the number of forged domains in MAILFROM. The original design for SPF allowed for that, but the current one does not. I'm not sure why that was changed. This is kind of a response to all the follow ups this morning. I can't afford to use this test on the majority of my domains because I can't currently make use of WHITELIST AUTH, and I have enough customers that use third-party outgoing mail servers for one reason or another that this would cause issues there as well. I was already debating what to do with a spamdomains variant that was coded for local domains, and I was only scoring that at 20% of my fail weight. I could remove that test and replace it with SPF scored at 20%, however the effects of the SPF would carry over to other sources that would potentially have problems and over which I would have no control over. There is some potential with this as a negative weight test, however once the spammers catch on, the value would be diminished greatly, and of course legit mail servers are sources of spam, just not as often as the illegitimate ones, and I don't see the need to credit senders based only on the fact that they matched their SPF records. IPNOTINMX already does most of this as a dumb test, and I only give that 1 point of credit anyway. Considering these issues, I don't see why I should push something forward with such a flaw. I would however reevaluate the idea if it was modified to work on HELO instead of MAILFROM, though that would require some monitoring as there are always unexpected results. I hope that this can become a tool, and I'm all for the idea of supporting innovation by adding my own records to the mix, but I'm not convinced that this will help in it's current format. I don't believe you can verify the sender any more reliably than we already are with SMTP, and efforts should instead be focused on verifying the server. I'm very sorry to have not liked either this effort or the Web-O-Trust thing, and I don't want to sound like I'm just being critical for the sake of it (though sometimes I am overly critical), but I feel that it is constructive for me to say this if for no other reason than to warn others about the potential of issues, but hopefully rather to influence the process for the better. I'm sure there are others around here that feel the same way, but choose not to voice their opinions out of fear of insulting someone else...or maybe I'm just whacked :) Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Outbound Port 25, was - Virginia Indicts Indicts
Pete McNeil wrote: A tip-off is that the counter to this argument is up-front in their proposal. Specifically that they will create and manage a mechanism that tracks the end-user's subscrbe/unsubscribe requests... I think this is a lot like putting the foxes in charge of the hen house. I thought the tip-off was where they claimed that 15% of legitimate commercial E-mail was being blocked :) The good thing is that this will go no where because there are too many of us, and if it's unwanted and we block it, it only makes them look all the worse. As things stand, they have a lot of catching up to do. You don't create a monopoly out of anarchy. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] OT: DNS Issue (HELP)
Darrell, It looks like your name server records were maybe munged for a period of time from a root update that is now fixed. Those munged records though are being cached and they should get a good copy once they expire. This might explain why all of us seem to be able to resolve your domain, being that we aren't likely to have it cached being smaller providers, however the larger providers seem to have bad records for it because they hit your domain while the data was bad. Just guessing of course. If you have some local ISP's which are likely to have chached an earlier copy of the records, try querying their servers to see what it returns. I suspect that they will have a bad copy also, at least for a short period of time. I don't believe there is anything you can do about this if I am correct. Matt Darrell LaRock wrote: Scott, On the DNSSTUFF, I used the cached ISP report looking at the NS record. What does it mean when an ISP has the name server set to ns92.worldnic.com? Does this mean at one time when the domain was looked up it was not resolved from the root servers? ATT Worldnet #1NS=ns1.infi.net. [TTL=1d 9h 38m 50s] NS=ns2.infi.net. [TTL=1d 9h 38m 50s] ATT Worldnet #2NS=ns1.infi.net. [TTL=1d 4h 18m 50s] NS=ns2.infi.net. [TTL=1d 4h 18m 50s] ATT Worldnet #1NS=ns1.infi.net. [TTL=1d 2h 53m 53s] NS=ns2.infi.net. [TTL=1d 2h 53m 53s] ATT Worldnet #2NS=ns91.worldnic.com. [TTL=10h 45m 11s] NS=ns92.worldnic.com. [TTL=10h 45m 11s] Taking wild stabs in the dark :) Darrell -- Original Message -- From: R. Scott Perry [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 19 Dec 2003 22:56:28 -0500 However, something is seriously wrong as the major ISP's can't resolve it (Earthlink, Charter, Some AOL Users, Road Runner). This occured right after the whois info was updated to the new authoratative servers. That's probably the problem. Once the first .com parent server gets the new NS records, it takes up to about 6 hours for all the other .com parent servers to get updated, and another 48 hours before TTL values expire on DNS servers throughout the world. Earthlink, Charter, and some other larger ISPs almost certainly have the old values cached, which will take up to 48 hours to expire after the change. During that time, they will be using the old NS records. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] They got the pill spammer
...or at least one of them. There's no way this guy gets past Elliot Spitzer. I hope they take away his passport for obvious reasons. Target Spam: NY AG, Microsoft File $38M Suits http://www.spamhaus.org/rokso/evidence.lasso?rokso_id=ROK2985 This sounds a lot like the guy (ring) with the heavily puncuation-obfuscated text only messages. The investigators also determined that the e-mail messages were developed and sent from hijacked computers belonging to a foreign government's defense ministry, others from a hospital, and still more from elementary and high schools. According to the lawsuits, the spam messages used other people's sender names, false subject lines, fake server names, inaccurate and misrepresented sender addresses, or obscured transmission paths, all in violation of New York and Washington state law. I'm pretty sure that I was blocking over 98% of this stuff, but the volume was so immense that it showed up commonly enough, especially in my account where there are addresses on about 6 domains and listed publicly in association with hundreds of domains (registry and sites), and the crud spammers just simply hammer my account, though I don't get any contest spam (static spammers) which is the overwhelming volume that reaches my server. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] ZAPTHEDINGBAT v1.0.0 and Y!DIRECTED v1.0.4
The obfuscation exploit for IE that was reported a week ago is now being seen on my server (2 times yesterday). Both were PayPal scams, and in both instances, I would have passed the messages if I didn't have this filter in place because the only other test they failed was FRAUDDOMAINS (a variant of SPAMDOMAINS which is scored higher). The filter is now downloadable from my site, named ZAPTHEDINGBAT (which is what the bug is named). MailPure :: Filter Software :: Declude Filters http://www.mailpure.com/software/decludefilters/ Also, the Y!DIRECTED filter has been updated to v1.0.4. It now includes an additional string that someone discovered which spammers are now using for redirection through Yahoo. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Active X filter
The parm name entry is used outside of ActiveX, maybe not a good idea to include it here? Also, your scoring is going to be incremental with 4 for the filter in Global.cfg as well as 4 points for each line of the filter this hits. I'm not sure if that's what you intended. While this is probably highly indicative of spam (ones with Active X controls embedded to play video for instance, plus some others, Java for instance), Web designers, and especially Flash programmers, will get blocked by this. The spammers sending this stuff out generally are static IP'd, and I would personally err on the side of letting the RBL's take care of it rather than introduce more potential for FP's on my system. I haven't seen this stuff getting through except in a very rare case. Matt Doug Anderson wrote: If anyone wants BODY 4 CONTAINS object classid= BODY 4 CONTAINS codebase= BODY 4 CONTAINS .cab#version= BODY 4 CONTAINS param name= ACTIVEX-FILTER filter ActiveX-filter.txt x 4 0 Seems to work. Anyone got anything else? --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SPF vs. Form Mail
Andy, I'm with you on the idea being that this is much like SPAMDOMAINS, however, I don't think that I will be subtracting any points for E-mails that pass. I see spam coming through legit servers every day, and what's to stop a static spammer from adding these records to their own server? Nothing I assume, and that could present problems than it fixes if negatively weighted. I view this as a fail only test, and while I could probably score it at 80% comfortably while it is not in widespread use, I'm only going to weight it the same as my SPAMDOMAINS test which I believe is at 40% of my fail weight. I still have to read up on this some more and figure it all out, but am I correct that this matches the MAILFROM address and not something else like the the HELO? Matt Andy Schmidt wrote: Hi, I assume that Form Mail's are a big problem under SPF? If a web site (greeting card site) inserts the users email address as the from address, then it will fail SPF, correct? Or, if we host a web site for a client, the registrations or feedback form mailers email the input to the client using the from address of the web visitor (otherwise, clients tend to press the reply button and end up sending their acknowledgements to our mail server, rather than to the visitor). These emails will fail SPF, because the web visitors domain will not list our web server as a valid sender!? In other words, in real life, SPF is best use to subtract weight for PASS, rather than add (any substantial) weight for FAIL? It has to be treated like the SPAMDOMAINS test - except that the entries are maintained by the owner of each domain and thus are more likely to be accurate. But we can't reach block based on SPF failures without ignoring the reality of the www? Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: Andy Schmidt [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 05:20 PM To: '[EMAIL PROTECTED]' Subject: RE: [Declude.JunkMail] SPF caught SPAM already Wow, With only a few hundred domains registered, what were the chances that it would already catch spam: 12/18/2003 16:32:17 Q1cd609ef0252d469 DSBL:5 SPAMCOP:7 NJABLDUL:4 SORBS-DUL:5 CBL:7 SPFFAIL:8 . Total weight = 36. 12/18/2003 16:32:17 Q1cd609ef0252d469 Bypassing whitelisting of E-mail with weight =20 (36) and at least 1 recipients (1). ... 12/18/2003 16:32:18 Q1cd609ef0252d469 Msg failed SPFFAIL (SPF returned FAIL for this E-mail.). Action=IGNORE. ... 12/18/2003 16:32:18 Q1cd609ef0252d469 Deleting spam from [EMAIL PROTECTED] to ... 12/18/2003 16:32:18 Q1cd609ef0252d469 Subject: =?iso-8859-1?b?QWRkIEluY2hlcyB3aXRoIHRoZSBwYXRjaA==?= Best Regards Andy --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] SPF vs. Form Mail
R. Scott Perry wrote: I think whitelisting E-mail based on an SPF PASS probably isn't a wise idea, but I'm sure that spammers that do use SPF will be much easier to catch (they are providing a list of IPs that they may be spamming from G). If I was a spammer, I would use this to my advantage. These guys collect 2,000 IP's at a time, and move around their blocks in order to avoid being perma-listed in the RBL's already, and turning on and off some SPF listings can't be that much more difficult. Besides that, even legit servers pass spam. Forwarding is problematic for this test, and then there's the fact that very small-time spammers will use their ISP to send out their garbage. The very small-time spammers are the most likely to get through my server, but thankfully the volume is low. If SPF becomes popular, crediting points for passing the test will become a big no-no. Maybe this isn't something that you will want to support long-term? Normally, it uses the return address of the E-mail (MAILFROM, from the X-Declude-Sender: header). However, if there is a NULL return address, or the address isn't valid (postmaster, for example), then the domain in the HELO/EHLO will be used. I'm not sure if this is in the RFC, but it would be a lot more accurate if you could compare the HELO to the SPF data. Some scripts to also falsify the HELO, but no where near the number of forged domains in MAILFROM. Maybe a separate test possibility? Or even a replacement? I do like this whole idea a lot better than Web-O-Trust though. My only concern about the viability of this test is how responsible administrators will be in covering their scripts as well as their mail server. I suspect that human nature will show its face and mitigate the usefulness to some extent. The fact that this appears hard to understand at first glance (to me at least) tells me that it's likely to be screwed up. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Something to be blocking
The most troublesome crud spammer of them all (the p-patch guy) is currently sending out E-mails with the following line in the headers: X-Ki: random characters I'm going to throw in a filter for this as follows: HEADERS 30CONTAINS X-Ki: I suspect this pattern may be short-lived, but he just got 2 messages to me in a 5 minute space, coming from two different IP's. Someone needs to put this guy in jail for a long-time. The FBI could track this guy down in a matter of days. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Does anyone not have Reverse DNS?
Why not just require everyone in the world to show the secret sign before having their E-mail accepted? Sarcasm obviously, but reverse DNS entries are not necessary for E-mail to function properly, and in many cases won't even match the domain given in HELO...so why require it? This also will do near nothing to stop the flood of spam over the long-haul, so it appears to be a net negative due to the problems that this creates. Sorry, but I just see this as another blunt weapon, and again, something that becomes our problem to deal with when problems occur. Just like I expect to see many legit servers sending E-mail without DNS entries, I also expect companies which take such actions to be almost impossible to reach for corrections because they are obviously causing widespread problems and don't have the staff to handle all of the inquiries that would result, and of course, their lack of logic appears to have spread to other highly imperfect anti-spam measures which have blacklisted at least three list members reported in the last few days. The only positive about all of this is that it continues to prove the incompetence of such companies to deal with spam, and that just makes me look all the better. Naturally, this is all just my opinion, so please don't be offended that I disagree so strongly. Matt Andy Schmidt wrote: 1. ISPs are not accurately, clearly and fairly specifying RDNS entries. They need to do a better job of this, but have little motivation to do this. Well - I see your point and admit that there will be a painful time of adjustment. But frankly, providers like yours will adopt their policies, when many of their business customers suddenly have valid complaints that they are unable to send emails anymore. There is no need for them to DELEGATE DNS, but at least they have to offer to adopt their Reverse DNS to your needs (e.g. generic host entries for your domain). In the meantime, why not relay your outbound mail through your ISP? 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 Todd Holt Sent: Wednesday, December 17, 2003 01:33 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Does anyone not have Reverse DNS? Jason, Many ISPs refuse (for one reason or another) to delegate RDNS. For example, we have a T-1 from MPower in Las Vegas. It is business class. It has is a static block of 8 IPs. Normally considered by most as acceptable to host a mail server. But Mpower refuses to delegate RDNS. And a few times people on this list have set forth criteria that would classify us as unacceptable. Bundling us into the dynamic IP bunch because of our RNDS from MPower: las-DSL224-cust089.mpowercom.net The most common reason for this reasoning is that most admins consider DSL to be equal to consumer. But there is such a thing as SDSL (symmetric DSL) at speeds 2Mbit! A better hosting environment than my T-1. In conclusion, I see two distinct problems here: 1. ISPs are not accurately, clearly and fairly specifying RDNS entries. They need to do a better job of this, but have little motivation to do this. 2. Mail admins need to do a better job of creating criteria for mail classification. Don't lump all DSL into spam source. Don't put a lot of stock into what an RDNS says, just that it exists. I really appreciate Pete McNeil's unique approach in building a tool that looks for the same things that I would look for by hand, in the content, not the context. I think we need more out of the box thinking like this. Todd Holt Xidix Technologies, Inc Las Vegas, NV USA www.xidix.com 702.319.4349 -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 7:52 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] Does anyone not have Reverse DNS? I wanted to throw this question to the list: 1) Who does *NOT* have Reverse DNS (PTR) entries for their mailservers? 2) If so, why not? Personally I think reverse DNS entries adds an ounce of ownership to who actually uses an IP address. For instance, I have several IPs given to me by my colo provider. I have reverse DNS on all of them, even the IPs I haven't used yet. If anyone looks my IPs up they will see something like: Number.freedom2be.net as reverse DNS. This is basically telling them that freedom2be.net is the operator of the IP address. 3) Shouldn't all mail servers on the internet have a reverse DNS entry with some valid administrative domain name? We use freedom2be.net exclusively for our reverse DNS entries. As our mail server is multi-homed with many different domains. If someone needs to contact the appropriate owner of the IP, say our mail server was doing something bad (which it never has) they would
Re: [Declude.JunkMail] Any suggestions on some tests ??
If you have Declude JunkMail Pro, then the custom filters shared on my site are all generally good at detecting this sort of thing. This one in particular would have been it by DYNAMIC, FOREIGN, TLD-WESTERNEUROPEAN, and TLD-MIDDLEEASTERN for a total of 9 points (or 90% of fail weight according to recommended scoring) between those filters alone. http://www.mailpure.com/software/decludefilters/ The subject is also base64 encoded Latin-1 (normal text), and that can be filtered as well, though there are some rare occurrances where this can be used with foreign languages utilizing high-bit characters. SUBJECT 8 CONTAINS iso-8859-1?b? Matt Alejandro Valenzuela wrote: Is there any test on declude that will detect this ?? beside ipr4 tests ?? only failed one test, not enough to tag it as spam... (on WEIGHT=10) Received: from worldonline.de [80.230.246.63] by mail.fanosa.com with ESMTP (SMTPD32-8.04) id A910153400AA; Mon, 15 Dec 2003 23:24:48 -0500 To: [EMAIL PROTECTED] MIME-Version: 1.0 User-Agent: Mozilla/5.001 (windows; U; NT4.0; en-us) Gecko/25250101 Subject: =?iso-8859-1?b?VHJ5IFNvbWUgVmlhZ3JcYSEgSGFyZCBhcyBhIFBvbGUgaW4gMTUgbWludXRlc w==?= From: Darrell Middleton [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Date: Tue, 16 Dec 2003 05:29:24 + Content-Type: multipart/alternative; boundary==_NextPart_000_0889_494E5F41.4FA5DE8F X-RBL-Warning: SORBS_DUL: Dynamic IP Address See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=80.230.246.63 X-Declude-Sender: [EMAIL PROTECTED] [80.230.246.63] X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Spam-Tests-Failed: SORBS_DUL, IPNOTINMX, NOLEGITCONTENT [4] X-Country-Chain: X-Date-Time: 12/15/2003 @ 23:24:51 X-Note: This E-mail was sent from cable-246-63.inter.net.il ([80.230.246.63]). X-IMAIL-SPAM-URL-DBL: www.545dre2c.com X-RCPT-TO: DELETED Status: U X-UIDL: 365550799 htmlbody center!--4veh7o3diyt--a href=http://www.545dre2c.com?rid=1097; !--srq13mYftm2B-- img src=http://www.test57v6.com/a7.gif; border=0/a/center /html/body --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] recipient in the subject line
Jeffrey Di Gregorio wrote: Hello, Does anyone know of a way to add a weight to a message that has the recipients name in the subject line? My experience was that almost all of such stuff that reaches my server is from one spammer. You can set up a filter as follows if you have JunkMail Standard or Pro. This won't work forever though, but you will probably be surprised at how the patterns you see are related to just one sick puppy in the end. # Pexicom, Inc. - SBL5185 # Version: 1.0.3 # New Network Addresses # # - Global.cfg - # PEXICOMipfileC:\IMail\Declude\Filters\Pexicom.txtx250 64.124.165.0/25 [64.124.165.0] - [64.124.165.127] 64.124.165.128/26 [64.124.165.128] - [64.124.165.191] 64.124.165.192/27 [64.124.165.192] - [64.124.165.223] # aroundthefireplace.com # yourmorningheadlines.com # morninginspiration.com # signedbyme.com # gossipandnews.com # didyouhearthestory.com # westofthenile.com # myguidetoamerica.com # internetcrossingguard.com 64.125.181.0/24 [64.125.181.0] - [64.125.181.255] # pexicom.com # pexicast.com # audienceresults.com # pxsy6.com # pxlg.com # trffx.com # pxsy6.com # midx.net 208.184.54.0/25 [208.184.54.0] - [208.184.54.127] # homplat.com # smallslm.com # frstbas.com # mntgom.com # frbnks.com # flgstff.com # dsmoin.com 208.184.58.0/25 [208.184.58.0] - [208.184.58.127] # grandslm.com # scndbas.com # smallslm.com # lttroc.com # scrmen.com # pkspek.com # knscit.com 209.249.21.128/25 [209.249.21.128] - [209.249.21.255] # dnbury.com # wlmngt.com # tllhas.com # svnnah.com # hnlulu.com # crhele.com # sprnfl.com # trhaut.com 209.249.55.128/25 [209.249.55.128] - [209.249.55.255] # mailofc.com # moreml.com # abcdml.com # alephml.com # iptmail.com 216.200.60.16/28 [216.200.60.16] - [216.200.60.31] 216.200.60.32/27 [216.200.60.32] - [216.200.60.63] 216.200.60.64/26 [216.200.60.64] - [216.200.60.127] # ameriml.com # rqstmail.com # tgtml.com # jbrdmail.com # sentml.com # mailtize.com --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] recipient in the subject line
Kami, et al., I know it's a bit of a pain to maintain, and it doesn't take away from the benefits of having some variables for filtering, but there is an effective filter for something related that I haven't yet shared. The filter is called ADDRESSSUB, and it's quite simple and highly accurate, though it should be scored low for obvious reasons. I score this at just 20% of fail weight, though I could probably raise that without a problem, but I don't think I need it. To make this work, you just simply create a list of your own local domains and populate a filter file like so: SUBJECT0CONTAINS@clickandpledge.com SUBJECT0CONTAINS@local-domain2.com SUBJECT0CONTAINS@local-domain3.com SUBJECT0CONTAINS@local-domain4.com ...etc. I try to score very low things that I've seen or expect to see in regular old E-mail in order to mitigate issues with FP's. This is one of them. This is also one of the things you are also likely to see in combination with many other techniques. Matt Kami Razvan wrote: Hi; I am not sure you can except of listing them in a filter file and then searching that way. What would be GREAT is we could use variables in the filters. So %LOCALHOST% could be used as a filter. e.g. BODY 5 CONTAINS%LOCALHOST% this way one could dynamically change filters. The same with Recipient. But since I recently made a request I am not going to ask for more... One can only ask for so much! :) Kami From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Di Gregorio Sent: Tuesday, December 16, 2003 2:58 PM To: '[EMAIL PROTECTED]' Subject: [Declude.JunkMail] recipient in the subject line Hello, Does anyone know of a way to add a weight to a message that has the recipients name in the subject line? Thanks Jeffrey Di Gregorio Systems Administrator Pacific School of Religion 510-849-8283 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RR.COM
Scott, Your HELO (nerosoft.com) doesn't match your reverse DNS domain (mail.netbound.com). This could be the result of some idiot at AOL rejecting your E-mail based on those things not matching. The switch should be easy enough to test out this theory. Try changing your domain in IMail to netbound.com for just a second and see what happens. The reverse DNS change just takes a bit longer to propagate, though that might be a good idea to do for the long-term. Generally speaking, reverse DNS is used for E-mail filtering and nothing else of importance, so choose to match mail over all other things. Please let the list know if this works, though I'm just stabbing in the dark of course. I've seen places as large as GM block on just reverse DNS alone, which is pretty stupid in my book, and that warning from AOL's HELO has been there for months at least, and shows that they have at least considered this idiotic move. Matt Scott MacLean wrote: Does anyone know how to expedite getting removed from AOL/Netscape/Compuserve's IP spam list? I have no idea how we got there, but they have been blocking mail from every domain on my server for almost two weeks now. I can guarantee we've never sent any spam their way, or any way, for that matter. Attempting to send email to any of those domains ends up with this result: 20031216 000133 127.0.0.1 SMTP (0384324F) Trying aol.com (0) 20031216 000133 127.0.0.1 SMTP (0384324F) Connect aol.com [205.188.156.154:25] (1) 20031216 000133 127.0.0.1 SMTP (0384324F) 554-(RLY:B2) The information presently available to AOL indicates this 20031216 000133 127.0.0.1 SMTP (0384324F) 554-server is transmitting unsolicited e-mail to AOL. Based on AOL's 20031216 000133 127.0.0.1 SMTP (0384324F) 554-Unsolicited Bulk E-mail policy at http://www.aol.com/info/bulkemail.html 20031216 000133 127.0.0.1 SMTP (0384324F) 554-AOL cannot accept further e-mail transactions from this server. 20031216 000133 127.0.0.1 SMTP (0384324F) 554-Please have your ISP/ASP or server admin call AOL at 1-888-212-5537, 20031216 000133 127.0.0.1 SMTP (0384324F) 554 or visit http://postmaster.info.aol.com http://postmaster.info.aol.com/ for more information. 20031216 000133 127.0.0.1 SMTP (0384324F) SMTP_DELIV_FAILED They don't even give us a chance - we connect, and they dump us instantly. Calling them at that number gives you not much more than a promise that they'll look into it and get back to you, i.e. they won't bother and will never call you back. The postmaster web site doesn't help much. I'm at a bit of a loss. Hmmm. I just did a test from my mail server. I did a manual telnet to a few different AOL listed MX servers on port 25, and got this: 220-rly-ya02.mx.aol.com ESMTP mail_relay_in-ya2.4; Tue, 16 Dec 2003 17:55:45 -0500 220-America Online (AOL) and its affiliated companies do not 220- authorize the use of its proprietary computers and computer 220- networks to accept, transmit, or distribute unsolicited bulk 220- e-mail sent from the internet. Effective immediately: AOL 220- may no longer accept connections from IP addresses which 220 have no reverse-DNS (PTR record) assigned. I was able to do a manual HELO, RCPT FROM, MAIL TO, DATA and successfully send an email. The server has only one IP bound, so it can't be because it's using a different IP address. What gives? At 04:31 PM 12/16/2003, Bill wrote: Hi, FYI, rr.com has finally removed my IP from their spammer list as of today. It took 4 requests dating back to 11/18. I only knew we were no longer being blocked because one of my customers told me a message got through. My log file from today verified this to be true. I never did receive and messages from them other than the auto-responses. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Morgan Sent: Friday, December 12, 2003 11:49 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] RR.COM Hi, We are having a problem sending e-mail to any user at rr.com. Our messages are refused as spam. I have checked all of the databases that they say they use and we are not listed in any of them. Over the last three weeks, I have sent several messages to [EMAIL PROTECTED] (the address that they say to use for problems like this) but have only gotten automated responses confirming receipt of the message. Has anyone else had a problem with rr.com? If so, how did you resolve it? Thanks, Bill --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RR.COM
Sheldon Koehler wrote: I would LOVE to see AOL start blocking on RDNS! If they do it, then we can start doing it. Then within a few months, all of the legitimate mail servers on the planet will have proper RDNS and the Spammers will have a much harder time with life. Spam will decline a LOT!!! A lot, I'm not convinced. While it would become more reliable than it is now, it wouldn't likely become more than 90% accurate for years to come and by then there would be a widely supported method of verifying the sender's domain. Remember, the SBL type of spammer typically has reverse DNS lookups for all of the IP's that they send E-mail from, and the crud type of spammer typically use zombied machines that are virus infected and mostly sit on residential broadband connections with reverse DNS lookups. Such a test would do nothing for this type of thing. What this would mostly affect is E-mail scripts configured from Web sites that don't have reverse DNS lookups. Some of that is spam, but there's a good deal of it created by legit sources who also generally lack the understanding or capabilities to detect issues with their reverse DNS lookups and spam blocking. The Internet is anarchy, and you can't expect that the community as a whole will produce a much better result than it does currently. It's up to the responsible administrators who have the understanding, the time and the tools to protect their users from spam at the receiving end, not the other way around. You need look no further than the continued spread viruses for proof of concept, which continues in greater and greater numbers despite attempts by Microsoft to automate updates, user education, and the wide distribution of anti-virus products at reasonable prices. Blocking servers without reverse DNS lookups will only result in spammers avoiding such sources, or taking extra care to make sure they exist, it will not stop any serious spammer from doing their so-called job, and as far as I can tell, it only makes ours harder as a result. Look no further than AOL's recent activity for proof of that. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RR.COM
Maybe not necessarily a reply to your comments, but the problem is that SMTP wasn't designed for security. Heck, how many years was it before they came up with SMTP AUTH? SMTP needs to be reworked, and then you need to give the Internet another 5 to 10 years to catch up with the new standards. Until then, I'm calling this a business opportunity. Matt Todd Holt wrote: But only if its done accurately. And right now, the state of the RDNS entries is such that it can't be done accurately. This is due in large part to the ISPs not having proper RDNS entries (or having sweeping blocks of static and dynamic, business and consumer class IPs with the same RDNS entries). I would like to first see the ISPs start accurately coding the RDNS entries such that we can tell the businesses from the consumers. And I have no problem filtering on consumer connections running their own mail servers. Then I want the ISPs to crack down on their own customers that spam. Difficult thing to do!! Todd Holt Xidix Technologies, Inc Las Vegas, NV USA www.xidix.com 702.319.4349 -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Sheldon Koehler Sent: Tuesday, December 16, 2003 4:26 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] RR.COM Please let the list know if this works, though I'm just stabbing in the dark of course. I've seen places as large as GM block on just reverse DNS alone, which is pretty stupid in my book, and that warning from AOL's HELO has been there for months at least, and shows that they have at least considered this idiotic move. I would LOVE to see AOL start blocking on RDNS! If they do it, then we can start doing it. Then within a few months, all of the legitimate mail servers on the planet will have proper RDNS and the Spammers will have a much harder time with life. Spam will decline a LOT!!! Sheldon Sheldon Koehler, Owner/Partnerhttp://www.tenforward.com Ten Forward Communications 360-457-9023 Nationwide access, neighborhood support! Whenever you find yourself on the side of the majority, it's time to pause and reflect. Mark Twain --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RR.COM
Scott, Clearly then, you have been blacklisted by AOL by way of your IP. DNSStuff.com shows you to be clean, and God only knows what might have gotten you listed at AOL. They might even have you in their DUL list. Hopefully AOL will get burned by bad publicity as a result of their obvious issues in blocking spam. The sad thing is that they suck at blocking spam also. Wish I could help, but it sounds like you need to keep pressing buttons until you reach someone that cares. If you have a budget for it, try issuing a press release by way of the newswires which points out their flaws and warns customers to avoid their service until the problems are resolved, or rather, draft one and send it to their corporate communications officer for comment before sending it to the wire service. No doubt this will get you noticed. Matt Scott MacLean wrote: At 06:39 PM 12/16/2003, Matthew Bramble wrote: Your HELO (nerosoft.com) doesn't match your reverse DNS domain (mail.netbound.com). This could be the result of some idiot at AOL rejecting your E-mail based on those things not matching. The HELO changes depending on the virtual domain sending the email. If [EMAIL PROTECTED] has his acme.com domain hosted as a virtual domain on my mail server, and he sends an email, it gets sent out with a HELO acme.com. The RDNS can only have one value - and that one IP address could represent hundreds of different domains. The switch should be easy enough to test out this theory. Try changing your domain in IMail to netbound.com for just a second and see what happens. The reverse DNS change just takes a bit longer to propagate, though that might be a good idea to do for the long-term. Generally speaking, reverse DNS is used for E-mail filtering and nothing else of importance, so choose to match mail over all other things. I sent an email from a netbound.com address to an AOL address. It got rejected just as quickly. In fact, the AOL SMTP server terminates the connection before my server even gets a chance to send an HELO! Please let the list know if this works, though I'm just stabbing in the dark of course. I've seen places as large as GM block on just reverse DNS alone, which is pretty stupid in my book, and that warning from AOL's HELO has been there for months at least, and shows that they have at least considered this idiotic move. Matt Scott MacLean wrote: Does anyone know how to expedite getting removed from AOL/Netscape/Compuserve's IP spam list? I have no idea how we got there, but they have been blocking mail from every domain on my server for almost two weeks now. I can guarantee we've never sent any spam their way, or any way, for that matter. Attempting to send email to any of those domains ends up with this result: 20031216 000133 127.0.0.1 SMTP (0384324F) Trying aol.com (0) 20031216 000133 127.0.0.1 SMTP (0384324F) Connect aol.com [205.188.156.154:25] (1) 20031216 000133 127.0.0.1 SMTP (0384324F) 554-(RLY:B2) The information presently available to AOL indicates this 20031216 000133 127.0.0.1 SMTP (0384324F) 554-server is transmitting unsolicited e-mail to AOL. Based on AOL's 20031216 000133 127.0.0.1 SMTP (0384324F) 554-Unsolicited Bulk E-mail policy at http://www.aol.com/info/bulkemail.html 20031216 000133 127.0.0.1 SMTP (0384324F) 554-AOL cannot accept further e-mail transactions from this server. 20031216 000133 127.0.0.1 SMTP (0384324F) 554-Please have your ISP/ASP or server admin call AOL at 1-888-212-5537, 20031216 000133 127.0.0.1 SMTP (0384324F) 554 or visit http://postmaster.info.aol.com http://postmaster.info.aol.com/ http://postmaster.info.aol.com/ for more information. 20031216 000133 127.0.0.1 SMTP (0384324F) SMTP_DELIV_FAILED They don't even give us a chance - we connect, and they dump us instantly. Calling them at that number gives you not much more than a promise that they'll look into it and get back to you, i.e. they won't bother and will never call you back. The postmaster web site doesn't help much. I'm at a bit of a loss. Hmmm. I just did a test from my mail server. I did a manual telnet to a few different AOL listed MX servers on port 25, and got this: 220-rly-ya02.mx.aol.com ESMTP mail_relay_in-ya2.4; Tue, 16 Dec 2003 17:55:45 -0500 220-America Online (AOL) and its affiliated companies do not 220- authorize the use of its proprietary computers and computer 220- networks to accept, transmit, or distribute unsolicited bulk 220- e-mail sent from the internet. Effective immediately: AOL 220- may no longer accept connections from IP addresses which 220 have no reverse-DNS (PTR record) assigned. I was able to do a manual HELO, RCPT FROM, MAIL TO, DATA and successfully send an email. The server has only one IP bound, so it can't be because it's using a different IP address. What gives? At 04:31 PM 12/16/2003, Bill wrote: Hi, FYI, rr.com has
Re: [Declude.JunkMail] Getting exec time on less than DEBUG mode?
I'm somewhat with Paul on this. The only thing is though that one doesn't need to constantly get time stats in order to judge such a change, and I don't think that I would personally bother to run this consistently unless I had an issue that was more suitable for debug mode in the first place. Maybe if there were some log analyzer tools that would average this stuff out per day and per hour, it would become a much more useful way to gauge performance over time. Matt paul wrote: I think this is a feature request: Is there some way to get the ms exec time on Declude without going to debug log mode? I just revamped my tests (adding a bunch of filters) and it sure would be nice to be able to compare before/after execution times without getting bombed by debug mode. My logs are godzilla-sized as it is. If others think this may be useful, it could get changed. That would be useful Scott, however, maybe make it a logging ON/OFF switch? So if you need that to be logged, just have exectime ON or something in Global.cfg. Paul --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] whitelist / CC
Dave, Try not to whitelist things over which you have no control over or a relationship with, and when you do, and use the IP whenever possible. When it comes to things like this, you should set up a pseudo-whitelist, which credits some points, but only enough to mitigate the false postives that you are seeing on those sources. This way you will still have the benefit of the custom filters that you are running as well as external tests, or rather you might not want to take away all the false positive points and start the bar a bit higher since this is a known issue. You create a pseudo-whitelist by setting up a custom filter as a negative scoring test. It might be best to score the filter at a fixed amount and then make adjustments to the individual lines when necessary. I have mine set up primarily to help with things might fail SpamCop or MailPolice, so the default credit that I give is about 80% of fail weight. It's also important to look for the least likely to be spoofed identifier. IP's are the best but hard to come by, REVDNS is the next best choice. Things like MAILFROM are consistently spoofed if the claimed source is popular (like an ecommerce site or ISP). A HEADERS filter can also be done in instances where the MAILFROM is dynamic and is a source for multiple content providers (such as third party bulk mailers). It's best to stay away from the BODY when possible and counterbalance in the custom filters that might have issues, though Sniffer may need a BODY filter to counterbalance for an FP there. Matt David Dodell wrote: I have Imail/Declude Junkmail/Virus running as a front end for another server which is using Lyris for multiple mailing lists. I had a problem in the past that certain ISP's (ie bellsouth.net) would fail multiple SPAM tests, so users posting to those lists would have their mail rejected. I decided to try and get around it by whitelisting the names of the mailing lists, ie [EMAIL PROTECTED], in the thoughts that Spam would be rejected by Lyris since the spammer was not a subscriber to the list. Works well. However, I'm noticing some spam is getting through by having the mailing list name, with a bunch of other accounts, ie mine, postmaster, etc all as part of the CC line. Since one of the accounts is whitelisted, it appears that Declude is whitelisting the message and letting it also get through to all of the other accounts on that cc line. Any suggestions on how I can deal with this? I thought that I might have to make a user configuration file per mailing list which I could just WHITELIST as the entry, but if I do this, will it still whitelist the email for the others on the cc line? David --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Whitelist as a filter
R. Scott Perry wrote: This is an excellent idea -- not just for saving processing time on filters, but also to enhance the flexibility of whitelisting. This will be done for the next release. :) It will actually be *slightly* different, with Whitelist replacing the weight in the filters, so it would look like: BODYWHITELIST CONTAINSDeclude SUBJECT WHITELIST STARTSWITH Hello If there is a match, the filter will end, and the E-mail will be whitelisted (with no further filters being run). -Scott Scott, I'm not sure why this would be approached this way. Why not automatically stop Declude from processing all filters, custom, technical, RBL's, whatever, when something is whitelisted? Why would we want to have to start coding this information into our individual filters? Please reconsider. Thanks, Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
