Re: [Declude.JunkMail] Logging change request, possible new tests, and honeypot processing
Darin Cox wrote: Gotcha. Thanks, Matt. I have another one: Adding a line to record sender IP/hostname to the log. Could be useful both for log reports and for building our own sender lists. The remote IP is already there, but the reverse DNS isn't. I would think that is more valuable than having the Message-ID like we have now, but Scott's away for a week so I would save such requests for when he gets back. Also, I've been thinking of some additional tests and considering writing some external tests where needed. 1. If sender address is an ISP (requires a lookup from a known ISP) and from address is another ISP (also determined from a lookup), then fail the test. Could help identify forging spam. Main task here is really just building the list of known ISPs. I too would love to have access to a variable that tracks the From address and not just the Mail From address (is that what you are getting at?). Currently this would have to be done in an external test which included header parsing to extract the From address since Declude doesn't currently provide that as a variable, though you could pass in the Mail From as a variable. I'm not sure though what the best approach would be to making use of this data as far as reliable scoring goes. 2. If domain is newly registered (configurable), fail the test. Could help identify spammers who constantly are registering new domains. I think I remember this idea being discussed on the list within the past couple of months, but I don't know if anyone has implemented anything. It's been discussed before. There are ways to query whois data and parse it on the fly, however currently every whois server that I am aware of has limitations that prohibit automated queries. There is also no caching mechanism for this data, so every time you check a domain, you have to do everything all over again, and that can be expensive. This would be most useful on domains parsed from the body of messages since the domains in zombie spam are mostly very short-lived and new. I think what really needs to happen here is for someone to come up with system where you query DNS (for caching), and if a domain isn't contained within DNS when queried, it is sought out and discovered for future queries. I would imagine that with BIND, you could do this by parsing the logs for non-matches and then automating the queries and subsequent population of the data (Windows can also be set up to log all queries). In such a system, there should be no reason why you couldn't query Mail From domains, reverse DNS domains, or URL domains. Also, if you cache the whois data on a centralized server, the number of queries on the registry shouldn't be that high. I'm game for throwing in some time this if there's a programmer around here that could handle the parsing/querying piece. 3. if sender name matches first part of email address (e.g. sender is joe [x.x.x.x], while recipient email address is [EMAIL PROTECTED]) then fail the test. Could help idenify forging spam. I think there are much stronger and more common patterns to tag here. I could be missing something though because zombies do very poorly on my system thanks to Sniffer and a multitude of pattern filters, and RBL's of course. Lastly, what are people using for honeypots? I'm assuming most are using program aliases in IMail to extract the info from the emails to build blacklists. Are there any existing solutions to this or is everyone building them from scratch each time? I'd be interested in putting together an IMail/SQL Server/DNS-BL system. Most around here don't use spam traps, they just look through held messages for patterns or IP's. Personally I have built a DNSBL/RHSBL that hits almost as often as SBL by simply finding a spammer's IP and then researching it manually so that I can identify whole blocks. Automating this sort of thing can be quite difficult because spam doesn't always come from servers or zombies operated by spammers. I've personally opted to go after static spammers, primarily because it is within my means, and because more than 90% of the spam that gets through my system comes from static spammers. I am not a big fan of automation because the value of a test is greatly impacted by the number and type of false positives. If you are looking for value from spam traps, Sniffer does a wonderful job and they will tag about 95% of the spam reaching your system and it's well worth paying for it when you might otherwise spend a lot more time building something automated that falls far short of it's accuracy and results. My only issue with Sniffer is with the false positives. Because it hits 95% of the spam, there are a fair number of false positives (although relatively few in comparison of hit rates on other tests), primarily on relationship-marketing materials that I don't consider spam, but others report as spam. These messages also commonly get SpamCo
Re: [Declude.JunkMail] f-prot
I find the Mcafee is the best at detecting viruses within encrupted zips. Otherwise they are pretty even. I'd recommend using F-Prot and Mcafee. Mcafee for the DOS command line scanner is dirt cheap. I'll see if I can find my price tomorrow. <<< [EMAIL PROTECTED] 5/15 12:29p >>> Can anyone tell me how f-prot compares to mcafee or symantec when it comes to keeping their database up with new viruses? That just seems pretty cheap but hey that's exactly what I'm looking for as long as it works well :) thanks, Larry Craddock --- [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] ALLRECIPs filter trouble
I'm currently using Imail/Declude as a gateway forwarding the e-mail onto my mail server. Out of my top 20 recipients, about 8 are employees that are long gone from my company or e-mail addresses that have never been. I assign these 20 points over my delete weight since I don't want the e-mails and what good is bouncing the sender with a user not found. If they were going to remove from the list, they had years to do it. Also by forcing lots of points to these dead accounts earlier in the process, they'll trigger the skipifweight and skip the bulk of my filters saving some CPU time. <<< [EMAIL PROTECTED] 5/16 4:32p >>> Scott, I am interested in what you are doing with this filter? Obviously you are checking if an incoming e-mail is for someone and assigning 20 points to it, but why? Goran Jovanovic The LAN Shoppe > -Original Message- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Scott Fisher > Sent: Friday, May 14, 2004 10:37 AM > To: [EMAIL PROTECTED] > Subject: [Declude.JunkMail] ALLRECIPs filter trouble > > I'm running 179i7. > > I'm not getting any matches on ALLRECIPS filters with the IS. Anyone have > any tips? > > ALLRECIPS 20 IS [EMAIL PROTECTED] > > > I am getting matches with the CONTAINS filter. > > ALLRECIPS 20 CONTAINS[EMAIL PROTECTED] > > Scott Fisher > Director of IT > Farm Progress Companies > > --- > [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 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. --- [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] Duplicate Logfile entries
Ok...hadn't ever noticed that behavior before in the logs. Guess I'd always been looking at single recipient emails. However, all recipients were in a single domain and we're using per-domain configuration...no per-user configs... so all actions would be the same. Darin. - Original Message - From: "Darrell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, May 16, 2004 11:47 PM Subject: Re: [Declude.JunkMail] Duplicate Logfile entries This is normal when the message has multiple recipients. This is because Declude can in certain instances take different actions based on recipients. Darrell - Check out http://www.invariantsystems.com for utilities for Declude and Imail Products. Quoting Darin Cox <[EMAIL PROTECTED]>: > Anyone else seeing duplicate sets of logfile entries? The FROM line changes, > but everything else is the same. Each subsequent FROM line has an additional > TO address before the IP. > > Darin. > > --- [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] Duplicate Logfile entries
This is normal when the message has multiple recipients. This is because Declude can in certain instances take different actions based on recipients. Darrell - Check out http://www.invariantsystems.com for utilities for Declude and Imail Products. Quoting Darin Cox <[EMAIL PROTECTED]>: > Anyone else seeing duplicate sets of logfile entries? The FROM line changes, > but everything else is the same. Each subsequent FROM line has an additional > TO address before the IP. > > Darin. > > --- [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] Duplicate Logfile entries
Anyone else seeing duplicate sets of logfile entries? The FROM line changes, but everything else is the same. Each subsequent FROM line has an additional TO address before the IP. Darin.
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Saturday, May 15, 2004, 4:58:34 PM, Andy Schmidt <[EMAIL PROTECTED]> wrote: [SNIP] AS> It should be an option. Those who need to bypass the DYNA tests on the AS> first hop should be able to - those who don't need to should not lose those AS> tests! But that was the point - You CAN do it NOW! No change to Declude is required and it doesn't matter if you are running Imail 8 or Imail 7, etc. The second point was that Imail 8 and WHITELIST AUTH doesn't universally solve the problem. It depends upon the SMTP SECURITY configuration in Imail 8 and your particular situation. If you don't know exactly, without any doubt, what I mean by that, then you could easily generate a lot of false positives by changing the 'out of the box' behavior of the DUL/DYNA/DUHL tests. Thanks, AS> Best Regards AS> Andy Schmidt AS> Phone: +1 201 934-3414 x20 (Business) AS> Fax:+1 201 934-9206 AS> -Original Message- AS> From: [EMAIL PROTECTED] AS> [mailto:[EMAIL PROTECTED] On Behalf Of Don Brown AS> Sent: Saturday, May 15, 2004 04:19 PM AS> To: Matt AS> Cc: [EMAIL PROTECTED] AS> Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank AS> This wasn't a bug or a larger issue of Declude trust based upon the 'from AS> Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were AS> the only ones skipped) when the 'from address' was spoofed as a local AS> address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, AS> either. AS> Imail 8 can still be configured where the Client is NOT required to Auth in AS> order to send. One example of that is 'Relay for Addresses.' AS> So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail AS> Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will AS> definitely tag our own customers. AS> So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL AS> mail, is only safe for those folks who: (1) are sure that none of their IP AS> addresses are on any DYNA/DUL/DUHL list (and will never be on AS> one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have AS> WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, AS> scanning the first hop is a simple matter of changing the test name to AS> eliminate the reserved string of DUL, DYNA or DUHL and using the hack which AS> Matt found. For instance: AS> Change this: AS> NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 AS> To this: AS> NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 AS> I don't think a switch in Declude is really needed. AS> Thanks, AS> Saturday, May 15, 2004, 10:01:11 AM, Matt <[EMAIL PROTECTED]> wrote: M>> Andy, M>> It's only been a matter of months since a realistic work around M>> wasavailable for most users (using WHITELIST AUTH). To the best of M>> myknowledge, I'm the only one of us that has said anything about it M>> onthis list (first time in March, but of course I could be wrong). M>> LikeI indicated though, there is a way to fix the problem using the M>> dnsbltrick, and it works immediately. I would however like to see a M>> switchgiven also, but this seems more like a convenience if you M>> useDUL/DYNA/DUHL the way that they were meant to be used in the M>> firstplace (which I was not), but still, it only means some extra M>> lookups. M>> Matt M>> Andy Schmidt wrote: M>> Thanks - ouch. M>> M>> I'd say that's a bug in design. M>> M>> Since AUTH is supported in Imail 8 and sinceothers may not allow M>> local users to send through their Imail server (myoutbound is going M>> through IIS SMTP with SMTP AUTH), there should be ATLEAST a config M>> option to turn this "spam me by faking sender" featureoff! M>> Best Regards M>> Andy Schmidt M>> Phone: +1 201 934-3414 x20(Business) M>> Fax: +1 201 934-9206 M>> -Original Message- M>> M>> From:[EMAIL PROTECTED]:Declude.JunkMail-owner M>> @declude.com] M>> On Behalf Of Matt M>> Sent: Saturday, May 15, 2004 01:49 AM M>> To:[EMAIL PROTECTED] M>> Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK isblank M>> In absentia... M>> M>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg17162.htm M>> l M>> This made a lot of sense before, and it was the only way to disable M>> DULtests for local users prior to IMail 8 and JunkMail ~1.76. M>> Decludewon't disable the tests for gatewayed domains, only where an M>> addressmatches a local account. You can also work around this by M>> using thednsbl trick like so: M>> DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 M>> 0 0 NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org M>> 127.0.0.3 0 0 NJABL-DYN-B dnsbl M>> %IP4R%.dynablock.njabl.org 127.0.0.3 0 0 SORBS-DYN M>> dnsbl %IP4R%.dnsbl.sorbs.net 127.0.0.10 0 0 M>> Note that I changed the names of the tests to exclude the M>> stringsDUL/DYNA/
RE: [Declude.JunkMail] ALLRECIPs filter trouble
Scott, I am interested in what you are doing with this filter? Obviously you are checking if an incoming e-mail is for someone and assigning 20 points to it, but why? Goran Jovanovic The LAN Shoppe > -Original Message- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Scott Fisher > Sent: Friday, May 14, 2004 10:37 AM > To: [EMAIL PROTECTED] > Subject: [Declude.JunkMail] ALLRECIPs filter trouble > > I'm running 179i7. > > I'm not getting any matches on ALLRECIPS filters with the IS. Anyone have > any tips? > > ALLRECIPS 20 IS [EMAIL PROTECTED] > > > I am getting matches with the CONTAINS filter. > > ALLRECIPS 20 CONTAINS[EMAIL PROTECTED] > > Scott Fisher > Director of IT > Farm Progress Companies > > --- > [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 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.
Re: [Declude.JunkMail] Logging change request, possible new tests, and honeypot processing
Gotcha. Thanks, Matt. I have another one: Adding a line to record sender IP/hostname to the log. Could be useful both for log reports and for building our own sender lists. Also, I've been thinking of some additional tests and considering writing some external tests where needed. 1. If sender address is an ISP (requires a lookup from a known ISP) and from address is another ISP (also determined from a lookup), then fail the test. Could help identify forging spam. Main task here is really just building the list of known ISPs. 2. If domain is newly registered (configurable), fail the test. Could help identify spammers who constantly are registering new domains. I think I remember this idea being discussed on the list within the past couple of months, but I don't know if anyone has implemented anything. 3. if sender name matches first part of email address (e.g. sender is joe [x.x.x.x], while recipient email address is [EMAIL PROTECTED]) then fail the test. Could help idenify forging spam. Lastly, what are people using for honeypots? I'm assuming most are using program aliases in IMail to extract the info from the emails to build blacklists. Are there any existing solutions to this or is everyone building them from scratch each time? I'd be interested in putting together an IMail/SQL Server/DNS-BL system. Thoughts? Darin. - Original Message - From: Matt To: [EMAIL PROTECTED] Sent: Sunday, May 16, 2004 1:40 PM Subject: Re: [Declude.JunkMail] Logging change request That was moved in a recent interim release.MattDarin Cox wrote: I'd like to have the Last Action line in the log moved from LOGLEVEL HIGH to LOGLEVEL MID to reduce the size of logs but still have an easy indicator as to what was done with the message. Would help greatly with log parsing at MID level, I think. Anyone agree or disagree with this? Darin. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] Logging change request
That was moved in a recent interim release. Matt Darin Cox wrote: I'd like to have the Last Action line in the log moved from LOGLEVEL HIGH to LOGLEVEL MID to reduce the size of logs but still have an easy indicator as to what was done with the message. Would help greatly with log parsing at MID level, I think. Anyone agree or disagree with this? Darin. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
[Declude.JunkMail] Logging change request
I'd like to have the Last Action line in the log moved from LOGLEVEL HIGH to LOGLEVEL MID to reduce the size of logs but still have an easy indicator as to what was done with the message. Would help greatly with log parsing at MID level, I think. Anyone agree or disagree with this? Darin.
