[courier-users] RE: couriertls, rfc1035, and /etc/hosts
Sam Varshavchik [EMAIL PROTECTED] wrote: What's so hard about consulting /etc/hosts? It's expected behavior. There's still the IPv6 issue. The traditional resolver API does not support IPv6. There is a newer API that supports IPv6, defined by RFC 2553; but I don't know how widely it is implemented in various systems; or whether it checks the host files (it should, but I had no reason to bother to check). Linux had it since the 2.4 kernel series (and, BTW, I wrote the Linux man pages); however I don't think it's in Debian stable, which is still at 2.2. I don't know which of the BSDs have implemented it either. It's an unknown factor. It wouldn't be too difficult to have couriertls use this, but I don't know how many systems will break. Debian Woody (which is the current stable distro) won't break for sure, since no new Courier packages will be included in it, ever. New Courier packages will be included in Sarge (currently the testing distro, and being prepared to become the new stable distro), and Sid (always the unstable distro). Since testing and unstable both use 2.4 kernels, Courier on Debian as a whole wouldn't break. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Re: couriertls, rfc1035, and /etc/hosts
Jon Nelson writes: Well, 'localhost', for one, won't ever work properly. And the consequences of that are? It's not just localhost but anything and everything in /etc/hosts that is not otherwise reflected by DNS. Again: and the consequences of that are? You still haven't explained what the problem is, here. The only impact of couriertls not consulting the hosts file is that the TCPREMOTEHOST and TCPLOCALHOST environment variables will not be set. Now, what exactly is the problem that's caused by that, in your case? pgp0.pgp Description: PGP signature
Re: [courier-users] Re: couriertls, rfc1035, and /etc/hosts
On Wed, 26 Nov 2003, Sam Varshavchik wrote: Jon Nelson writes: Well, 'localhost', for one, won't ever work properly. And the consequences of that are� It's not just localhost but anything and everything in /etc/hosts that is not otherwise reflected by DNS. Again: and the consequences of that are? You still haven't explained what the problem is, here. The only impact of couriertls not consulting the hosts file is that the TCPREMOTEHOST and TCPLOCALHOST environment variables will not be set. Now, what exactly is the problem that's caused by that, in your case? I thought that was the job of couriertcpd? The problem is that a useful program, couriertls, and by useful I mean useful to a user to construct (de)-SSL/TLSify I/O streams, doesn't behave like one would expect it to. Beyond that, how many people here have expected a certain kind of behavior out of courier by altering the /etc/hosts file only to eventually learn that it is not (ever) consulted? How many people here have struggled only to learn that courier bypasses entirely the operating system's hostname lookup preferences (on Linux, /etc/nsswitch.conf usually says to consult /etc/hosts then DNS, but it can also be configured to consult a bunch of other things). There are many times when it's not just inconvenient but annoying, difficult, or impossible to require a DNS setup. By forcing the issue, you are essentially denying a large userbase an easy way to use courier, and this userbase consists of the overwhelming majority of home and small network users. Why should a person have to become proficient in DNS record keeping and maintainence (with the notoriously insecure BIND, usually) in addition to having to learn the courier system? What's so hard about consulting /etc/hosts? It's expected behavior. -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson [EMAIL PROTECTED] C and Python Code Gardener --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Re: couriertls, rfc1035, and /etc/hosts
Jon Nelson writes: On Wed, 26 Nov 2003, Sam Varshavchik wrote: Jon Nelson writes: Well, 'localhost', for one, won't ever work properly. And the consequences of that are? It's not just localhost but anything and everything in /etc/hosts that is not otherwise reflected by DNS. Again: and the consequences of that are? You still haven't explained what the problem is, here. The only impact of couriertls not consulting the hosts file is that the TCPREMOTEHOST and TCPLOCALHOST environment variables will not be set. Now, what exactly is the problem that's caused by that, in your case? I thought that was the job of couriertcpd? Ok, I misread what you wrote. The problem is that a useful program, couriertls, and by useful I mean useful to a user to construct (de)-SSL/TLSify I/O streams, doesn't behave like one would expect it to. Beyond that, how many people here have expected a certain kind of behavior out of courier by altering the /etc/hosts file only to eventually learn that it is not (ever) consulted? How many people here have struggled only to learn that Yes, I can see how couriertls might be useful in that context. Initially, I added the client options to couriertls purely for my own convenience, when I needed to debug SSL/TLS grok-age from a server. And, I made a mistake of documenting those options. That'll teach me a lesson: next time I do something useful, I'm not going to document it :-) What's so hard about consulting /etc/hosts? It's expected behavior. There's still the IPv6 issue. The traditional resolver API does not support IPv6. There is a newer API that supports IPv6, defined by RFC 2553; but I don't know how widely it is implemented in various systems; or whether it checks the host files (it should, but I had no reason to bother to check). Linux had it since the 2.4 kernel series (and, BTW, I wrote the Linux man pages); however I don't think it's in Debian stable, which is still at 2.2. I don't know which of the BSDs have implemented it either. It's an unknown factor. It wouldn't be too difficult to have couriertls use this, but I don't know how many systems will break. pgp0.pgp Description: PGP signature
[courier-users] Re: couriertls, rfc1035, and /etc/hosts
Jon Nelson writes: queries. The problem here, of course, is that names like 'localhost' and 'localhost.localdomain' do not resolve. What I'm trying to understand, MrSam, is the rationale for doing things this way? A couple of reasons: A) IPv6 (not implemented in the legacy resolver routines) B) The resolver routines must do more than just address lookups, namely MX and PTR records. And, it's not clear to me what's the issue with couriertls not resolving stuff from /etc/hosts. All that means is that the IP address's hostname won't get picked up. Big deal. pgp0.pgp Description: PGP signature
Re: [courier-users] Re: couriertls, rfc1035, and /etc/hosts
On Tue, 25 Nov 2003, Sam Varshavchik wrote: Jon Nelson writes: queries. The problem here, of course, is that names like 'localhost' and 'localhost.localdomain' do not resolve. What I'm trying to understand, MrSam, is the rationale for doing things this way? A couple of reasons: A) IPv6 (not implemented in the legacy resolver routines) B) The resolver routines must do more than just address lookups, namely MX and PTR records. And, it's not clear to me what's the issue with couriertls not resolving stuff from /etc/hosts. All that means is that the IP address's hostname won't get picked up. Big deal. Well, 'localhost', for one, won't ever work properly. Secondly, /etc/hosts is there specifically to provide a static table of host names. So, from your perspective, everybody must either run their own nameserver, or never use localhost, right? Additionally, it's clear that couriertls was originally designed to only be used within courier (rather than by users), because if it wasn't, one would probably pre-suppose that /etc/hosts would be utilized. Since couriertls *is* useful outside of the context of an smtp server, however, users will want to (and do) use it for more general purpose I/O that involves SSL/TLS. Users will therefore expect it to behave just like every other program on unix that does name resolution which, in this context, means consulting /etc/hosts. By the other message posted today, somebody else ran into problems because the actual behavior differed from the expected behavior. I'm not saying that the expected behavior in all cases is the right behavior, but I feel I can make a case for this particular change: the rfc1035 support routines should consult /etc/hosts (first) -- Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is two wolves attempting to have a sheep for dinner and finding a well-informed, well-armed sheep. Jon Nelson [EMAIL PROTECTED] C and Python Code Gardener --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
RE: [courier-users] Re: couriertls, rfc1035, and /etc/hosts
Well, 'localhost', for one, won't ever work properly. Why not? Add your domain to your search list, and have a record for localhost.mydom.ain in the mydom.ain zone. So, from your perspective, everybody must either run their own nameserver, or never use localhost, right? Well, anyone sending a significant amount of mail is foolish not to run a caching name server... Additionally, it's clear that couriertls was originally designed to only be used within courier (rather than by users), because if it wasn't, one would probably pre-suppose that /etc/hosts would be utilized. What other MTA does this by default instead of calling directly? --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] Re: couriertls, rfc1035, and /etc/hosts
Jon Nelson writes: On Tue, 25 Nov 2003, Sam Varshavchik wrote: Jon Nelson writes: queries. The problem here, of course, is that names like 'localhost' and 'localhost.localdomain' do not resolve. What I'm trying to understand, MrSam, is the rationale for doing things this way? A couple of reasons: A) IPv6 (not implemented in the legacy resolver routines) B) The resolver routines must do more than just address lookups, namely MX and PTR records. And, it's not clear to me what's the issue with couriertls not resolving stuff from /etc/hosts. All that means is that the IP address's hostname won't get picked up. Big deal. Well, 'localhost', for one, won't ever work properly. And the consequences of that are? Secondly, /etc/hosts is there specifically to provide a static table of host names. /etc/hosts is ancient legacy left over from the time before DNS. Before DNS came about, everyone used a host file to map IP addresses to hostnames. DNS replaced that procedure several decades ago. pgp0.pgp Description: PGP signature
Re: [courier-users] Re: couriertls, rfc1035, and /etc/hosts
And the consequences of that are? It's not just localhost but anything and everything in /etc/hosts that is not otherwise reflected by DNS. And the consequences of that are? I run Bind to provide DNS for my 3 computer network. It's hardly an overhead, it also provides a caching name server for requests, and squid likewise does not use /etc/hosts. Secondly, /etc/hosts is there specifically to provide a static table of host names. /etc/hosts is ancient legacy left over from the time before DNS. Before DNS came about, everyone used a host file to map IP addresses to hostnames. DNS replaced that procedure several decades ago. Is that so? DNS *replaced* that procedure? Explain, then, the presence of an /etc/hosts file on *every* 'nix machine I have ever used, from *BSD to every flavor of Linux, ever. replaced? Supplemented, yes. Supplanted for non-local hosts, yes. But /etc/hosts has not been replaced. Is there an /etc/hosts file on your machine? Nowhere does it say in the courier docs that courier doesn't rely on the host machine's name resolution capabilities. ]$ cat /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost Well, there's the reason for /etc/hosts - so the loopback interface can work before DNS comes up. I honestly find it ridiculous that courier doesn't consider using /etc/hosts, assuming that all users of courier *must* have access to a nameserver. Courier is a mail server targeted at people who send and receive mail, and as such expects them to have some sort of name server. My external IP has a DNS entry so I can actually use my mail server (and my internal hosts have dynamic entries from DHCP), and if you're managing a network large enough to have internal mail servers and still using /etc/hosts, I really pity you. -- Phillip Hutchings [EMAIL PROTECTED] http://www.sitharus.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [courier-users] Re: couriertls, rfc1035, and /etc/hosts
Courier is a mail server targeted at people who send and receive mail, and as such expects them to have some sort of name server. My external IP has a DNS entry so I can actually use my mail server (and my internal hosts have dynamic entries from DHCP), and if you're managing a network large enough to have internal mail servers and still using /etc/hosts, I really pity you. A nit to pick... On linux glibc and solaris, you don't use '/etc/hosts', you use whatever libnss_* module /etc/nsswitch tells you to use.. This means you can have a large network of machines which are managed by Ldap or NIS that don't ever hit DNS for local lookups. Now, I admit smtp servers are 'special', but you *are* breaking several assumptions most people expect by not using the OS provided nss lookups. And yes, I deal with around 200 odd hosts that still use /etc/hosts lookups.. they are the compute nodes for a couple of 32-64 node clusters. It's not *that* big a deal since the cluster nodes are identical. But I am looking at either libnss_ldap, or running a ldap-bind dns server. The ldap-bind-dns route DOES have several disadvantages, most notably convincing it to update quickly when you make an ldap change. -- -- Troy Benjegerdes'da hozer'[EMAIL PROTECTED] Somone asked my why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
