RE: [Declude.JunkMail] Declude Kill list changes...
RE: To those of you using the Kill List from Image`fx As we stated before, due to the fact we are writing a new program that will read Declude log files and Kill files we had to make a minor change to our Kill List. We apologize if this causes anyone any inconvenience, however, in the end it will pay off. Keep in mind that this does not effect the addresses in the list only their description. Here is a short description of the new changes made. Spam AddressUnique Identifier -- @some-domain1.com ID-20020803-000263 @some-domain2.com ID-20020803-000264 -- ID Unique ID search string - Separator 2002Year 08 Month 03 Day - Separator 000264 Latest Entree Number Must be unique - Allows up to 99 address entries -- The date will now represent the last time the address was used not the first time it was issued. Hopefully this will be the last change to the kill file, unless some one comes up with a better scheme. If you do, do it before I finish the application. PS: I wish to thank Scott and everyone on this list for allowing me to post and participate. ;) PSS: You can download the updated list from the usual url: http://www.imagefxonline.net/apps/delog/fromfile.txt Regards, Tom Image`fx --- [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] Newbie
I purchased the Pro version, and aside from entering my code, I left config files as-is. What is the recommended strategy to start using the product effectively? I've been using JunkMail for about a week now. What I discovered was the weight20 caught a ton of spam and no legit email. So, the way I have mine set up, at least for now, is I send everything that fails the weight20 test to the spam folder (HOLD action) and I asked several of my users, including the MIS dept. and a few others that were complaining about how much spam they received, to be my guinnea pigs. I configured these individual user accounts to SUBJECT for the badheaders, spamheaders, spamcop and weight10. I have asked my test users to forward me spam that isnt flagged that really is spam, and legitimate email that has been flagged as spam. Everything else I have left with the default WARN setting. My company is relatively small, 300 users, so I have just been monitoring the spam folder and checking out the dec.log everyday to see what is being flagged and making sure email getting sent to the spam folder really is spam. I plan on doing this for awhile longer till I get a better feel for what is being flagged. I realize that if your user group is large, this is probably not practical, but it's worked great for me so far. Once I see which legitimate mail is accidently getting flagged, I can adjust my configuration to be a bit more aggressive. This is a great product! Sharyn We are the worldwide producer and marketer of the award winning Cruzan Single Barrel Rum, judged Best in the World at the annual San Francisco Wine and Spirits Championships, and the artisan tequilas of Porfidio 100% Agave Tequilas, judged Best Tequila four years running by the Wine Enthusiast magazine. For more information, please click (go to) htmla href=http://www.cruzanrums.com;http:///aa href=http://www.cruzanrums;www.cruzanrums.com/a/html --- [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] 1.57 beta- variable with Subject?
In 1.57 beta we can use: WEIGHT15s ROUTETO Admin@%LOCALHOST% Is using variables also allowed for other actions? E.g. WEIGHT15SUBJECT [SPAM-%WEIEGHT%] In reviewing the spam we were trying to see if we can get a quick glance at the weight that the email had before digging into its header. Most of the actions can use variables, including the SUBJECT action (and WARN/HEADER/FOOTER as well). -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RBL+ Service
I have the log set to Mid and all of the RBL+ tests configured the same as your sample congif file, i.e. RBL DUL RBL+DUL etc. The tests run in order of appearance (RBL, then DUL, etc.) right? Correct. If an e-mail fails RBL, DUL and RBL+DUL, would all three of them appear in the log as failed tests? Yes. Looking at the MAPS site (actually at the contracts) it says that if the IP is on the list, they will respond in the 127/8 raange. Is it possible to configure for this range instead of an explicit IP like 127.1.0.0.2? Well, it sounds like MAPS is trying to be prepared in case they make changes later. Declude doesn't allow for IP ranges in the return codes, but there is a catchall of * that would work with any return code. Is MAPS saying what would cause a result in the 127/8 range? I'm not sure you would even want to test on 127/8 if you don't know what they will be doing with those IPs. That's similar to just using one of the free spam tests without checking to see what is does; if you are not careful, you'll get a lot of E-mail blocked. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] win 2K server
Greetings everyone, I HAD a Windows NT 4.0 machine running Imail version 6.xx (latest patches, etc) with Declude anti-spam and anti-virus with sniffer from sortmonster. Everything ran fine until last friday morning when BOTH mirrored drives crashed. When I went to the shop both drives were clank, clank, clank I build a new machine with Windows 2000 advanced server and installed Imail and all the latest patches. I have installed declude and sniffer. I am using F-prot for the virus scan through the declude program. On the NT 4.0 machine running an AMD 750 processor the cpu usage on the task manager showed between 2 - 5% with peaks around 40%. On the new 2000 machine running a 1.8 Ghz intel 4 it will also run about the same cpu usage. Then it starts showing usage averaging about 45% with peaks to about 90%. The performance monitor shows the File control bytes/sec is showing about 250,000 per second. Normally this is 400 -500 with peaks to 4000-5000. This is driving me nuts as I can't seem to find what is causing the problem. The sys0803.txt shows ALL the same entry - 08:03 12:55 1884 LST imailsrv-[EMAIL PROTECTED] Illegal IMail List Server Command! The ENTIRE log file contains the above entries showing the only differences to be the date and time. NO OTHER NORMAL ENTRIES are in there! The daily logs are over 25 meg with nothing but that entry. I have turned OFF the logging and the problem still exists. If I reboot the computer the cpu usage goes back to the normal 5% usage. Then all of a sudden it jumps to 35 - 50% usage. There is no pattern to the amount of time before it happens. Last night it took almost an hour before it happened. I have approximately 100 domains running on the computer with about 4760 users. Keep in mind that the windows NT 4.0 running the same domains and users did NOT do this. It started with the Windows advanced 2000 server. The declude anti-spam and anti-virus program is STILL catching about 25,000 pieces of spam per day as it did on the NT 4.0 machine. I even have the declude set to DELETE the spam and virus instead of holding it to save disk writes. Any assistance with this problem will be greatly appreciated. bob bloise system administrator trellis technologies, inc. --- [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.
HELO:RE: [Declude.JunkMail] win 2K server
Bob, I can only reassure you that it's very doubtful to be a Win2k problem, we run almost exactly the same set up as your selves except that our server is a humble 1Ghz with only 128MB RAM but with 350 domains and ~3000 users. CPU usage is very low ~2-5% peaking at 50% very occasionally. If the log file is filling with [EMAIL PROTECTED] Illegal IMail List Server Command it might be a problem with the list server, or someone is repeating send the same illegal command a kind of DOS attack - possibly. David -Original Message- From: bbloise [mailto:[EMAIL PROTECTED]] Sent: 03 August 2002 18:40 To: Declude List Subject: [Declude.JunkMail] win 2K server Greetings everyone, I HAD a Windows NT 4.0 machine running Imail version 6.xx (latest patches, etc) with Declude anti-spam and anti-virus with sniffer from sortmonster. Everything ran fine until last friday morning when BOTH mirrored drives crashed. When I went to the shop both drives were clank, clank, clank I build a new machine with Windows 2000 advanced server and installed Imail and all the latest patches. I have installed declude and sniffer. I am using F-prot for the virus scan through the declude program. On the NT 4.0 machine running an AMD 750 processor the cpu usage on the task manager showed between 2 - 5% with peaks around 40%. On the new 2000 machine running a 1.8 Ghz intel 4 it will also run about the same cpu usage. Then it starts showing usage averaging about 45% with peaks to about 90%. The performance monitor shows the File control bytes/sec is showing about 250,000 per second. Normally this is 400 -500 with peaks to 4000-5000. This is driving me nuts as I can't seem to find what is causing the problem. The sys0803.txt shows ALL the same entry - 08:03 12:55 1884 LST imailsrv-[EMAIL PROTECTED] Illegal IMail List Server Command! The ENTIRE log file contains the above entries showing the only differences to be the date and time. NO OTHER NORMAL ENTRIES are in there! The daily logs are over 25 meg with nothing but that entry. I have turned OFF the logging and the problem still exists. If I reboot the computer the cpu usage goes back to the normal 5% usage. Then all of a sudden it jumps to 35 - 50% usage. There is no pattern to the amount of time before it happens. Last night it took almost an hour before it happened. I have approximately 100 domains running on the computer with about 4760 users. Keep in mind that the windows NT 4.0 running the same domains and users did NOT do this. It started with the Windows advanced 2000 server. The declude anti-spam and anti-virus program is STILL catching about 25,000 pieces of spam per day as it did on the NT 4.0 machine. I even have the declude set to DELETE the spam and virus instead of holding it to save disk writes. Any assistance with this problem will be greatly appreciated. bob bloise system administrator trellis technologies, inc. --- [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] Newbie - Very Happy
Hi, Many thanks to everyone on the list for their advice. I have been working with this tool for a day now and love it! Already deleting WEIGHT 20 messages, and reviewing 15's (I did lower some of the weight values) Overall the product is VERY flexible. I also downloaded Spam Review that Bill recommended - great tool! I am having one problem with it and was wondering if others were. I cannot seem to get any entries into the Kill.lst file. The file exists, the path is correct, but no entries. Anybody else see this? Again, many thanks, my customers are going to love us for this! Regards, George --- [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] RBL Problem - Declude Sending Wrong IP
The long and short is that there is a problem with MAPS and using HOP/HOP High. HOP 0 HOPHIGH 1 08/02/2002 16:36:26 Qfb50142 Msg failed RBL (This E-mail came from 1.4.11.75, a potential spam source listed in RBL.). Headers: Received: from B2BWeb1.Resource.MH2.Com [65.203.99.90] by Leitos.com with ESMTP (SMTPD32-6.06) id AB50D7E0142; Fri, 02 Aug 2002 16:36:16 -0500 Received: from daa21301www003.cus.drtn.corp ([1.4.11.75]) by B2BWeb1.Resource.MH2.Com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 16:36:15 -0500 I'm not sure that I see the problem... You'll note that this was killed due to the RBL failing on HOP HIGH. Declude did what it was suppose to do. Yes. MAPS has Blackholed most all of the IANA reserved addresses, which are defined at http://www.iana.org/assignments/ipv4-address-space. But, they have NOT Blackholed the RFC1918 private addresses. That's good. The IANA Reserved addresses are ones that are *RESERVED* by IANA. That means that tomorrow IANA has the full right to give them out to spammers. And spammers are very likely today to use fake Received: headers using them. And *nobody* has a right to use those addresses except IANA. The problem here isn't with MAPS -- it's with drtn.corp (not even a valid domain name), who is using an IP address they aren't authorized to use. While that isn't against the law, it's against the RFCs -- and doing so has drawbacks, such as having your mail killed. Note that Declude JunkMail automatically detects private IPs (RFC1918), but we can't exempt IPs that could be used by spammers in the future. Checking HOP 1 does reduce SPAM. So, is it possible to not check MAPS when greater than HOP zero is an IANA or RFC1918 reserved address? You can whitelist the IP, that would likely be the best bet in this situation. Also, can you write to the log when it does fail a HOP 0? Good idea -- I'll see if that can be done. This is the text that MAPS returns on thier site for those verified x above: This network address is reserved by the Internet Assigned Numbers Authority (IANA). No Internet traffic should originate from this address. Any packets with this source address can be assumed to be forged. And that's exactly why they blacklist those IPs. :) -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Declude Kill list update for 08/03/02
Here is the Declude Kill List latest update for 08/03/2002. The full list can be downloaded from the following web site address http://www.imagefxonline.net/apps/delog/fromfile.txt A few words of caution: This file contains a list of addresses that have spammed our system without out the consent of our users. These sites may be one of the following; 1. OPT-IN 2. OPT-OUT 3. OPT-IN/OPT-OUT 4. Mass Marketing service 5. Fraudulent Mailing Service 6. A Site that just sends junk and/or bogus newsletters These sites should not be one of the following; 1. ISP 2. IPP 3. EDU 4. Legitimate Mail Service or Organization 5. Legitimate List Service or Organization 6. Legitimate News Service or Organization 7. Legitimate Corporation similar to CISCO 8. Government or Similar Organization All or any comments are welcome, please keep in mind Declude can use multiple lists. This means you can set a different action per list and you don't have to delete. Because everyone has a different opinion about these lists it will be hard to keep one master list and it will make it hard for each of us to trust the validity of each others list. With that in mind, we have to somehow figure out what the best way would be to handle this and join forces to fight spam. Regards, Tom Image`fx - PS: Here is the list update for 08/03/2002: PS: USE IT AT YOUR OWN RISK! - .nogoodspam.com ID-20020803-000265 @ITBrains.com ID-20020803-000266 .chtah.com ID-20020803-000267 @hta.or.jp ID-20020803-000268 @greennet.glID-20020803-000269 @metarewardmail.com ID-20020803-000270 .bluemountainarts.com ID-20020803-000271 .kleinman.com ID-20020803-000272 .qool.com ID-20020803-000273 .thefashionrack.com ID-20020803-000274 .coolfunsites.com ID-20020803-000275 - --- [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] RBL+ Service
All three tests are not shown in the log. Here's an example: I searched Declude logs from 7/1 - today and did NOT find failed tests for: RBL+DUL, RBL+RSS and MAPSALL. That's probably not unusual. For example, RBL+DUL (and MAPSALL) would only catch mail from a dialup line that also happened to be bad enough to get listed in RBL, which would be rare. The reason I'm going down this path is that the MAPSALL (RBL+ Service) test is suppose to include all three databases, so that only one (as opposed to 7) lookups is required. However, since there is no log entry for MAPSALL, I am hesitant to Remark out all of the other tests. MAPSALL is actually the test that will fail is the E-mail comes from an IP listed in all the MAPS databases (RBL+DUL+RSS would be another way of describing it). All contracts say essentially the same thing, with the exception of what is queried: RBL - blackholes.mail-abuse.org DUL - dialups.mail-abuse.org RSS - relays.mail-abuse.org. RBL+ - rbl-plus.mail-abuse.org That is correct. With just RBL, DUL, or RSS, one of the individual zones is queried (which returns a single result). For RBL+, only one zone is queried, but it can return one of 7 responses (for all combinations of the 3 tests). It looks like the Declude config file only queries rbl-plus.mail-abuse.org, As it should, for RBL+. :) but does it seven times in order to repor exactly why it failed. Correct, that is the current design, and will likely be changed for a future release. When changed, the end result will be exactly the same, but with a slight increase in performance. How can I test to make sure MAPSALL will work, so I can remark out the other six tests? You can't. If you want to have one test, you would need the definition to look like: RBLPLUSANY ip4rrbl-plus.mail-abuse.org * That will get triggered if an E-mail comes from an IP listed in any of the MAPS databases. However, you have less control, as all 3 tests (and combinations of them) will get treated equally. With this one, you could safely remark out the other tests. -Scott --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] RBL Problem - Declude Sending Wrong IP
I realize the primary problem is with the sending server's configuration. I haven't been very effective at convincing people to change something on their end, when they say that the only place their mail doesn't get delivered is here. Most don't know how to spell DNS, either. Does MAPS return anything which would indicate the IP is IANA reserved? This is only a potential problem when checking beyond HOP 0 against RBL and RBL+. If I whitelist an IANA Reserved block for the purposes of HOP 1 that will whitelist the e-mail even if it fails other fatal tests for HOP 0. So, that's not a very good solution. I can whitelist addresses after the fact, but that means the customer had called and complained or I caught it by accident. Also, not so good. IANA has had most of those blocks reserved for a very long time. The dates were included in the original e-mail. I realize they could release them, but I don't think it is very likely. Even if they did release some, it is doubtful that it would be many. If Declude ignored them for HOPs greater than 0 and IANA later released one, someone would most surely discover it so it could be fixed. We're only talking about testing MAPS (RBL and RBL+) for HOPs which are greater than zero. I would like to continue to use RBL, (actually RBL+ instead) and check HOP 1. I don't know the best solution . . . Saturday, August 3, 2002, 5:22:50 PM, R. Scott Perry [EMAIL PROTECTED] wrote: RSP The long and short is that there is a problem with MAPS and using RSP HOP/HOP High. HOP 0 HOPHIGH 1 08/02/2002 16:36:26 Qfb50142 Msg failed RBL (This E-mail came from 1.4.11.75, a potential spam source listed in RBL.). Headers: Received: from B2BWeb1.Resource.MH2.Com [65.203.99.90] by Leitos.com with ESMTP (SMTPD32-6.06) id AB50D7E0142; Fri, 02 Aug 2002 16:36:16 -0500 Received: from daa21301www003.cus.drtn.corp ([1.4.11.75]) by B2BWeb1.Resource.MH2.Com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 2 Aug 2002 16:36:15 -0500 RSP I'm not sure that I see the problem... You'll note that this was killed due to the RBL failing on HOP HIGH. Declude did what it was suppose to do. RSP Yes. MAPS has Blackholed most all of the IANA reserved addresses, which are defined at http://www.iana.org/assignments/ipv4-address-space. But, they have NOT Blackholed the RFC1918 private addresses. RSP That's good. The IANA Reserved addresses are ones that are *RESERVED* by RSP IANA. That means that tomorrow IANA has the full right to give them out to RSP spammers. And spammers are very likely today to use fake Received: headers RSP using them. And *nobody* has a right to use those addresses except IANA. RSP The problem here isn't with MAPS -- it's with drtn.corp (not even a valid RSP domain name), who is using an IP address they aren't authorized to RSP use. While that isn't against the law, it's against the RFCs -- and doing RSP so has drawbacks, such as having your mail killed. RSP Note that Declude JunkMail automatically detects private IPs (RFC1918), but RSP we can't exempt IPs that could be used by spammers in the future. Checking HOP 1 does reduce SPAM. So, is it possible to not check MAPS when greater than HOP zero is an IANA or RFC1918 reserved address? RSP You can whitelist the IP, that would likely be the best bet in this situation. Also, can you write to the log when it does fail a HOP 0? RSP Good idea -- I'll see if that can be done. This is the text that MAPS returns on thier site for those verified x above: This network address is reserved by the Internet Assigned Numbers Authority (IANA). No Internet traffic should originate from this address. Any packets with this source address can be assumed to be forged. RSP And that's exactly why they blacklist those IPs. :) RSP -Scott RSP --- RSP [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] RSP --- RSP This E-mail came from the Declude.JunkMail mailing list. To RSP unsubscribe, just send an E-mail to [EMAIL PROTECTED], and RSP type unsubscribe Declude.JunkMail. The archives can be found RSP at http://www.mail-archive.com. Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net PGP Key ID: 04C99A55 (972) 788-2364 Fax: (972) 788-5049 Providing Internet Solutions Worldwide - An eDataWeb Affiliate --- [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.
DORKZTL:RE: [Declude.JunkMail] Who are these guys?
The first is a Spanish site...almost like Excite. It list place for friends and lovers, news, chat room, etc. The second looks like an email program of some sort... Jim Rooth Klotron, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Sent: Saturday, August 03, 2002 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] Who are these guys? Since I do not understand other languages I could not figure out what these sites were. I was hopping someone could help otherwise I can not place them on the kill list. I'm not sure what this one is, it looks like it's in Spanish: http://www.24horas.com Just need an opinion on this one, it's in English: http://www.zoanmail.com/login.php (this one looks like a mail Thanks, Tom Image`fx --- [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. --- --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 --- [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] Declude Kill list effectiveness
Here are the Kill List results for 08/03/2002. Regards, Tom Image`fx Report ID Version 1.00b Detailed Report for: 08/03/2002 20:32:31 Log file examined: X:\IMAIL\SPOOL\DEC0803.LOG Unique Message Count: 1546 Total Percent of ID effectiveness: 35% Total Unique Identifier found: 79 ID-20020803-91 failed: 21 ID-20020803-56 failed: 65 ID-20020803-000263 failed: 4 ID-20020803-000112 failed: 7 ID-20020803-95 failed: 9 ID-20020803-20 failed: 1 ID-20020803-81 failed: 6 ID-20020803-69 failed: 5 ID-20020803-52 failed: 3 ID-20020803-15 failed: 3 ID-20020803-000212 failed: 26 ID-20020803-46 failed: 13 ID-20020803-000115 failed: 7 ID-20020803-35 failed: 4 ID-20020803-63 failed: 7 ID-20020803-09 failed: 10 ID-20020803-000220 failed: 1 ID-20020803-000113 failed: 6 ID-20020803-000135 failed: 10 ID-20020803-97 failed: 9 ID-20020803-000136 failed: 64 ID-20020803-000122 failed: 7 ID-20020803-11 failed: 2 ID-20020803-70 failed: 1 ID-20020803-23 failed: 10 ID-20020803-22 failed: 8 ID-20020803-42 failed: 2 ID-20020803-21 failed: 6 ID-20020803-82 failed: 12 ID-20020803-000188 failed: 8 ID-20020803-24 failed: 10 ID-20020803-000152 failed: 16 ID-20020803-000102 failed: 2 ID-20020803-96 failed: 5 ID-20020803-000166 failed: 3 ID-20020803-02 failed: 6 ID-20020803-000174 failed: 7 ID-20020803-000244 failed: 8 ID-20020803-51 failed: 14 ID-20020803-000139 failed: 2 ID-20020803-000148 failed: 6 ID-20020803-83 failed: 3 ID-20020803-62 failed: 2 ID-20020803-64 failed: 6 ID-20020803-73 failed: 4 ID-20020803-000204 failed: 3 ID-20020803-000128 failed: 6 ID-20020803-000184 failed: 9 ID-20020803-000123 failed: 5 ID-20020803-000137 failed: 1 ID-20020803-36 failed: 8 ID-20020803-38 failed: 5 ID-20020803-000249 failed: 1 ID-20020803-000262 failed: 4 ID-20020803-39 failed: 3 ID-20020803-54 failed: 3 ID-20020803-000149 failed: 1 ID-20020803-10 failed: 3 ID-20020803-000111 failed: 1 ID-20020803-000101 failed: 7 ID-20020803-000155 failed: 1 ID-20020803-16 failed: 1 ID-20020803-000105 failed: 1 ID-20020803-000254 failed: 2 ID-20020803-18 failed: 1 ID-20020803-000206 failed: 1 ID-20020803-19 failed: 1 ID-20020803-99 failed: 1 ID-20020803-000178 failed: 1 ID-20020803-27 failed: 1 ID-20020803-05 failed: 1 ID-20020803-000100 failed: 4 ID-20020803-08 failed: 11 ID-20020803-000177 failed: 16 ID-20020803-71 failed: 1 ID-20020803-84 failed: 3 ID-20020803-000140 failed: 4 ID-20020803-06 failed: 1 ID-20020803-000248 failed: 1 Total failure of all Identifiers: 544 --- [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] RBL Problem - Declude Sending Wrong IP
Saturday, August 3, 2002, 7:03:30 PM, R. Scott Perry [EMAIL PROTECTED] wrote: [SNIP] This is only a potential problem when checking beyond HOP 0 against RBL and RBL+. RSP ... and any other spam test that blacklists those IPs (I don't know offhand RSP if any do, but it is likely). O.K. It is only a potential problem when checking above HOP 0. [SNIP] So, that's not a very good solution. I can whitelist addresses after the fact, but that means the customer had called and complained or I caught it by accident. Also, not so good. RSP That IS good. People who are making the spam problem worse really should RSP go through that inconvenience (in my opinion). If they set up their RSP networks properly, the mail would have gone through, and the spam problem RSP would be easier for you to deal with. I would agree except it is not my customer's network and they hear from the sender or the sender's admin (those who can't spell DNS, either) that it is their ISP's (my) problem, because they are only having this problem with us (me). It's the old hardware vs. software loop, again. That was O.K. with Open Relays, but this is a different scenario. RSP I'm not sure if it is worth the extra effort to help these people that are RSP making the spam problem worse. You have to take a stand somewhere (like RSP people did with open relays, which are RFC-compliant). RSP Note that RFC1918 -- the very one that gives the safe private IPs -- RSP specifies that if you want to use other ones, you are required to obtain RSP them from an Internet registry. RSP There are other problems with people using these invalid IPs -- for RSP example, their routing information can leak out to their ISP. I generally agree and we took a stand WRT Open Relays and our customers generally understood or eventually got over it. However, Open Relay is applicable to Hop 0 and we're talking about checking Hop 1 and above. HOP 1 and above can easily be the IP of the internal LAN, which was the instant case. You recognized that potential when you added the RFC1918 exclusion to Declude. I don't think I'm going to get away with telling someone (particularly one who can't spell DNS) that they have to renumber their internal network in order for our customer to receive e-mail from them. I'm good, but I don't think I'm that good, and I really don't want to find out either. I probably would get a few laughs, though, but I doubt it would be me who was laughing. We're only talking about testing MAPS (RBL and RBL+) for HOPs which are greater than zero. Correction. We're only talking about testing above Hop 0 (Hop 1 Up). RSP Have you asked MAPS about this? If not blocking reserved IPs is a good RSP solution, wouldn't it be better for MAPS to take out those IPs from their RSP database? RSP-Scott I think them having the IANA Reserved addresses in the database is great WRT Hop 0. I'd also encourage them to add the RFC1918 addresses for the same reason (hop 0). The difference is that Declude already knows to ignore the RFC1918 addresses when checking higher than Hop 0 but it doesn't know to ignore the IANA addresses. I sent an e-mail to MAPS (bcc to your private address) asking if they pass anything special or would be willing to add something for the IANA Reserved space. I also asked why the RFC 1918 space wasn't blackholed, as well. Maybe they will answer in our lifetime. I recognize that you would rather not program this into the code and that you don't want to have the responsibility to change code when IANA releases a reserved block. I further recognize that it almost puts you in a position of having to monitor IANA. The other thing, too, is what if we find out some other list has included these reserved addresses, when we have only solved it with MAPS - more special coding. I understand from your point of view and don't blame you a bit. So, how about making it user configurable? Put the CIDRs for all reserved addresses to ignore for hop 1 and above in a section of the global.cfg. It's then up to the user to maintain it and it's a one time change for you to program. In addition, I think that both Reserved space (IANA and RFC1918) should get blackholed when hop 0 and inbound from the Internet. Does my BlackIP list get used for all hops or only for hop 0? I'm hoping it is used for all hops. If so, then how to best handle the blackhole for only hop 0? Thanks, Don Brown - Dallas, Texas USA Internet Concepts, Inc. [EMAIL PROTECTED] http://www.inetconcepts.net PGP Key ID: 04C99A55 (972) 788-2364 Fax: (972) 788-5049 Providing Internet Solutions Worldwide - An eDataWeb Affiliate --- [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
[Declude.JunkMail] Attach eml file
Hi, What variables, if any, can be used in the spamattach.eml file? %SUBJECT% and %FULLMSG% appear not to work. Also, can the HEADER action be read from a text file or can the HEADER be formatted as well as include variables. I'm looking to advise recipients of what tests they failed and to advise me if they don't want to receive any more email from that spam source. ATTACH would appear to me the best option as I read somewhere that HEADER won't be seen in a HTML formatted email. I'm sure this has all been done before. TIA Glen. AQUARIUS Communications for all your Internet needs voice(02)9977-3788 fax(02)9977-3844 http://www.aquarius.com.au mailto:[EMAIL PROTECTED] --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
