[Declude.JunkMail] VeriSign info updates
For those interested in following the VeriSign saga... http://www.icann.org/announcements/advisory-19sep03.htm http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html 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] blocking spam faked as coming from local address
Bill, Thanks for the link to the GNU stuff. I might be asking for some help writing useful strings of pipes in the future :) I have noted from monitoring this for the last two days that the type of spam that forges the From address as being local has a high rate of passage through my server, albeit a very low overall volume (4 of 6 spams got through). It's not that forging helps the spam, but instead it seems to be mostly of the type that is sparse in content and uses un-marked relays. Adding a few points would help. I'm still going to monitor for problems with valid forged senders before I assume this to be safe. I will end up adding points to valid forged senders though that are my users and send E-mail to other local users using a different mail server than my own. I think you might have overlooked this in your response because WHITELIST AUTH won't forgive these senders, and they have the possibility of showing up on some RBL's, though not likely anything that I score too high. It's the non-customers that are valid and forging along with other issues that concerns me (mostly software notifications and at least one list from an automaker). I learned some important things from this discussion that I will make use of. One of which is how my DYNAMIC filter can't just rely on WHITELIST AUTH for preventing false positives, and another is how I implement SPAMDOMAINS, likely using @ symbols so I don't pick up FP's from forwarded VERP stuff. Matt Bill Landry wrote: - 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
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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.
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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] blocking spam faked as coming from local address
- Original Message - From: Matthew Bramble Thanks for the link to the GNU stuff. I might be asking for some help writing useful strings of pipes in the future :) No problem, I have several scripts I run to generate differnt kinds of reports. [snip] I think you might have overlooked this in your response because WHITELIST AUTH won't forgive these senders, [...] Good point. I would suggest that in these circumstances where a customer is using their ISP's MTA for outbound mail delivery, that you have them set their e-mail address in their e-mail client to their ISP account and then set their Reply To address as their e-mail address on your IMail server. I think this would resolve the inadvertant flagging of these customer e-mails with referrence to the spamdomains tests. 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] VeriSteal is stealing traffic from your domain.
My primary is my mail/Web server that is co-located off-site running MS DNS without Active Directory. My secondary is my LAN's Microsoft Active Directory bound DNS server. The unregistered .com and .net misspellings are in my mail/Web server's cache, however these invalid sub-domains don't show up in the cache of either server. It's strange behavior. I wonder where my computer is getting this information. Maybe this is proof of why you shouldn't wildcard from the root servers? Matt ISPhuset Nordic AS wrote: what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
But VeriSign does not even have the authority nor control over any other TLDs except .com and .net, so it doesn't make sense that you are having the name resolution issues you are experiencing. Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:34 PM Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. My primary is my mail/Web server that is co-located off-site running MS DNS without Active Directory. My secondary is my LAN's Microsoft Active Directory bound DNS server. The unregistered .com and .net misspellings are in my mail/Web server's cache, however these invalid sub-domains don't show up in the cache of either server.It's strange behavior. I wonder where my computer is getting this information. Maybe this is proof of why you shouldn't wildcard from the root servers?MattISPhuset Nordic AS wrote: what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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
Re: [Declude.JunkMail] blocking spam faked as coming from local address
It would solve that issue, however I'm a big promoter of never using a domain that you don't own when you can avoid it because it creates a liability, though not on simple replies. I've worked with many to help them remove any trace of an old ISP account and this might tell their receivers that the un-owned account is still active. I'd rather whitelist them instead, it would be less work. I'm not worried about adding a couple extra points to that stuff though since their ISP's mail server should be fairly clean, and I have decided that rejecting valid E-mail from a server marked as an open relay isn't in fact a false positive, though this only rarely happens. It's the non-customers sending valid stuff that is forged and the hardware devices that send out notifications which tend to have difficulties in passing some of the technical tests (HELOBOGUS, BADHEADERS and SPAMHEADERS among others). I already have some issues with this stuff FP'ing and bounces aren't useful in the second instance. Matt Bill Landry wrote: - Original Message - From: Matthew Bramble Thanks for the link to the GNU stuff. I might be asking for some help writing useful strings of pipes in the future :) No problem, I have several scripts I run to generate differnt kinds of reports. [snip] I think you might have overlooked this in your response because WHITELIST AUTH won't forgive these senders, [...] Good point. I would suggest that in these circumstances where a customer is using their ISP's MTA for outbound mail delivery, that you have them set their e-mail address in their e-mail client to their ISP account and then set their "Reply To" address as their e-mail address on your IMail server. I think this would resolve the inadvertant flagging of these customer e-mails with referrence to the spamdomains tests. Bill
Re: [Declude.JunkMail] blocking spam faked as coming from local address
Ah yes, amail admin's job is never done... ;-) Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:50 PM Subject: Re: [Declude.JunkMail] blocking spam faked as coming from local address It would solve that issue, however I'm a big promoter of never using a domain that you don't own when you can avoid it because it creates a liability, though not on simple replies. I've worked with many to help them remove any trace of an old ISP account and this might tell their receivers that the un-owned account is still active. I'd rather whitelist them instead, it would be less work.I'm not worried about adding a couple extra points to that stuff though since their ISP's mail server should be fairly clean, and I have decided that rejecting valid E-mail from a server marked as an open relay isn't in fact a false positive, though this only rarely happens. It's the non-customers sending valid stuff that is forged and the hardware devices that send out notifications which tend to have difficulties in passing some of the technical tests (HELOBOGUS, BADHEADERS and SPAMHEADERS among others). I already have some issues with this stuff FP'ing and bounces aren't useful in the second instance.MattBill Landry wrote: - Original Message - From: Matthew Bramble Thanks for the link to the GNU stuff. I might be asking for some help writing useful strings of pipes in the future :) No problem, I have several scripts I run to generate differnt kinds of reports. [snip] I think you might have overlooked this in your response because WHITELIST AUTH won't forgive these senders, [...] Good point. I would suggest that in these circumstances where a customer is using their ISP's MTA for outbound mail delivery, that you have them set their e-mail address in their e-mail client to their ISP account and then set their "Reply To" address as their e-mail address on your IMail server. I think this would resolve the inadvertant flagging of these customer e-mails with referrence to the spamdomains tests. Bill
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
I think this has something to do with Active Directory. I have no clue as to where the lookup is coming from because it isn't cached. It is most certainly happening though: http://www.mailpure.com/VeriStrange.jpg I did a quick search and couldn't find any mention of this on Google. Matt Bill Landry wrote: But VeriSign does not even have the authority nor control over any other TLDs except .com and .net, so it doesn't make sense that you are having the name resolution issues you are experiencing. Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:34 PM Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. My primary is my mail/Web server that is co-located off-site running MS DNS without Active Directory. My secondary is my LAN's Microsoft Active Directory bound DNS server. The unregistered .com and .net misspellings are in my mail/Web server's cache, however these invalid sub-domains don't show up in the cache of either server. It's strange behavior. I wonder where my computer is getting this information. Maybe this is proof of why you shouldn't wildcard from the root servers? Matt ISPhuset Nordic AS wrote: what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Title: Message Which ip adresses are there on the servers u hve set up as dns on that maschine ? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew BrambleSent: 22. september 2003 08:57To: [EMAIL PROTECTED]Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.I think this has something to do with Active Directory. I have no clue as to where the lookup is coming from because it isn't cached. It is most certainly happening though:http://www.mailpure.com/VeriStrange.jpgI did a quick search and couldn't find any mention of this on Google.MattBill Landry wrote: But VeriSign does not even have the authority nor control over any other TLDs except .com and .net, so it doesn't make sense that you are having the name resolution issues you are experiencing. Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:34 PM Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. My primary is my mail/Web server that is co-located off-site running MS DNS without Active Directory. My secondary is my LAN's Microsoft Active Directory bound DNS server. The unregistered .com and .net misspellings are in my mail/Web server's cache, however these invalid sub-domains don't show up in the cache of either server.It's strange behavior. I wonder where my computer is getting this information. Maybe this is proof of why you shouldn't wildcard from the root servers?MattISPhuset Nordic AS wrote: what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server, it goes back to the local Active Directory server and appends the lookup that produces no match to my unregistered Active Directory name, which returns the IP for SiteFinder. If I registered my Active Directory name, I wouldn't be directed to SiteFinder. Make sense now? Matt Bill Landry wrote: Are you running W2K or XP? If so, make sure you have the "DNS Client" service disabled. We setup all machines with it off by default now, because it has caused nothing but problems for us in the past by caching bogus info. Good luck! Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:56 PM Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I think this has something to do with Active Directory. I have no clue as to where the lookup is coming from because it isn't cached. It is most certainly happening though: http://www.mailpure.com/VeriStrange.jpg I did a quick search and couldn't find any mention of this on Google. Matt Bill Landry wrote: But VeriSign does not even have the authority nor control over any other TLDs except .com and .net, so it doesn't make sense that you are having the name resolution issues you are experiencing. Bill - Original Message - From: Matthew Bramble To: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 11:34 PM Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. My primary is my mail/Web server that is co-located off-site running MS DNS without Active Directory. My secondary is my LAN's Microsoft Active Directory bound DNS server. The unregistered .com and .net misspellings are in my mail/Web server's cache, however these invalid sub-domains don't show up in the cache of either server. It's strange behavior. I wonder where my computer is getting this information. Maybe this is proof of why you shouldn't wildcard from the root servers? Matt ISPhuset Nordic AS wrote: what dns are u using ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 08:05 To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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
Re: [Declude.JunkMail] Strange log and header behavior
So I decided to whitelist the message using: WHITELIST FROM root in the Global.cfg file. FYI, I would not recommend that -- it will whitelist all E-mails that have root in their return address (such as [EMAIL PROTECTED]). X-Declude-Sender: root [204.189.38.3] X-Queue-File: D523f367500567d1d.SMD - outgoing X-Note: Total spam test weight: 0 These headers do correspond with: --- Log file entry: M:\IMail\Declude\Unix-Toolsgrep Q523f367500567d1d m:\imail\spool\spam\log\dec0921.log NO LOG ENTRY FOUND = this. If Declude JunkMail is not run for some reason, you will still see those partial headers. In this case, it uses different code to get the IP address, which only checks the first line. This normally will happen if Declude Virus quarantines an E-mail. Do you have any C:\Declude.gp1 or C:\Declude.gp2 files with a date similar to the time that E-mail was processed (or more recent)? 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. It just occurred to me that this may be happening if you use the PREWHITELIST ON option, which essentially disables Declude JunkMail if a whitelist occurs. This could have the side-effects that you are mentioning. It will not use the expected (by me) IP, because different code is used to determine the IP when the Declude JunkMail code is not run, and certain headers may not be added. I'll need to investigate this further to see what changes need to be made when the PREWHITELIST ON setting is used. As for the IPs, the Declude JunkMail code is behaving correctly without the PREWHITELIST ON setting. Specifically, you have an IPBYPASS (or HOP) line that is telling it to skip over the first hop, but the second hop (the one where the IP should be) is missing the IP address. If it had 127.0.0.1 in there, then Declude JunkMail would see that as the IP address. But since there is no IP, Declude JunkMail treats this the same as if there was no IP listed at all. -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.
[Declude.JunkMail] Bogus email from local domain
Hi; I just posted a message in the IMail list regarding this.. Can a test be defined so emails from local domains that do not exist are identified. E.g.: [EMAIL PROTECTED] This user does not exist. If Declude could have a test - InvalidLocalUser - then we can simply add a large enough weight or hopefully later on when such feature is available stop processing the email from this user and simply delete it. When you receive about 20 of these emails to different people one can imagine all the useless cpu required to process what could have simply been deleted. 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] VeriSteal is stealing traffic from your domain.
I'm behind Active Directory here and it doesn't happen the same way as you describe. Other than mistyped .COM and .NET domains, it gives me an error. That's really odd. I think this has something to do with Active Directory. I have no clue as to where the lookup is coming from because it isn't cached. It is most certainly happening though: http://www.mailpure.com/VeriStrange.jpg --- [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] Bogus email from local domain
Kami, if you remove the nobody alias from your hosted domains, then IMail will simply refuse to accept delivery for non-existent users with a 550 no such user and neither IMail nor Declude will have to do any processing for these messages. Bill - Original Message - From: Kami Razvan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 5:30 AM Subject: [Declude.JunkMail] Bogus email from local domain Hi; I just posted a message in the IMail list regarding this.. Can a test be defined so emails from local domains that do not exist are identified. E.g.: [EMAIL PROTECTED] This user does not exist. If Declude could have a test - InvalidLocalUser - then we can simply add a large enough weight or hopefully later on when such feature is available stop processing the email from this user and simply delete it. When you receive about 20 of these emails to different people one can imagine all the useless cpu required to process what could have simply been deleted. 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. --- [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: Matthew Bramble I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Hmmm, well I was talking about shutting of the DNS Client on the workstations, since that is where queries will bypass DNS by using locally cached info, even if it is incorrect, until the cached entries expire. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name:adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 Make sense now? Yep. 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] Strange log and header behavior
- Original Message - From: R. Scott Perry [EMAIL PROTECTED] So I decided to whitelist the message using: WHITELIST FROM root in the Global.cfg file. FYI, I would not recommend that -- it will whitelist all E-mails that have root in their return address (such as [EMAIL PROTECTED]). I just did this for testing to see if it would prevent the other tests from showing up in my logs. That's why I noticed that it actually prevented any entries from being logged. X-Declude-Sender: root [204.189.38.3] X-Queue-File: D523f367500567d1d.SMD - outgoing X-Note: Total spam test weight: 0 These headers do correspond with: --- Log file entry: M:\IMail\Declude\Unix-Toolsgrep Q523f367500567d1d m:\imail\spool\spam\log\dec0921.log NO LOG ENTRY FOUND = this. If Declude JunkMail is not run for some reason, you will still see those partial headers. In this case, it uses different code to get the IP address, which only checks the first line. This normally will happen if Declude Virus quarantines an E-mail. Do you have any C:\Declude.gp1 or C:\Declude.gp2 files with a date similar to the time that E-mail was processed (or more recent)? There are no gp* files in the root of c:\. 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. It just occurred to me that this may be happening if you use the PREWHITELIST ON option, which essentially disables Declude JunkMail if a whitelist occurs. This could have the side-effects that you are mentioning. It will not use the expected (by me) IP, because different code is used to determine the IP when the Declude JunkMail code is not run, and certain headers may not be added. I'll need to investigate this further to see what changes need to be made when the PREWHITELIST ON setting is used. Yes, I do use PREWHITELIST ON. As for the IPs, the Declude JunkMail code is behaving correctly without the PREWHITELIST ON setting. Specifically, you have an IPBYPASS (or HOP) line that is telling it to skip over the first hop, but the second hop (the one where the IP should be) is missing the IP address. If it had 127.0.0.1 in there, then Declude JunkMail would see that as the IP address. But since there is no IP, Declude JunkMail treats this the same as if there was no IP listed at all. HOP is set to 0, but I am using IPBYPASS for the gateway server addresses. I will try a couple of other things, as well. 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] Bogus email from local domain
:) We do not have nobody. Let me explain again since there is a misunderstanding here. If I send you an email and make my outlook Reply address: [EMAIL PROTECTED] domain.com you will get the email. Right? I can change my email to: [EMAIL PROTECTED] Naturally that email does not exist. All I say is Imail should know its own database and this query should be much faster than doing the IP4R tests. So before it does anything - if it receives an email from a domain that is local to it - IMail has to make sure that email exists. Otherwise reject the email. - in Imail list I was suggesting Imail to reject it.. In Declude we can simply have a test that can say this FROM address is invalid as a local domain. So someone can not have: [EMAIL PROTECTED] in their from address and send me email. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Landry Sent: Monday, September 22, 2003 9:55 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Bogus email from local domain Kami, if you remove the nobody alias from your hosted domains, then IMail will simply refuse to accept delivery for non-existent users with a 550 no such user and neither IMail nor Declude will have to do any processing for these messages. Bill - Original Message - From: Kami Razvan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 5:30 AM Subject: [Declude.JunkMail] Bogus email from local domain Hi; I just posted a message in the IMail list regarding this.. Can a test be defined so emails from local domains that do not exist are identified. E.g.: [EMAIL PROTECTED] This user does not exist. If Declude could have a test - InvalidLocalUser - then we can simply add a large enough weight or hopefully later on when such feature is available stop processing the email from this user and simply delete it. When you receive about 20 of these emails to different people one can imagine all the useless cpu required to process what could have simply been deleted. 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. --- [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.
Has nothing to do with AD. It has to do with you do not have fowarders configured, instead relying on root servers, which of course are run by you-know-who. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Sunday, September 21, 2003 11:05 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. Very strange. I just confirmed that it happens from both Netscape and IE on both local computers, but it doesn't happen on my mail/web server. I think this has to do with the fact that I am on a local network with Active Directory, which my mail/web server isn't using. Anyone else behind an Active Directory server that can confirm? Matt Andy Schmidt wrote: 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.
Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server, it goes back to the local Active Directory server and appends the lookup that produces no match to my unregistered Active Directory name, which returns the IP for SiteFinder. If I registered my Active Directory name, I wouldn't be directed to SiteFinder. Make sense now? 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.
[Declude.JunkMail] Is it possible
I have a strange request, however, I don't think it can be done. I have a store-and-forward domain (Exchange User) that would like for us to forward individual spam email to another location for each individual user. The catch is, they don't want to send us their individual user email addresses so that I can create a per-user junkmail file for them, this would cause double management. They have informed me that their last Spam provider ISP could do this with a store-and-forward domain. Declude does a great job of creating sub-folders on the fly for on the box Imail users, however, this is more on the fly creation of Imail main boxes, which to me is dangerous since spammers could send email to any ole' user. Any suggestions, thanks for the time. Keith --- [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] Is it possible
Declude does a great job of creating sub-folders on the fly for on the box Imail users, however, this is more on the fly creation of Imail main boxes, ...which to me is dangerous since spammers could send email to any ole' user... Well, they can already send mail to any old user, since you don't have access to their userbase and are forwarding stuff on to them and bouncing stuff from their server back out to the 'Net (and killing their double-bounces). Even if you could assume that all mailboxes are valid and create IMail maildrops for them, how are you supposed to generate the forwarding addresses? How does this differ substantively from them just accepting mail for more than one host alias? For example, if someone sends to [EMAIL PROTECTED],andyou forward it to [EMAIL PROTECTED]@mx.example.com, how was that easier than having their server just accept the mail to the original address? It's not like the sender is in any way notified of the forward. Please explain further if you wish. -Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [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.
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now. I think this is one of the issues that ICANN was talking about concerning how the change can have unintended consequences (besides spam blockers). This also looks to be a problem in general with how Microsoft delegates lookups. Their software shouldn't take the root of your Active Directory tree and then append sub-domains to it and turn to the root servers for resolution. That appears to be a security risk if you ask me, and it doesn't make sense to do. Matt John Tolmachoff (Lists) wrote: Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server, it goes back to the local Active Directory server and appends the lookup that produces no match to my unregistered Active Directory name, which returns the IP for SiteFinder. If I registered my Active Directory name, I wouldn't be directed to SiteFinder. Make sense now? Matt
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Thats why you are supposed to use fex .loc This is a deathsin in my opinion if fex someone register this domain u use and then someone on the inside want to send an email to to them it will never get trough Jesus this is so basic in AD i thought most people know about those failures From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew BrambleSent: 22. september 2003 19:40To: [EMAIL PROTECTED] Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now.I think this is one of the issues that ICANN was talking about concerning how the change can have unintended consequences (besides spam blockers). This also looks to be a problem in general with how Microsoft delegates lookups. Their software shouldn't take the root of your Active Directory tree and then append sub-domains to it and turn to the root servers for resolution. That appears to be a security risk if you ask me, and it doesn't make sense to do.MattJohn Tolmachoff (Lists) wrote: Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server, it goes back to the local Active Directory server and appends the lookup that produces no match to my unregistered Active Directory name, which returns the IP for SiteFinder. If I registered my Active Directory name, I wouldn't be directed to SiteFinder. Make sense now? Matt
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
sure but yuo will still have the same problem as i see it if I fex register the domain then I can "steal" the traffic... its the same result. I have an ex. hereon a company who set up there system like this and they could suddenly not send internal mail anymore... why wll someone had registered the domain they used as an internal domain... 600 users couldnt send mail for 8 weeks cost them big money to fix this From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew BrambleSent: 22. september 2003 20:19To: [EMAIL PROTECTED] ISPhuset Nordic / Benny Samuelsen wrote: Thats why you are supposed to use fex .locThat makes some sense, however there has been plenty of talk about allowing an infinite number of TLD's on the Internet. Also, many companies actually use a sub-directory of their primary domain for their Active Directory. I believe that your AD server would be sending lookups out to the root servers even if you used .loc as your TLD, the only difference is that .loc won't return SiteFinder, but something on .com and .net will now, but before it worked the same as .loc as long as your name wasn't registered. if fex someone register this domain u use and then someone on the inside want to send an email to to them it will never get trough Only if your E-mail server is behind your Active Directory server. I can't see why you would want to do that. My Web/mail server doesn't use Active Directory and is located off-site. Jesus this is so basic in AD i thought most people know about those failuresWhen I set up my AD server, I spent dozens of hours trying to figure the thing out by reading just about every document on Microsoft's Web site that I could find. No where did I ever see such a thing mentioned. As things stand, I wasted enough time setting up AD for what is currently a 2 computer network and I'm sure that many others feel the same way. I'm quite happy with my internal name also, and have no interest in changing it. If I want to register it, it's only $10 a year.What I'm pointing to with this is actually support for why something needs to be returned by the root servers saying record doesn't exist instead of just matching whatever they get with their site, even processing the E-mail that is received which would otherwise be unaddressable.Matt From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew BrambleSent: 22. september 2003 19:40To: [EMAIL PROTECTED] Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now.I think this is one of the issues that ICANN was talking about concerning how the change can have unintended consequences (besides spam blockers). This also looks to be a problem in general with how Microsoft delegates lookups. Their software shouldn't take the root of your Active Directory tree and then append sub-domains to it and turn to the root servers for resolution. That appears to be a security risk if you ask me, and it doesn't make sense to do.MattJohn Tolmachoff (Lists) wrote: Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server, it goes back to the local Active Directory server and appends the lookup that produces no match to my unregistered Active Directory name, which returns the IP for SiteFinder. If I registered my Active Directory name, I wouldn't be directed to SiteFinder. Make sense now? Matt
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Clearly the problem was deeper than just the domain they choose, there were issues with their overall architecture. Was that not the case? Matt ISPhuset Nordic / Benny Samuelsen wrote: sure but yuo will still have the same problem as i see it if I fex register the domain then I can "steal" the traffic... its the same result. I have an ex. hereon a company who set up there system like this and they could suddenly not send internal mail anymore... why wll someone had registered the domain they used as an internal domain... 600 users couldnt send mail for 8 weeks cost them big money to fix this From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 20:19 To: [EMAIL PROTECTED] ISPhuset Nordic / Benny Samuelsen wrote: Thats why you are supposed to use fex .loc That makes some sense, however there has been plenty of talk about allowing an infinite number of TLD's on the Internet. Also, many companies actually use a sub-directory of their primary domain for their Active Directory. I believe that your AD server would be sending lookups out to the root servers even if you used .loc as your TLD, the only difference is that .loc won't return SiteFinder, but something on .com and .net will now, but before it worked the same as .loc as long as your name wasn't registered. if fex someone register this domain u use and then someone on the inside want to send an email to to them it will never get trough Only if your E-mail server is behind your Active Directory server. I can't see why you would want to do that. My Web/mail server doesn't use Active Directory and is located off-site. Jesus this is so basic in AD i thought most people know about those failures When I set up my AD server, I spent dozens of hours trying to figure the thing out by reading just about every document on Microsoft's Web site that I could find. No where did I ever see such a thing mentioned. As things stand, I wasted enough time setting up AD for what is currently a 2 computer network and I'm sure that many others feel the same way. I'm quite happy with my internal name also, and have no interest in changing it. If I want to register it, it's only $10 a year. What I'm pointing to with this is actually support for why something needs to be returned by the root servers saying record doesn't exist instead of just matching whatever they get with their site, even processing the E-mail that is received which would otherwise be unaddressable. Matt From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: 22. september 2003 19:40 To: [EMAIL PROTECTED] Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now. I think this is one of the issues that ICANN was talking about concerning how the change can have unintended consequences (besides spam blockers). This also looks to be a problem in general with how Microsoft delegates lookups. Their software shouldn't take the root of your Active Directory tree and then append sub-domains to it and turn to the root servers for resolution. That appears to be a security risk if you ask me, and it doesn't make sense to do. Matt John Tolmachoff (Lists) wrote: Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address: 64.94.110.11 That's the bogus sub-domain appended to my local Active Directory domain (replaced for security with an equivalent). The issue relates to the fact that my real Active Directory domain name is not registered and lies in the .com namespace, so when the lookup fails on the primary server,
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
The MS example I saw was to use a domain that ended .local if you did not want to use a real/public domain. This seems to work, lets hope that .local never becomes a real tld. Sincerely, Jonathan Miller Internet Service Department ACCS.net Advanced Computer Communication Systems, Inc. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. This AD server is over 2 years old. Support was very weak back then. It was set up as a trial of AD so I could see if there was any benefit to using it on my production server. I decided that is was not useful and too many problems existed. I do see the reasoning in either owning the domain or using a fake TLD. Eventually the fake TLDs though could come back and haunt users if they are ever allowed to be registered for Internet use. I believe that will happen some day. Matt Joshua Levitsky wrote: On Sep 22, 2003, at 1:40 PM, Matthew Bramble wrote: Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now. In my MCSE class the Microsoft printed material said to use .local if you didn't have an internet domain. I always do it that way when the company I do consulting for doesn't have a domain or if they have a domain and the mail / web is at a hosting company. If the domain isn't totally in-house then I use .local -Josh
[Declude.JunkMail] SWEN
I have come up with a filter that catches the SWEN virus emails and bounces. The only false positives in the last three days have come from CNN.com being caught on line 3. They are using and Iframe and also include a link to a javascript (what are they thinking!). BODY 0 CONTAINS BRBRBRMessage follows:BRBR BODY 0 CONTAINS BRBRBRUndeliverable to BODY 0 CONTAINS iframe src= BODY 0 CONTAINS Run attached file. Choose Yes on displayed dialog box. BODY 0 CONTAINS Run attached file BODY 0 CONTAINS qmail program BODY 0 CONTAINS Message from microsoft.com BODY 0 CONTAINS I'm afraid I wasn't able to deliver your message to one or more destinations BODY 0 CONTAINS I'm afraid the message returned below could not be delivered to the following addresses BODY 0 CONTAINS I'm sorry I wasn't able to deliver your message to one or more destinations BODY 0 CONTAINS I'm sorry the message returned below could not be delivered BODY 0 CONTAINS I'm sorry to have to inform you that I wasn't able to deliver your message to the following addresses SUBJECT 0 CONTAINS Abort Annoucement SUBJECT 0 CONTAINS Abort Message SUBJECT 0 CONTAINS Bug Advise SUBJECT 0 CONTAINS Current Network Patch SUBJECT 0 CONTAINS Current Security Patch SUBJECT 0 CONTAINS Error Advise SUBJECT 0 CONTAINS Internet Security Upgrade SUBJECT 0 CONTAINS Last Internet Security Pack SUBJECT 0 CONTAINS Last Internet Security Patch SUBJECT 0 CONTAINS Last Internet Security Upgrade SUBJECT 0 CONTAINS Last Microsoft Security Patch SUBJECT 0 CONTAINS Last Net Critical Pack SUBJECT 0 CONTAINS Last Network Security Upgrade SUBJECT 0 CONTAINS Last Network Security Patch SUBJECT 0 CONTAINS Latest Microsoft Critical Update SUBJECT 0 CONTAINS Microsoft Critical Update SUBJECT 0 CONTAINS Microsoft Upgrade SUBJECT 0 CONTAINS Network Update SUBJECT 0 CONTAINS New Internet Critical Update SUBJECT 0 CONTAINS New Microsoft Critical Patch SUBJECT 0 CONTAINS New Microsoft Patch SUBJECT 0 CONTAINS New Net Critical Pack SUBJECT 0 CONTAINS New Net Critical Patch SUBJECT 0 CONTAINS New Network Critical Update SUBJECT 0 CONTAINS New Network Critical Upgrade SUBJECT 0 CONTAINS New Network Security Patch SUBJECT 0 CONTAINS New Security Update SUBJECT 0 CONTAINS Newest Internet Pack SUBJECT 0 CONTAINS Newest Internet Upgrade SUBJECT 0 CONTAINS Newest Microsoft Pack SUBJECT 0 CONTAINS Newest Microsoft Security Patch SUBJECT 0 CONTAINS Newest Microsoft Upgrade SUBJECT 0 CONTAINS Newest Net Patch SUBJECT 0 CONTAINS Newest Network Critical Update SUBJECT 0 CONTAINS newest pack Kevin Bilbee Network Administrator Standard Abrasives, Inc. [EMAIL PROTECTED] (805) 520-5800 x7332 Changing the way industry works. --- [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] country filter question
Is it OK to put comments in the country TXT filter file? Such as adding the
name of the country at the end? For instamce:
COUNTRIES 0 CONTAINSSE sweden
('cause i may forget what some of the codes represent.)
Thanks,
Doug
Doug Bevins, Systems Manager
Record-Journal, 11 Crown St., Meriden CT 06450
Phone (203) 317-2223 Fax (203) 317-2233
[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.
RE: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
The MS example I saw was to use a domain that ended .local if you did not want to use a real/public domain. This seems to work, let s hope that .local never becomes a real tld. It may. MS needs to update their example -- it should be .localhost (or .test, .example, or .invalid). Those TLDs are defined by RFC2606 and are guaranteed never to become real TLDs. -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] VeriSteal is stealing traffic from your domain.
It was a combination but the main problem was the domain they used, that solved it cleared up most of the problems From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew BrambleSent: 22. september 2003 21:00To: [EMAIL PROTECTED] Clearly the problem was deeper than just the domain they choose, there were issues with their overall architecture. Was that not the case?MattISPhuset Nordic / Benny Samuelsen wrote: sure but yuo will still have the same problem as i see it if I fex register the domain then I can "steal" the traffic... its the same result. I have an ex. hereon a company who set up there system like this and they could suddenly not send internal mail anymore... why wll someone had registered the domain they used as an internal domain... 600 users couldnt send mail for 8 weeks cost them big money to fix this From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew BrambleSent: 22. september 2003 20:19To: [EMAIL PROTECTED] ISPhuset Nordic / Benny Samuelsen wrote: Thats why you are supposed to use fex .locThat makes some sense, however there has been plenty of talk about allowing an infinite number of TLD's on the Internet. Also, many companies actually use a sub-directory of their primary domain for their Active Directory. I believe that your AD server would be sending lookups out to the root servers even if you used .loc as your TLD, the only difference is that .loc won't return SiteFinder, but something on .com and .net will now, but before it worked the same as .loc as long as your name wasn't registered. if fex someone register this domain u use and then someone on the inside want to send an email to to them it will never get trough Only if your E-mail server is behind your Active Directory server. I can't see why you would want to do that. My Web/mail server doesn't use Active Directory and is located off-site. Jesus this is so basic in AD i thought most people know about those failuresWhen I set up my AD server, I spent dozens of hours trying to figure the thing out by reading just about every document on Microsoft's Web site that I could find. No where did I ever see such a thing mentioned. As things stand, I wasted enough time setting up AD for what is currently a 2 computer network and I'm sure that many others feel the same way. I'm quite happy with my internal name also, and have no interest in changing it. If I want to register it, it's only $10 a year.What I'm pointing to with this is actually support for why something needs to be returned by the root servers saying record doesn't exist instead of just matching whatever they get with their site, even processing the E-mail that is received which would otherwise be unaddressable.Matt From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew BrambleSent: 22. september 2003 19:40To: [EMAIL PROTECTED] Who says that I have to register the domain that Active Directory is using? My Active Directory name isn't intended to be used on the Internet. In most installations, you look to your own Active Directory server first for the lookups, so if it exists on the Internet it won't interfeer...until now.I think this is one of the issues that ICANN was talking about concerning how the change can have unintended consequences (besides spam blockers). This also looks to be a problem in general with how Microsoft delegates lookups. Their software shouldn't take the root of your Active Directory tree and then append sub-domains to it and turn to the root servers for resolution. That appears to be a security risk if you ask me, and it doesn't make sense to do.MattJohn Tolmachoff (Lists) wrote: Ah yes, using an unregistered domain name with a real TLD is a no-no. When are people using AD going to get this? AD must be configured correctly or else problems will come up when you least expect it. John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew Bramble Sent: Monday, September 22, 2003 12:52 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain. I figured it out. The problem is definitely with Active Directory. Turning off DNS Client on the local server only created a situation where their first bogus sub-domain would timeout but a retry would still go to SiteFinder. Here's what nslookup returns when directed at the DNS server on the co-located machine (not running Active Directory): adsfadsfasfdadsf.declude.com Server: ns1.igaia.com Address: 208.7.179.11 Non-authoritative answer: Name: adsfadsfasfdadsf.declude.com.primary.igaiaoffice.com Address:
RE: [Declude.JunkMail] OT: VerySinn disrupts LAN traffic
Title: Message There are reports of people's printers that stopped working. Essentially, TCP/IP connected printers on a local LAN set up by an ignorant network "admin" withan invalid domain name,connected to a local print server. Somehow, the workstations FIRST did a lookup by the (invalid) host/domain name - and would get a negative response from the external DNS. Then they would do internal name resolution and the printer could be found. After VerySinn's move, the external resolution now points to VerySinn - and the result is a printer failure in a local LAN. The point is, who knows how many things relied on the proper "not found" response to domain lookups - that are now broken and someone will waste time trying to figure out what changed. Best RegardsAndy SchmidtHM Systems Software, Inc.600 East Crescent Avenue, Suite 203Upper Saddle River, NJ 07458-1846Phone: +1 201 934-3414 x20 (Business)Fax: +1 201 934-9206http://www.HM-Software.com/
Re: [Declude.JunkMail] country filter question
Is it OK to put comments in the country TXT filter file? Such as adding the
name of the country at the end? For instamce:
COUNTRIES 0 CONTAINSSE sweden
('cause i may forget what some of the codes represent.)
No. Otherwise, Declude JunkMail will look for SE sweden in the list
of countries that the E-mail passed through. You can, however, have a line
before it that has a comment, if it starts with #.
-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] VeriSteal is stealing traffic from your domain.
On Sep 22, 2003, at 3:05 PM, Matthew Bramble wrote: do see the reasoning in either owning the domain or using a fake TLD. Eventually the fake TLDs though could come back and haunt users if they are ever allowed to be registered for Internet use. I believe that will happen some day. I have always been told, and in talking to others gotten the same feeling that .local would never be made a TLD. People make that assumption in recent RFCs... ftp://ftp.isi.edu/in-notes/rfc2965.txt -Josh
RE: [Declude.JunkMail] OT: VerySinn disrupts LAN traffic
Title: Message Maybe, just maybe, people will start to realize that hiring someone to do their AD for cheap is not a good idea. You get what you pay for. I can not count the number of AD setup jobs I did not get because they found some one that would do it for 1/3 the price. I tried to warn them John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Schmidt Sent: Monday, September 22, 2003 12:04 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] OT: VerySinn disrupts LAN traffic There are reports of people's printers that stopped working. Essentially, TCP/IP connected printers on a local LAN set up by an ignorant network admin withan invalid domain name,connected to a local print server. Somehow, the workstations FIRST did a lookup by the (invalid) host/domain name - and would get a negative response from the external DNS. Then they would do internal name resolution and the printer could be found. After VerySinn's move, the external resolution now points to VerySinn - and the result is a printer failure in a local LAN. The point is, who knows how many things relied on the proper not found response to domain lookups - that are now broken and someone will waste time trying to figure out what changed. Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 http://www.HM-Software.com/
Re: [Declude.JunkMail] VeriSteal is stealing traffic from your domain.
Josh, >From that RFC: The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. Probably safe, but by no means assured at this point. Matt Joshua Levitsky wrote: On Sep 22, 2003, at 3:05 PM, Matthew Bramble wrote: do see the reasoning in either owning the domain or using a fake TLD. Eventually the fake TLDs though could come back and haunt users if they are ever allowed to be registered for Internet use. I believe that will happen some day. I have always been told, and in talking to others gotten the same feeling that ".local" would never be made a TLD. People make that assumption in recent RFCs... ftp://ftp.isi.edu/in-notes/rfc2965.txt -Josh
[Declude.JunkMail] SUBJECTSPACES
I have come across legit messages that were caught by this because some stupid person had lots of spaces after the last word or character. Is there a way we can mitigate this by ignoring subject spaces after the last character? John Tolmachoff MCSE CSSA Engineer/Consultant eServices For You www.eservicesforyou.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] identifying actual WORDFILTER trigger
Hi, Is there a toggle or setting that will put enable the WORDFILTER to append the actual phrase to the headers of the email? We're filtering on a lot of stuff and need to prune it back. Examining the headers of FP messages would be the easiest but they only confirm the WORDFILTER and not the actual match phrase (Did a quick check of the archives and could not find any info on 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] VeriSteal is stealing traffic from your domain.
I know, but was just showing that people are writing things with the assumption that .local will never exist. On Sep 22, 2003, at 5:47 PM, Matthew Bramble wrote: Josh, >From that RFC: The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. Probably safe, but by no means assured at this point. Matt
[Declude.JunkMail] More logging issues
Scott, I know I can figure this out by parsing the IMail logs, but I am wondering why these messages have Action=IGNORE applied to them, but without the Subject and From/To lines, there is no way to tell by parsing just the Declude JunkMail logs: = 09/22/2003 17:01:04 Q8d3c39c70054e638 nNOLEGITCONTENT:-5 REVDNS:1 GIBBERISH-FILTER:5 NOGIBBERISH-FILTER:-5 SUBJECT-FILTER:-3 VERP-FILTER:5 FORGED-DOMAINS:5 SPAMCHECK:-3 . Total weight = 0 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed REVDNS (This E-mail was sent from a MUA/MTA 65.169.102.21 with no reverse DNS entry.). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed GIBBERISH-FILTER (Message failed GIBBERISH-FILTER test (88)). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed NOGIBBERISH-FILTER (Message failed NOGIBBERISH-FILTER test (86)). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed SUBJECT-FILTER (Message failed SUBJECT-FILTER test (130)). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed VERP-FILTER (Message failed VERP-FILTER test (11)). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed FORGED-DOMAINS (Spamdomain '@cwhealth.net' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS].). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 Msg failed SPAMCHECK (Message failed SPAMCHECK: -3.). Action=IGNORE. 09/22/2003 17:01:04 Q8d3c39c70054e638 R1 Message OK = Running Declude v1.76i1, with log level set to MID. 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.
[Declude.JunkMail] Bogus IP in headers
Scott, looks like people are starting to try and hide their internal IP address through some rather bazaar means. We have been getting quite a few of these (e-mail addresses changed to protect the innocent): = 09/22/2003 11:00:41 Q38c433940072f11a Bogus IP: UNIX: localhost 09/22/2003 11:00:48 Q38c433940072f11a LBL:3 NOMOREFUNN:2 VISI-RELAY:3 nIPNOTINMX:-3 nNOLEGITCONTENT:-5 HELO-FILTER:-10 REVDNS -FILTER:-5 ALLIGATE-SPAM-L1:1 . Total weight = -14 09/22/2003 11:00:48 Q38c433940072f11a Msg failed LBL (0.0.0.0.lbl.lagengymnastik.dk.). Action=IGNORE. 09/22/2003 11:00:48 Q38c433940072f11a Msg failed NOMOREFUNN (0.0.0.0.no-more-funn.moensted.dk.). Action=WARN. 09/22/2003 11:00:48 Q38c433940072f11a Msg failed VISI-RELAY (Mail from 0.0.0.0 refused -- see http://relays.visi.com/lookup.c gi?ipaddr=0.0.0.0). Action=WARN. 09/22/2003 11:00:48 Q38c433940072f11a Msg failed HELO-FILTER (Message failed HELO-FILTER test (122)). Action=WARN. 09/22/2003 11:00:48 Q38c433940072f11a Msg failed REVDNS-FILTER (Message failed REVDNS-FILTER test (78)). Action=WARN. 09/22/2003 11:00:48 Q38c433940072f11a Msg failed ALLIGATE-SPAM-L1 (Message failed ALLIGATE-SPAM-L1: 12.). Action=WARN. 09/22/2003 11:00:48 Q38c433940072f11a L1 Message OK 09/22/2003 11:00:48 Q38c433940072f11a Subject: ipn Website Focus Group Opportunity 09/22/2003 11:00:48 Q38c433940072f11a From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] IP: 198.88.144.42 ID: 423 6CADF58 = And a few of these, as well: = 09/22/2003 17:43:40 Q9709116000502df7 Bogus IP: ?.?.?.? 09/22/2003 17:43:47 Q9709116000502df7 BLARSBL:2 COMPU:2 LBL:3 NOMOREFUNN:2 VISI-RELAY:3 nNOLEGITCONTENT:-5 GIBBERISH-FILTER:5 HEADERS-FILTER:5 MAILFROM-FILTER:10 NOGIBBERISH-FILTER:-5 REVDNS-FILTER:-10 ALLIGATE-SPAM-L1:1 ALLIGATE-SPAM-L2:2 SNIFFER-GENERAL:12 SPAMCHECK:-3 . Total weight = 24 09/22/2003 17:43:47 Q9709116000502df7 Msg failed BLARSBL (This E-mail came from 209.202.220.160, a potential spam source listed in BLARSBL.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed COMPU (Sender IP: 209.202.220.138). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed LBL (0.0.0.0.lbl.lagengymnastik.dk.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed NOMOREFUNN (0.0.0.0.no-more-funn.moensted.dk.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed VISI-RELAY (Mail from 0.0.0.0 refused -- see http://relays.visi.com/lookup.cgi?ipaddr=0.0.0.0). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed IPNOTINMX (). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed GIBBERISH-FILTER (Message failed GIBBERISH-FILTER test (132)). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed HEADERS-FILTER (Message failed HEADERS-FILTER test (58)). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed MAILFROM-FILTER (Message failed MAILFROM-FILTER test (1096)). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed NOGIBBERISH-FILTER (Message failed NOGIBBERISH-FILTER test (52)). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed REVDNS-FILTER (Message failed REVDNS-FILTER test (59)). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed ALLIGATE-SPAM-L1 (Message failed ALLIGATE-SPAM-L1: 30.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed ALLIGATE-SPAM-L2 (Message failed ALLIGATE-SPAM-L2: 30.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed SNIFFER-GENERAL (Message failed SNIFFER-GENERAL: 63.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed SPAMCHECK (Message failed SPAMCHECK: -3.). Action=WARN. 09/22/2003 17:43:47 Q9709116000502df7 Msg failed WEIGHT16-35 (Total weight between 16 and 35.). Action=HOLD. 09/22/2003 17:43:47 Q9709116000502df7 Subject: resume submission 09/22/2003 17:43:47 Q9709116000502df7 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] IP: 209.202.220.160 ID: D67DAADE47 = The problem with this is that if you using HOPHIGH 1 or greater, JunkMail is running tests against the 0.0.0.0 address and coming back from the IP4R and RHSBLs with a match. I would request that JunkMail be set to never run tests against the 0.0.0.0 IP address, unless that IP address actually shows up in the received headers. Thanks, 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] More logging issues
Scott, I know I can figure this out by parsing the IMail logs, but I am wondering why these messages have Action=IGNORE applied to them, but without the Subject and From/To lines, there is no way to tell by parsing just the Declude JunkMail logs: If it is an ongoing issue you are investigating, you can use LOGLEVEL HIGH, which will record the file that Declude JunkMail gets the settings from, so you will know exactly which file has the action set to IGNORE (the IGNORE action will also be used if the config file doesn't have any action listed for 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] More logging issues
- Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 6:24 PM Subject: Re: [Declude.JunkMail] More logging issues Scott, I know I can figure this out by parsing the IMail logs, but I am wondering why these messages have Action=IGNORE applied to them, but without the Subject and From/To lines, there is no way to tell by parsing just the Declude JunkMail logs: If it is an ongoing issue you are investigating, you can use LOGLEVEL HIGH, which will record the file that Declude JunkMail gets the settings from, so you will know exactly which file has the action set to IGNORE (the IGNORE action will also be used if the config file doesn't have any action listed for the test). Scott, the message was outgoing, but I do not have any outgoing tests configured in my global.cfg file, nor do I have any IGNORE actions set on any incoming tests. I did a column by column compare of my global.cfg tests against my $default$.junkmail files in Excel, and all global tests were defined in all $default$.junkmail files and all actions are set to WARN, except PERCENT, which is set to HOLD. I can set the logging to HIGH, but any ideas what else I should look at? 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] Bogus IP in headers
Scott, looks like people are starting to try and hide their internal IP address through some rather bazaar means. We have been getting quite a few of these (e-mail addresses changed to protect the innocent): Do you have the full (or at least all the Received:) headers of such an E-mail? This should only happen if there is a gateway that is not properly recording the IP of the remote mailserver. The problem with this is that if you using HOPHIGH 1 or greater, JunkMail is running tests against the 0.0.0.0 address and coming back from the IP4R and RHSBLs with a match. I would request that JunkMail be set to never run tests against the 0.0.0.0 IP address, unless that IP address actually shows up in the received headers. Declude JunkMail is already programmed to skip the IP-based spam tests if the IP is 0.0.0.0. Unfortunately, while Declude JunkMail is able to scan multiple hops, there is a wide variety of formats that mailservers use to record IPs (since recording IPs isn't mandatory, so some do strange things like include the IP address in a non-standard format within a comment), and there are ways spammers can bypass them. For example, if a mailserver doesn't use the proper format of from hostname.example.com [192.0.2.25], but instead uses from hostname.example.com (192.0.2.25), then a spammer could use a HELO of [0.0.0.0], which would change that to from [0.0.0.0] (192.0.2.25), in which case Declude JunkMail would see the IP as 0.0.0.0 (which in fact it is in this case, according to the RFCs). Hopefully, from the headers, I will be able to see if Declude JunkMail can be doing anything differently to handle this, and see why it may be looking up 0.0.0.0. -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] More logging issues
Scott, the message was outgoing, but I do not have any outgoing tests configured in my global.cfg file, nor do I have any IGNORE actions set on any incoming tests. Declude JunkMail defaults to the IGNORE action if a test isn't listed. So if you have no line stating which action to use in the global.cfg file, Declude JunkMail will assume you want to use the IGNORE action. -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] More logging issues
- Original Message - From: R. Scott Perry [EMAIL PROTECTED] Declude JunkMail defaults to the IGNORE action if a test isn't listed. So if you have no line stating which action to use in the global.cfg file, Declude JunkMail will assume you want to use the IGNORE action. Okay, but if that's the case, it appears to only be running about 1/10th of the tests I have defined. Is there a way to disable the reporting of all outgoing tests in the log file so that it does not skew my log reports? 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] Bogus IP in headers
- Original Message - From: R. Scott Perry [EMAIL PROTECTED] Do you have the full (or at least all the Received:) headers of such an E-mail? I couldn't locate a message with headers to show you for the Bogus IP: UNIX: localhost, but I did find one of the Bogus IP: ?.?.?.? messages, here are the headers (again, e-mail addresses changed to protect the innocent): = Received: from gw1.pointshare.com [204.189.38.4] by intramail01.pointshare.net with ESMTP (SMTPD32-8.02) id A70911600050; Mon, 22 Sep 2003 17:42:49 -0700 Received: from lycos.com (www3.mail.lycos.com [209.202.220.160]) by gw1.pointshare.com (Mail Gateway) with SMTP id D67DAADE47 for [EMAIL PROTECTED]; Mon, 22 Sep 2003 17:42:43 -0700 (PDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue, 23 Sep 2003 00:42:24 - To: [EMAIL PROTECTED] Date: Mon, 22 Sep 2003 20:42:24 -0400 From: Anish Ray [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 X-Sent-Mail: off Reply-To: [EMAIL PROTECTED] X-Mailer: MailCity Service X-Priority: 3 Subject: resume submission X-Sender-Ip: 140.142.172.166 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: multipart/mixed; boundary==_-=_-IMMLKNJOFNOHJHAA Content-Transfer-Encoding: 7bit X-IMAIL-SPAM-VALFROM: (291504208) X-Alligate-In: FAILED - Score Adult: 9 (Req: 35) Spam: 21 (Req: 50) Tot: 30 (Req: 6) X-Alligate-Tracking: 68886B86F3287CD0 X-Alligate-Signature: 884897994 X-Alligate-SpoolFile: D9709116000502df7.SMD X-Alligate-Sender: [EMAIL PROTECTED] [209.202.220.160] X-RBL-Warning: BLARSBL: This E-mail came from 209.202.220.160, a potential spam source listed in BLARSBL. X-RBL-Warning: COMPU: Sender IP: 209.202.220.138 X-RBL-Warning: LBL: 0.0.0.0.lbl.lagengymnastik.dk. X-RBL-Warning: NOMOREFUNN: 0.0.0.0.no-more-funn.moensted.dk. X-RBL-Warning: VISI-RELAY: Mail from 0.0.0.0 refused -- see http://relays.visi.com/lookup.cgi?ipaddr=0.0.0.0 X-RBL-Warning: IPNOTINMX: X-RBL-Warning: GIBBERISH-FILTER: Message failed GIBBERISH-FILTER test (132) X-RBL-Warning: HEADERS-FILTER: Message failed HEADERS-FILTER test (58) X-RBL-Warning: MAILFROM-FILTER: Message failed MAILFROM-FILTER test (1096) X-RBL-Warning: NOGIBBERISH-FILTER: Message failed NOGIBBERISH-FILTER test (52) X-RBL-Warning: REVDNS-FILTER: Message failed REVDNS-FILTER test (59) X-RBL-Warning: ALLIGATE-SPAM-L1: Message failed ALLIGATE-SPAM-L1: 30. X-RBL-Warning: ALLIGATE-SPAM-L2: Message failed ALLIGATE-SPAM-L2: 30. X-RBL-Warning: SNIFFER-GENERAL: Message failed SNIFFER-GENERAL: 63. X-RBL-Warning: SPAMCHECK: Message failed SPAMCHECK: -3. X-Declude-Sender: [EMAIL PROTECTED] [209.202.220.160] X-Note: This e-mail was scanned for viruses filtered for spam X-Queue-File: D9709116000502df7.SMD - incoming X-Note: Total spam test weight: 24 = 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.
[Declude.JunkMail] VeriSigns response to ICANN
The VeriSign response: http://www.icann.org/correspondence/lewis-to-twomey-21sep03.htm 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.
[Declude.JunkMail] Another very effective filter test
This test is very effective at flagging or blocking spam from mail hosts that attempt to connect to your mail server and announce your own hostnames or IP addresses to it in their HELO string, especially if your IMail/Declude server is directly sending and receiving mail from the Internet (less functional, but still works if relaying via mail gateway to IMail/Declude). This filter looks for the bogus HELO info in the headers. In my testing, 100% of the messages delivered by these mail hosts is spam. Think about it, why would any other legitimate mail server out there attempt to connect to your mail server announcing your own hostname or IP address in its HELO string? The answer is, it wouldn't. Anyway, here is the test I use to detect these. In global.cfg: FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0 In ForgedHelo-Filter.txt file: = # In case you have mail gateways, deduct equal weight for these hosts HELO -7 ENDSWITH gw1.yourdomain.com HELO -7 ENDSWITH gw2.yourdomain.com # Remote mail hosts connecting and announcing your IP addresses HELO 0 CONTAINS xxx.xxx.xxx. HELO 0 CONTAINS xxx.xxx.xxx. # Remote mail hosts connection and announcing your hostnames HELO 0 ENDSWITH your-host.com HELO 0 ENDSWITH your-host.net HELO 0 ENDSWITH cust-host.com HELO 0 ENDSWITH cust-host.net = If you are not already running a test like this, try it out. I think you will find that it will flag lots of spam. 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] Another very effective filter test
Bill, This looks to be more promising than filtering for forged MAILFROM's (because of the FP's that exist there). The spam that has gotten through which forged the MAILFROM also forged the HELO, while the legit stuff had appropriate HELO's listed. I have one issue though that others might need to work around. I have MS SMTP on the same machine configured at the .16 address, however when it hands off to my main domain, MS SMTP forges the IP as being that of the server it's handing off to, .15 in this instance, but it uses the proper name given to the MS SMTP server. Here's an example: Received: from webmail.igaia.com [208.7.179.15] by igaia.com with ESMTP (SMTPD32-7.13) id A541250019C; Mon, 22 Sep 2003 18:18:41 -0400 Received: from mail pickup service by webmail.igaia.com with Microsoft SMTPSVC; Mon, 22 Sep 2003 18:18:41 -0400 Reply-To: "snip" snip From: "snip" snip To: "snip" snip Subject: Used Vehicle Inquiry - snip Date: Mon, 22 Sep 2003 18:18:41 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: [EMAIL PROTECTED] X-OriginalArrivalTime: 22 Sep 2003 22:18:41.0563 (UTC) FILETIME=[7A9B1EB0:01C38157] X-Declude-Sender: snip [208.7.179.15] X-Declude-Spoolname: D75410250019c9ee6.SMD X-Note: This E-mail was scanned by iGaia Incorporated's E-mail service (www.igaia.com) for spam. X-Note: This E-mail was sent from igaia.com ([208.7.179.15]). X-Spam-Tests-Failed: NOLEGITCONTENT, BCC-1, BCC-3, FORGEDASLOCAL, DYNAMIC [0] X-RCPT-TO: snip Status: U X-UIDL: 364035046 Clearly this isn't proper behavior for MS SMTP (unless I'm mistaken about something). In this instance, it would be necessary to provide exclusions for every instance of MS SMTP. I'm not sure what happens when MS SMTP forges the IP like this when hosted on a different server, maybe one out of your control, but I suspect that happens also according to the "Smart Host" if it is configured to hand off such messages (as mine is). If MS SMTP is configured to attempt delivery itself, I would imagine that it will report the proper IP in the HELO. Some software and hardware devices that send out notifications with their own SMTP engine will also make the HELO whatever the configuration says it is, and people will often use their own primary mail domain in this which would FP on this test. I have two such devices from my customer base that are doing this. Firewalls seem to be the most common offenders. Besides those two issues which people may need to work around, this seems like a solid test. I'm curious as to the exact format of the HELO that Declude matches with this filter. Based on your code, it suggests that the data contains an IP address and ends with the sender's HELO domain. I thought that all that was matched with the HELO filter was the domain name that is reported??? Could you clarify. That will affect how I exclude webmail.igaia.com from tripping the filter when it is received by igaia.com. You can answer that one tomorrow if you wish...I'm giving up on these late-late nights. Matt Bill Landry wrote: This test is very effective at flagging or blocking spam from mail hosts that attempt to connect to your mail server and announce your own hostnames or IP addresses to it in their HELO string, especially if your IMail/Declude server is directly sending and receiving mail from the Internet (less functional, but still works if relaying via mail gateway to IMail/Declude). This filter looks for the bogus HELO info in the headers. In my testing, 100% of the messages delivered by these mail hosts is spam. Think about it, why would any other legitimate mail server out there attempt to connect to your mail server announcing your own hostname or IP address in its HELO string? The answer is, it wouldn't. Anyway, here is the test I use to detect these. In global.cfg: FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0 In ForgedHelo-Filter.txt file: = # In case you have mail gateways, deduct equal weight for these hosts HELO -7 ENDSWITH gw1.yourdomain.com HELO -7 ENDSWITH gw2.yourdomain.com # Remote mail hosts connecting and announcing your IP addresses HELO 0 CONTAINS xxx.xxx.xxx. HELO 0 CONTAINS xxx.xxx.xxx. # Remote mail hosts connection and announcing your hostnames HELO 0 ENDSWITH your-host.com HELO 0 ENDSWITH your-host.net HELO 0 ENDSWITH cust-host.com HELO 0 ENDSWITH cust-host.net = If you are not already running a test like this, try it out. I think you will find that it will flag lots of spam. Bill
Re: [Declude.JunkMail] Another very effective filter test
Bill, One other very important note. You need to be using IMail 8, WHITELIST AUTH with Declude 1.76b and make sure that all the mail clients are configured to use SMTP AUTH, otherwise intra-server E-mail is going to get tagged. I can't use this in it's present form because I'm using IMail 7 :( Am I missing something? Matt Bill Landry wrote: This test is very effective at flagging or blocking spam from mail hosts that attempt to connect to your mail server and announce your own hostnames or IP addresses to it in their HELO string, especially if your IMail/Declude server is directly sending and receiving mail from the Internet (less functional, but still works if relaying via mail gateway to IMail/Declude). This filter looks for the bogus HELO info in the headers. In my testing, 100% of the messages delivered by these mail hosts is spam. Think about it, why would any other legitimate mail server out there attempt to connect to your mail server announcing your own hostname or IP address in its HELO string? The answer is, it wouldn't. Anyway, here is the test I use to detect these. In global.cfg: FORGEDHELO-FILTER filter M:\IMail\Declude\ForgedHelo-Filter.txt x 7 0 In ForgedHelo-Filter.txt file: = # In case you have mail gateways, deduct equal weight for these hosts HELO -7 ENDSWITH gw1.yourdomain.com HELO -7 ENDSWITH gw2.yourdomain.com # Remote mail hosts connecting and announcing your IP addresses HELO 0 CONTAINS xxx.xxx.xxx. HELO 0 CONTAINS xxx.xxx.xxx. # Remote mail hosts connection and announcing your hostnames HELO 0 ENDSWITH your-host.com HELO 0 ENDSWITH your-host.net HELO 0 ENDSWITH cust-host.com HELO 0 ENDSWITH cust-host.net = If you are not already running a test like this, try it out. I think you will find that it will flag lots of spam. 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] Bogus email from local domain
Ah, now I understand. That could be a nice feature, since you are correct, IMail should know whether the account exists or not. A simple check of the From address (if it shows a local domain) would be all that it would take, and then a simple reject if the account does not exist as a user or alias. Bill - Original Message - From: Kami Razvan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 7:58 AM Subject: RE: [Declude.JunkMail] Bogus email from local domain :) We do not have nobody. Let me explain again since there is a misunderstanding here. If I send you an email and make my outlook Reply address: [EMAIL PROTECTED] domain.com you will get the email. Right? I can change my email to: [EMAIL PROTECTED] Naturally that email does not exist. All I say is Imail should know its own database and this query should be much faster than doing the IP4R tests. So before it does anything - if it receives an email from a domain that is local to it - IMail has to make sure that email exists. Otherwise reject the email. - in Imail list I was suggesting Imail to reject it.. In Declude we can simply have a test that can say this FROM address is invalid as a local domain. So someone can not have: [EMAIL PROTECTED] in their from address and send me email. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Landry Sent: Monday, September 22, 2003 9:55 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Bogus email from local domain Kami, if you remove the nobody alias from your hosted domains, then IMail will simply refuse to accept delivery for non-existent users with a 550 no such user and neither IMail nor Declude will have to do any processing for these messages. Bill - Original Message - From: Kami Razvan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 22, 2003 5:30 AM Subject: [Declude.JunkMail] Bogus email from local domain Hi; I just posted a message in the IMail list regarding this.. Can a test be defined so emails from local domains that do not exist are identified. E.g.: [EMAIL PROTECTED] This user does not exist. If Declude could have a test - InvalidLocalUser - then we can simply add a large enough weight or hopefully later on when such feature is available stop processing the email from this user and simply delete it. When you receive about 20 of these emails to different people one can imagine all the useless cpu required to process what could have simply been deleted. 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. --- [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. --- [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.
