[Declude.JunkMail] Warning for Bulk Register/Comcast customers
One of my resellers today just brought over a couple more domains due to Comcast blocking the mailforward.bulkregister.com servers for the past two days. These servers are used by Bulk Register to forward all E-mail for a given domain to accounts hosted elsewhere and they have minimal if any spam blocking on them. The Comcast blocking might be isolated to just one region (Northern Pennsylvania), but it might also be a widespread issue. I suspect that the massive volumes of Sober viruses spit out by the latest variants is the cause of Comcast taking drastic action. So anyway, I just wanted to warn those with customers that forward from Bulk Register to Comcast hosted accounts since they might be experiencing issues. Matt --- [This E-mail was scanned for viruses by Declude EVA 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] OT - At wits end
Orin, I have seen these issues in relation to EDNS0 being enabled on one of the servers. While most servers and firewalls will work perfectly with EDNS0 enabled, there are certainly some that will produce consistent failed lookups. EDNS0 is a new way of doing DNS lookups by sending more data in a single packet, but some older software sees this as invalid or an attempted exploit and rejects these packets. It does not fall back effectively. One possibility is the server that IMail is querying is based on Windows 2003 DNS and has EDNS0 enabled. This can happen with an old firewall as well as older versions of BIND. If so, they definitely should disable it, and instructions can be found here: http://support.microsoft.com/kb/828263 Since you are running your own mail server, you should also definitely consider turning DNS on for your own server so that you don't have to rely on others. If you are using Windows 2003, then you should follow the above instructions regardless of whether or not you see any problems. In the long-run you just simply can't rely upon someone else's server like this, and by installing it on your IMail/Declude box it will not require you to also host DNS records...it can cache-only. Setup of Microsoft DNS is super easy, and you can point both IMail and Declude at it by using 127.0.0.1 as the IP to query. The other advice given so far could also net good results, but doing it yourself will very likely fix the problem and make you self-sufficient from here on. Matt Orin Wells wrote: We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our mail server that iMail would trip down to it and find the target. I first tried a qwest.net DNS server and I thought it was going to work until I got back a message saying the destination email address was not valid (no relaying). I thought that odd so I replaced the server with the douglasfast.net dns server. I was right back to where I started wondering why anything different happened when the Qwest sever was in place because it appears iMail only knows about a single DNS server. The one entered in iMail itself. I am not about to make the douglasfast.net server our primary dns server to solve this for a single client. Now it appears our DNS servers see every known domain in the world except any behind this service (douglasfast.net - which is an electric company offering network services in Roseburg, OR). And apparently every DNS server in the world can see their domains except ours. The two ISPs are apparently not eager to talk to each other to help resolve the problem so we have the usual the problem has to be on their end finger pointing. And I don't have the experience to try to figure out why the DNS servers at our server farm can not talk to the DNS servers at the destination site or even to spot the real problem. It does not appear to be an issue of IP blocking as such because I can telnet into the destination mail server from within our server (behind the 64.85... ) using their ip address. Both ends have verified that there is no IP blocking going on at fire walls, routers or in the Exchange server - or they have claimed to have checked this. I can also see their domain from my workstation that is connected to qwest.net. Why do the qwest DNS servers work OK and the DNSWizards do not? The folks at our server farm have tried a variety of tests, cache flushes and
[Declude.JunkMail] Declude and IMail 2006
We have had access to the Beta and have run all our standard tests successfully. The caveat that I will offer is that there is no way in which we can replicate every combination of tests and events in our simulated environments. But to the best of our knowledge Declude and IMail 2006 seem to be OK David B www.declude.com --- [This E-mail was scanned for viruses by Declude EVA 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] OT - At wits end
Dave I've tried this, and when I point imail to 127.0.0.1 the spam log shows that I'm not able to connect to the external spam databases. As soon as I point imail back to our dns server, the spam filter begins to work again. I've got our two DNS servers, and one other all set up in the tcp properties on the imail box. Any thoughts? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Doherty Sent: Tuesday, November 29, 2005 11:03 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT - At wits end Hi, Orin- A couple of suggestions First, look at your HOSTS file in c:\winnt\system32\drivers\etc to see if 64.62.134.10 is listed there. Delete the entry if you find it there. Next, add DNS service to your IMail server. Set the DNS servers in Network Properties to known-good upstream DNS resolvers. Set the DNS address in IMail to 127.0.0.1. This has the effect of providing mulitple DNS servers to IMail. -d - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 1:35 AM Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our mail server that iMail would trip down to it and find the target. I first tried a qwest.net DNS server and I thought it was going to work until I got back a message saying the destination email address was not valid (no relaying). I thought that odd so I replaced the server with the douglasfast.net dns server. I was right back to where I started wondering why anything different happened when the Qwest sever was in place because it appears iMail only knows about a single DNS server. The one entered in iMail itself. I am not about to make the douglasfast.net server our primary dns server to solve this for a single client. Now it appears our DNS servers see every known domain in the world except any behind this service (douglasfast.net - which is an electric company offering network services in Roseburg, OR). And apparently every DNS server in the world can see their domains except ours. The two ISPs are apparently not eager to talk to each other to help resolve the problem so we have the usual the problem has to be on their end finger pointing. And I don't have the experience to try to figure out why the DNS servers at our server farm can not talk to the DNS servers at the destination site or even to spot the real problem. It does not appear to be an issue of IP blocking as such because I can telnet into the destination mail server from within our server (behind the 64.85... ) using their ip address. Both ends have verified that there is no IP blocking going on at fire walls, routers or in the Exchange server - or they have claimed to have checked this. I can also see their domain from my workstation that is connected to qwest.net. Why do the qwest DNS servers work OK and the DNSWizards do not? The folks at our server farm have tried a variety of tests, cache flushes and re-acquisitions along with a lot of other things and have not figured out what is going on nor made any headway. If you use dnsstuff.com on the douglasfast.net DNS servers the results are sometimes odd. There are some FAIL issues indicating there are some timing problems on the server (using DNSReport.com). Checking for the MX records seems to correctly identify the mail server (DNS
RE: [Declude.JunkMail] OT - At wits end
At 10:57 PM 11/29/2005, John T \(Lists\) wrote: The domain you are trying to send to has DNS problems. http://www.dnsreport.com/tools/dnsreport.ch?domain=ucancap.org This we knew. But no one on their end seems to care much about that. I question it is the cause of what we are seeing. Your domain has minor DNS problems. http://www.dnsreport.com/tools/dnsreport.ch?domain=cado-oregon.org I actually hadn't done a look up on this one. I will point this out to our ISP. Likely this is true for any of our domains. Have you tried clearing the DNS Cache on your DNS servers? I have been assured this has been done several times. Have you tried to do a NSLookup for the MX record of the recipient domain from your DNS servers? From the Imail server? I have been told the ISP has tried this to no success. I can not do it from our iMail server. I can get to the DNS server but it won't give me a response when I try it. Maybe I am doing something wrong. dnsstuff.com seems to have no problem finding it. Thanks. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Orin Wells Sent: Tuesday, November 29, 2005 10:36 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our mail server that iMail would trip down to it and find the target. I first tried a qwest.net DNS server and I thought it was going to work until I got back a message saying the destination email address was not valid (no relaying). I thought that odd so I replaced the server with the douglasfast.net dns server. I was right back to where I started wondering why anything different happened when the Qwest sever was in place because it appears iMail only knows about a single DNS server. The one entered in iMail itself. I am not about to make the douglasfast.net server our primary dns server to solve this for a single client. Now it appears our DNS servers see every known domain in the world except any behind this service (douglasfast.net - which is an electric company offering network services in Roseburg, OR). And apparently every DNS server in the world can see their domains except ours. The two ISPs are apparently not eager to talk to each other to help resolve the problem so we have the usual the problem has to be on their end finger pointing. And I don't have the experience to try to figure out why the DNS servers at our server farm can not talk to the DNS servers at the destination site or even to spot the real problem. It does not appear to be an issue of IP blocking as such because I can telnet into the destination mail server from within our server (behind the 64.85... ) using their ip address. Both ends have verified that there is no IP blocking going on at fire walls, routers or in the Exchange server - or they have claimed to have checked this. I can also see their domain from my workstation that is connected to qwest.net. Why do the qwest DNS servers work OK and the DNSWizards do not? The folks at our server farm have tried a variety of tests, cache flushes and re-acquisitions along with a lot of other things and have not figured out what is going on nor made any headway. If you use dnsstuff.com on the douglasfast.net DNS servers the results are sometimes odd. There are some FAIL issues indicating there
Re: [Declude.JunkMail] OT - At wits end
At 11:03 PM 11/29/2005, Dave Doherty wrote: Hi, Orin- A couple of suggestions First, look at your HOSTS file in c:\winnt\system32\drivers\etc to see if 64.62.134.10 is listed there. Delete the entry if you find it there. Thanks. Done that. Nothing there. Next, add DNS service to your IMail server. I have been hesitant to do our own DNS services because of others who have told me doing your own DNS can become a full time job. I am assuming they are talking about a registered DNS server when every hacker in the world wants to play with it. I hadn't thought about activating DNS though. We are running a 2000 server and I would have to figure out how to turn it on. We will be going to 2003 soon if we can ever get the servers running correctly. I hate hardware!! Set the DNS servers in Network Properties to known-good upstream DNS resolvers. Other than this, the primary servers for all our domains are thought to be good. I believe they have another server we could add to the stream. Set the DNS address in IMail to 127.0.0.1. This has the effect of providing mulitple DNS servers to IMail. Ahhh. That was a piece I was missing here. We have 64.85.13.6 which is the primary DNS server. Will this then use the servers in Network Properties or is it going to expect the local server to be providing DNS services? Thanks for the suggestions. -d - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 1:35 AM Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our mail server that iMail would trip down to it and find the target. I first tried a qwest.net DNS server and I thought it was going to work until I got back a message saying the destination email address was not valid (no relaying). I thought that odd so I replaced the server with the douglasfast.net dns server. I was right back to where I started wondering why anything different happened when the Qwest sever was in place because it appears iMail only knows about a single DNS server. The one entered in iMail itself. I am not about to make the douglasfast.net server our primary dns server to solve this for a single client. Now it appears our DNS servers see every known domain in the world except any behind this service (douglasfast.net - which is an electric company offering network services in Roseburg, OR). And apparently every DNS server in the world can see their domains except ours. The two ISPs are apparently not eager to talk to each other to help resolve the problem so we have the usual the problem has to be on their end finger pointing. And I don't have the experience to try to figure out why the DNS servers at our server farm can not talk to the DNS servers at the destination site or even to spot the real problem. It does not appear to be an issue of IP blocking as such because I can telnet into the destination mail server from within our server (behind the 64.85... ) using their ip address. Both ends have verified that there is no IP blocking going on at fire walls, routers or in the Exchange server - or they have claimed to have checked this. I can also see their domain from my workstation that is connected to qwest.net. Why do the qwest DNS servers work OK and the DNSWizards do not? The folks at our server farm have tried a variety of tests,
[Declude.JunkMail] Declude 3.0.5.21 Posted
JM - INVITEFIXON Located in Declude.cfg. Some customers had issues related to Outlook meeting requests appearing as text only. The default for this directive is OFF. JM - Fixed skipping of certain DNSBL tests. JM - STOPALLTESTS is now working correctly EVA - Incorrect log entries regarding to licensing with EVA EVA - Vulnerability Notifications available for Imail David B www.declude.com --- [This E-mail was scanned for viruses by Declude EVA 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] OT - At wits end
I have been hesitant to do our own DNS services because of others who have told me doing your own DNS can become a full time job. I am assuming they are talking about a registered DNS server when every hacker in the world wants to play with it. I hadn't thought about activating DNS though. We are running a 2000 server and I would have to figure out how to turn it on. We will be going to 2003 soon if we can ever get the servers running correctly. I hate hardware!! I have been running my own DNS servers for 4 years and never have had a problem or compromise. At one point a couple years ago, Len Conrad even ran some tests against my servers and they passed fine. On my Imail server, DNS service is running as a cache only server and is for use only for Imail and Declude. There are no domains configured. This configuration speeds up the process for both Imail and Declude. On my 3 DNS servers, I have about 45 domain zones on them. Once a zone is set up, there is no maintaining it unless a record has to change. John T eServices For You --- [This E-mail was scanned for viruses by Declude EVA 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] OT - At wits end
My two cents ... John and Matt are offering sound best practices advice for installing a cacheing only DNS on your Windows 2000. It's dead easy, and you'll find that your queries to find mail servers and RBL answers are faster. Cacheing only means that this DNS service on your Imail server won't be responsible for serving up any zones, so you don't need to worry about messing that up. If you're worried about the bad guys (of course!), you can easily configure the service to only accept queries from your internal machines by IP, and/or use your firewall to block inbound queries. I tested using the nameserver you cited to look up ucancap.org and found that it could timeout, but once I got the record, it would be cached for 24 hours. I found that the reply came by UDP, was less than 512 bytes, and nicely included the IP address of the MX host along with the MX record. I noted that, at least from my network, I had really good tracert times (but they block ICMP). Their mailhost is slow to respond; reaching them, I see that their HELO greeting is barracuda.ucancap.org so I'd have to wonder how long they've had an antispam device from barracuda.com in front of their real mail host, and is this when you stopped being able to send them mail? ... I just did some nslookup tests using ns1.dnswizards.com and also ns2.dnswizards.com and get hinky results, with ridiculous timeouts. I'd suggest that if nothing else, you stop using them for your DNS queries! Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orin Wells Sent: Wednesday, November 30, 2005 8:09 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT - At wits end At 11:03 PM 11/29/2005, Dave Doherty wrote: Hi, Orin- A couple of suggestions First, look at your HOSTS file in c:\winnt\system32\drivers\etc to see if 64.62.134.10 is listed there. Delete the entry if you find it there. Thanks. Done that. Nothing there. Next, add DNS service to your IMail server. I have been hesitant to do our own DNS services because of others who have told me doing your own DNS can become a full time job. I am assuming they are talking about a registered DNS server when every hacker in the world wants to play with it. I hadn't thought about activating DNS though. We are running a 2000 server and I would have to figure out how to turn it on. We will be going to 2003 soon if we can ever get the servers running correctly. I hate hardware!! Set the DNS servers in Network Properties to known-good upstream DNS resolvers. Other than this, the primary servers for all our domains are thought to be good. I believe they have another server we could add to the stream. Set the DNS address in IMail to 127.0.0.1. This has the effect of providing mulitple DNS servers to IMail. Ahhh. That was a piece I was missing here. We have 64.85.13.6 which is the primary DNS server. Will this then use the servers in Network Properties or is it going to expect the local server to be providing DNS services? Thanks for the suggestions. -d - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 1:35 AM Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our
Re: [Declude.JunkMail] OT - At wits end
Andrew, I was reading your reponse, thinking This is one of the more lucid responses coming from the list (There is a huge amount of useful information from the list, but not all of it is lucid. Sometimes you have to dig for the gems.). And then I got down to the last paragraph and read hinky results! I almost fell out of my chair laughing... Don't get me wrong, I have used the word myself. But seeing it at the end of that response was like being handed the punch line to joke. So you have provided useful feedback AND brightened at least one persons day... Mike - Original Message - From: Colbeck, Andrew [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 12:53 PM Subject: RE: [Declude.JunkMail] OT - At wits end My two cents ... John and Matt are offering sound best practices advice for installing a cacheing only DNS on your Windows 2000. It's dead easy, and you'll find that your queries to find mail servers and RBL answers are faster. Cacheing only means that this DNS service on your Imail server won't be responsible for serving up any zones, so you don't need to worry about messing that up. If you're worried about the bad guys (of course!), you can easily configure the service to only accept queries from your internal machines by IP, and/or use your firewall to block inbound queries. I tested using the nameserver you cited to look up ucancap.org and found that it could timeout, but once I got the record, it would be cached for 24 hours. I found that the reply came by UDP, was less than 512 bytes, and nicely included the IP address of the MX host along with the MX record. I noted that, at least from my network, I had really good tracert times (but they block ICMP). Their mailhost is slow to respond; reaching them, I see that their HELO greeting is barracuda.ucancap.org so I'd have to wonder how long they've had an antispam device from barracuda.com in front of their real mail host, and is this when you stopped being able to send them mail? ... I just did some nslookup tests using ns1.dnswizards.com and also ns2.dnswizards.com and get hinky results, with ridiculous timeouts. I'd suggest that if nothing else, you stop using them for your DNS queries! Andrew 8) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orin Wells Sent: Wednesday, November 30, 2005 8:09 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] OT - At wits end At 11:03 PM 11/29/2005, Dave Doherty wrote: Hi, Orin- A couple of suggestions First, look at your HOSTS file in c:\winnt\system32\drivers\etc to see if 64.62.134.10 is listed there. Delete the entry if you find it there. Thanks. Done that. Nothing there. Next, add DNS service to your IMail server. I have been hesitant to do our own DNS services because of others who have told me doing your own DNS can become a full time job. I am assuming they are talking about a registered DNS server when every hacker in the world wants to play with it. I hadn't thought about activating DNS though. We are running a 2000 server and I would have to figure out how to turn it on. We will be going to 2003 soon if we can ever get the servers running correctly. I hate hardware!! Set the DNS servers in Network Properties to known-good upstream DNS resolvers. Other than this, the primary servers for all our domains are thought to be good. I believe they have another server we could add to the stream. Set the DNS address in IMail to 127.0.0.1. This has the effect of providing mulitple DNS servers to IMail. Ahhh. That was a piece I was missing here. We have 64.85.13.6 which is the primary DNS server. Will this then use the servers in Network Properties or is it going to expect the local server to be providing DNS services? Thanks for the suggestions. -d - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 1:35 AM Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and
Re: [Declude.JunkMail] Keyword
Given the fact that these types of tests (keyword, subjectetc) take up processor memory, is there a way to run a scan of the logs and get a list of the keywords that actually tripped the keyword filter, so that you can clean up a keyword list and remove the ones that are not doing anything? Thanks, Brian - Original Message - From: Matt To: Declude.JunkMail@declude.com Sent: Monday, November 28, 2005 8:53 PM Subject: Re: [Declude.JunkMail] Keyword Richard,That is going to be something that only the logs can tell you when you do things this way, and you would need to be running in Debug mode. The best way to tell what failed is to use a weight for the filter and then set the filter action to WARN, that way it will insert in the headers which line was failed.MattRichard Farris wrote: If I have a text file with all my keywords in it and the log file says KEYWORD HOLD (which it should) How do I know which keyword in the list of hundreds held it? Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet" - Original Message - From: John T (Lists) To: Declude.JunkMail@declude.com Sent: Monday, November 28, 2005 7:17 PM Subject: RE: [Declude.JunkMail] Keyword Depends upon how it failed. If by keyword you mean a filter test like my KEYSUBJECT then in the log it will tell you which line of the associated filter file that a match was found. John T eServices For You -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Richard FarrisSent: Monday, November 28, 2005 5:11 PMTo: Declude.JunkMail@declude.comSubject: [Declude.JunkMail] Keyword If you find your are holding mail because of a keyword, how do you find out which keyword it is? Richard FarrisEthixs Online1.270.247. Office1.800.548.3877 Tech Support"Crossroads to a Cleaner Internet
Re: [Declude.JunkMail] OT - At wits end
Hi Orin- Others have also answered this, but having a caching-only DNS server on your Imail box doesn't require that you run your own DNS. On the W2K server, access the Control Panel, Add/Remove Programs, and then click the option on the left-hand side that says Add/ remove Windows components. Highlight Networking Services, click the Details button, and check the DNS option, which I believe is the second choice. You may also be able to install it by placing the original W2K installation disk in the drive and letting autorun start up. Anyway, once installation is done be sure to access http://windowsupdate.microsoft.com to check for updates. I think there have been several updates to the DNS sevice since W2K first came out. Check the services applet to be sure the DNS Server service is up andrunning and set to automatic start. Check to be sure that you have a couple of good DNS resolvers in the network properties settings. You can test the resolvers you have chosenby opening a command prompt and attempting to ping a couple of blacklists, genral websites, etc. You may ot get responses if ICMP is blocked, but Ping should give you the resolved IP. If all is well, then set your DNS in Imail to 127.0.0.1 I have been running my Imail server for years this way, and it works great! -Dave - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 11:09 AM Subject: Re: [Declude.JunkMail] OT - At wits end At 11:03 PM 11/29/2005, Dave Doherty wrote: Hi, Orin- A couple of suggestions First, look at your HOSTS file in c:\winnt\system32\drivers\etc to see if 64.62.134.10 is listed there. Delete the entry if you find it there. Thanks. Done that. Nothing there. Next, add DNS service to your IMail server. I have been hesitant to do our own DNS services because of others who have told me doing your own DNS can become a full time job. I am assuming they are talking about a registered DNS server when every hacker in the world wants to play with it. I hadn't thought about activating DNS though. We are running a 2000 server and I would have to figure out how to turn it on. We will be going to 2003 soon if we can ever get the servers running correctly. I hate hardware!! Set the DNS servers in Network Properties to known-good upstream DNS resolvers. Other than this, the primary servers for all our domains are thought to be good. I believe they have another server we could add to the stream. Set the DNS address in IMail to 127.0.0.1. This has the effect of providing mulitple DNS servers to IMail. Ahhh. That was a piece I was missing here. We have 64.85.13.6 which is the primary DNS server. Will this then use the servers in Network Properties or is it going to expect the local server to be providing DNS services? Thanks for the suggestions. -d - Original Message - From: Orin Wells [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 1:35 AM Subject: [Declude.JunkMail] OT - At wits end We have a bit of a puzzler with one our clients in trying to communicate with another domain. What happens is they get 20 attempts failure to deliver. What is REALLY happening is that the DNS servers that service our environment do not see the target domain for some unknown reason and thus iMail is unable to resolve the domain to an ip address for delivery. And since our imail server is pointing to one of these DNS servers as our primary server I have been unable to find a way around the problem. It seems to have started on or about November 9th when the firewall at the target site received the last message from our server. We think something changed but no one will admit to anything changing. The sending environment is running under iMail 7.07 and is cado-oregon.org (IP 64.85.18.53). There are two dns servers providing our DNS: ns1.dnswizards.com and ns1.dnswizards.com (IP 64.85.13.6 and 64.85.14.6). The first is what iMail has as the designated DNS server. No domain on our server can send email to the domain ucancap.org (ip 64.62.134.10) - this actually ends up going to a domain called altrue.he.net which apparently hosts their website. This is odd, but they are happy with it and it is not the problem. Their mail is hosted on their own exchange server and the mx record at the destination hosting company shows it going to mail.ucancap.org (IP 216.110.199.124). The remote hosting DNS server is ns1.douglasfast.net (IP 216.110.195.3) I thought out of desperation that if I added an outside DNS server to the list used by our mail server that iMail would trip down to it and find the target. I first tried a qwest.net DNS server and I thought it was going to work until I got back a message saying the destination email address was not valid (no relaying). I thought that odd so I replaced the server with the
[Declude.JunkMail] declude.cfg threads procedure
Hi, I recently upgraded to Declude 3.0.5.20. Everything is running well except for a backlog in the proc directory in the heavy part of the day. I began adjusting threads in declude.cfg. The original setting was 5. With my Dual 1.5 Ghz machine, I figured 75 was closer to the mark. Do I need to stop/start any services to make the change effective, or just change the number in declude.cfg? Bill --- [This E-mail scanned for viruses by Declude EVA] --- [This E-mail was scanned for viruses by Declude EVA www.declude.com] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] declude.cfg threads procedure
Changes to the Declude.cfg file require a restart of the Decludeproc.exe service. Of course, I highly recommend first stopping the Imail SMTP and Queue Manager services before restarting the Decludeproc service but some one has posted that is not needed. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Bill Green dfn Systems Sent: Wednesday, November 30, 2005 1:40 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] declude.cfg threads procedure Hi, I recently upgraded to Declude 3.0.5.20. Everything is running well except for a backlog in the proc directory in the heavy part of the day. I began adjusting threads in declude.cfg. The original setting was 5. With my Dual 1.5 Ghz machine, I figured 75 was closer to the mark. Do I need to stop/start any services to make the change effective, or just change the number in declude.cfg? Bill --- [This E-mail scanned for viruses by Declude EVA] --- [This E-mail was scanned for viruses by Declude EVA 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 EVA www.declude.com] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] declude.cfg threads procedure
It's not necessary to stop/start any IMail services, since IMail calls declude.exe (not decludeproc.exe), and all declude.exe does is move the queue files from the spool directory to the proc directory. Decludeproc checks the proc directory at whatever time interval you have set in you declude.cfg and processes whatever it finds there. Bill - Original Message - From: John T (Lists) [EMAIL PROTECTED] To: Declude.JunkMail@declude.com Sent: Wednesday, November 30, 2005 2:09 PM Subject: RE: [Declude.JunkMail] declude.cfg threads procedure Changes to the Declude.cfg file require a restart of the Decludeproc.exe service. Of course, I highly recommend first stopping the Imail SMTP and Queue Manager services before restarting the Decludeproc service but some one has posted that is not needed. John T eServices For You -Original Message- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED] On Behalf Of Bill Green dfn Systems Sent: Wednesday, November 30, 2005 1:40 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] declude.cfg threads procedure Hi, I recently upgraded to Declude 3.0.5.20. Everything is running well except for a backlog in the proc directory in the heavy part of the day. I began adjusting threads in declude.cfg. The original setting was 5. With my Dual 1.5 Ghz machine, I figured 75 was closer to the mark. Do I need to stop/start any services to make the change effective, or just change the number in declude.cfg? Bill --- [This E-mail scanned for viruses by Declude EVA] --- [This E-mail was scanned for viruses by Declude EVA 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 EVA 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 EVA 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.
