"Gary W. Swearingen" wrote:
> Thanks. I tried that and some other things (eg service.switch). Even
> read the book and help files some more. Terry's suggestion regarding
> "expensive" seemed like the opposite of what I needed (I was trying to
> keep the msg out of the queues) and I had no luck trying to disable some
> DNS which he hinted at.
> I got my first good clue after adding level 15 logging to see an 80-sec
> delay between MUA-launched sendmail and the MTA daemon. I then used
> level-99 logging to find
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
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.
> 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",
> to this
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.
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).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message