Date: 04 Jan 2003 11:59:06 -0800 From: swear@attbi.com (Gary W. Swearingen) To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-current@freebsd.org Subject: Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay) Message-ID: <14vg14vg8l.g14@localhost.localdomain> In-Reply-To: <3E16BA5E.1FD866D1@mindspring.com> References: <rgptrg1uzx.trg@localhost.localdomain> <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <c9622346-1e23-11d7-83f4-0002b32ee8e9@iv.nn.kiev.ua> <ihadihx3fq.dih_-_@localhost.localdomain> <3E163C0A.C0CF8146@mindspring.com> <8p4r8pwgl6.r8p@localhost.localdomain> <3E16BA5E.1FD866D1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Dang; I meant to move this thread to -questions only, not -current.] Terry Lambert <tlambert2@mindspring.com> writes: > [ There is a genuine FreeBSD bug or two at the root of your problem ] > > "Gary W. Swearingen" wrote: > > > BTW, I was suprised to find several help files only > > under /usr/src and the Sendmail Installation and Operation only under > > that and not yet built from the source "op.me". (PR worthy?) > > Like I said: the documentation is port. The book is for a > relatively old version, and has not been updated for a very > long time. [...] And mine's 2nd edition from '97, but covers m4/.mc and still quite helpful, methinks. Someone's found were the ASCII version of "op" is hiding with an obfuscated name. But there's a SECURITY, TRACEFLAGS, TUNING, and a different README hiding under /usr/src (./contrib/sendmail/src/). (I think that there's quite a lot of documentation in src/../README-type files which should be brought out and indexed -- one of my many pipe dreams.) > > Why isn't "::1.in-addr.arpa." built into the resolver (or something) > > like "1.0.0.127.in-addr.arpa." seems to be? (Rhetorical question.) > > This is actually a problem with your local DNS server not > having the correct defaults. It seems the real problem is that the FreeBSD installer sets up sendmail, while not setting up a DNS server (named_enable="NO"), which wouldn't be a problem if the resolver handled "::1.." like it does "1.0.0.127..." (with no DNS server). > So the DNS lookups are > tried, and the gethostbyaddr() times out in 90 seconds, in your > case, because your DNS isn't set up correctly for IPv6. My DNS isn't set up correctly for IPv4, either, but THAT manages to work. (BTW, the time-out itself seemed to be 80 sec.) > Might as well get it in the archive, for the next person who > needs to know... 8-). I hope many people find it -- well done! Good descriptions of your terms. I'm keeping a copy of it with my sendmail notes. > You're kludge breaks as soon as the submitting machine is not the > server machine (i.e. you start making MSP connections over your > local network). My ISP charges more for an Internet-connected LAN and I have no need for one, so I don't bother. This brings to mind a common problem many of us always have with free Unixy OSes; the developer/documenters tend to ignore the many users who have no full-time Internet connection, local DNS server, permanent domain names or IP address, or LAN. Of course, we're pretty happy feeding off the crumbs of the big systems table. :) > > My local DNS is the resolver and /etc/hosts with > > ::1 localhost localhost.localdomain > > 127.0.0.1 localhost localhost.localdomain > > Nope. Not used the way you think. The reverse lookup doesn't > treat the hosts file as authoritative, when trying to index by > IP. I'm not sure if this is just because it hates the "::1" > shorthand, or if there's some deeper issue, but I think it's > that there's a deeper issue here. I've never thought about it beyond the "localhost" case. So is "/etc/hosts" obsolete (eg, for LAN hosts) if you need reverse lookup, like if you want to use sendmail? But I mentioned "/etc/hosts" mostly to point out that I'm using only the non-server parts of "bind" which I called the "resolver" and that it seemed to be doing reverse lookup on 127.0.0.1 (or have it hard coded). > > I'm not even caching. Nowhere to do your fix (outside C code), AFAIK. > > You need to set up a caching DNS server on the machine, specify > it as your DNS server in your /etc/resolv.conf, and then set > the forwarder to whatever DNS server you currently have in your > resolv.conf, tun on forwarding, turn on caching, and then make > it authoritative for 127.in-addr.arpa., and the equivalent for > IPv6, and add reverse records. Easier said than done, of course. And there's the complication that my forwarder info gets put in resolve.conf dynamically by DHCP. (But I suspect it's stable enough for my purposes to hard code it in the named files.) I think I'll live with my kludge for a while. > Technically, this is probably a bug in either the FreeBSD resolver > library, or the default FreeBSD hosts file, or both. I'll try using the longhand version of "::1" (which I saw in another message); I didn't know there were two versions. And I'll write a PR on it, though if it's not a /etc/hosts problem, there's going to be too much hand waving for a good chance of the PR being closed before it's obsolete. > [ Hold Expensive ] > > > Uh huh. I gathered that from my reading, and maybe I'll try that sort > > of queuing someday. I'm off the net most of the time and have a gut > > objection to a queue runner banging on a closed door so often and just > > feel more comfortable with the simple "do-it-now" method. But it would > > be nice to be able to "send" mail while offline, I suppose. > > The local delivery mailer is not marked expensive, so local > delivery goes immediately. Unless it can't go immediately, in which case it's queued. > The "HoldExpensive" just means that it won't try to send or > lookup mail that has to go via SMTP -- mail that isn't local -- > until you do an explicit queue run. > > The queue runner doesn't bang it's head... it brings the link up, > and does what it needs to do. But since it runs with a .cf generated > from a different .mc, it has timeouts that make the DNS work, instead > of failing before the link is established. The runner would bang its head trying to bring the link up on MY system and I (currently) want it that way. > If you weren't interested in that, I think you'd just dial in and > leave the link up all the time, right? Then it wouldn't matter > what kind of network connection you had. 8-). I have full-time cable, but I believe in security through probability/ unavailability, even if the risk reduction is small, and I like the hands-on feel of control in bringing the Internet interface up and down by command. (Actully, I click-toggle my UTC clock which indicates my interface status by its background color.) Call me silly. > If you need the specific DNS modifying options, I guess I could > dig them out for you, instead of pointing you at the .../cf/README; No, I'd try some more reading and experimentation first if I was going to try that. But thanks for the offer. The info about DNS was educational, at least, and I'll refer to it again when I need it more. > Mail's a lot more complicated than most people think, and adding > in IPv6 makes it even more complicated, especially since FreeBSD > has some bad defaults in that area (and/or a resolver bug or two). Most Unix users know that sendmail is very complicated, but they don't know why, nor many of the DNS issues. I've resisted many years of urgings to use qmail, et al., for the obvious reasons (and because I had the book), but as sendmail gives me several days of grief (and no e-mail) per year, I wonder if one of the others wouldn't be easier for single-computer users like me to use. I should find out. Thanks again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14vg14vg8l.g14>