From owner-freebsd-current Fri Jan 3 22:51:55 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6DB37B401 for ; Fri, 3 Jan 2003 22:51:53 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAF1C43EE1 for ; Fri, 3 Jan 2003 22:51:52 -0800 (PST) (envelope-from swear@attbi.com) Received: from localhost.localdomain ([12.242.158.67]) by rwcrmhc52.attbi.com (rwcrmhc52) with ESMTP id <2003010406515105200evsqee>; Sat, 4 Jan 2003 06:51:51 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.6/8.12.6) with ESMTP id h046s3T4071601; Fri, 3 Jan 2003 22:54:03 -0800 (PST) (envelope-from swear@attbi.com) Received: (from jojo@localhost) by localhost.localdomain (8.12.6/8.12.6/Submit) id h046rwTD071600; Fri, 3 Jan 2003 22:53:58 -0800 (PST) (envelope-from swear@attbi.com) To: Terry Lambert Cc: freebsd-current@freebsd.org Subject: Re: [resolution] Re: sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay) References: <3E1352BC.4043921B@mindspring.com> <20030101145232.A391@zardoc.esmtp.org> <3E13D095.FC52B758@mindspring.com> <3E163C0A.C0CF8146@mindspring.com> From: swear@attbi.com (Gary W. Swearingen) Date: 03 Jan 2003 22:53:57 -0800 In-Reply-To: <3E163C0A.C0CF8146@mindspring.com> Message-ID: <8p4r8pwgl6.r8p@localhost.localdomain> Lines: 78 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert writes: > The book is pretty useless. The reason the fix you are using > works is because you have an IPv6 connection by default, and by > explicitly specifying an IPv4 address, IPv4 is used. > > The issue here is the .in-addr.arpa. delegation for localhost > is considered to be local. When the getpeername() happens, it > gets an IPv6 address instead of an IPv4, and the the gethostbyaddr() > hangs looking for "::1.in-addr.arpa.", but has no problem finding > "1.0.0.127.in-addr.arpa.". I guess you're saying IPv6 is a "sendmail" default and not a OS default; "ping localhost" says it's pinging "127.0.0.1", not "::1". I didn't see much IPv6 stuff (like a default choice) in the README file, unsuprisingly. 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?) 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.) > You can "fix" this by disabling the DNS cross-check in the file > sendmail.cf, and by getting rid of the peer name lookup in the > loopback case. What you did with the IPv4 just took advanatage > of the fact that the in-addr.arpa. IPv4 delegations existed, when > the IPv6 loopback address ones did not. Repairing sendmail config rot only once or twice a year, I can barely deal with the .mc file; I try to stay out of the .cf file. And in quite a lot of reading, I've not run across "cross-check" or "peer name lookup" or "loopback case" or "delegations" and would be unlikely to determine the implementation of your spec if I had. But don't bother explaining; you have better things to do, I'm sure. I sounds like you have a better fix below anyway, and I'm happy with my kludge. I do think I get the gist of what you're saying about the DNS issues. > > Is there a quick way to disable IPv6? While I figure that out or > > rebuild my kernel, I got a quick fix by changing, in my "submit.mc", > > this > > FEATURE(`msp') > > to this > > FEATURE(`msp',`[127.0.0.1]') > > This isn't the correct fix. The correct fix is to add an IPv6 address > and in-addr.arap. delegation for the loopback in your local DNS. My local DNS is the resolver and /etc/hosts with ::1 localhost localhost.localdomain 127.0.0.1 localhost localhost.localdomain I'm not even caching. Nowhere to do your fix (outside C code), AFAIK. Would I have had this problem in 4.7 with the GENERIC kernel? Should the docs say that you must run at least a caching DNS server and say that you must set up this "::1.in-addr.arpa." thing, in order to run sendmail with the GENERIC (or any IPv6) kernel? > As far as the HoldExpensive I recommended, the way you stated the > problem seemed to indicate that it was a failure to connect, not > a failure to validate a connection was going through. In general, > ou want to queue up any mail that can bring up a link, if your link > is transiently connected, and then control the link with a seperate > queue interval. The other DNS statements I made were to ensure that > the interface did not end up bouncing up when sendmail was started, > for local mail delivery, or for remote mail delivery, outside the > administratively controlled queueing intervals (which could be on > the order of seconds, if you wanted). 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. Thanks for the info (both times), even if some of it went over my head. :-) -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message