RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Matt I understand the logic and I think it can be very usefull for certain IP Blacklist a having relative high FP rate. From my reports I can see that XBL has had a FP (or "wrong result") in the last 14 days and 123000 messages only in 54 cases. This is a very low FP-rate. But there are other tests like FIVETEN-SRC that has had a wrong result in the same range for 9100 messages. The question is if FIVETEN-SRC allows a %IP4R% lookup. Markus From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Friday, May 14, 2004 10:30 PMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank Bill,The value is in scoring the last hop hits higher than prior hop hits. In this case, a hit on XBL for the last appropriate hop (not IPBYPASSED) would result in 8 points (6 + 2), while a hit on a prior hop would result in just 2 points. Note that the number of false positives is much higher with prior hops on tests that populate from spamtraps or are designed to detect open relays. Tests like SBL and other static spam source tests have very little danger in scoring the same for every hop, though SBL will sometimes list spam zombies that are unresolved for periods of time (I wish they didn't do that).MattBill Landry wrote: - Original Message - From: "Matt" [EMAIL PROTECTED] XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org127.0.0.4 60 XBL(ALL)ip4rsbl-xbl.spamhaus.org 127.0.0.420 Scott/Matt, would a configuration like above require multiple DNS queries since the hostnames defined in the tests are no longer identical? Or is the variable (in this case "%IP4R%") ignored in the hostname, so that as far as Declude is concerned, the hostnames are still identical? 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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Matt, But if you rename the tests to DYN than how you are configuring non-DUL tests twice? Darrell From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Saturday, May 15, 2004 6:42 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank Andy, I think there might be some confusion here. If you change the test names and use the %IP4R%/dnsbl trick, it will always test the first hop regardless of what the Mail From is, unless of course you are whitelisting the sender. You don't have to remove the tests, you just have to rename them. I renamed mine with DYN, that way Declude doesn't see them as matching DUL/DYNA/DUHL and therefore will not skip them when the Mail From matches a local address. The only drawback that I have found with this work around is when you try configuring non-DUL tests twice, once only for the first hop, and once for all hops, in which case the work around will cause some extra lookups, but that's minor, and I'm only aware of a few people besides myself that are doing this. Nothing else appears to be a problem in anyway whatsoever. Matt Andy Schmidt wrote: Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHLand using the hack which Matt found. NO - removing DUL/DYNA/DUHL is NOT an option. Because MUCH of the privateemails originate from some address that is on that list - but only on theFIRST hope. Thus, the DUL/DYNA/DUHL skip tests on the FIRST hop! They can't be omitted - otherwise we'd block most private mail relayedthrough other providers SMTP servers.Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Don BrownSent: Saturday, May 15, 2004 04:19 PMTo: MattCc: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blankThis wasn't a bug or a larger issue of Declude trust based upon the 'fromAddress.' There was no choice but to skip DUL/DYNA/DUHL tests (which werethe only ones skipped) when the 'from address' was spoofed as a localaddress. Imail 8 and WHITELIST AUTH help, but they don't solve this issue,either.Imail 8 can still be configured where the Client is NOT required to Auth inorder to send. One example of that is 'Relay for Addresses.'So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No MailRelay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we willdefinitely tag our own customers.So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALLmail, is only safe for those folks who: (1) are sure that none of their IPaddresses are on any DYNA/DUL/DUHL list (and will never be onone) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and haveWHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases,scanning the first hop is a simple matter of changing the test name toeliminate the reserved string of DUL, DYNA or DUHL and using the hack whichMatt found. For instance:Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0I don't think a switch in Declude is really needed.Thanks,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 MattM 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 RegardsM 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-ownerM @declude.com]M On Behalf Of MattM Sent: Saturday, May 15, 2004 01:49 AMM 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.htmM 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
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Markus Gufler wrote: But there are other tests like FIVETEN-SRC that has had a wrong result in the same range for 9100 messages. The question is if FIVETEN-SRC allows a %IP4R% lookup. They are all in fact IP4R lookups (if that is what the test is set for). If you set Declude to say HOPHIGH 3 and use the test in standard fashion, Declude will test as many as 4 IP's against the 'ip4r' test. If you use the hack and define it as a 'dnsbl' test with the %IP4R% variable, regardless of the HOPHIGH setting, it will only test the last appropriate IP (bypasses IP's that are IPBYPASSed). I have been scoring last hop and all hops differently for several months now with good results. Certainly the last hop is most important, but a little bit of spam is being relayed through legitimate servers or from one open relay to another, which is why I test on multiple hops. There are noticeably more false positives though on tests that track open relays because many of those lists don't expire their listings quickly enough, re-test, or do anything at all to remove old entries. Because of this, I score the last hop relatively high with one test (now using the %IP4R% variable and a dnsbl type test), and another test that is set up the normal way and scored lower because it can hit any of the hops where it might hit one of those old entries in a spamtrap/open relay type test. I have found that this technique is not measurably useful with tests that track static sources such as SBL, AHBL-SOURCES, NJABL-SOURCES, and some others. The reason is because these are 99.9% IP's belonging to spammers, delegated to them by their ISP's. So if you chose to split up tests with this technique, you only need to use it on spamtrap/open relay tests like ORDB, XBL, SPAMCOP and other similar resources. Note that FIVETEN-SRC and SORBS-SPAM are supposedly source tests, but they do mix IP's from zombies that have sent them spam, and their removal procedures are almost non-existant. I also don't like their way of breaking down data, as FIVETEN for instance can produce a hit for an open relay on as many as 3 of their tests, and that doesn't work well with Declude unless you combo the test with a custom filter so that it only scores once. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Darrell LaRock wrote: Matt, But if you rename the tests to DYN than how you are configuring non-DUL tests twice? For DUL-type tests, I am only configuring them once, i.e. DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 0 0 NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 0 0 NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org 127.0.0.3 0 0 SORBS-DYN dnsbl %IP4R%.dnsbl.sorbs.net 127.0.0.10 0 0 You seem confused about how I was using one of the magic names for a hack that I was using for non-DUL-type tests. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Hi Andy, Look at the example, again and note the %IP4R%. That tests ONLY the 1st HOP (or for clarity, the IP which delivered the mail to your server). Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 Saturday, May 15, 2004, 5:01:47 PM, Andy Schmidt [EMAIL PROTECTED] wrote: Then, in either cases, scanning the first hop is a simple matter of AS changing the test name to eliminate the reserved string of DUL, DYNA or DUHL AS and using the hack which Matt found. AS NO - removing DUL/DYNA/DUHL is NOT an option. Because MUCH of the private AS emails originate from some address that is on that list - but only on the AS FIRST hope. Thus, the DUL/DYNA/DUHL skip tests on the FIRST hop! AS They can't be omitted - otherwise we'd block most private mail relayed AS through other providers SMTP servers. 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/DUHL
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/DUHL. This took me a long time to figure out, so the M trickisn't that common, however I started using these strings to M limit somenon-DUL
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
In absentia... http://www.mail-archive.com/[EMAIL PROTECTED]/msg17162.html This made a lot of sense before, and it was the only way to disable DUL tests for local users prior to IMail 8 and JunkMail ~1.76. Declude won't disable the tests for gatewayed domains, only where an address matches a local account. You can also work around this by using the dnsbl trick like so: DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 0 0 NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 0 0 NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org 127.0.0.3 0 0 SORBS-DYN dnsbl %IP4R%.dnsbl.sorbs.net 127.0.0.10 0 0 Note that I changed the names of the tests to exclude the strings DUL/DYNA/DUHL. This took me a long time to figure out, so the trick isn't that common, however I started using these strings to limit some non-DUL tests to just the last hop with higher scoring, and did impact my ability to block spam on local accounts, however it took me quite a while to notice that it was going on (several months). Matt Andy Schmidt wrote: Message Scott (in case you're not gone yet): At this moment, Declude will not apply scores from any dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA or DUHL in the name AND the Mail From matches a local user. Does Declude REALLY trust the mail from and will bypass DUL/DYNA/DUHL test just by someone forging the mail from? Never heard about that "bug"/behavior before? Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Title: Message Thanks - ouch. I'd say that's a bug in design. Since AUTH is supported in Imail 8 and since others may not allow local users to send through their Imail server (my outbound is going through IIS SMTP with SMTP AUTH), there should be AT LEAST a config option to turn this "spam me by faking sender" feature off! Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Saturday, May 15, 2004 01:49 AMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blankIn absentia... http://www.mail-archive.com/[EMAIL PROTECTED]/msg17162.htmlThis made a lot of sense before, and it was the only way to disable DUL tests for local users prior to IMail 8 and JunkMail ~1.76. Declude won't disable the tests for gatewayed domains, only where an address matches a local account. You can also work around this by using the dnsbl trick like so:DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 0 0NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 0 0NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org 127.0.0.3 0 0SORBS-DYN dnsbl %IP4R%.dnsbl.sorbs.net 127.0.0.10 0 0Note that I changed the names of the tests to exclude the strings DUL/DYNA/DUHL. This took me a long time to figure out, so the trick isn't that common, however I started using these strings to limit some non-DUL tests to just the last hop with higher scoring, and did impact my ability to block spam on local accounts, however it took me quite a while to notice that it was going on (several months).MattAndy Schmidt wrote: Scott (in case you're not gone yet): At this moment, Declude will not apply scores from any dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA or DUHL in the name AND the Mail From matches a local user. Does Declude REALLY trust the mail from and will bypass DUL/DYNA/DUHL test just by someone forging the mail from? Never heard about that "bug"/behavior before? Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206 -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Andy,
It's only been a matter of months since a realistic work around was
available for most users (using WHITELIST AUTH). To the best of my
knowledge, I'm the only one of us that has said anything about it on
this list (first time in March, but of course I could be wrong). Like
I indicated though, there is a way to fix the problem using the dnsbl
trick, and it works immediately. I would however like to see a switch
given also, but this seems more like a convenience if you use
DUL/DYNA/DUHL the way that they were meant to be used in the first
place (which I was not), but still, it only means some extra lookups.
Matt
Andy Schmidt wrote:
Message
Thanks - ouch.
I'd say that's a bug in design.
Since AUTH is supported in Imail 8 and since
others may not allow local users to send through their Imail server (my
outbound is going through IIS SMTP with SMTP AUTH), there should be AT
LEAST a config option to turn this "spam me by faking sender" feature
off!
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 Matt
Sent: Saturday, May 15, 2004 01:49 AM
To: [EMAIL PROTECTED]
Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is
blank
In absentia...
http://www.mail-archive.com/[EMAIL PROTECTED]/msg17162.html
This made a lot of sense before, and it was the only way to disable DUL
tests for local users prior to IMail 8 and JunkMail ~1.76. Declude
won't disable the tests for gatewayed domains, only where an address
matches a local account. You can also work around this by using the
dnsbl trick like so:
DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net
127.0.0.3 0 0
NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org
127.0.0.3 0 0
NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org
127.0.0.3 0 0
SORBS-DYN dnsbl %IP4R%.dnsbl.sorbs.net
127.0.0.10 0 0
Note that I changed the names of the tests to exclude the strings
DUL/DYNA/DUHL. This took me a long time to figure out, so the trick
isn't that common, however I started using these strings to limit some
non-DUL tests to just the last hop with higher scoring, and did impact
my ability to block spam on local accounts, however it took me quite a
while to notice that it was going on (several months).
Matt
Andy Schmidt wrote:
Scott (in case you're not gone yet):
At this moment, Declude will not apply scores
from any dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA or
DUHL in the name AND the Mail From matches a local user.
Does Declude REALLY trust the mail from and
will bypass DUL/DYNA/DUHL test just by someone forging the mail from?
Never heard about that "bug"/behavior before?
Best Regards
Andy Schmidt
Phone: +1 201 934-3414 x20
(Business)
Fax: +1 201 934-9206
--
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=
--
=
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
This wasn't a bug or a larger issue of Declude trust based upon the 'from Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were the only ones skipped) when the 'from address' was spoofed as a local address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, either. Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL mail, is only safe for those folks who: (1) are sure that none of their IP addresses are on any DYNA/DUL/DUHL list (and will never be on one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. For instance: Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 I don't think a switch in Declude is really needed. Thanks, 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 M a 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 M allow local users to send through their Imail server (myoutbound is M going through IIS SMTP with SMTP AUTH), there should be ATLEAST a M config 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]:[EMAIL PROTECTED] 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.html M This made a lot of sense before, and it was the only way to M disable DULtests for local users prior to IMail 8 and JunkMail M ~1.76. Decludewon't disable the tests for gatewayed domains, only M where an addressmatches a local account. You can also work around M this by using thednsbl trick like so: M DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 0 0 M NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 0 0 M NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org 127.0.0.3 0 0 M SORBS-DYN 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/DUHL. This took me a long time to figure out, so M the trickisn't that common, however I started using these strings M to limit somenon-DUL tests to just the last hop with higher M scoring, and did impactmy ability to block spam on local accounts, M however it took me quite awhile to notice that it was going on M (several months). M Matt M Andy Schmidt wrote: M Scott (in case you're not gone yet): M MAt this moment, Declude will not apply scoresfrom any M dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA orDUHL in M the name AND the Mail From matches a local user. M M Does Declude REALLY trust the mail from andwill bypass M DUL/DYNA/DUHL test just by someone forging the mail from? M M Never heard about that bug/behavior before? M Best Regards M Andy Schmidt M Phone: +1 201 934-3414 x20(Business) M Fax: +1 201 934-9206 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-2364Fax: (972) 788-5049 --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' If you use 'Relay for Addresses.', you can easily list the same adresses in JunkMail. This is the equivalent of whitelist auth - Original Message - From: Don Brown [EMAIL PROTECTED] To: Matt [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, May 15, 2004 8:19 PM Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank This wasn't a bug or a larger issue of Declude trust based upon the 'from Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were the only ones skipped) when the 'from address' was spoofed as a local address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, either. Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL mail, is only safe for those folks who: (1) are sure that none of their IP addresses are on any DYNA/DUL/DUHL list (and will never be on one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. For instance: Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 I don't think a switch in Declude is really needed. Thanks, 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 M a 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 M allow local users to send through their Imail server (myoutbound is M going through IIS SMTP with SMTP AUTH), there should be ATLEAST a M config 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]:[EMAIL PROTECTED] e.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.html M This made a lot of sense before, and it was the only way to M disable DULtests for local users prior to IMail 8 and JunkMail M ~1.76. Decludewon't disable the tests for gatewayed domains, only M where an addressmatches a local account. You can also work around M this by using thednsbl trick like so: M DNSRBL-DYN dnsbl %IP4R%.dun.dnsrbl.net 127.0.0.3 0 0 M NJABL-DYN-A dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 0 0 M NJABL-DYN-B dnsbl %IP4R%.dynablock.njabl.org 127.0.0.3 0 0 M SORBS-DYN 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/DUHL. This took me a long time to figure out, so M the trickisn't that common, however I started using these strings M to limit somenon-DUL tests to just the last hop with higher M scoring, and did impactmy ability to block spam on local accounts, M however it took me quite awhile to notice that it was going on M (several months). M Matt M Andy Schmidt wrote: M Scott (in case you're not gone yet): M MAt this moment, Declude will not apply scoresfrom any M dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA orDUHL in M the name AND the Mail From matches a local user. M M Does Declude REALLY trust the mail from andwill bypass M DUL/DYNA/DUHL test just by someone forging the mail from? M M Never heard about that bug/behavior before? M Best Regards M Andy Schmidt M Phone: +1 201 934-3414 x20(Business) M Fax: +1 201 934-9206 M -- M = M MailPure
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. Only if you are not using Imail 8 with AUTH and only if you are using Imail for outbound mail relaying. Neither is true in my case. It should be an option. Those who need to bypass the DYNA tests on the first hop should be able to - those who don't need to should not lose those tests! 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 Don Brown Sent: Saturday, May 15, 2004 04:19 PM To: Matt Cc: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank This wasn't a bug or a larger issue of Declude trust based upon the 'from Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were the only ones skipped) when the 'from address' was spoofed as a local address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, either. Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL mail, is only safe for those folks who: (1) are sure that none of their IP addresses are on any DYNA/DUL/DUHL list (and will never be on one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. For instance: Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 I don't think a switch in Declude is really needed. Thanks, 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/DUHL. This took me a long time to figure out, so the M trickisn't that common, however I started using these strings to M limit somenon-DUL tests to just the last hop with higher scoring, and M did impactmy ability to block spam on local accounts, however it took M me quite awhile to notice that it was going on (several months). M Matt M Andy Schmidt wrote: M Scott (in case you're not gone yet): M MAt this moment, Declude will not apply scoresfrom any dnsbl, M ip4r or rhsbl tests
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. NO - removing DUL/DYNA/DUHL is NOT an option. Because MUCH of the private emails originate from some address that is on that list - but only on the FIRST hope. Thus, the DUL/DYNA/DUHL skip tests on the FIRST hop! They can't be omitted - otherwise we'd block most private mail relayed through other providers SMTP servers. 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 Don Brown Sent: Saturday, May 15, 2004 04:19 PM To: Matt Cc: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank This wasn't a bug or a larger issue of Declude trust based upon the 'from Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were the only ones skipped) when the 'from address' was spoofed as a local address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, either. Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL mail, is only safe for those folks who: (1) are sure that none of their IP addresses are on any DYNA/DUL/DUHL list (and will never be on one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. For instance: Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 I don't think a switch in Declude is really needed. Thanks, 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/DUHL. This took me a long time to figure out, so the M trickisn't that common, however I started using these strings to M limit somenon-DUL tests to just the last hop with higher scoring, and M did impactmy ability to block spam on local accounts, however it took M me quite awhile to notice that it was going on (several months). M Matt M Andy Schmidt wrote: M Scott (in case you're not gone yet): M MAt this moment, Declude will not apply scoresfrom any dnsbl, M
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Andy, I think there might be some confusion here. If you change the test names and use the %IP4R%/dnsbl trick, it will always test the first hop regardless of what the Mail From is, unless of course you are whitelisting the sender. You don't have to remove the tests, you just have to rename them. I renamed mine with DYN, that way Declude doesn't see them as matching DUL/DYNA/DUHL and therefore will not skip them when the Mail From matches a local address. The only drawback that I have found with this work around is when you try configuring non-DUL tests twice, once only for the first hop, and once for all hops, in which case the work around will cause some extra lookups, but that's minor, and I'm only aware of a few people besides myself that are doing this. Nothing else appears to be a problem in anyway whatsoever. Matt Andy Schmidt wrote: Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. NO - removing DUL/DYNA/DUHL is NOT an option. Because MUCH of the private emails originate from some address that is on that list - but only on the FIRST hope. Thus, the DUL/DYNA/DUHL skip tests on the FIRST hop! They can't be omitted - otherwise we'd block most private mail relayed through other providers SMTP servers. 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 Don Brown Sent: Saturday, May 15, 2004 04:19 PM To: Matt Cc: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank This wasn't a bug or a larger issue of Declude trust based upon the 'from Address.' There was no choice but to skip DUL/DYNA/DUHL tests (which were the only ones skipped) when the 'from address' was spoofed as a local address. Imail 8 and WHITELIST AUTH help, but they don't solve this issue, either. Imail 8 can still be configured where the Client is NOT required to Auth in order to send. One example of that is 'Relay for Addresses.' So, if we have IPs on a DUL/DYNA/DUHL list, are using anything but 'No Mail Relay' in Imail 8 and we run a DYNA/DUL/DUHL test on the first hop, we will definitely tag our own customers. So, the way I see it, running DYNA/DUL/DUHL tests on the first hop of ALL mail, is only safe for those folks who: (1) are sure that none of their IP addresses are on any DYNA/DUL/DUHL list (and will never be on one) -OR- (2) run Imail 8, have it configured for 'No Mail Relay' and have WHITELIST AUTH specified in the Declude's Global.cfg. Then, in either cases, scanning the first hop is a simple matter of changing the test name to eliminate the reserved string of DUL, DYNA or DUHL and using the hack which Matt found. For instance: Change this: NJABL-DUL ip4r dnsbl.njabl.org 127.0.0.3 10 0 To this: NJABL-HOP1 dnsbl %IP4R%.dnsbl.njabl.org 127.0.0.3 10 0 I don't think a switch in Declude is really needed. Thanks, 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 d
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Scott, I seem to have broken things worse :) Is there any reason why the following wouldn't work? XBL(LAST) dnsbl %REMOTEIP%.sbl-xbl.spamhaus.org 127.0.0.4 6 0 I tested the DUL lists using this format and it seemed to be working. Here's the headers from a single hop test that tripped on the ip4r version of XBL and returned the proper %REMOTEIP% in the headers: Received: from nickdisk.every1.net [218.72.105.91] by mx1.mailpure.com (SMTPD32-8.05) id A3B01190256; Fri, 14 May 2004 12:28:32 -0400 Message-ID: [EMAIL PROTECTED] Date: Fri, 14 May 2004 20:43:49 +0500 From: "jada grant" [EMAIL PROTECTED] User-Agent: IncrediMail 2001 (1800838) X-Accept-Language: en-us MIME-Version: 1.0 To: hidden Subject: [23] enhance your anatomy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MailPure: X-MailPure: XBL(ALL): Failed, listed in sbl-xbl.spamhaus.org (weight 2). X-MailPure: FIVETEN-SPAM: Failed, listed in blackholes.five-ten-sg.com (weight 1). X-MailPure: NOREVDNS: Failed, no reverse DNS entry (weight 1). X-MailPure: CMDSPACE: Failed, improperly formatted SMTP commands (weight 3). X-MailPure: SNIFFER-PORN: Failed, listed in the Porn/Adult category (weight 8). X-MailPure: BADCOUNTRYNOREVDNS: Message failed BADCOUNTRYNOREVDNS test (line 7, weight 5) (weight capped at 5). X-MailPure: FOREIGN: Message failed FOREIGN test (line 446, weight 3) (weight capped at 3). X-MailPure: RECIPIENTS: hidden X-MailPure: X-MailPure: Spam Score: 23 X-MailPure: Scan Time: 12:28:45 on 05/14/2004 X-MailPure: Spool File: Df3b0011902563c94.SMD X-MailPure: Server Name: nickdisk.every1.net X-MailPure: SMTP Sender: [EMAIL PROTECTED] X-MailPure: Received From: [No Reverse DNS] [218.72.105.91] X-MailPure: Country Chain: CHINA-destination X-MailPure: X-MailPure: Spam and virus blocking services provided by MailPure.com X-MailPure: R. Scott Perry wrote: You could save me a bit of time though by answering this one question. With custom filters, will they also be skipped if there is a DUL/DUHL/DYNA in the name and the Mail From is local, i.e. DYNAMIC or DUL-COMBO? If so, I'll just change those names as well though I would prefer not to. No -- the filters will not be skipped based on the test name. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a 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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
I seem to have broken things worse :) Is there any reason why the following wouldn't work? XBL(LAST)dnsbl%REMOTEIP%.sbl-xbl.spamhaus.org127.0.0.4 60 I tested the DUL lists using this format and it seemed to be working. Here's the headers from a single hop test that tripped on the ip4r version of XBL and returned the proper %REMOTEIP% in the headers: The problem here is that the remote IP is 192.0.2.25, so Declude JunkMail will create 192.0.2.25.sbl-xbl.spamhaus.org. But, you really want 25.2.0.192.sbl-xbl.spamhaus.org. Fortunately, you can use: XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org127.0.0.46 0 which should do what you want. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a 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.
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
DOH! And unfortunately I just finished backing out of the changes :) Thanks for the clarification/correction. Matt R. Scott Perry wrote: I seem to have broken things worse :) Is there any reason why the following wouldn't work? XBL(LAST)dnsbl%REMOTEIP%.sbl-xbl.spamhaus.org 127.0.0.460 I tested the DUL lists using this format and it seemed to be working. Here's the headers from a single hop test that tripped on the ip4r version of XBL and returned the proper %REMOTEIP% in the headers: The problem here is that the remote IP is 192.0.2.25, so Declude JunkMail will create 192.0.2.25.sbl-xbl.spamhaus.org. But, you really want 25.2.0.192.sbl-xbl.spamhaus.org. Fortunately, you can use: XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org 127.0.0.460 which should do what you want. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a 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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [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] DUL skipping was ISBLANK is blank
Friday, May 14, 2004, 11:36:22 AM, R. Scott Perry [EMAIL PROTECTED] wrote: I seem to have broken things worse :) Is there any reason why the following wouldn't work? XBL(LAST)dnsbl%REMOTEIP%.sbl-xbl.spamhaus.org127.0.0.4 60 I tested the DUL lists using this format and it seemed to be working. Here's the headers from a single hop test that tripped on the 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.46 RSP 0 RSP which should do what you want. RSP -Scott Since sbl-xbl.spamhaus.org is an ip4r list, doesn't the below do the same thing as using %IP4R% as shown above? If not, what is the difference? SBL-ALL ip4r sbl-xbl.spamhaus.org Thanks, Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net (972) 788-2364Fax: (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.
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Don, Since I started this thread, I'll try to answer what's at issue here. Declude has functionality to only scan the last hop on any dnsbl, ip4r and rhsbl test when it has either DUL, DYNA or DUHL in the name of the test. This is done in order to protect you from scoring hits on dial-up or residential IP's when they weren't the connecting server and when you are using Declude to score on multiple hops (I believe this is version restricted). In order to keep these DUL/DYNA/DUHL tests from hitting your own local users when they are sending E-mail (only one hop and typically dynamic/residential), Declude disables any dnsbl, ip4r or rhsbl test when they have one of those strings in the name. This was very useful until IMail 8 came along and they started providing an indication of whether or not AUTH was used in the Q*.SMD file. When IMail 8 did that, Scott introduced a function called WHITELIST AUTH that will whitelist any E-mail that is AUTH'd. Every user on my system uses AUTH and I'm on IMail 8 so I can take advantage of WHITELIST AUTH. The issue now is that when a spammer forges a locally hosted 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. So for users that have IMail 8, where all of their users are whitelisted either by IP or by AUTH, it would be nice to turn this functionality off. Something that seemed to confuse you was the fact that I am using several tests twice like so: XBL(LAST) dnsbl %IP4R%.sbl-xbl.spamhaus.org 127.0.0.4 6 0 XBL(ALL) ip4r sbl-xbl.spamhaus.org 127.0.0.4 2 0 The reason why I do this is because I score on multiple hops, and instead of having XBL score exactly the same on every hop, I created a work around so that it would score higher on the last hop, and lower if it only hit one of the prior hops. The prior hop functionality helps with catching spam that is relayed from one open relay to another open relay, or worse yet, from an open relay to a legitimate mail server. At the same time there are lots of IP's in some of these lists that have long since been fixed/closed and are sending only legitimate E-mail through legitimate servers, and only adding a few points helps protect from false positives. The former kludge that I used was to use (DYNA) in the name of the test that I only wanted to score on the last hop, but this morning, I found that on locally hosted E-mail, this test would be defeated if the spammer forged a local address. By changing the test to how it appears as XBL(LAST) in the above example, I'm creating a way to score only the last hop without it being defeated when a local address is forged and DUL/DYNA/DUHL appears in the name. The short answer is that in the example above for XBL(LAST), using the dnsbl/%IP4R% hack, you can construct a test that only hits the last hop (if you are scoring on multiple hops like I am). It's convoluted, but it works, and I do recommend doing it, but only if you understand how it works and why it is useful. Matt Don Brown wrote: Friday, May 14, 2004, 11:36:22 AM, R. Scott Perry [EMAIL PROTECTED] wrote: I seem to have broken things worse :) Is there any reason why the following wouldn't work? XBL(LAST)dnsbl%REMOTEIP%.sbl-xbl.spamhaus.org127.0.0.4 60 I tested the DUL lists using this format and it seemed to be working. Here's the headers from a single hop test that tripped on the 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.46 RSP 0 RSP which should do what you want. RSP -Scott Since sbl-xbl.spamhaus.org is an ip4r list, doesn't the below do the same thing as using %IP4R% as shown above? If not, what is the difference? SBL-ALL ip4r sbl-xbl.spamhaus.org Thanks, Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net (972) 788-2364Fax: (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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
- Original Message - From: Matt [EMAIL PROTECTED] XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org127.0.0.4 60 XBL(ALL)ip4rsbl-xbl.spamhaus.org 127.0.0.420 Scott/Matt, would a configuration like above require multiple DNS queries since the hostnames defined in the tests are no longer identical? Or is the variable (in this case %IP4R%) ignored in the hostname, so that as far as Declude is concerned, the hostnames are still identical? 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] DUL skipping was ISBLANK is blank
XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org127.0.0.4 60 XBL(ALL)ip4rsbl-xbl.spamhaus.org 127.0.0.420 Scott/Matt, would a configuration like above require multiple DNS queries since the hostnames defined in the tests are no longer identical? Or is the variable (in this case %IP4R%) ignored in the hostname, so that as far as Declude is concerned, the hostnames are still identical? Having both of those would indeed cause multiple DNS queries. Even though they end up using the same zone, the ip4r lookups are handled separately from the dnsbl lookups. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a 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.
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Bill, The value is in scoring the last hop hits higher than prior hop hits. In this case, a hit on XBL for the last appropriate hop (not IPBYPASSED) would result in 8 points (6 + 2), while a hit on a prior hop would result in just 2 points. Note that the number of false positives is much higher with prior hops on tests that populate from spamtraps or are designed to detect open relays. Tests like SBL and other static spam source tests have very little danger in scoring the same for every hop, though SBL will sometimes list spam zombies that are unresolved for periods of time (I wish they didn't do that). Matt Bill Landry wrote: - Original Message - From: "Matt" [EMAIL PROTECTED] XBL(LAST)dnsbl%IP4R%.sbl-xbl.spamhaus.org127.0.0.4 60 XBL(ALL)ip4rsbl-xbl.spamhaus.org 127.0.0.420 Scott/Matt, would a configuration like above require multiple DNS queries since the hostnames defined in the tests are no longer identical? Or is the variable (in this case "%IP4R%") ignored in the hostname, so that as far as Declude is concerned, the hostnames are still identical? 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. -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Title: Message Matt, I think there is a misunderstanding (possibly on MY side). DUL/DYNA/DUHL tests from hitting your own local users when they are sending E-mail (only one hop and typically dynamic/residential), Declude disables any dnsbl, ip4r or rhsbl test when they have one of those strings in the name I was aware that DUL/DYNA/DUHL only checks the LAST hop (the server connnecting to you) - but doesn't check the prior hops. The idea is, that of course, ANY valid dial-up user will eventually appear in the first hop - the one to his provider's mail server. But a dial-up user should never be contacting YOUR mail server directly - so the LAST hop should not come from a dial-up user. What you are saying sounds almost like the reverse? I found that on locally hosted E-mail, this test would be defeated if the spammer forged a local address. You mean forging an IP address? Or forging a FROM address? I don't believe Declude "trusts" the from address - of course it will be forged for spam!? Every user on my system uses AUTH and I'm on IMail 8 so I can take advantage of WHITELIST AUTH. The issue now is that when a spammer forges a locally hosted 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. I use AUTH as well without problems. If you don't want the DUL/DYNA/DUHL, then why are you using those strings? Best RegardsAndy SchmidtHM Systems Software, Inc.600 East Crescent Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206http://www.HM-Software.com/ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MattSent: Friday, May 14, 2004 02:41 PMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blankDon,Since I started this thread, I'll try to answer what's at issue here.Declude has functionality to only scan the last hop on any dnsbl, ip4r and rhsbl test when it has either DUL, DYNA or DUHL in the name of the test. This is done in order to protect you from scoring hits on dial-up or residential IP's when they weren't the connecting server and when you are using Declude to score on multiple hops (I believe this is version restricted).In order to keep these DUL/DYNA/DUHL tests from hitting your own local users when they are sending E-mail (only one hop and typically dynamic/residential), Declude disables any dnsbl, ip4r or rhsbl test when they have one of those strings in the name. This was very useful until IMail 8 came along and they started providing an indication of whether or not AUTH was used in the Q*.SMD file. When IMail 8 did that, Scott introduced a function called WHITELIST AUTH that will whitelist any E-mail that is AUTH'd.Every user on my system uses AUTH and I'm on IMail 8 so I can take advantage of WHITELIST AUTH. The issue now is that when a spammer forges a locally hosted 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. So for users that have IMail 8, where all of their users are whitelisted either by IP or by AUTH, it would be nice to turn this functionality off.Something that seemed to confuse you was the fact that I am using several tests twice like so:XBL(LAST) dnsbl %IP4R%.sbl-xbl.spamhaus.org 127.0.0.4 6 0XBL(ALL) ip4r sbl-xbl.spamhaus.org 127.0.0.4 2 0The reason why I do this is because I score on multiple hops, and instead of having XBL score exactly the same on every hop, I created a work around so that it would score higher on the last hop, and lower if it only hit one of the prior hops. The prior hop functionality helps with catching spam that is relayed from one open relay to another open relay, or worse yet, from an open relay to a legitimate mail server. At the same time there are lots of IP's in some of these lists that have long since been fixed/closed and are sending only legitimate E-mail through legitimate servers, and only adding a few points helps protect from false positives.The former kludge that I used was to use (DYNA) in the name of the test that I only wanted to score on the last hop, but this morning, I found that on locally hosted E-mail, this test would be defeated if the spammer forged a local address. By changing the test to how it appears as XBL(LAST) in the above example, I'm creating a way to score only the last hop without it being defeated when a local address is forged and DUL/DYNA/DUHL appears in the name.The short answer is that in the example above for XBL(LAST), using the dnsbl/%IP4R% hack, you can construct a test that only hits the last hop (if you
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Andy Schmidt wrote: Message Matt, I think there is a misunderstanding (possibly on MY side). DUL/DYNA/DUHL tests from hitting your own local users when they are sending E-mail (only one hop and typically dynamic/residential), Declude disables any dnsbl, ip4r or rhsbl test when they have one of those strings in the name I was aware that DUL/DYNA/DUHL only checks the LAST hop (the server connnecting to you) - but doesn't check the prior hops. The idea is, that of course, ANY valid dial-up user will eventually appear in the first hop - the one to his provider's mail server. But a dial-up user should never be contacting YOUR mail server directly - so the LAST hop should not come from a dial-up user. What you are saying sounds almost like the reverse? The caviat is that if the connecting IP is from your own customer trying to send E-mail, it may very well be a DUL IP. I found that on locally hosted E-mail, this test would be defeated if the spammer forged a local address. You mean forging an IP address? Or forging a FROM address? I don't believe Declude "trusts" the from address - of course it will be forged for spam!? At this moment, Declude will not apply scores from any dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA or DUHL in the name AND the Mail From matches a local user. So to a certain extent, Declude does "trust" the from address. The reason for this was to defeat DUL tests for local users that might be sending from IP's listed in DUL lists. This was good thinking before WHITELIST AUTH became available because otherwise we couldn't use DUL lists effectively if we hosted accounts and had users that came in from DUL IP's, but for those that can whitelist all legitimate senders, either by IP, AUTH, or otherwise guarantee that no one will be sending from a DUL tagged IP, turning this feature off is of great benefit. The work-around discussed today is also an effective means of doing this. Every user on my system uses AUTH and I'm on IMail 8 so I can take advantage of WHITELIST AUTH. The issue now is that when a spammer forges a locally hosted 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. I use AUTH as well without problems. If you don't want the DUL/DYNA/DUHL, then why are you using those strings? I was using those strings on non-DUL tests as a kludge. I've tried to explain this several times recently and in the past. I score on multiple hops, but I want to score hits on the connecting IP high than on a relaying IP. I am doing this because some spam is relayed from one machine to another and even through an ISP's mailserver, but at the same time, there is a higher false positive rate with relaying IP's because some lists keep IP's in their database for many months or even years after they are nominated, and without an attempt to clean up the listing. ORDB for instance is very bad about this, and their removal process is useless in this regard since most broadband IP's don't have mail servers to receive the removal requests on. Take a look at the reply to Bill from two messages ago for further explanation of why this is done, and note that I was only naming tests like XBL(DYNA) to make that one test only score on the last hop, and the one marked XBL(ALL) would score on any hop that matched, including the first. I have HOPHIGH set to 3 which means (I believe) that I am checking as many as 4 hops (or 3 hops plus the connecting IP). Matt 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Friday, May 14, 2004 02:41 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank Don, Since I started this thread, I'll try to answer what's at issue here. Declude has functionality to only scan the last hop on any dnsbl, ip4r and rhsbl test when it has either DUL, DYNA or DUHL in the name of the test. This is done in order to protect you from scoring hits on dial-up or residential IP's when they weren't the connecting server and when you are using Declude to score on multiple hops (I believe this is version restricted). In order to keep these DUL/DYNA/DUHL tests from hitting your own local users when they are sending E-mail (only one hop and typically dynamic/residential), Declude disables any dnsbl, ip4r or rhsbl test when they have one of those strings in the name. This was very useful until IMail 8 came along and they started providing an indication of whether or not AUTH was used in the Q*.SMD fi
Re: [Declude.JunkMail] DUL skipping was ISBLANK is blank
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 MDUL/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 doestrust 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
RE: [Declude.JunkMail] DUL skipping was ISBLANK is blank
Title: Message Scott (in case you're not gone yet): At this moment, Declude will not apply scores from any dnsbl, ip4r or rhsbl tests if they have either DUL, DYNA or DUHL in the name AND the Mail From matches a local user. Does Declude REALLY trust the mail from and will bypass DUL/DYNA/DUHL test just by someone forging the mail from? Never heard about that "bug"/behavior before? Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206
