See below Friday, May 14, 2004, 5:22:35 PM, Matt <[EMAIL PROTECTED]> wrote: M> Andy Schmidt wrote: M> Matt, M> � M> I think there is a misunderstanding (possiblyon MY side). M> � M> >> DUL/DYNA/DUHL tests from hitting your ownlocal users when M> they are sending E-mail (only one hop and M> typicallydynamic/residential), Declude disables any dnsbl, ip4r or M> rhsbl testwhen they have one of those strings in the name << M> � M> I was aware that DUL/DYNA/DUHL only checksthe LAST hop (the M> server connnecting to you) - but doesn't check theprior hops.� The M> idea is, that of course, ANY valid dial-up user willeventually M> appear in the first hop - the one to his provider's mailserver.� M> But a dial-up user should never be contacting YOUR mail M> serverdirectly - so the LAST hop should not come from a dial-up M> user. M> � M> What you are saying sounds almost like thereverse?�
M> The caviat is that if the connecting IP is from your own M> customertrying to send E-mail, it may very well be a DUL IP. However, if you are using Imail 8 with Authentication and Whitelist Auth in Declude, it doesn't matter. The mail is whitelisted, anyway and is not subject to the DUL tests or any other tests, for that matter. >>>I found that on locally hosted E-mail, this test would be �>>>defeated ifthe spammer forged a local address.�<< M> You mean forging an IP address?� Or forging aFROM address?� I M> don't believe Declude "trusts" the from address - ofcourse it will M> be forged for spam!?� M> At this moment, Declude will not apply scores from any dnsbl, M> ip4r orrhsbl tests if they have either DUL, DYNA or DUHL in the M> name AND theMail From matches a local user. I don't think that is accurate, except to the extent that if the user Authenticated (which has nothing to do with a forged 'from' address) that no checks will happen, since the e-mail is whitelisted at that point. OTOH, if it is not from an Authenticated user, and thus not a whitelisted e-mail, it is subject to all tests. M> � So to a certain M> extent, Declude does"trust" the from address.� The reason for this M> was to defeat DUL testsfor local users that might be sending from M> IP's listed in DUL lists. Apples and oranges. Stick to IP or the 'From' address. The test doesn't flip-flop. It's an ip4r or its an rhsbl test - they are mutually exclusive to a certain extent - however, both are moot with Imail 8 and Whitelist Auth, since the e-mail will be whitelisted and not subject to either test, if the sender authenticated for smtp. M> �This was good thinking before WHITELIST M> AUTH became available becauseotherwise we couldn't use DUL lists M> effectively if we hosted accountsand had users that came in from M> DUL IP's, but for those that canwhitelist all legitimate senders, M> either by IP, AUTH, or otherwiseguarantee that no one will be M> sending from a DUL tagged IP, turningthis feature off is of great M> benefit.� The work-around discussed todayis also an effective means M> of doing this. I don't think that's correct. You could whitelist your block of IP addresses, before Auth. However, you're talking about applying the DUL list to more than the last hop, which is totally different, and in doing so, you will inevitably come upon the sending IP, which is potentially listed on the DUL and therefore potentially tag a legitimate e-mail. However, if the e-mail is sent from one of your users, using your SMTP, then they will have authenticated, be whitelisted and not subject to the test. I just don't see what you really accomplish other than to do more DNS transactions. >>> Every user on mysystem uses AUTH and I'm on IMail 8 so I can >>> take advantage ofWHITELIST AUTH.� The issue now is that when a >>> spammer forges a locallyhosted address in the Mail From, Declude >>> is still disabling all dnsbl,ip4r and rhsbl tests that contain >>> either DUL, DYNA or DUHL in the name,and this now represents a >>> weakness instead of a benefit.�<< M> I use AUTH as well without problems. If youdon't want the M> DUL/DYNA/DUHL, then why are you using those strings? Good point. Although I really don't comprehend the value in the tests, the easy way around it would be to change the name of the tests to eliminate the DUL/DYNA/DUHL part of the string. Still, I don't comprehend why you'd want to do that. Maybe, my gray matter is back of book -- it's late for an old guy . . . . M> I was using those strings on non-DUL tests as a kludge.� I've M> tried toexplain this several times recently and in the past.� I M> score onmultiple hops, but I want to score hits on the connecting M> IP high thanon a relaying IP.� I am doing this because some spam is M> relayed fromone machine to another and even through an ISP's M> mailserver, but at thesame time, there is a higher false positive M> rate with relaying IP'sbecause some lists keep IP's in their M> database for many months or evenyears after they are nominated, and M> without an attempt to clean up thelisting.� ORDB for instance is M> very bad about this, and their removalprocess is useless in this M> regard since most broadband IP's don't havemail servers to receive M> the removal requests on. M> Take a look at the reply to Bill from two messages ago for M> furtherexplanation of why this is done, and note that I was only M> naming testslike XBL(DYNA) to make that one test only score on the M> last hop, andthe one marked XBL(ALL) would score on any hop that M> matched, includingthe first.� I have HOPHIGH set to 3 which means M> (I believe) that I amchecking as many as 4 hops (or 3 hops plus the M> connecting IP). I understand the weighting concept, but it is apples and oranges with the previous part of the thread. In the prior e-mail you talked about what I was potentially confused about and I hope that this response gives you a better picture of that. Thanks, M> Matt M> Best Regards M> Andy Schmidt M> H M Systems Software, Inc. M> 600 East Crescent Avenue, Suite 203 M> Upper Saddle River, NJ 07458-1846 M> Phone:� +1 201 934-3414x20 (Business) M> Fax:��� +1 201 934-9206 M> http://www.HM-Software.com/ M> -----Original Message----- M> M> From:[EMAIL PROTECTED]:[EMAIL PROTECTED] M> On Behalf Of Matt M> Sent: Friday, May 14, 2004 02:41 PM M> To:[EMAIL PROTECTED] M> Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK isblank M> Don, M> Since I started this thread, I'll try to answer what's at issue here. M> Declude has functionality to only scan the last hop on any M> dnsbl, ip4rand rhsbl test when it has either DUL, DYNA or DUHL in M> the name of thetest.� This is done in order to protect you from M> scoring hits ondial-up or residential IP's when they weren't the M> connecting server andwhen you are using Declude to score on M> multiple hops (I believe this isversion restricted). M> In order to keep these DUL/DYNA/DUHL tests from hitting your M> own localusers when they are sending E-mail (only one hop and M> typicallydynamic/residential), Declude disables any dnsbl, ip4r or M> rhsbl testwhen they have one of those strings in the name.� This M> was very usefuluntil IMail 8 came along and they started providing M> an indication ofwhether or not AUTH was used in the Q*.SMD file.� M> When IMail 8 didthat, Scott introduced a function called WHITELIST M> AUTH that willwhitelist any E-mail that is AUTH'd. M> Every user on my system uses AUTH and I'm on IMail 8 so I can M> takeadvantage of WHITELIST AUTH.� The issue now is that when a M> spammerforges a locally hosted address in the Mail From, Declude is M> stilldisabling all dnsbl, ip4r and rhsbl tests that contain either M> DUL, DYNAor DUHL in the name, and this now represents a weakness M> instead of abenefit.� So for users that have IMail 8, where all of M> their users arewhitelisted either by IP or by AUTH, it would be M> nice to turn thisfunctionality off. M> Something that seemed to confuse you was the fact that I am M> usingseveral tests twice like so: M> XBL(LAST)��� ��� dnsbl��� %IP4R%.sbl-xbl.spamhaus.org��� ���127.0.0.4��� 6��� 0 M> XBL(ALL)��� � � � � ip4r��� sbl-xbl.spamhaus.org�� � � � � � �� ��� ���127.0.0.4��� 2��� 0 M> The reason why I do this is because I score on multiple hops, M> andinstead of having XBL score exactly the same on every hop, I M> created awork around so that it would score higher on the last hop, M> and lower ifit only hit one of the prior hops.� The prior hop M> functionality helpswith catching spam that is relayed from one open M> relay to another openrelay, or worse yet, from an open relay to a M> legitimate mail server.�At the same time there are lots of IP's in M> some of these lists thathave long since been fixed/closed and are M> sending only legitimateE-mail through legitimate servers, and only M> adding a few points helpsprotect from false positives. M> The former kludge that I used was to use (DYNA) in the name of M> the testthat I only wanted to score on the last hop, but this M> morning, I foundthat on locally hosted E-mail, this test would be M> defeated if thespammer forged a local address.� By changing the M> test to how it appearsas XBL(LAST) in the above example, I'm M> creating a way to score only thelast hop without it being defeated M> when a local address is forged andDUL/DYNA/DUHL appears in the name. M> The short answer is that in the example above for XBL(LAST), M> using thednsbl/%IP4R% hack, you can construct a test that only hits M> the last hop(if you are scoring on multiple hops like I am). M> It's convoluted, but it works, and I do recommend doing it, but M> only ifyou understand how it works and why it is useful. M> Matt M> Don Brown wrote: M> Friday, May 14, 2004, 11:36:22 AM, R. Scott Perry <[EMAIL PROTECTED]> wrote: M> I seem to have broken things worse :) Is there any reason why the M> following wouldn't work? M> XBL(LAST) dnsbl %REMOTEIP%.sbl-xbl.spamhaus.org 127.0.0.4 M> 6 0 M> I tested the DUL lists using this format and it seemed to be M> working. Here's the headers from a single hop test that tripped on the M> ip4r version of XBL and returned the proper %REMOTEIP% in the headers: RSP>> The problem here is that the remote IP is 192.0.2.25, so Declude JunkMail RSP>> will create "192.0.2.25.sbl-xbl.spamhaus.org". But, you really want RSP>> "25.2.0.192.sbl-xbl.spamhaus.org". Fortunately, you can use: RSP>> XBL(LAST) dnsbl %IP4R%.sbl-xbl.spamhaus.org 127.0.0.4 6 RSP>> 0 RSP>> which should do what you want. RSP>> -Scott M> Since sbl-xbl.spamhaus.org is an ip4r list, doesn't the below do the M> same thing as using %IP4R% as shown above? If not, what is the M> difference? M> SBL-ALL ip4r sbl-xbl.spamhaus.org M> Thanks, M> ---- M> Don Brown - Dallas, Texas USA Internet Concepts, M> [EMAIL PROTECTED] http://www.inetconcepts.net(972) M> 788-2364 Fax: (972) 788-5049 M> ---- M> --- M> [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] M> --- M> This E-mail came from the Declude.JunkMail mailing list. To M> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and M> type "unsubscribe Declude.JunkMail". The archives can be found M> at http://www.mail-archive.com. M> -- M> ===================================================== M> MailPure custom filters for Declude JunkMail M> Pro.http://www.mailpure.com/software/===================================================== ---- Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net (972) 788-2364 Fax: (972) 788-5049 ---- --- [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.
