[Declude.JunkMail] automated response
I am out of the office until Wed. Oct 19. Thank you for your message, I will get back to you as soon as I can after I return. John Richardson --- 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: Re[8]: [Declude.JunkMail] DNS Changes
Thanks, K. ipconfig from a mailserver that can surf the net is another "duh" quickie... . --Sandy --- 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: Re[8]: [Declude.JunkMail] DNS Changes
Not to be picky but run this query instead nslookup -q=mx gmail.com. 1.2.3.4 If you do not include the dot it may append the default domain for the windows box to the query. If there is no default domain specified then all is good. But the extra do will always work. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Thursday, October 09, 2008 1:35 PM To: Linda Pagillo Subject: Re[8]: [Declude.JunkMail] DNS Changes >I worked for an ISP for a long time before joining Declude. DNS > servers are NOT useless without the recursive DNS option turned on. > I don't know where you're getting your information, but it is > incorrect. What I said was (it's right there above, please reread) there is nothing else they could do with said servers _that would lead them to believe they were suitable for Declude's use_. That is obvious. There is no reason anyone should think that authoritative-only nameservers are "their DNS servers". Such servers could not be the servers they use to surf the web, for example. The only reason they would enter such a server into the Declude config is because they have not been sufficiently briefed on the characteristics of the server that is suitable for Declude vs. one that may not be used. The test "can you run 'nslookup -q=mx gmail.com 1.2.3.4' is enough to tell people that the 1.2.3.4 is or isn't valid. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release / Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/downloa d/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re lease/ --- 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 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[8]: [Declude.JunkMail] DNS Changes
>I worked for an ISP for a long time before joining Declude. DNS > servers are NOT useless without the recursive DNS option turned on. > I don't know where you're getting your information, but it is > incorrect. What I said was (it's right there above, please reread) there is nothing else they could do with said servers _that would lead them to believe they were suitable for Declude's use_. That is obvious. There is no reason anyone should think that authoritative-only nameservers are "their DNS servers". Such servers could not be the servers they use to surf the web, for example. The only reason they would enter such a server into the Declude config is because they have not been sufficiently briefed on the characteristics of the server that is suitable for Declude vs. one that may not be used. The test "can you run 'nslookup -q=mx gmail.com 1.2.3.4' is enough to tell people that the 1.2.3.4 is or isn't valid. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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: Re[8]: [Declude.JunkMail] DNS Changes
I will admit, Bind is not the easiest thing to setup if you are a new admin. The first time I tried to setup bind it took me about 3 hours, but to me the benefits outweigh commercial packages. Including reading on-line documentation and eliminating one error at a time, making sure it was secure. But now that I have the minimal settings it is a 5 minute setup. I have passed these instructions on to many other not so experienced admins. These instructions work on any platform bind will run on. Just change the paths to suit the OS. Kevin Bilbee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Thursday, October 09, 2008 11:48 AM To: Kevin Bilbee Subject: Re[8]: [Declude.JunkMail] DNS Changes > I have a suggestion since DNS is so critical to Declude. A secure recursive > bind implementation can be setup in less than 5 minutes. Kevin, thank you very much for proving the absurd ease with which this one (of many) DNS servers can be set up for this purpose, and to everybody else who voiced their agreement. I expect the voices of the qualified sysadmins here are unified. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release / Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/downloa d/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/re lease/ --- 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 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[8]: [Declude.JunkMail] DNS Changes
> I have a suggestion since DNS is so critical to Declude. A secure recursive > bind implementation can be setup in less than 5 minutes. Kevin, thank you very much for proving the absurd ease with which this one (of many) DNS servers can be set up for this purpose, and to everybody else who voiced their agreement. I expect the voices of the qualified sysadmins here are unified. --Sandy Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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: Re[6]: [Declude.JunkMail] DNS Changes
Thanks Kevin. I will be sure to pass this info on to the customers that i speak with. From: "Kevin Bilbee" <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2008 2:19 PM To: declude.junkmail@declude.com Subject: RE: Re[6]: [Declude.JunkMail] DNS Changes I have a suggestion since DNS is so critical to Declude. A secure recursive bind implementation can be setup in less than 5 minutes. How is this difficult? There is no learning DNS. Steps - Tested with Bind 9.5.0-P2 Windows XP/2003/2008 Binary Kit 1) Download BIND http://www.isc.org/index.pl?/sw/bind/index.php 2) Install Bind a. Unzip and run BINDInstall.exe b. Give the service account a strong password c. Do not start bind service after install 3) Configure Bind a. Go to c:\windows\system32\dns and give the service account "named" read\write permissions to the etc folder b. Place the attached files into the etc folder. c. Open a command propmt i. CD to c:\windows\system32\dns\bin ii. Run rndc-confgen -a d. Change the first line of the named.conf file to your IP range that needs recursive DNS. I would use the ip address of the mail server and 12.0.0.1. change the 169.14.238.0/24 to the IP of your mail server. acl "dmz" { 169.14.238.0/24; 127.0.0.1; }; 4) Start bind and make some queries This process takes less than 5 minutes. You now have a reliable easily upgradeable recursive DNS dedicated to your mail server. Kevin Bilbee From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Linda Pagillo Sent: Thursday, October 09, 2008 8:47 AM To: declude.junkmail@declude.com Subject: re: Re[6]: [Declude.JunkMail] DNS Changes Sandy, Yes, things may be slowed down a bit by using a DNS server over a > WAN, how many people i speak with who do not have the recursive option > set on their DNS servers... ... even more so, they are using their ISP's DNS server and the ISP > does not allow recursive lookups because of the high traffic. We have no bearing on how people choose to run their business or > educate their employees. I will work on getting a few articles together next week. If you > would like to contribute your extensive knowledge of DNS, shoot me > an email at [EMAIL PROTECTED] and i will glady add your > information. Sent: Thursday, October 09, 2008 4:44 AM To: "Linda Pagillo" Subject: Re[6]: [Declude.JunkMail] DNS Changes > In a perfect world this would be correct, but as you already know > from working in the IT profession, no server, DNS or otherwise has > an uptime of 100%. A single physical "DNS server" may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all "enterprise" IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likely talking about making DNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. > Yes, things may be slowed down a bit by using a DNS server over a > WAN, Will certainly be slowed down, no "may", let's please be clear about this. > but in my experience, it's more reliable to use the OpenDNS servers > with Declude because they are configured properly for use of the RBL > tests. An OpenDNS server is not "more reliable" for RBL lookups than local recursive DNS servers. It is "more reliable" than overloaded ISP DNS servers. That is not the same statement. > You'd be suprised how many people i talk to in a week who have very > little understanding about the role DNS plays in having these tests > work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they
[Declude.JunkMail] Project Honeypot
Anyone using Project Honeypot as a spam database lookup? If so, what do you have in your declude configuration for the setup? Thanks David --- 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: Re[6]: [Declude.JunkMail] DNS Changes
Sandy, Yes, things may be slowed down a bit by using a DNS server over a > WAN, how many people i speak with who do not have the recursive option > set on their DNS servers... ... even more so, they are using their ISP's DNS server and the ISP > does not allow recursive lookups because of the high traffic. We have no bearing on how people choose to run their business or > educate their employees. I will work on getting a few articles together next week. If you > would like to contribute your extensive knowledge of DNS, shoot me > an email at [EMAIL PROTECTED] and i will glady add your > information. Sent: Thursday, October 09, 2008 4:44 AM To: "Linda Pagillo" Subject: Re[6]: [Declude.JunkMail] DNS Changes > In a perfect world this would be correct, but as you already know > from working in the IT profession, no server, DNS or otherwise has > an uptime of 100%. A single physical "DNS server" may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all "enterprise" IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likely talking about making DNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. > Yes, things may be slowed down a bit by using a DNS server over a > WAN, Will certainly be slowed down, no "may", let's please be clear about this. > but in my experience, it's more reliable to use the OpenDNS servers > with Declude because they are configured properly for use of the RBL > tests. An OpenDNS server is not "more reliable" for RBL lookups than local recursive DNS servers. It is "more reliable" than overloaded ISP DNS servers. That is not the same statement. > You'd be suprised how many people i talk to in a week who have very > little understanding about the role DNS plays in having these tests > work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. > I don't consider the questions that are asked by our customers as > "stupid stuff that is not our fault", especially the questions about > how DNS plays an important role in our product. But you know very well what I mean by "stupid stuff...". These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell at them, and you don't tell them to rely on somebody else's account. You do the smart thing and reset their password. Likewise for people that can't open their corporate e-mail account because they forgot to plug in their LAN cable when they came back from a trip. You don't hang up on them, and you don't tell to go down to the local coffee shop and use their GMail account. You tell them how to deal with the problem, not how to avoid it. > When a customer comes to me in a panic about their mail backing up > and causing delays, they are quite happy when we diagnose, fix and > educate them about the issue, DNS related or otherwise. I do not see > that as "bad" service. We provide some of the best support > available. If you would like to see the thank you letters and cards > that i receive each year, i will gladly show them to you. I'm not debating whether people are pleased with your service. I am sure they are pleased as punch to have avoided learning something new and nonetheless brought their mailserver back to life (albeit at lower performance). That does not chang
Re: Re[6]: [Declude.JunkMail] DNS Changes
There is also the question of loss of connectivity from point A to OpenDNS server #1 which is all that you have if you setup Declude to use a Single Source DNS server. If anywhere in that path there is an outage you will have no DNS. Far better to learn a little about DNS and run your own. Then you can at least use several other sources even if you care to set it up to use OpenDNS. As for $0.01 I have changed that as of recent events to $0.005 as your 401K has probably gone down that much in recent months. At 09:01 AM 10/9/2008 -0400, Darin Cox wrote: >1. The customer has no control over its availability. >My $0.01. (decreased due to inflation and other financial considerations, >plus being mostly a reiteration of points already made) - This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of these documents is strictly prohibited. If you have received this information in error, please notify the sender immediately and arrange for the return or destruction of the document(s). Warning: All e-mail sent to or from this address will be received or otherwise recorded by the Corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. --- 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: Re[6]: [Declude.JunkMail] DNS Changes
I have to say I also agree with Sandy. While recommending a free external DNS solution like OpenDNS is an easy fix for many less technical customers, as Sandy has pointed out it is not the best solution. 1. The customer has no control over its availability. With a free external DNS solution there is no guarantee it will be available in the future. This is why an internal or pay-for solution is generally a better choice, especially for something as critical as business mail services. 2. There is a performance hit from using external DNS for mail processing. So again, while recommending it may be an easy fix, and may get you many thanks, the above points should always be discussed so the customer understands the implications of using a solution like OpenDNS. While there is a full range of customer knowledge levels and desired depth/control of a technical solution, I would have to agree that running mail servers and use of a technical solution like Declude should require a background knowledge in DNS and SMTP. I would think that being halfway up-to-speed with the technical background necessary is a much worse and dangerous place to be in running these services than either outsourcing or having a deep enough understanding to do something as simple as set up multiple internal DNS servers with recursion turned on. My $0.01. (decreased due to inflation and other financial considerations, plus being mostly a reiteration of points already made) Darin. - Original Message - From: "Sanford Whiteman" <[EMAIL PROTECTED]> To: "Linda Pagillo" Sent: Thursday, October 09, 2008 4:52 AM Subject: Re[6]: [Declude.JunkMail] DNS Changes > In a perfect world this would be correct, but as you already know > from working in the IT profession, no server, DNS or otherwise has > an uptime of 100%. A single physical "DNS server" may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all "enterprise" IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likelytalkingaboutmakingDNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. > Yes, things may be slowed down a bit by using a DNS server over a > WAN, Will certainly be slowed down, no "may", let's please be clear about this. > but in my experience, it's more reliable to use the OpenDNS servers > with Declude because they are configured properly for use of the RBL > tests. An OpenDNS server is not "more reliable" for RBL lookups than local recursive DNS servers. It is "more reliable" than overloaded ISP DNS servers. That is not the same statement. > You'd be suprised how many people i talk to in a week who have very > little understanding about the role DNS plays in having these tests > work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. > I don't consider the questions that are asked by our customers as > "stupid stuff that is not our fault", especially the questions about > how DNS plays an important role in our product. But you know very well what I mean by "stupid stuff...". These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't
RE: Re[6]: [Declude.JunkMail] DNS Changes
Sandy, I agree with you. While recommending OpenDNS is certainly painless and easy for the support desk, it is certainly not the best solution for an "in-house" mail server - especially those running anti-spam products. Just my .02 ~Patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Thursday, October 09, 2008 4:52 AM To: Linda Pagillo Subject: Re[6]: [Declude.JunkMail] DNS Changes > In a perfect world this would be correct, but as you already know from > working in the IT profession, no server, DNS or otherwise has an > uptime of 100%. A single physical "DNS server" may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all "enterprise" IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likelytalkingaboutmakingDNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. > Yes, things may be slowed down a bit by using a DNS server over a > WAN, Will certainly be slowed down, no "may", let's please be clear about this. > but in my experience, it's more reliable to use the OpenDNS servers > with Declude because they are configured properly for use of the RBL > tests. An OpenDNS server is not "more reliable" for RBL lookups than local recursive DNS servers. It is "more reliable" than overloaded ISP DNS servers. That is not the same statement. > You'd be suprised how many people i talk to in a week who have very > little understanding about the role DNS plays in having these tests > work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. > I don't consider the questions that are asked by our customers as > "stupid stuff that is not our fault", especially the questions about > how DNS plays an important role in our product. But you know very well what I mean by "stupid stuff...". These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell at them, and you don't tell them to rely on somebody else's account. You do the smart thing and reset their password. Likewise for people that can't open their corporate e-mail account because they forgot to plug in their LAN cable when they came back from a trip. You don't hang up on them, and you don't tell to go down to the local coffee shop and use their GMail account. You tell them how to deal with the problem, not how to avoid it. > When a customer comes to me in a panic about their mail backing up > and causing delays, they are quite happy when we diagnose, fix and > educate them about the issue, DNS related or otherwise. I do not see > that as "bad" service. We provide some of the best support > available. If you would like to see the thank you letters and cards > that i receive each year, i will gladly show them to you. I'm not debating whether people are pleased with your service. I am sure they are pleased as punch to have avoided learning something new and nonetheless brought their mailserver back to life (albeit at lower performance). That does not change the fact that by suggesting that the "right" thing to do for DNS is use a
Re[6]: [Declude.JunkMail] DNS Changes
> In a perfect world this would be correct, but as you already know > from working in the IT profession, no server, DNS or otherwise has > an uptime of 100%. A single physical "DNS server" may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all "enterprise" IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likelytalkingaboutmakingDNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. > Yes, things may be slowed down a bit by using a DNS server over a > WAN, Will certainly be slowed down, no "may", let's please be clear about this. > but in my experience, it's more reliable to use the OpenDNS servers > with Declude because they are configured properly for use of the RBL > tests. An OpenDNS server is not "more reliable" for RBL lookups than local recursive DNS servers. It is "more reliable" than overloaded ISP DNS servers. That is not the same statement. > You'd be suprised how many people i talk to in a week who have very > little understanding about the role DNS plays in having these tests > work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. > I don't consider the questions that are asked by our customers as > "stupid stuff that is not our fault", especially the questions about > how DNS plays an important role in our product. But you know very well what I mean by "stupid stuff...". These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell at them, and you don't tell them to rely on somebody else's account. You do the smart thing and reset their password. Likewise for people that can't open their corporate e-mail account because they forgot to plug in their LAN cable when they came back from a trip. You don't hang up on them, and you don't tell to go down to the local coffee shop and use their GMail account. You tell them how to deal with the problem, not how to avoid it. > When a customer comes to me in a panic about their mail backing up > and causing delays, they are quite happy when we diagnose, fix and > educate them about the issue, DNS related or otherwise. I do not see > that as "bad" service. We provide some of the best support > available. If you would like to see the thank you letters and cards > that i receive each year, i will gladly show them to you. I'm not debating whether people are pleased with your service. I am sure they are pleased as punch to have avoided learning something new and nonetheless brought their mailserver back to life (albeit at lower performance). That does not change the fact that by suggesting that the "right" thing to do for DNS is use a free service, you are pretending that DNS is not a necessary skill area for a mail admin, and *that is ridiculous*. These are DECLUDE users we are talking about! Yours is not a tremendously user-friendly product in the anti-spam scene. Its powers are rich and at times obscure. Maybe some people can get by with the defaults for a while; eventually, that will not suffice. And if they want to understand how to optimize their anti-abuse de
re: Re[4]: [Declude.JunkMail] DNS Changes
Sandy... >Uptime should be 100% on DNS servers. It's 2008! This should not even >be a consideration. No matter how wonderfully they work, a >high-traffic mail server will _always_ be slowed down by using DNS >servers over a WAN. In a perfect world this would be correct, but as you already know from working in the IT profession, no server, DNS or otherwise has an uptime of 100%. I have yet to see one that does in the 10 years that i have been an IT professional. Yes, things may be slowed down a bit by using a DNS server over a WAN, but in my experience, it's more reliable to use the OpenDNS servers with Declude because they are configured properly for use of the RBL tests. You'd be suprised how many people i talk to in a week who have very little understanding about the role DNS plays in having these tests work properly. >Well... anyone running a help desk for an otherwise stable >product/environment sees the majority of questions for stupid stuff >that is not your fault. Does that mean that corporate help desks, >which are constantly saddled with password resets and access requests, >should just tell users to share the same user account + password? >(Some do: bad ones.) I don't consider the questions that are asked by our customers as "stupid stuff that is not our fault", especially the questions about how DNS plays an important role in our product. When a customer comes to me in a panic about their mail backing up and causing delays, they are quite happy when we diagnose, fix and educate them about the issue, DNS related or otherwise. I do not see that as "bad" service. We provide some of the best support available. If you would like to see the thank you letters and cards that i receive each year, i will gladly show them to you. In my years of working in this business, i have never come across a technical support agent that spent hours on the phone with me (on holidays, weekends, after hours and days off) providing me with an educated, detailed description and resolution of a problem i was having. I have never had a technical support agent give me their personal cell phone number so that i could reach them in their worst time of need. We proudly go above and beyond the call of duty. If that is considered bad service, i don't know what to say. Sent: Thursday, October 09, 2008 1:44 AM To: "Linda Pagillo" Subject: Re[4]: [Declude.JunkMail] DNS Changes > Kevin, in our experience, the two OpenDNS servers (208.67.220.220 > and 208.67.222.222) that we suggest be used with Declude, work > wonderfully and the uptime is excellent. Uptime should be 100% on DNS servers. It's 2008! This should not even be a consideration. No matter how wonderfully they work, a high-traffic mail server will _always_ be slowed down by using DNS servers over a WAN. > Like i said earlier, we here in support see a lot of problems from > our customer's in-house DNS servers failing to do recursive lookups. Well... anyone running a help desk for an otherwise stable product/environment sees the majority of questions for stupid stuff that is not your fault. Does that mean that corporate help desks, which are constantly saddled with password resets and access requests, should just tell users to share the same user account + password? (Some do: bad ones.) > Giving our customers the suggestion and the option to use the > OpenDNS server(s) is exactly that, a suggestion and an option. Actually, what you said was "I suggest always using 208.67.220.220 because you will never have to rely on your internal DNS" -- that is not an idle option but a pretty firm prescription from the company. Guess it depends on whether "suggest" beats "always" or vice versa. > You can use any DNS server that does recursive lookups. The problem is, > most of the people we come across on a daily basis do not have > recursive lookup option set up on their local DNS servers. All companies either have an internal recursive DNS server (maybe they don't know its IP?) or already use their ISPs DNS or some other remote DNS service like OpenDNS. Are you talking about people who have a DNS server running on localhost, but not a recursive server, and have deliberately set Declude to use this server instead of the fully functioning one they must have in order to send mail? G-d help us if these people are blithely switching to OpenDNS instead of taking their DNS illiteracy seriously! I would submit that you are both (a) doing your own product a disservice by hampering its performance AND (b) doing your client a disservice by treating their management like "It's okay that your IT person doesn't know how to configure/locate the simplest possible DNS setup, he/she can still be a responsible mail admin." This may be a good way to grab more Declude users who would otherwise outsource all of their anti-spam, but it is unethical to suggest that anyone so unqualified should be in charge of their company's anti-spam defenses. Sorry if anyone's feelings are h