Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
pmc> While it is true that the said sendmail-option solves the problem pmc> (if sendmail is new enough to understand it), I could nowhere find pmc> information on how to fix the bug in the nameserver - that is, pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7. FreeBSD's nameserver is fine. The problem is the remote nameserver authorative for the domain in question. That nameserver is incorrectly returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for queries. Nothing needs to be fixed in FreeBSD's nameserver. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Gregory Neil Shapiro wrote: > pmc> While it is true that the said sendmail-option solves the problem > pmc> (if sendmail is new enough to understand it), I could nowhere find > pmc> information on how to fix the bug in the nameserver - that is, > pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7. > > FreeBSD's nameserver is fine. The problem is the remote nameserver > authorative for the domain in question. That nameserver is incorrectly > returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for > queries. Nothing needs to be fixed in FreeBSD's nameserver. However, it's possible to address the problem by placing a caching-only nameserver between you and the nameserver with the problem, and hitting the local nameserver, and letting it recurse only if the data isn't in cache. This will address the second and subsequent requests, but the first one will still take however long it takes the proxy request to time out, before the cache is loaded (and converts the SERVFAIL into a NODATA, but only for or A6 requests that receive no response or a SERVFAIL response). It's also possible to rip out IPv6 support entirely, which is what the people who won't fix their nameserver software are tacitly recommending. It's also possible to achieve the same effect by creating a proxy that rejects all IPv6 address requests immediately with NODATA (or NXDOMAIN), which has the benefit of still screwing up IPv6 deployment, but without mutilating all the applications. I would be real tempted to automatically generate complaint email to the technical contact in the whois database for all /A6 requests that fail that way, instead, if the delay bthered me (which it doesn't). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Wed, Jan 01, 2003, Peter Much wrote: > Attached is a log of what is happening actually, there > are two systems "disp" and "gate" involved. "gate" is the > mailhub, and "disp" wants to send a mail to it: > > Hostname: disp (127.0.0.1)gate (127.0.0.1) > OS: FreeBSD 4.4 FreeBSD 4.7 > Interface:disp-e (192.168.98.5) gate-e (192.168.98.2) > dynIP outbound > Nameserver: LAN Primary andLAN Slave > forwarder to "gate" named.root file is here > > The hostnames are associated to the lo0 Interfaces (and > mentioned in /etc/hosts), they have MX pointing to their > respective LAN interfaces. > > "disp" has these nameservice-relevant sendmail.mc options: > FEATURE(relay_based_on_MX) > FEATURE(`nocanonify', `canonify_hosts') > FEATURE(`accept_unresolvable_domains') > define(`SMART_HOST', `gate') > BTW: As soon as the outbound internet connection is available > and we have root nameservers accessible, the problem goes away. > > # mail pmc@dyn What is "dyn"? > Subject: test > test > ^D > # sendmail -d1-10.9 -q > getla: 0 > getauthinfo: root@localhost > ;; res_query(5.98.168.192.in-addr.arpa, 1, 12) > ;; res_mkquery(0, 5.98.168.192.in-addr.arpa, 1, 12) > ;; res_send() > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59759 > ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > ;; 5.98.168.192.in-addr.arpa, type = PTR, class = IN What's in the logfile? What's the output of: date | sendmail -d0.13 -d8.8 -v pmc@dyn PS: news:comp.mail.sendmail might be more appropriate. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
! ! Gregory Neil Shapiro wrote: ! > pmc> While it is true that the said sendmail-option solves the problem ! > pmc> (if sendmail is new enough to understand it), I could nowhere find ! > pmc> information on how to fix the bug in the nameserver - that is, ! > pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7. ! > ! > FreeBSD's nameserver is fine. The problem is the remote nameserver ! > authorative for the domain in question. That nameserver is incorrectly ! > returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for ! > queries. Nothing needs to be fixed in FreeBSD's nameserver. Sorry, Gregory, but You missed me entirely. What I am talking about is a limited test environment consisting _only_ of FreeBSD Systems. So what You name "the remote nameserver" is very well (or not well, in this case) a FreeBSD 4.4 or 4.7 nameserver! What is actually happening (I investigated further with tcpdump) is the following: (When I say "local" i mean the local machine, when i say "remote" i mean another machine in the limited test environment, when i say "outbound" i mean a linkup from the environment to the internet.) 1. a mail for remote delivery is locally created. 2. the local sendmail has the directive smarthost "gate". 3. the local nameserver is master/primary for the test environment domain, which is "oper.dinoex.org" (this does not exist in the real world). This nameserver has an MX for "gate" pointing to "gate-e", which is the LAN network interface name of "gate". It also has an A record for "gate-e". 4. sendmail asks the nameserver for various things during its startup and while parsing the mail (local interfaces, final destination hostname) - all of these work as to be expected. 5. sendmail enters delivery mode and asks for the MX record for "gate", and gets "gate-e.oper.dinoex.org". 6. Then it asks the nameserver for the "" record of "gate-e.oper.dinoex.org" (which does not exist - the nameserver answers by sending the zonefile header (seems ok?). Then sendmail asks again for the "" record of "gate-e" (without domain). Now the local nameserver does not answer, but tries to propagate the query up! If there is an outbound connection active, this query will go out to some internet forwarder (or possibly the root nameservers), and from there likely return as not existing - then the mail will be delivered. But if there is currently no outbound connection available, then this query will return with SERVFAIL, and then sendmail does put the mail into "deferred" state. Background: This environment should be configured to use an internet connection for internet-relevant things, but to work flawlessly without such a connection as long as matters do concern only systems within the LAN. That means, if I write a mail to [EMAIL PROTECTED], then it is obvious that there will be outbound traffic to lookup and verify this hostname (and likely the mail will be deferred if the outbound linkup is inactive). But if I write a mail to another system within the LAN, this has to work without an outbound connection. And usually it does, except for this lookup of the unqualified mail hub interface adress. ! However, it's possible to address the problem by placing a ! caching-only nameserver between you and the nameserver with ! the problem, and hitting the local nameserver, and letting it Difficult, as this nameserver runs on the local host. ! recurse only if the data isn't in cache. This will address ! the second and subsequent requests, but the first one will ! still take however long it takes the proxy request to time ! out, before the cache is loaded (and converts the SERVFAIL ! into a NODATA, but only for or A6 requests that receive ! no response or a SERVFAIL response). ! ! It's also possible to rip out IPv6 support entirely, which is ! what the people who won't fix their nameserver software are ! tacitly recommending. Yes, Ted, I understand well. And I see a lot of workarounds to get rid of the problem - the most simple would be to just upgrade all sendmail binaries so they understand the Broken option. (Or even simpler in this case, to keep the internet connection up all time.) But this is, now that I have tracked and understood the problem, not my primary intention. Now I want to understand what is actually going wrong here and why. I do not think that my approach -to have an environment that is able to access the internet and is also able to run on its own- is essentially wrong. But in this case I am not even sure who is to blame: named or sendmail, or my named configuration (rather cookbook) - and while I am quite good in understanding mail matters, I am not all too experienced concerning nameservers or even IPv6. So I feel the need for a bit of competence gathering. Another matter is: this stuff is obviously creating network traffic and load on the root nameservers. What good for? And anyway,
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much wrote: > 6. Then it asks the nameserver for the "" record of >"gate-e.oper.dinoex.org" (which does not exist - the >nameserver answers by sending the zonefile header (seems >ok?). Then sendmail asks again for the "" record of >"gate-e" (without domain). Now the local nameserver does >not answer, but tries to propagate the query up! >If there is an outbound connection active, this query will >go out to some internet forwarder (or possibly the root >nameservers), and from there likely return as not existing - >then the mail will be delivered. But if there is currently >no outbound connection available, then this query will >return with SERVFAIL, and then sendmail does put the mail >into "deferred" state. > > Background: This environment should be configured to use > an internet connection for internet-relevant things, but to > work flawlessly without such a connection as long as matters > do concern only systems within the LAN. This is called a "split horizon DNS", and you need to run two DNS servers, one interior, and one exterior, both authoritative for your domain, in order for this to work. The problem is that you are forwarding a request that should be local, and you are doing it because your local server does not pass the authority test for your local domain. I have been told that BIND 9 can solve this problem with two different "views"; however, I do not believe it. I wrote a BCP RFC for this, which ended up not getting published, as I did not push it on the promise that the views would solve the problem, and arrive much sooner than they did. I believe it is still available from: ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt > Yes, Ted, I understand well. And I see a lot of workarounds "Terry", not "Ted". 8-). > Another matter is: this stuff is obviously creating network > traffic and load on the root nameservers. What good for? To replace the IPv4 traffic entirely, eventually. > ! I would be real tempted to automatically generate complaint > ! email to the technical contact in the whois database for all > ! /A6 requests that fail that way, instead, if the delay > ! bthered me (which it doesn't). > > Well, in this case that technical contact would be me, and > that's why I'm asking. ;-)) The easist answer to that is to find DNS software that responds correctly, and tell them to change software. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
! > Background: This environment should be configured to use ! > an internet connection for internet-relevant things, but to ! > work flawlessly without such a connection as long as matters ! > do concern only systems within the LAN. ! ! This is called a "split horizon DNS", and you need to run two ! DNS servers, one interior, and one exterior, both authoritative ! for your domain, in order for this to work. The problem is that ! you are forwarding a request that should be local, and you are ! doing it because your local server does not pass the authority ! test for your local domain. Well, I think I got it now. What I did not know was that any nameserver installation is expected to always have some kind of root nameserver accessible (either the real ones from the internet, or elseways a local shortcut) in order to function properly. Failing this seems not to hurt as long as only hostnames and domains are resolved which actually do exist in the zone files. But when sendmail (or the resolver) doesn't find an record for some FQDN, it next tries to resolve the short hostname - and the local nameserver seems not to consider itself authoritative for an unqualified hostname (which would be indistinguishable from a TLD, anyway). ! I have been told that BIND 9 can solve this problem with two ! different "views"; however, I do not believe it. I wrote a ! BCP RFC for this, which ended up not getting published, as I ! did not push it on the promise that the views would solve the ! problem, and arrive much sooner than they did. I believe it ! is still available from: ! ! ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt Yes, this paints my configuration. And now I do not think that a "split horizon" configuration could solve my problem at all. Because if it could tell me that my unqualified hostname does not exist (without querying the outside), then it would also tell me that FreeBSD.org does not exist... So I see only three strategies: 1. Keep the internet connection available at anytime. 2. Use the Broken hack. 3. Configure IPv6 in the LAN. regards, Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much wrote: > ! I have been told that BIND 9 can solve this problem with two > ! different "views"; however, I do not believe it. I wrote a > ! BCP RFC for this, which ended up not getting published, as I > ! did not push it on the promise that the views would solve the > ! problem, and arrive much sooner than they did. I believe it > ! is still available from: > ! > ! ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-split-00.txt > > Yes, this paints my configuration. > And now I do not think that a "split horizon" configuration could > solve my problem at all. Because if it could tell me that my > unqualified hostname does not exist (without querying the outside), > then it would also tell me that FreeBSD.org does not exist... That's not entirely true. The normal way to handle this is to define a domain for your internal machines, and then make the DNS server authoritative for it. The domain most people use for this is "link.local" or ".local", or "example.com". It's actually pretty easy to spend the $10/year and register a real domain for you, and then use that, instead, as the local domain. With your local DNS server being authoritative for that domain (having an SOA record for the domain name), then it can tell when hosts do or don't exist there. So if I look up an unqualified "froboz", it's assumed to be in the local domain because of the DNS suffix every machine is using, and every machine is using it, either because you told it to, or because that's what the DHCP server told it to use, when it handed each machine it's IP address. > So I see only three strategies: > 1. Keep the internet connection available at anytime. > 2. Use the Broken hack. > 3. Configure IPv6 in the LAN. 4. Claim "link.local" as your domain name, stuff it into your DHCP server as the domain name it hands out to machines when it hands out IP addresses, and then stuff an SOA record for it into your local DNS server (and an SOA record for 168.192.in-addr.arpa., or whatever your local non-routed network addresses are, on the interior side of your NAT). This is more a "How Do I Set Up A LAN Inside A NAT?" question, than it is anything else... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Mon, Jan 06, 2003 at 03:37:26PM -0800, Terry Lambert wrote: ! > And now I do not think that a "split horizon" configuration could ! > solve my problem at all. Because if it could tell me that my ! > unqualified hostname does not exist (without querying the outside), ! > then it would also tell me that FreeBSD.org does not exist... ! ! That's not entirely true. ! ! The normal way to handle this is to define a domain for your ! internal machines, and then make the DNS server authoritative ! for it. The domain most people use for this is "link.local" ! or ".local", or "example.com". Done this. It is ".oper.dinoex.org" - I think this should do. ! With your local DNS server being authoritative for that domain ! (having an SOA record for the domain name), then it can tell ! when hosts do or don't exist there. Done this. So, if I lookup "schnarz.oper.dinoex.org", then I get "Non-existent host/domain". ! So if I look up an unqualified "froboz", it's assumed to be in ! the local domain because of the DNS suffix every machine is using, ! and every machine is using it, either because you told it to, or ! because that's what the DHCP server told it to use, when it handed ! each machine it's IP address. Exactly. And when this is not found, then the resolver will inplicitly issue another query for the unqualified name. And it is even worse with sendmail, because sendmail does quite interesting things there - like switching off RES_DEFNAMES - so this one will definitely not add the local domain. regards, Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much wrote: > ! So if I look up an unqualified "froboz", it's assumed to be in > ! the local domain because of the DNS suffix every machine is using, > ! and every machine is using it, either because you told it to, or > ! because that's what the DHCP server told it to use, when it handed > ! each machine it's IP address. > > Exactly. And when this is not found, then the resolver will > inplicitly issue another query for the unqualified name. > > And it is even worse with sendmail, because sendmail does quite > interesting things there - like switching off RES_DEFNAMES - > so this one will definitely not add the local domain. This is broken in 2 ways: 1) The default names option in the standard resolver will prevent another query for the unqualified name, since unqualified names are supposed to get the local domain name, unconditionally. 2) It's possible to change the resolver flags in sendmail by adding lines to the M4 file source code. You need to look at the source tree and read cf/README. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-06 17:36:52 +0100: > ! > Background: This environment should be configured to use > ! > an internet connection for internet-relevant things, but to > ! > work flawlessly without such a connection as long as matters > ! > do concern only systems within the LAN. > ! > ! This is called a "split horizon DNS", and you need to run two > ! DNS servers, one interior, and one exterior, both authoritative > ! for your domain, in order for this to work. The problem is that > ! you are forwarding a request that should be local, and you are > ! doing it because your local server does not pass the authority > ! test for your local domain. > > Well, I think I got it now. What I did not know was that any > nameserver installation is expected to always have some kind > of root nameserver accessible (either the real ones from the > internet, or elseways a local shortcut) in order to function > properly. This is wrong in at least two ways. An authoritative content server doesn't need to know root servers, because they're out of it's business. A non-recursive (forwarding-only) resolver doesn't need to know root servers, just the upstream resolver it forwards all requests to. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
! > Exactly. And when this is not found, then the resolver will ! > inplicitly issue another query for the unqualified name. ! > ! > And it is even worse with sendmail, because sendmail does quite ! > interesting things there - like switching off RES_DEFNAMES - ! > so this one will definitely not add the local domain. ! ! This is broken in 2 ways: Hmm... possibly. ! 1)The default names option in the standard resolver will prevent ! another query for the unqualified name, since unqualified names ! are supposed to get the local domain name, unconditionally. I'm sorry, my named.log shows it the other way round - as does the debug mode of nslookup: $ nslookup Default Server: localhost.oper.dinoex.org Address: 127.0.0.1 > set debug > wurz [defnames is set by default] Server: localhost.oper.dinoex.org Address: 127.0.0.1 ;; res_nmkquery(QUERY, wurz.oper.dinoex.org, IN, A) Got answer: HEADER: opcode = QUERY, id = 56443, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: wurz.oper.dinoex.org, type = A, class = IN AUTHORITY RECORDS: -> oper.dinoex.org ttl = 3600 (1H) origin = disp-e.oper.dinoex.org[this is localhost] mail addr = admin.disp.oper.dinoex.org [this is me] serial = 20011217 refresh = 3600 (1H) retry = 900 (15M) expire = 360 (5w6d16h) minimum ttl = 3600 (1H) ;; res_nmkquery(QUERY, wurz, IN, A) timeout [here it starts dialing out!] Got answer: HEADER: opcode = QUERY, id = 56444, rcode = NXDOMAIN header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: wurz, type = A, class = IN AUTHORITY RECORDS: -> (root) ttl = 10800 (3H) origin = A.ROOT-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.COM serial = 2003010801 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D) *** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain > set nodefnames > wurz Server: localhost.oper.dinoex.org Address: 127.0.0.1 ;; res_nmkquery(QUERY, wurz, IN, A) Got answer: HEADER: opcode = QUERY, id = 56445, rcode = NXDOMAIN header flags: response, want recursion, recursion avail. questions = 1, answers = 0, authority records = 1, additional = 0 QUESTIONS: wurz, type = A, class = IN AUTHORITY RECORDS: -> (root) ttl = 10701 (2h58m21s) origin = A.ROOT-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.COM serial = 2003010801 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D) *** localhost.oper.dinoex.org can't find wurz: Non-existent host/domain -- ! 2)It's possible to change the resolver flags in sendmail by ! adding lines to the M4 file source code. You need to look ! at the source tree and read cf/README. Been there, done it, got the t-shirt. I walked thru the whole code there, only to find lots of niceies like the following - from daemon.c: - if (host[0] == '[') { [some stuff deleted] } else { /* contortion to get around SGI cc complaints */ { p = &host[strlen(host) - 1]; hp = sm_gethostbyname(host, family); if (hp == NULL && *p == '.') { # if NAMED_BIND int oldopts = _res.options; _res.options &= ~(RES_DEFNAMES|RES_DNSRCH); # endif /* NAMED_BIND */ *p = '\0'; hp = sm_gethostbyname(host, family); *p = '.'; # if NAMED_BIND _res.options = oldopts; # endif /* NAMED_BIND */ } } - Now this looks correct, because the second call to sm_gethostbyname hits only on FQDNs with terminating dot - but then sm_gethostbyname() in conf.c will not care about the resolver-flags at all and will shorten all unresolveable hostnames that do not have a terminating dot to their first component and retry with that. So even if we have a full qualified hostname with terminating dot, it will end up with a resolver query for the first name component - and that gets treated just like in the debug log above. Now, as far as I am considered, I think I have had enough of this stuff. I have underst
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Roman Neuhauser wrote: > > ! This is called a "split horizon DNS", and you need to run two > > ! DNS servers, one interior, and one exterior, both authoritative > > ! for your domain, in order for this to work. The problem is that > > ! you are forwarding a request that should be local, and you are > > ! doing it because your local server does not pass the authority > > ! test for your local domain. > > > > Well, I think I got it now. What I did not know was that any > > nameserver installation is expected to always have some kind > > of root nameserver accessible (either the real ones from the > > internet, or elseways a local shortcut) in order to function > > properly. > > This is wrong in at least two ways. > > An authoritative content server doesn't need to know root servers, > because they're out of it's business. The authoritative server must also be a forwarding server. This is because of both the way the resolver library itself works (single preference), and the fact that on a border router, you have only a single IP address on which to bind a DNS service, and therefore can offer only a single DNS service to interior machines. While technically, some UNIX clients permit multiple definitaions in this case, practically, you can't take advantage of this, because you must deal with interior Windows clients machines, where this is not permitted. > A non-recursive (forwarding-only) resolver doesn't need to know > root servers, just the upstream resolver it forwards all requests > to. Realize that this is not possible, with the current resolver library, since all programs will reference the single /etc/resolv.conf. If you reference a completely authoritative interior server, with no forwarding, and the resolver stops there, then the exterior server is not referenced. This is complicated, both as noted above, for Windows clients (it would require a second IP address on the interior network, minimally, to resolve), and by the fact that the IP address of the external interface is unknown until after link-up, which will generally occur well after the DHCP lease is granted to interior machines. This is even urther complicated by the fact that the DHCP server is likely to be a Windows Primary Domain Controller, and therefore not the border device, itself. Note that even though your resolver is internally authoritative, for the Internet's view of the world, an external resolver for the domain is likly authoritative, instead. Specifically, you will be running hosted primary for www.example.com and for the MX records for example.com. The only way for this to actually work is to split the authority for the example.com domain between two nameservers -- one interior, and one exterior. Partial delegation is simply not supported by the current DNS model. The problem comes down to round-tripping local changes to the DNS, e.g. DHCP leases, etc.. If you can solve the round-tripping problem, you can, in fact, deal with this via the DNSNOT mechanism. Unfortuanately, a transiently connected DNS server will not receive notifications from a primary DNS server, particularly when it is offline, but also for any state changes occurring while it is offline, unless it attempts a zone transfer (e.g. on link up). Zone transfers are not desirable in this case, since the authority is split; the closes you can get is a "blind secondary". To implement a blind secondary requires modification of the DNS server secondary declaration mechanism, to result in a serach from root by the secondary server, in order to locate the primary for the domain being served. For this to work, the syntax of the declaration of a secondary must be changes, and a zone transfer attempted on linkup. The syntax of a blind secondary is defined at: Blind Secondary DNS Extension ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt It is a trivial change, but can increase the root load. The way to avoid this is to mandate caching, and only transit to the root if the name server is not where it was previously (e.g. as a result of an ISP reconfiguration while the secondary was offline). An expiration time for the cache is not relvent, in that this has to do with claim of authority; if the SOA is stale, then it serves as the timeout. In addition to this, to resolve authority issues, we have to recognize the seperation of control between transiently and non-transiently connected servers. I did not mention this before, since the problem under discussion was how to *avoid* lookups, requiring a link-up operation, for fully qualified DNS names which were not defined locally; making this modification requires careful reconfiguration. Specifically, the external primary is considered to be in a delegated subdomain of the locally authoritative domain; for lookups direct to the name server, the subdomain is implied in the operation. This, too, requires a modification of the DNS server implementation. The si
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Peter Much wrote: > ! 1)The default names option in the standard resolver will prevent > ! another query for the unqualified name, since unqualified names > ! are supposed to get the local domain name, unconditionally. > > I'm sorry, my named.log shows it the other way round - as does > the debug mode of nslookup: What are the precise contents of your /etc/resolv.conf? > ! 2)It's possible to change the resolver flags in sendmail by > ! adding lines to the M4 file source code. You need to look > ! at the source tree and read cf/README. > > Been there, done it, got the t-shirt. I walked thru the whole > code there, only to find lots of niceies like the following > - from daemon.c: [ ... ] > Now, as far as I am considered, I think I have had enough of this > stuff. I have understood from the code why it behaves the way it > does, have learned a bit about name resolution, and now either > have to live with it the way it is, or change the code in a way > I like. Naturally, I personally believe all problems are solvable, and Greg can answer on the resolution of names in sendmail for this second case, but I understand your losing interest. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-09 12:48:03 -0800: > To: Roman Neuhauser <[EMAIL PROTECTED]> please don't cc me. > Roman Neuhauser wrote: > > > ! This is called a "split horizon DNS", and you need to run two > > > ! DNS servers, one interior, and one exterior, both authoritative > > > ! for your domain, in order for this to work. The problem is that > > > ! you are forwarding a request that should be local, and you are > > > ! doing it because your local server does not pass the authority > > > ! test for your local domain. > > > > > > Well, I think I got it now. What I did not know was that any > > > nameserver installation is expected to always have some kind > > > of root nameserver accessible (either the real ones from the > > > internet, or elseways a local shortcut) in order to function > > > properly. > > > > This is wrong in at least two ways. > > > > An authoritative content server doesn't need to know root servers, > > because they're out of it's business. > > The authoritative server must also be a forwarding server. > This is because of both the way the resolver library itself works You talked about nameservers and split horizon, I talked about nameservers and split horizon. Now you talk about Bind. Don't change the playground, please. I don't know how the Bind library works, but I know that the authoritative server I use has now idea of roots. > (single preference), and the fact that on a border router, you > have only a single IP address on which to bind a DNS service, > and therefore can offer only a single DNS service to interior > machines. Hmm? Are you talking about having both a cache and a content server on a router? The interior Windows clients of course only query the cache, so you can have the content server on 127.0.0.1. And, BTW, I don't see why I couldn't have more than one address on the inside interface, cache on one, content/authoritative server on another. > While technically, some UNIX clients permit multiple > definitaions in this case, practically, you can't take advantage > of this, because you must deal with interior Windows clients > machines, where this is not permitted. I don't know what you're talking about. Could you rephrase it? > > A non-recursive (forwarding-only) resolver doesn't need to know > > root servers, just the upstream resolver it forwards all requests > > to. > > Realize that this is not possible, with the current resolver > library, since all programs will reference the single /etc/resolv.conf. Now it seems *you* don't know what your talking about. 1.2.3.5 <-- ISP's "name server" (in fact, recursive cache) ^ | v 1.2.3.4 10.0.0.{1,2} <-- my router, with a forwarding cache on 10.0.0.1 ^ and a content server (for, say, domain.local) | on 10.0.0.2 v 10.0.0.{3..10} <-- fbsd/windows boxes all my boxes, including the router, have 10.0.0.1 in /etc/resolv.conf, and the cache on the router is configured to forward all recursive queries to 1.2.3.5 what's the problem? > If you reference a completely authoritative interior server, with > no forwarding, and the resolver stops there, then the exterior > server is not referenced. A properly configured authoritative server will: 1. drop recursive queries 2. drop queries for data it's not authoritative for anything else is asking for trouble > This is complicated, I don't think so. > both as noted above, for Windows clients (it would require a second IP > address on the interior network, minimally, to resolve), which is: 1. not true in the sense that you can have the authoritative server on 127.0.0.1 which is always there 2. trivial to add > and by the fact that the IP address of the external interface is > unknown until after link-up, hm? what does the external IP have to do with this? > which will generally occur well after the DHCP lease is granted to > interior machines. This is even urther complicated by the fact > that the DHCP server is likely to be a Windows Primary Domain > Controller, and therefore not the border device, itself. i don't see how that's related. > Note that even though your resolver is internally authoritative, this is an oxymoron. a resolver (cache) cannot not be authoritative. > The only way for this to actually work is to split the authority > for the example.com domain between two nameservers -- one interior, > and one exterior. Partial delegation is simply not supported by > the current DNS model. I don't know what partial delegation is, but I *do* know that I have a split horizon here with one nameserver. > Unfortuanately, a transiently connected DNS server will not receive > notifications from a primary DNS server, particularly when it is > offline, but also for any state changes occurring while it is >
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Roman Neuhauser wrote: > You talked about nameservers and split horizon, > I talked about nameservers and split horizon. > Now you talk about Bind. Don't change the playground, please. You weren't really talking about split horizon, I think; a "horizon" in this case is any place you can't see over without a referral happening. > I don't know how the Bind library works, but I know that the > authoritative server I use has now idea of roots. So, do you manually put "yahoo.com" SOA records in your DNS? How do you answer requests for "yahoo.com". > > (single preference), and the fact that on a border router, you > > have only a single IP address on which to bind a DNS service, > > and therefore can offer only a single DNS service to interior > > machines. > > Hmm? Are you talking about having both a cache and a content server > on a router? The interior Windows clients of course only query the > cache, so you can have the content server on 127.0.0.1. And, BTW, I > don't see why I couldn't have more than one address on the inside > interface, cache on one, content/authoritative server on another. Because your Windows clients could contact only one of them. > > While technically, some UNIX clients permit multiple > > definitaions in this case, practically, you can't take advantage > > of this, because you must deal with interior Windows clients > > machines, where this is not permitted. > > I don't know what you're talking about. Could you rephrase it? See above. > > > A non-recursive (forwarding-only) resolver doesn't need to know > > > root servers, just the upstream resolver it forwards all requests > > > to. > > > > Realize that this is not possible, with the current resolver > > library, since all programs will reference the single /etc/resolv.conf. > > Now it seems *you* don't know what your talking about. > > 1.2.3.5 <-- ISP's "name server" (in fact, recursive cache) > ^ > | > v > 1.2.3.4 > 10.0.0.{1,2} <-- my router, with a forwarding cache on 10.0.0.1 > ^ and a content server (for, say, domain.local) > | on 10.0.0.2 > v > 10.0.0.{3..10} <-- fbsd/windows boxes > > all my boxes, including the router, have 10.0.0.1 in > /etc/resolv.conf, and the cache on the router is configured to > forward all recursive queries to 1.2.3.5 > > what's the problem? Where was *your* second nameserver again? I see a nameserver on 10.0.0.{1,2}; where is your nameserver on 1.2.3.4? The problem is that you don't have a resolv.conf for your Windows box, you only ohave the ability to specify a single DNS server in your DHCP configuration, and if your DHCP server is a Windows box (which it must be, if you expect to use certain Windows networking features), then the DNS server it refers to will be the DHCP server; that means you can't refer to both. The second problem is that 1.2.3.4 is a dialup address assigned by the ISP; this makes it impossible to run the DNS server there, unless the link is up, since it's the other end of a PPP conection. > > If you reference a completely authoritative interior server, with > > no forwarding, and the resolver stops there, then the exterior > > server is not referenced. > > A properly configured authoritative server will: > > 1. drop recursive queries > 2. drop queries for data it's not authoritative for > > anything else is asking for trouble And then, how does an internal client get the external IP "yahoo.com", if the requests are being dropped?!? The idea here is to not bring up the link for local traffic, including DNS traffic, but to bring the link up for non-local traffic. The point of the local DNS server being caching is *only* to avoid the 30 second timeout from the first lookup, which happens when it's the DNS traffic that causes the link to come up. > > This is complicated, > > I don't think so. That's because you haven't studied the problem for 4 years, like me, Archie Cobbs, and Julian Eisher, and then deployed a FreeBSD based commercial product to thousands of customers, like we did. > > both as noted above, for Windows clients (it would require a second IP > > address on the interior network, minimally, to resolve), > > which is: > > 1. not true in the sense that you can have the authoritative server >on 127.0.0.1 which is always there Then it's a proxy for the interior and exterior DNS servers running on your border device. It's also specially written, rather than using off-the-shelf software, since it can't be a standard bind. > 2. trivial to add I guess, if you have the source code to Windows TCP on hand. Last time I checked, this was millions of $ to license. > > and by the fact that the IP address of the external interface is > > unknown until after link-up, > > hm? what does the external IP have to do with this?
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > To: Roman Neuhauser <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] you sent me a copy again, please, don't do it. 1. I don't want one, I'll read your message on the list. 2. it's futile: your provider's MTA breaks RFC 2821: 2.3.5: ... The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction. compare: Date: Fri, 10 Jan 2003 20:34:09 +0100 (CET) From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] (Postmaster) Subject: Postfix SMTP server: errors from +stork.mail.pas.earthlink.net[207.217.120.188] Transcript of session follows. Out: 220 mail.bellavista.cz ESMTP Postfix In: EHLO stork Out: 504 : Helo command rejected: need fully-qualified hostname In: HELO stork Out: 504 : Helo command rejected: need fully-qualified hostname In: QUIT Out: 221 Bye your messages to freebsd.org go through one more hop that's configured properly, so they get through. now... > Roman Neuhauser wrote: > > You talked about nameservers and split horizon, > > I talked about nameservers and split horizon. > > Now you talk about Bind. Don't change the playground, please. > > You weren't really talking about split horizon, I think; a > "horizon" in this case is any place you can't see over without > a referral happening. > > > > I don't know how the Bind library works, but I know that the > > authoritative server I use has now idea of roots. > > So, do you manually put "yahoo.com" SOA records in your DNS? no. > How do you answer requests for "yahoo.com". it's simple: say you want to go to www.freebsd.org. your resolver sends a DNS query to 10.0.0.1:53 where 10.0.0.1 is configured in your /etc/resolv.conf. this query has the RD bit set. the DNS cache at 10.0.0.1:53 (let's say it's just been flushed) does need to know the roots, but were talking about authoritative servers. read on. your resolver sent out a recursive lookup (RD [Recursion Desired] bit set). let's say the DNS cache at 10.0.0.1 doesn't forward, it recurses itself instead. this is an example of such a lookup (198.41.0.4 is a.root-servers.net): roman@freepuppy ~ 1015:0 > dnsq a www.freebsd.org 198.41.0.4 1 www.freebsd.org: 339 bytes, 1+0+9+9 records, response, noerror query: 1 www.freebsd.org authority: org 172800 NS a7.nstld.com authority: org 172800 NS l7.nstld.com authority: org 172800 NS g7.nstld.com authority: org 172800 NS f7.nstld.com authority: org 172800 NS m5.nstld.com authority: org 172800 NS j5.nstld.com authority: org 172800 NS i5.nstld.com authority: org 172800 NS c5.nstld.com authority: org 172800 NS e5.nstld.com additional: a7.nstld.com 172800 A 192.5.6.36 additional: l7.nstld.com 172800 A 192.41.162.36 additional: g7.nstld.com 172800 A 192.42.93.36 additional: f7.nstld.com 172800 A 192.35.51.36 additional: m5.nstld.com 172800 A 192.55.83.34 additional: j5.nstld.com 172800 A 192.48.79.34 additional: i5.nstld.com 172800 A 192.43.172.34 additional: c5.nstld.com 172800 A 192.26.92.34 additional: e5.nstld.com 172800 A 192.12.94.34 this says: "I don't know the IP of www.freebsd.org (IOW, I'm not authoritative for it), but these are the authoritative servers for .org., go ask there." so the cache picks one those, and continues: roman@freepuppy ~ 1016:0 > dnsq a www.freebsd.org 192.5.6.36 1 www.freebsd.org: 145 bytes, 1+0+4+1 records, response, noerror query: 1 www.freebsd.org authority: freebsd.org 172800 NS ns0.freebsd.org authority: freebsd.org 172800 NS ns1.downloadtech.com authority: freebsd.org 172800 NS ns1.iafrica.com authority: freebsd.org 172800 NS ns2.downloadtech.com additional: ns0.freebsd.org 172800 A 216.136.204.126 this says: "I'm not authoritative for www.freebsd.org, but I know these servers are authoritative for freebsd.org. go ask there.
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
Roman Neuhauser wrote: > > So, do you manually put "yahoo.com" SOA records in your DNS? > > no. > > > How do you answer requests for "yahoo.com". > > it's simple: [ ... "I have a DNS caching server that forwards all requests, except those to "bellavista.cz"; for those, it does content redirection on the request to another server whose sole purpose in life is to answer those requests, while refusing all other requests" ... ] [ ... ] > my real setup is this: 10.0.0.1 is the router, and I have a DNS > cache on 10.0.0.25, and a content server authoritative for > bellavista.cz on 10.0.0.26. or at least it thinks it's > authoritative, and the cache is configured to short-circuit all > queries about bellavista.cz to 10.0.0.26. > > now, this setup might actually look a bit different. suppose the > outside IP of my router (62.168.44.50) is listed as an authoritative > server for bellavista.cz, and suppose I forward all traffic for > 62.168.44.50:53 to 10.0.0.26:53. the content nameserver can then > provide different answers based on the client's IP address. > nonrecursive queries (RD bit cleared; "gimme an authoritative > answer") about lilith.bellavista.cz comming from 10.0.0/24 will be > answered with 10.0.0.1, while those coming from anywhere else will > get 62.168.44.50. and so on. In "bind", this is called a "view". I noted previously that this can be accomplished with bind version 9. The thing that makes this different is that you are consuming multiple internal IP addresses for your seperate DNS servers. While this is possible, it's generally not recommended, because of Windows stupidity. As far as splitting the responses by source IP address: that only works by default if all machines in the domain are interior to the local network, and all machines which are externally visible are dual-homed. Many DSL lines these days are done via a /2, which means they are limited to 2 routable addresses. As far as whether or not the external interface is a real primary, a stealth primary, or a stealth secondary, really depends on the configuration of the connection. If we look at providing a packaged solution for use by people who aren't computer programmers or UNIX system administrators, which is the case of the original poster, then you have to come up with a setup that has a minimal number of toggled states (via UI toggles) to cover all potential allowed configurations; in this case, we are talking three use cases: 1) Real primary for domain is hosted by ISP, because hosted services are not permitted to drop offline, simply because the device is transiently connected. 2) Real primary domain is on the external port, and the border device is connected full time. 3) Real primary domain is hosted by ISP, because hosted services are not permitted to drop offline, simply because the permanent link fails. There's actually a 4th use case, where initial pages are cached and forwarded, but it requires additional ISP infrastructure to implement (e.g. "Encanto Networks"). Basically, you need to be able to GUI-config the device to one of these roles, and to permit it to change roles, as needed, to deal with customer "upgrades" and changes in ISP connectivity (this effectively commoditizes ISP's to nothing more than "IP dialtone", which is pretty much what they want, since they could care less if you sell boxes, and all they want is minimized customer contacts, because those eat into their profit margin). > again, the content server only knows about names within/under > bellavista.cz, it doesn't need to know the root servers. the cache > is recursive, so it does. Clearly, you have either written your own cache, or you are using DJB's cache, with patches. > > > Hmm? Are you talking about having both a cache and a content server > > > on a router? The interior Windows clients of course only query the > > > cache, so you can have the content server on 127.0.0.1. And, BTW, I > > > don't see why I couldn't have more than one address on the inside > > > interface, cache on one, content/authoritative server on another. > > > > Because your Windows clients could contact only one of them. > > sure. Windows clients ask the cache, which in turn asks the content > server. This works, if you cache maintains a fixed IP address, and if you can configure Microsoft's DHCP server to give out the IP address of your cache for it's DNS. This has several drawbacks in a predominantly Microsoft client network. The main one of these is that the client credential is no longer automatically established with the domain controller (the user gets beat up for a second login into the network), and the client machines do not have their forward and reverse IP addresses configured into the DNS automatically (a feature of the Microsoft DHCP/DNS server combin
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Thu, Jan 09, 2003 at 12:07:19PM -0800, Terry Lambert wrote: ! What are the precise contents of your /etc/resolv.conf? search oper.dinoex.org nameserver 127.0.0.1 nameserver 192.168.98.2 rgds, PMc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
thanks for not cc'ing me. # [EMAIL PROTECTED] / 2003-01-10 15:18:43 -0800: > Roman Neuhauser wrote: > > > So, do you manually put "yahoo.com" SOA records in your DNS? > > > > no. > > > > > How do you answer requests for "yahoo.com". > > > > it's simple: > > [ ... "I have a DNS caching server that forwards all requests, >except those to "bellavista.cz"; for those, it does >content redirection on the request to another server >whose sole purpose in life is to answer those requests, >while refusing all other requests" ... ] actually, the DNS cache is recursive: it doesn't forward, it resolves the names itself. > [ ... ] > > my real setup is this: 10.0.0.1 is the router, and I have a DNS > > cache on 10.0.0.25, and a content server authoritative for > > bellavista.cz on 10.0.0.26. or at least it thinks it's > > authoritative, and the cache is configured to short-circuit all > > queries about bellavista.cz to 10.0.0.26. > > > > now, this setup might actually look a bit different. suppose the > > outside IP of my router (62.168.44.50) is listed as an authoritative > > server for bellavista.cz, and suppose I forward all traffic for > > 62.168.44.50:53 to 10.0.0.26:53. the content nameserver can then > > provide different answers based on the client's IP address. > > nonrecursive queries (RD bit cleared; "gimme an authoritative > > answer") about lilith.bellavista.cz comming from 10.0.0/24 will be > > answered with 10.0.0.1, while those coming from anywhere else will > > get 62.168.44.50. and so on. > > In "bind", this is called a "view". I noted previously that this > can be accomplished with bind version 9. so I heard. > The thing that makes this different is that you are consuming > multiple internal IP addresses for your seperate DNS servers. > While this is possible, it's generally not recommended, because > of Windows stupidity. I still don't understand this claim. The Windows boxen will never ask the authoritative server, so I don't see any problem. There's obviously none [that would affect my users], as this is exactly what I do, and no machines have any trouble with resolving. That means several FreeBSD boxes, several NT 5, NT 5.1, and a W98 box. No problems whatsoever. All these systems delegate name resolution to 10.0.0.25, which is a *cache*, through /etc/resolv.conf or its windowsland counterpart. The cache at 10.0.0.25 resolves names by recursing the name server hierarchy rooted at {a..m}.root-servers.net with the exception of bellavista.cz, which is short-circuited to 10.0.0.26. > As far as splitting the responses by source IP address: that only > works by default if all machines in the domain are interior to > the local network, and all machines which are externally visible > are dual-homed. Many DSL lines these days are done via a /2, > which means they are limited to 2 routable addresses. No, it only works by default if all the DNS *caches* are interior to the local network, because the content DNS server is queried by the cache, not the Windows client. > As far as whether or not the external interface is a real primary, > a stealth primary, or a stealth secondary, really depends on the > configuration of the connection. ... > Basically, you need to be able to GUI-config the device you keep trying to divert the point of discussion. the OP has had Bind ans Sendmail configured without a GUI configurator; nowhere did he mention a need for one. > > again, the content server only knows about names within/under > > bellavista.cz, it doesn't need to know the root servers. the cache > > is recursive, so it does. > > Clearly, you have either written your own cache, or you are using > DJB's cache, with patches. I use djbdns without any patches. I might not have expressed myself clearly: "the content server only knows about names within/under bellavista.cz, it doesn't need to know the root servers. the cache is recursive, so it does need to know them." > > > > Hmm? Are you talking about having both a cache and a content server > > > > on a router? The interior Windows clients of course only query the > > > > cache, so you can have the content server on 127.0.0.1. And, BTW, I > > > > don't see why I couldn't have more than one address on the inside > > > > interface, cache on one, content/authoritative server on another. > > > > > > Because your Windows clients could contact only one of them. > > > > sure. Windows clients ask the cache, which in turn asks the content > > server. > > This works, if you cache maintains a fixed IP address, and if > you can configure Microsoft's DHCP server to give out the IP > address of your cache for it's DNS. the OP has FreeBSD on both the router/NAT and the inside box. nowhere did he menti
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > you sent me a copy again, please, don't do it. > 1. I don't want one, I'll read your message on the list. Then make this clear -- YOU don't provide a Reply-to: or Followup-to:. So Terry (and myself) aren't to blame. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
David O'Brien wrote: > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > > you sent me a copy again, please, don't do it. > > 1. I don't want one, I'll read your message on the list. > > Then make this clear -- YOU don't provide a Reply-to: or Followup-to:. > So Terry (and myself) aren't to blame. I guess he doesn't like it showing up in his mail logs, since if it's via my ISP's mail server, the one to him directly bounces anyway. Gotta wonder why anyone would care, if they never see the thing anyway... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800: > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > > you sent me a copy again, please, don't do it. > > 1. I don't want one, I'll read your message on the list. > > Then make this clear -- YOU don't provide a Reply-to: or Followup-to:. > So Terry (and myself) aren't to blame. I *do* make it clear: 1. I *do* send out the MFT header, but the freebsd.org MTA's strip it. 2. I make my preference clear in the signature. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-12 21:57:25 -0800: > David O'Brien wrote: > > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > > > Cc: [EMAIL PROTECTED] > > > > > > you sent me a copy again, please, don't do it. > > > 1. I don't want one, I'll read your message on the list. > > > > Then make this clear -- YOU don't provide a Reply-to: or Followup-to:. > > So Terry (and myself) aren't to blame. > > I guess he doesn't like it showing up in his mail logs, since if > it's via my ISP's mail server, the one to him directly bounces > anyway. Gotta wonder why anyone would care, if they never see the > thing anyway... 8-). No, that's not the reason. I just don't like getting cc's. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
In the last episode (Jan 13), Roman Neuhauser said: > # [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800: > > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > > > Cc: [EMAIL PROTECTED] > > > > > > you sent me a copy again, please, don't do it. 1. I don't > > > want one, I'll read your message on the list. > > > > Then make this clear -- YOU don't provide a Reply-to: or > > Followup-to:. So Terry (and myself) aren't to blame. > > I *do* make it clear: > > 1. I *do* send out the MFT header, but the freebsd.org MTA's strip it. Whoa. Who broke that? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
# [EMAIL PROTECTED] / 2003-01-13 11:49:15 -0600: > In the last episode (Jan 13), Roman Neuhauser said: > > # [EMAIL PROTECTED] / 2003-01-12 21:33:32 -0800: > > > On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: > > > > # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: > > > > > To: Roman Neuhauser <[EMAIL PROTECTED]> > > > > > Cc: [EMAIL PROTECTED] > > > > > > > > you sent me a copy again, please, don't do it. 1. I don't > > > > want one, I'll read your message on the list. > > > > > > Then make this clear -- YOU don't provide a Reply-to: or > > > Followup-to:. So Terry (and myself) aren't to blame. > > > > I *do* make it clear: > > > > 1. I *do* send out the MFT header, but the freebsd.org MTA's strip it. > > Whoa. Who broke that? No idea. I'm slowly trying to resolve this with [EMAIL PROTECTED] -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant ?
Roman Neuhauser wrote: > No, that's not the reason. I just don't like getting cc's. That's easily fixed: I recommend /usr/ports/mail/procmail. You can't expect people on a mailing list to tailor their MUA configuration to suit your choices. It's up to you to set up your own MUA and filters to cater to your own pickiness. - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant ?
> Roman Neuhauser wrote: > > No, that's not the reason. I just don't like getting cc's. > > That's easily fixed: I recommend /usr/ports/mail/procmail. > > You can't expect people on a mailing list to tailor their MUA > configuration to suit your choices. It's up to you to set up your own > MUA and filters to cater to your own pickiness. Amen! Can we get back on topic now, please? :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message