Re: [Declude.JunkMail] blocking spam faked as coming from local address
Talking about SPAMDOMAINS anyone have a list they would like to share with me (on or offlist). I just setup this test and put in the ones I could THINK of of top of my head (yahoo, msn, hotmail and a couple of others) but my list was no more then about 10-12 before I ran out of domains I could think of that I know was commonly used.. Best regards, Eje Aya Gustafsson mailto:[EMAIL PROTECTED] The Family Entertainment Network http://www.fament.com Phone : 620-231- Fax : 240-376-7272 - Your Full Time Professionals - Online Store http://www.wisp-router.com/ MikroTik, Star-OS, PACWireless, EnGenius, RF Industries -- MB Let's keep in mind that the discussion has changed from the original MB topic of MAILFROM Forged to VERP + Forged. MB For the last day I've been filtering using the SPAMDOMAINS method which MB captures examples of both topics in this thread, however it didn't MB capture E-mail that fakes a local domain when it is sent from my MB Microsoft SMTP server because I have that IPBYPASSed (there would MB otherwise be a lot of this). MB MAILFROM Forged MB --- MB As far as the MAILFROM test goes for finding faked local addresses, here MB are my results but bear in mind that this excludes intra-server faked MB domains from Web sites: MB 3 - Spam w/Forged address (2 passed filters with 80% of fail weight, MB 1 failed). MB 9 - Legit w/Forged address (E-mails sent from one local user to MB another local user but didn't use my server for sending.) MB = MB 12 - E-mails caught with whitelisting local Web server. MB For me the FP rate of a MAILFROM ENDSWITH local domain test was 75% with MB whitelisting (as it is currently set) or about 89% without whitelisting MB because of mail sent from local Web sites. The FP rate would definitely MB higher on weekdays because legit volume is higher and several customers MB have business communications sent forged. This test tagged a total of 3 MB pieces of spam out of a total of 1,968 unique messages received (0.15% MB of unique messages). MB I am going to look at an entire week's traffic with the MAILFROM test as MB Andrew suggested in order to spot the possibility of adding a point or MB two if there is leeway in the current scoring. For such a small number MB of forged addresses though, I don't want to risk the possibility of MB FPing on anything. I do have problems with legit E-mail doing this that MB fails multiple tests that I don't want to turn down to allow this, and I MB don't like to whitelist if at all possible. MB SPAMDOMAINS-based VERP + Forged MB MB Now as far as the SPAMDOMAINS-based test results go, here's what I found: MB 120 - Spam messages caught (71%) MB 117 - Spam w/VERP MB 3 - Spam w/Forged addresses MB 50 - Legit messages caught (29%) MB 41 - Legit w/VERP MB 9 - Legit w/Forged addresses MB MB 170 - Total Messages Caught MB The only spams that got through were the two mentioned above that MB actually forged the local sender. I also had one false positive in this MB group which was sent from Yahoo Groups and FP'd because for some reason, MB this message failed EASYNET-PROXIES. I assume that this was a problem MB in the lookup returned by Easynet because that IP is not currently in MB their database, and that same server successfully sent about 40 other MB messages without being caught. This message was also sent to a dead MB address that I am scoring as a 'spamtrap' but it is forwarded to another MB account so I'm not killing the message automatically. MB From looking at the spam using VERP, almost all of it came from a small MB handful of companies who have been tagged by FIVETEN-SPAMSUPPORT, MB MAILPOLICE-BULK, SPAMCOP, EASYNET-DNSBL and SBL. All but about 5 of MB these were tagged by at least two of those mentioned which is enough to MB fail any message with no other points necessary. None of the spam VERP MB messages passed my filters. MB It appears that all of this VERP stuff comes from gray-spam (for lack of MB a better word). These are addresses harvested primarily from contest MB and free membership sites with participants knowingly giving their MB addresses away for such things (not all of it uses VERP of course). The MB ones using VERP likely have somewhat static addresses and therefore MB these mailers are easily tagged by the leading blocklists. I don't MB believe I have any problems with VERP spammers, though this will take MB more monitoring to make a solid conclusion. MB I do have problems already with FP's on legit opt-in advertising, some MB of which use VERP. Too often such places find their way onto MailPolice MB or SpamCop only to be removed shortly thereafter, a problem
Re: [Declude.JunkMail] Re:COUNTRY test
Just in case you didn't notice and used my example over Scott's (which is generally not recommended), I had the points out of place in my example (yours did also). Matt Matthew Bramble wrote: David Dodell wrote: How to you list multiple countries? COUNTRIES CONTAINS 5 kr,cn ?? Just one string per line and make sure there are no characters following the country code. COUNTRIESCONTAINS5kr COUNTRIESCONTAINS5cn --- [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] VeriGrime
Kevin, I agree in theory to your point but your argument does not take the scale of this situation into consideration. The .com extension is typically the most sought after extension. .Net is widely used for ISPs that have been most affected by operator processes that are / were in place for their users / network optimization. This maneuver was not a violation DNS specification. However, this substantially more serious and market affecting than anything else that has happened so far. Lets forget about the hundreds of thousands of processes it disabled for a minute and just look at the possible legal violations of VeriSign's Registry Agreement. There are far reaching ramifications pertaining the search engine market as well (Hence the 100 million dollar antitrust lawsuit: http://www.siliconvalley.com/mld/siliconvalley/6818688.htm). I am not the owner of whois.sc. So, I would express your opinion directly to them. I posted that for the thousands of sysadmins that have had tens of thousands of processes break because of the unilateral change made by this wildcard implementation. I also point out that VeriBlind did this without ICANN approval. This has also prompted the IAB to release a commentary on the use of DNS wildcards: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html This article makes no mention of VeriSign. Instead it says Problems encountered in a recent experiment with wildcards Today, ICANN has formerly asked VeriSlime to voluntarily suspend the Site Finder service pending an investigation that was ALREADY underway before the update was released. VeriMime has been strangely very quiet. I wonder why. Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Sunday, September 21, 2003 12:31 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime I think for this to stick they need to change the letter to address the issue of other TLD systems that do the same thing. YOU are TARGETING one company when in fact others started this before Verisign with other TLDs. If this is what you actual believe on its technical merits/violation of the RFCs then the letter should be expanded to include all companies that manage TLD root servers that return and answer for non-existent domains. Although I think the letter makes good technical points, I think it is misplaced to reference only Verisign. I would sign a letter that includes all companies that manage TLD root servers that return answers for non-existent domain names. My two cents. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Phillip Holmes Sent: Saturday, September 20, 2003 7:29 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime Petition against VeriCrime's abuse of root operation: http://www.whois.sc/verisign-dns/ Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of serge Sent: Saturday, September 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] Veriscam oops just found something in the archive, please disregard my question if it was already explained here in simple tems i will read the archives and see if i get it :) --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] blocking spam faked as coming from local address
Scott, is this list moderated? I sent a response to the list regarding this thread on Friday and it has not shown up on the list. This has happened to me at least three times over the past month or so. No, it is not moderated. However, we have on 2 occasions in the past few months discovered IMail eating a message (after Declude scans it, IMail deletes it rather than delivering it). This happens with IMail v7 (which our mailserver is currently running), but not IMail v8, so we are planning to upgrade the mailserver soon to get around this. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] question on IPNOTINMX
Below is the declude warnings from an email I got. I was wondering how IPNOTINMX tripped when as per HELOBOGUS there are no MX or A records? Since there is no MX record isn't it impossible for there to be an IP in a record that doesn't exist? If an E-mail fails the IPNOTINMX test, it means that the IP address that the E-mail came from didn't appear in the MX record. Since there is no MX record, it is impossible for the IP to be in there, so the E_mail fails the test. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] blocking spam faked as coming from local address
Just a note that this appears to happen only with v7.1 of Imail and came up in our testing before we went live with Declude. We're running 7.07 here without problems, at least, any problems that we're aware of. We are waiting before upgrading to 8.x until they fix the suddenly the SMTP service quits working bug. With the heavy mail load we have here, I don't want a misbehaving service causing us headaches. No, it is not moderated. However, we have on 2 occasions in the past few months discovered IMail eating a message (after Declude scans it, IMail deletes it rather than delivering it). This happens with IMail v7 (which our mailserver is currently running), but not IMail v8, so we are planning to upgrade the mailserver soon to get around this. --- [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] blocking spam faked as coming from local address
- Original Message - From: Matthew Bramble Let's keep in mind that the discussion has changed from the original topic of MAILFROM Forged to VERP + Forged. Yep, my bad. Is that a fair enough presentation? Yes, very nice analysis! Based on this conversation I have modified my rules a bit (but probably not enough to meet your liking, however... ;-)) I have split up Forged and VERP rules in my global.cfg as follows (with a sample file entry after each): = VERP-FILTER filter M:\IMail\Declude\VERP-Filter.txt x 5 0 MAILFROM 0 CONTAINS hosted-domain.com --- FORGED-DOMAINS spamdomains M:\IMail\Declude\ForgedDomains.txt x 5 0 @hosted-domain.comhosted-domain.com = This will allow me to track Forged versus VERP flagged messages separately, and provide additional weight to actual Forged addresses since they will fail both tests, whereas VERP addresses will only fail the VERP-Filter test. Here is my rational for using these test and why they should not be causing FP problems. Unless you are an open relay, you know what customer servers are relaying through your IMail server (http forms, mail, PDFs, whatever, it doesn't matter the content). So if you are not an open relay, then you must know the IP addresses of these other systems in order to permit them to relay through you, but not permit the rest of the world. So if that is the case, whitelist their IP addresses and then no worries about blocking their messages with either of these tests. If you have mobile/roving and remote users that relay through your IMail server, you must be supporting SMTP Auth (again to prevent being a open relay), and if you are using WHITELIST AUTH, then again, no worries, the messages will automatically be whitelisted, thus preventing their messages from being block by either of these tests. So once again, for me these are very valuable tests with very few false positives (meaning messages that get held for further manual processing). Messages that are incorrectly flagged (like legit mailing lists) still get passed on because they do not reach a hold or delete trigger weight. I can't help believing that this would also be the case for a lot of other Declude users. These tests works very well in a weighted environment for us, and as I have shown, they flag a lot of crap (which is the goal, correct?). BTW, are you using grep and other utilities on Windows? If so, where did you get your tools? This could make pattern matching much less laborious for me, but I'd have to brush up (a lot) on regular expressions. Yes, on Windows. You can find the UNIX utilities for Win32 at: http://unxutils.sourceforge.net/ 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] question on IPNOTINMX
Josh, IPNOTINMX = IP NOT IN MX. As you said earlier there are no MX records for the IP address of the server you received that mail from. Declude looks at the senders mail from domain and compares it to the the IP address the server received the mail from looking for an MX. In this case the senders mail from domain is not an MX for the IP address so the test fails. With this test most people do not assign weight to this test because it catches a lot of legit mail. Most apply reverse weight if it passes (i.e. if the IP addresses matches a MX record for the senders mail from domain.) This is ideally what it was designed for... In summary any message where the senders mail from domain does not match/find a MX record for that domain on the IP address your server received it from will list the IPNOTINMX test as failed. Darrell -- Check Out DLAnalyzer a comprehensive reporting tool for Declude Junkmail Logs - http://www.dlanalyzer.com Joshua Levitsky writes: Below is the declude warnings from an email I got. I was wondering how IPNOTINMX tripped when as per HELOBOGUS there are no MX or A records? Since there is no MX record isn't it impossible for there to be an IP in a record that doesn't exist? Am I right about my logic above? Am I just up too late? The mail was caught cause I catch on 20, but I was curious about the IPNOTINMX showing up. -Josh From: suzanne [EMAIL PROTECTED] Subject: hey Date: September 21, 2003 12:10:59 AM EDT To: Firstname Lastname [EMAIL PROTECTED] Received: from D6Z9X2 [68.68.245.212] by joshie.com (SMTPD32-8.03) id A50412D200C8; Sun, 21 Sep 2003 00:11:48 -0400 X-Priority: 3 (normal) Importance: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 Message-Id: [EMAIL PROTECTED] X-Rbl-Warning: SPAMCOP: Blocked - see http://spamcop.net/bl.shtml?68.68.245.212 X-Rbl-Warning: FIVETENSRC: 212.245.68.68.blackholes.five-ten-sg.com. X-Rbl-Warning: NOABUSE: Not supporting [EMAIL PROTECTED] X-Rbl-Warning: BASE64: A binary encoded text or HTML section was found in this E-mail. X-Rbl-Warning: HELOBOGUS: Domain D6Z9X2 has no MX or A records. X-Rbl-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid fl-wdel-u2-c6bb-212.atlsfl.adelphia.net. X-Rbl-Warning: GIBBERISH: Message failed GIBBERISH test (84) X-Rbl-Warning: ANTIGIBBERISH: Message failed ANTIGIBBERISH test (14) X-Declude-Sender: [EMAIL PROTECTED] [68.68.245.212] X-Declude-Spoolname: D250412d200c8c414.SMD X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. X-Note: This E-mail was sent from fl-wdel-u2-c6bb-212.atlsfl.adelphia.net ([68.68.245.212]). X-Spam-Tests-Failed: SPAMCOP, FIVETENSRC, NOABUSE, BASE64, HELOBOGUS, SPAMDOMAINS, GIBBERISH, ANTIGIBBERISH, IPNOTINMX, NOLEGITCONTENT, SPAMLOW [34] X-Country-Chain: UNITED STATES-destination --- [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] VeriGrime
Lets start this off with I agree Versign has done things in the past that were on the shady side. But I also feel that on this issue they are being targeted because they are the largest TLD operator with a wildcard implementation. A good side affect is that if I was receiving spam from a nonexistane .museum domain MAILFROM would not fail. Would Scott have fixed Declude to handle wildcards? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Phillip B. Holmes Sent: Saturday, September 20, 2003 11:38 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriGrime Kevin, I agree in theory to your point but your argument does not take the scale of this situation into consideration. The .com extension is typically the most sought after extension. .Net is widely used for ISPs that have been most affected by operator processes that are / were in place for their users / network optimization. This maneuver was not a violation DNS specification. However, this substantially more serious and market affecting than anything else that has happened so far. Lets forget about the hundreds of thousands of processes it disabled for a minute and just look at the possible legal violations of VeriSign's Registry Agreement. There are far reaching ramifications pertaining the search engine market as well (Hence the 100 million dollar antitrust lawsuit: http://www.siliconvalley.com/mld/siliconvalley/6818688.htm). What the Verisign petition/lawsuit is saying is if you rob Fort Knox clean it is not ok, but if you just rob a small town bank you should be able to walk free. If Versign's laywers are smart they will get the suit thrown out in bias. They are not listing or sewing any other TLD owners that are using wildcards. I am not the owner of whois.sc. So, I would express your opinion directly to them. I posted that for the thousands of sysadmins that have had tens of thousands of processes break because of the unilateral change made by this wildcard implementation. I also point out that VeriBlind did this without ICANN approval. This has also prompted the IAB to release a commentary on the use of DNS wildcards: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html This article makes no mention of VeriSign. Instead it says Problems encountered in a recent experiment with wildcards At least they are being fair and not specifically mentioning a particular TLD operator. That was my original point. Today, ICANN has formerly asked VeriSlime to voluntarily suspend the Site Finder service pending an investigation that was ALREADY underway before the update was released. Then ICANN should ask all TLD operators to remove their wildcard implementations. They affect queries just like Verisigns wildcards. Once again BIAS against Verisign because they are the operators of the two largest TLDs. VeriMime has been strangely very quiet. I wonder why. Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Sunday, September 21, 2003 12:31 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime I think for this to stick they need to change the letter to address the issue of other TLD systems that do the same thing. YOU are TARGETING one company when in fact others started this before Verisign with other TLDs. If this is what you actual believe on its technical merits/violation of the RFCs then the letter should be expanded to include all companies that manage TLD root servers that return and answer for non-existent domains. Although I think the letter makes good technical points, I think it is misplaced to reference only Verisign. I would sign a letter that includes all companies that manage TLD root servers that return answers for non-existent domain names. My two cents. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Phillip Holmes Sent: Saturday, September 20, 2003 7:29 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime Petition against VeriCrime's abuse of root operation: http://www.whois.sc/verisign-dns/ Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of serge Sent: Saturday, September 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] Veriscam oops just found something in the archive, please disregard my question if it was already explained here in simple tems i will read the archives and see if i get it :) --- [This E-mail scanned for viruses by Declude Virus] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found
Re: [Declude.JunkMail] VeriGrime
There are two different classes though of TLD's in question though, gTLD's and ccTLD's. The only other offending gTLD is the .museum domain, and efforts to wildcard .biz was stopped by ICANN. Some of the ccTLD's are being used generically, however it seems that ICANN is going about this as an issue for the country in question to decide. Personally, I believe that the wildcard .museum domains aren't really an issue since this isn't a commercial domain, and only museums can apply for one and there are only 632 such names in existence. In this context, VeriSign is on it's own, and VeriSign is merely the party currently given the responsibility for maintaining the registry for .com and .net, and not the organization in charge of all such affairs concerning that gTLD. Hatred for VeriSign should also be shared by Yahoo who is supplying the backend for the search mechanism to work (Inktomi and Overture). I don't give this very long before it gets pulled. If it doesn't get pulled, ICANN should be forced to go under a total reorganization. Matt Kevin Bilbee wrote: Lets start this off with I agree Versign has done things in the past that were on the shady side. But I also feel that on this issue they are being targeted because they are the largest TLD operator with a wildcard implementation. A good side affect is that if I was receiving spam from a nonexistane .museum domain MAILFROM would not fail. Would Scott have fixed Declude to handle wildcards? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phillip B. Holmes Sent: Saturday, September 20, 2003 11:38 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriGrime Kevin, I agree in theory to your point but your argument does not take the scale of this situation into consideration. The .com extension is typically the most sought after extension. .Net is widely used for ISPs that have been most affected by operator processes that are / were in place for their users / network optimization. This maneuver was not a violation DNS specification. However, this substantially more serious and market affecting than anything else that has happened so far. Lets forget about the hundreds of thousands of processes it disabled for a minute and just look at the possible legal violations of VeriSign's Registry Agreement. There are far reaching ramifications pertaining the search engine market as well (Hence the 100 million dollar antitrust lawsuit: http://www.siliconvalley.com/mld/siliconvalley/6818688.htm). What the Verisign petition/lawsuit is saying is if you rob Fort Knox clean it is not ok, but if you just rob a small town bank you should be able to walk free. If Versign's laywers are smart they will get the suit thrown out in bias. They are not listing or sewing any other TLD owners that are using wildcards. I am not the owner of whois.sc. So, I would express your opinion directly to them. I posted that for the thousands of sysadmins that have had tens of thousands of processes break because of the unilateral change made by this wildcard implementation. I also point out that VeriBlind did this without ICANN approval. This has also prompted the IAB to release a commentary on the use of DNS wildcards: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html This article makes no mention of VeriSign. Instead it says "Problems encountered in a recent experiment with wildcards" At least they are being fair and not specifically mentioning a particular TLD operator. That was my original point. Today, ICANN has formerly asked VeriSlime to voluntarily suspend the Site Finder "service" pending an investigation that was ALREADY underway before the update was released. Then ICANN should ask all TLD operators to remove their wildcard implementations. They affect queries just like Verisigns wildcards. Once again BIAS against Verisign because they are the operators of the two largest TLDs. VeriMime has been strangely very quiet. I wonder why. Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kevin Bilbee Sent: Sunday, September 21, 2003 12:31 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime I think for this to stick they need to change the letter to address the issue of other TLD systems that do the same thing. YOU are TARGETING one company when in fact others started this before Verisign with other TLDs. If this is what you actual believe on its technical merits/violation of the RFCs then the letter should be expanded to include all companies that manage TLD root servers that return and answer for non-existent domains. Although I think the letter makes good technical points, I think it is misplaced to reference only Verisign. I would sign a letter that includes all companies that manage TLD root servers that return answers for
RE: [Declude.JunkMail] VeriGrime
Agreed. But, Reguardless of the size of the TLD, if wildcards are found unacceptable for gTLD's then .museum should also stop, countries should also stop. The accaptable rules for DNS should not change due to the fact you are a country. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Matthew BrambleSent: Sunday, September 21, 2003 11:35 AMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] VeriGrimeThere are two different classes though of TLD's in question though, gTLD's and ccTLD's. The only other offending gTLD is the .museum domain, and efforts to wildcard .biz was stopped by ICANN. Some of the ccTLD's are being used generically, however it seems that ICANN is going about this as an issue for the country in question to decide.Personally, I believe that the wildcard .museum domains aren't really an issue since this isn't a commercial domain, and only museums can apply for one and there are only 632 such names in existence.In this context, VeriSign is on it's own, and VeriSign is merely the party currently given the responsibility for maintaining the registry for .com and .net, and not the organization in charge of all such affairs concerning that gTLD.Hatred for VeriSign should also be shared by Yahoo who is supplying the backend for the search mechanism to work (Inktomi and Overture).I don't give this very long before it gets pulled. If it doesn't get pulled, ICANN should be forced to go under a total reorganization.MattKevin Bilbee wrote: Lets start this off with I agree Versign has done things in the past that were on the shady side. But I also feel that on this issue they are being targeted because they are the largest TLD operator with a wildcard implementation. A good side affect is that if I was receiving spam from a nonexistane .museum domain MAILFROM would not fail. Would Scott have fixed Declude to handle wildcards? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phillip B. Holmes Sent: Saturday, September 20, 2003 11:38 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriGrime Kevin, I agree in theory to your point but your argument does not take the scale of this situation into consideration. The .com extension is typically the most sought after extension. .Net is widely used for ISPs that have been most affected by operator processes that are / were in place for their users / network optimization. This maneuver was not a violation DNS specification. However, this substantially more serious and market affecting than anything else that has happened so far. Lets forget about the hundreds of thousands of processes it disabled for a minute and just look at the possible legal violations of VeriSign's Registry Agreement. There are far reaching ramifications pertaining the search engine market as well (Hence the 100 million dollar antitrust lawsuit: http://www.siliconvalley.com/mld/siliconvalley/6818688.htm). What the Verisign petition/lawsuit is saying is if you rob Fort Knox clean it is not ok, but if you just rob a small town bank you should be able to walk free. If Versign's laywers are smart they will get the suit thrown out in bias. They are not listing or sewing any other TLD owners that are using wildcards. I am not the owner of whois.sc. So, I would express your opinion directly to them. I posted that for the thousands of sysadmins that have had tens of thousands of processes break because of the unilateral change made by this wildcard implementation. I also point out that VeriBlind did this without ICANN approval. This has also prompted the IAB to release a commentary on the use of DNS wildcards: http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html This article makes no mention of VeriSign. Instead it says "Problems encountered in a recent experiment with wildcards" At least they are being fair and not specifically mentioning a particular TLD operator. That was my original point. Today, ICANN has formerly asked VeriSlime to voluntarily suspend the Site Finder "service" pending an investigation that was ALREADY underway before the update was released. Then ICANN should ask all TLD operators to remove their wildcard implementations. They affect queries just like Verisigns wildcards. Once again BIAS against Verisign because they are the operators of the two largest TLDs. VeriMime has been strangely very quiet. I wonder why. Best Regards, Phillip B. Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kevin Bilbee Sent: Sunday, September 21, 2003 12:31 AM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriCrime I think for this to stick they need to change the letter to address the issue of other TLD systems that do the same thing. YOU are TARGETING one company when in fact others started
Re: [Declude.JunkMail] VeriGrime
I kind of look at it like this...VeriSign is only contracted to maintain the registry and they don't technically own the domain names in question (although they have attempted to claim so in the past). I believe it to be improper for them to benefit financially from effectively claiming every un-registered combination and using them commercially without paying a fee for it. I don't feel this way about .museum because that isn't a for profit venture and there is no money being made from the functionality there. As far as ccTLD's go, I don't like the fact that some have been commercialized in the first place, however ICANN is powerless to do anything about this. They can complain, but they can't stop a country like Togo from doing whatever they want with their namespace. To protest such activities is useless IMO, just look at the UN in general, we don't even listen to the UN as a country if we don't feel like it, so why should Togo on a matter that has so little impact and can be worked around so easily. ICANN certainly isn't going to impose sanctions on them :) I believe though that they could find VeriSign in violation of their contract as a registrar by claiming names for their own commercial use without paying for them, and they should do just that. I wouldn't personally favor going after MuseDomo because they are clearly always going to lose a good deal of money on a namespace that accounts for just 0.16% of all names registered and the functionality isn't being abused, instead, it is being used exclusively to help in a very tight context (632 potential sites with a TLD set up to help increase awareness of museums on the Web in general). I think the whole idea of wildcarding TLD's isn't purely bad, just when it is used commercially. I would be all for some not-for-profit doing this for all domains in order to help Web surfers and to avoid confusion from default Microsoft IE and AOL functionality which takes this traffic as their own and opens up a good deal of potential for abuse (advertising buy.com for amazon.com misspellings for instance). They could achieve this by simply doing something like returning close matches for the unregistered domain name, and rank them both by closeness (like Meriam-Webster) and also by popularity. Such a system could not be abused and would benefit the Web surfer, and for our purposes, it would be easy to work around as has already been done. Heck, VeriSign could even do this as far as the way I see it, just not the way it is being done now as a for-profit money buys placement sort of model. Matt Kevin Bilbee wrote: Agreed. But, Reguardless of the size of the TLD, if wildcards are found unacceptable for gTLD's then .museum should also stop, countries should also stop. The accaptable rules for DNS should not change due to the fact you are a country. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matthew Bramble Sent: Sunday, September 21, 2003 11:35 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriGrime There are two different classes though of TLD's in question though, gTLD's and ccTLD's. The only other offending gTLD is the .museum domain, and efforts to wildcard .biz was stopped by ICANN. Some of the ccTLD's are being used generically, however it seems that ICANN is going about this as an issue for the country in question to decide. Personally, I believe that the wildcard .museum domains aren't really an issue since this isn't a commercial domain, and only museums can apply for one and there are only 632 such names in existence. In this context, VeriSign is on it's own, and VeriSign is merely the party currently given the responsibility for maintaining the registry for .com and .net, and not the organization in charge of all such affairs concerning that gTLD. Hatred for VeriSign should also be shared by Yahoo who is supplying the backend for the search mechanism to work (Inktomi and Overture). I don't give this very long before it gets pulled. If it doesn't get pulled, ICANN should be forced to go under a total reorganization. Matt Kevin Bilbee wrote: Lets start this off with I agree Versign has done things in the past that were on the shady side. But I also feel that on this issue they are being targeted because they are the largest TLD operator with a wildcard implementation. A good side affect is that if I was receiving spam from a nonexistane .museum domain MAILFROM would not fail. Would Scott have fixed Declude to handle wildcards? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Phillip B. Holmes Sent: Saturday, September 20, 2003 11:38 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] VeriGrime Kevin, I agree in theory to your point but your argument does not take the scale of this situation into
Re: [Declude.JunkMail] Re:COUNTRY test
Thanks for all of the info on the COUNTRY test. So, how are most folks using this test? I'd be interested in seeing what countries other people are adding weights for, and how much. Thanks, Scot - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 20, 2003 2:59 PM Subject: Re: [Declude.JunkMail] Re:COUNTRY test David Dodell wrote: How to you list multiple countries? COUNTRIES CONTAINS 5 kr,cn ?? Just one string per line and make sure there are no characters following the country code. COUNTRIESCONTAINS5kr COUNTRIESCONTAINS5cn --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Number of times JM scans an email?
Scott: I was looking through the logs and found something that I had never noticed before. If an email is sent to 10 people in the domain it appears that the same email is scanned for JM 10 times and based on what I see a spam that was sent to one user with the end result being delete was scanned 10 times with the same action and only at the very end was deleted. That is a single item scanned 10 times - same content, same final action. Why? Is this normal or am I just imagining it? Regards, Kami --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] question on IPNOTINMX
On Sep 21, 2003, at 11:03 AM, DLAnalyzer Support wrote: With this test most people do not assign weight to this test because it catches a lot of legit mail. Most apply reverse weight if it passes (i.e. if the IP addresses matches a MX record for the senders mail from domain.) This is ideally what it was designed for... That's exactly what I do, and so when I was looking at the email and saw it had IPNOTINMX I thought to myself... should it really get positive points when there is no MX to not have an IP in? -Josh --- [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] Number of times JM scans an email?
That is a single item scanned 10 times - same content, same final action. Why? Is this normal or am I just imagining it? It's normal, and you aren't imagining it -- but it isn't exactly what you think. What you are seeing is Declude JunkMail going through the list of recipients, and determining the actions for each one. So Declude JunkMail runs the tests, then checks to see what action(s) it should take, based on the list of recipients. You'll see the log file entries for each recipient, showing what action(s) Declude JunkMail is going to take. However, the tests are only run once per E-mail, no matter how many recipients. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Number of times JM scans an email?
Scott, I just have to jump in here, because I raised the issue of the multiple recipients a short while ago, and my understanding was that if one receipient sets an action on a message, that action will also be performed on the message to all other receipients. I have seen that happen with several customers for whom we do not have JunkMail activated, yet an action is performed. Are you saying that individual actions will take place for individual messages if they have individual JunkMail files, but if they do not have a JunkMail file, then the action is determined by the one recipient who does have actions set? Can you clarify this, please? Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Sunday, September 21, 2003 17:45 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Number of times JM scans an email? That is a single item scanned 10 times - same content, same final action. Why? Is this normal or am I just imagining it? It's normal, and you aren't imagining it -- but it isn't exactly what you think. What you are seeing is Declude JunkMail going through the list of recipients, and determining the actions for each one. So Declude JunkMail runs the tests, then checks to see what action(s) it should take, based on the list of recipients. You'll see the log file entries for each recipient, showing what action(s) Declude JunkMail is going to take. However, the tests are only run once per E-mail, no matter how many recipients. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our free 30-day evaluation. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Strange log and header behavior
A couple of weeks ago I post a strange anomaly where log entries show up in the JunkMail log but the no Declude headers show up in the actual message. Now I have the opposite effect where Declude headers will show up in the message but nothing is entered into the JunkMail log. Here is the scenario. Cron notification message is delivered from one of my gateway servers to IMail/Declude. No whitelist entry in Global.cfg file for this message: = Received: from gw2.pointshare.com [204.189.38.3] by intramail01.pointshare.net with ESMTP (SMTPD32-8.02) id A42F2A580054; Sun, 21 Sep 2003 17:37:03 -0700 Received: by gw2.pointshare.com (Mail Gateway) id 34FCCADDF3; Sun, 21 Sep 2003 17:37:04 -0700 (PDT) Delivered-To: [EMAIL PROTECTED] From: root (Cron Daemon) To: root Subject: Cron [EMAIL PROTECTED] run-parts /etc/cron.hourly Message-Id: [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 17:37:03 -0700 (PDT) X-Alligate-In: IGNORED - WhiteListed IP Address: (204.189.38.3) X-Alligate-Tracking: D86E20E437BEB0B2 X-Alligate-Signature: 0 X-Alligate-SpoolFile: D442f2a5800548e2f.SMD X-Alligate-Sender: root [204.189.38.3] X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: HEADERS-FILTER: Message failed HEADERS-FILTER test (58) X-RBL-Warning: SUBJECT-FILTER: Message failed SUBJECT-FILTER test (70) X-Declude-Sender: root [] X-Queue-File: D442f2a5800548e2f.SMD - outgoing X-Note: Total spam test weight: -6 --- Log file entry: M:\IMail\Declude\Unix-Toolsgrep Q442f2a5800548e2f m:\imail\spool\spam\log\dec0921.log 09/21/2003 17:37:06 Q442f2a5800548e2f HEADERS-FILTER:9 SUBJECT-FILTER:-15 . Total weight = -6 09/21/2003 17:37:06 Q442f2a5800548e2f Msg failed IPNOTINMX (). Action=WARN. 09/21/2003 17:37:06 Q442f2a5800548e2f Msg failed NOLEGITCONTENT (No content unique to legitimate E-mail detected.). Action=WARN. 09/21/2003 17:37:06 Q442f2a5800548e2f Msg failed SUBJECT-FILTER (Message failed SUBJECT-FILTER test (70)). Action=WARN. 09/21/2003 17:37:06 Q442f2a5800548e2f L1 Message OK 09/21/2003 17:37:06 Q442f2a5800548e2f Subject: Cron [EMAIL PROTECTED] run-parts /etc/cron.hourly 09/21/2003 17:37:06 Q442f2a5800548e2f From: root To: [EMAIL PROTECTED] IP: ID: = Note that Declude is not able to determine the IP address of the sending server in the message above, probably due to the first received header, which does not contain one. So I decided to whitelist the message using: WHITELIST FROM root in the Global.cfg file. When the next cron message got delivered: = Received: from gw2.pointshare.com [204.189.38.3] by intramail01.pointshare.net with ESMTP (SMTPD32-8.02) id A23F36750056; Sun, 21 Sep 2003 18:37:03 -0700 Received: by gw2.pointshare.com (Mail Gateway) id 4E37EADDF3; Sun, 21 Sep 2003 18:37:04 -0700 (PDT) Delivered-To: [EMAIL PROTECTED] From: root (Cron Daemon) To: root Subject: Cron [EMAIL PROTECTED] run-parts /etc/cron.hourly Message-Id: [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 18:37:03 -0700 (PDT) X-Declude-Sender: root [204.189.38.3] X-Queue-File: D523f367500567d1d.SMD - outgoing X-Note: Total spam test weight: 0 --- Log file entry: M:\IMail\Declude\Unix-Toolsgrep Q523f367500567d1d m:\imail\spool\spam\log\dec0921.log NO LOG ENTRY FOUND = Note that Declude was now able to determine the IP address of the sending server (strange). But when the whitelist is enabled, there is an even stranger side effect in that nothing for the message shows up in the JunkMail log file. Remove the whitelist entry, and Declude again cannot determine the sending servers IP address, but the message once again shows up in the logs. I am running: = Diagnostics ON (Declude v1.76i1). Declude JunkMail: Config file found (m:\imail\Declude\global.CFG). Declude Virus: Config file found (m:\imail\Declude\Virus.CFG). Declude JunkMail Status: PRO version registered. Declude Virus Status:Pro Version Registered. = The reason I want to whitelist these servers is so that no specific test entries will show up in the logs which could skew my reports. Thoughts? 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] VeriGrime
I agree again. Except for the exclusion you are giving to " MuseDomo ". If the rules are for one they should be for all. I agree if Verisign wants to use wildcards for TLD's then your not for profit no advertising model would be great. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Matthew BrambleSent: Sunday, September 21, 2003 2:34 PMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] VeriGrimeI kind of look at it like this...VeriSign is only contracted to maintain the registry and they don't technically own the domain names in question (although they have attempted to claim so in the past). I believe it to be improper for them to benefit financially from effectively claiming every un-registered combination and using them commercially without paying a fee for it. I don't feel this way about .museum because that isn't a for profit venture and there is no money being made from the functionality there.As far as ccTLD's go, I don't like the fact that some have been commercialized in the first place, however ICANN is powerless to do anything about this. They can complain, but they can't stop a country like Togo from doing whatever they want with their namespace. To protest such activities is useless IMO, just look at the UN in general, we don't even listen to the UN as a country if we don't feel like it, so why should Togo on a matter that has so little impact and can be worked around so easily. ICANN certainly isn't going to impose sanctions on them :) I believe though that they could find VeriSign in violation of their contract as a registrar by claiming names for their own commercial use without paying for them, and they should do just that.I wouldn't personally favor going after MuseDomo because they are clearly always going to lose a good deal of money on a namespace that accounts for just 0.16% of all names registered and the functionality isn't being abused, instead, it is being used exclusively to help in a very tight context (632 potential sites with a TLD set up to help increase awareness of museums on the Web in general).I think the whole idea of wildcarding TLD's isn't purely bad, just when it is used commercially. I would be all for some not-for-profit doing this for all domains in order to help Web surfers and to avoid confusion from default Microsoft IE and AOL functionality which takes this traffic as their own and opens up a good deal of potential for abuse (advertising buy.com for amazon.com misspellings for instance). They could achieve this by simply doing something like returning close matches for the unregistered domain name, and rank them both by closeness (like Meriam-Webster) and also by popularity. Such a system could not be abused and would benefit the Web surfer, and for our purposes, it would be easy to work around as has already been done. Heck, VeriSign could even do this as far as the way I see it, just not the way it is being done now as a for-profit money buys placement sort of model.MattKevin Bilbee wrote: Agreed. But, Reguardless of the size of the TLD, if wildcards are found unacceptable for gTLD's then .museum should also stop, countries should also stop. The accaptable rules for DNS should not change due to the fact you are a country. Kevin Bilbee -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matthew BrambleSent: Sunday, September 21, 2003 11:35 AMTo: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] VeriGrimeThere are two different classes though of TLD's in question though, gTLD's and ccTLD's. The only other offending gTLD is the .museum domain, and efforts to wildcard .biz was stopped by ICANN. Some of the ccTLD's are being used generically, however it seems that ICANN is going about this as an issue for the country in question to decide.Personally, I believe that the wildcard .museum domains aren't really an issue since this isn't a commercial domain, and only museums can apply for one and there are only 632 such names in existence.In this context, VeriSign is on it's own, and VeriSign is merely the party currently given the responsibility for maintaining the registry for .com and .net, and not the organization in charge of all such affairs concerning that gTLD.Hatred for VeriSign should also be shared by Yahoo who is supplying the backend for the search mechanism to work (Inktomi and Overture).I don't give this very long before it gets pulled. If it doesn't get pulled, ICANN should be forced to go under a total reorganization.MattKevin Bilbee wrote: Lets start this off with I agree Versign has done things in the past that
RE: [Declude.JunkMail] Museum
Title: Message (632 potential sites with a TLD set up to help increase awareness of museums on the Web in general). where is THAT number coming from? There are probably 2 or 3 museums even in smaller towns (I can think of 2 in my home-town of 30,000) Best RegardsAndy SchmidtPhone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206
[Declude.JunkMail] VeriSteal is stealing traffic from your domain.
I didn't realize this until a second ago, but VeriCorrupt is stealing traffic from every domain name out there on the Internet, regardless of the extension, and regardless of whether or not it is registered. Want to see something else that's quite strange? http://asfdasdsadfdsf.online.museum http://asdfaasdfasdf.site.biz For some reason that brings you to VeriThief's SiteFinder?? If you take out the .online it will take you to the wildcarded MuseDoma site. Seems that VeriSteal has some bleed over. Want to see something even worse? http://asdasdfasdfa.igaia.com http://asdfasdfasdf.declude.com Any lookup, registered or unregistered that doesn't return an A record is being directed at this site. Why the hell are these guys stealing traffic from the domain names that I am paying for? THIS MUST END! Up until now, I only thought this was limited to unregistered domains. VeriHijack can't be allowed to write the rules whatever way they see fit. They quite literally just took over the backbone of the Internet. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Can't reproduce here. I get regular Not found in my browser. 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 Matthew Bramble Sent: Monday, September 22, 2003 01:34 AM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I didn't realize this until a second ago, but VeriCorrupt is stealing traffic from every domain name out there on the Internet, regardless of the extension, and regardless of whether or not it is registered. Want to see something else that's quite strange? http://asfdasdsadfdsf.online.museum http://asdfaasdfasdf.site.biz For some reason that brings you to VeriThief's SiteFinder?? If you take out the .online it will take you to the wildcarded MuseDoma site. Seems that VeriSteal has some bleed over. Want to see something even worse? http://asdasdfasdfa.igaia.com http://asdfasdfasdf.declude.com Any lookup, registered or unregistered that doesn't return an A record is being directed at this site. Why the hell are these guys stealing traffic from the domain names that I am paying for? THIS MUST END! Up until now, I only thought this was limited to unregistered domains. VeriHijack can't be allowed to write the rules whatever way they see fit. They quite literally just took over the backbone of the Internet. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [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] VeriSteal is stealing traffic from your domain.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: 22. september 2003 07:34 To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I didn't realize this until a second ago, but VeriCorrupt is stealing traffic from every domain name out there on the Internet, regardless of the extension, and regardless of whether or not it is registered. Want to see something else that's quite strange? http://asfdasdsadfdsf.online.museum http://asdfaasdfasdf.site.biz For some reason that brings you to VeriThief's SiteFinder?? If you take out the .online it will take you to the wildcarded MuseDoma site. Seems that VeriSteal has some bleed over. Want to see something even worse? http://asdasdfasdfa.igaia.com http://asdfasdfasdf.declude.com ??? when doing this from my pc here uin norway I just get Page cannot be displayed Any lookup, registered or unregistered that doesn't return an A record is being directed at this site. Why the hell are these guys stealing traffic from the domain names that I am paying for? THIS MUST END! Up until now, I only thought this was limited to unregistered domains. VeriHijack can't be allowed to write the rules whatever way they see fit. They quite literally just took over the backbone of the Internet. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [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] VeriSteal is stealing traffic from your domain.
Hmmm, I cannot reproduce any of your findings below. Each link below that I clicked on returned: The page cannot be displayed in the browser, which is what I would expect. Nor have I read anything that states VeriSign is doing what you are claiming. Bill - Original Message - From: Matthew Bramble [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 10:34 PM Subject: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I didn't realize this until a second ago, but VeriCorrupt is stealing traffic from every domain name out there on the Internet, regardless of the extension, and regardless of whether or not it is registered. Want to see something else that's quite strange? http://asfdasdsadfdsf.online.museum http://asdfaasdfasdf.site.biz For some reason that brings you to VeriThief's SiteFinder?? If you take out the .online it will take you to the wildcarded MuseDoma site. Seems that VeriSteal has some bleed over. Want to see something even worse? http://asdasdfasdfa.igaia.com http://asdfasdfasdf.declude.com Any lookup, registered or unregistered that doesn't return an A record is being directed at this site. Why the hell are these guys stealing traffic from the domain names that I am paying for? THIS MUST END! Up until now, I only thought this was limited to unregistered domains. VeriHijack can't be allowed to write the rules whatever way they see fit. They quite literally just took over the backbone of the Internet. Matt --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- [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.
