Date: 03 Jan 2003 22:53:57 -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: <8p4r8pwgl6.r8p@localhost.localdomain> In-Reply-To: <3E163C0A.C0CF8146@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert2@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8p4r8pwgl6.r8p>