sendmail init error: Can't assign requested address

[Ernest Sales]

On Tuesday, May 15, 2007 6:29 PM, Chuck Swiger wrote:

> On May 15, 2007, at 9:06 AM, Ernest Sales wrote:
> [ ... ]
> > Honestly, I don't understand what each of this four daemons is
> > supposed
> > to do. I just want the minimal working sendmail config in a NATed
> > host,
> > the /etc/defaults/rc.conf reads as your sample, and init says
> > sendmail_outbound_enable is set to NO, which seems odd but dunno the
> > consequences.
>
> There are only two daemons, actually: the MTA, and the client mqueue
> runner.
>
> The separation was made because sendmail used to run as a single,
> setuid-root executable, and has had a rather infamous security
> history as a consequence.  If you want sendmail to be running and
> listening on port 25 as a MTA, you need to set the sendmail_enable/
> sendmail_outbound_enable to YES.
>
> [ ... ]
> >>> Is there any standard, anything like the CIDR blocks reserved for
> >>> private networks?
> >>
> >> The zeroconf/rendezvous stuff likes to use ".local" as the domain
> >> unless other info is available.
> >
> > Cool. Tried .local and works too. Looks like sendmail is happy with
> > finding 'dot anything' after the hostname. So far, my problem is
> > fixed.
> > But the init behavior for unqualified hostnames is less
> than optimal:
> > having to wait one minute until sendmail agrees --and it finally
> > agrees-- is annoying; and this happens for every sendmail daemon
> > launch.
> > As more end-users using PCs without FQDN jump to FreeBSD
> this could be
> > more heard of. Wonder if filing a PR; comments welcome.
>
> The standard period for a DNS timeout is anywhere up to about two
> minutes, depending on how many resolvers are configured in /etc/
> resolv.conf.  It's possible to tell sendmail not to use DNS, and
> avoid this timeout, but normally people run mailservers only on
> machines with working DNS and a sensible hostname.  This
> isn't a bug,
> it's just an assumption that sendmail makes which is typically
> appropriate, but not for the case of a random client machine without
> working DNS....

A broader point of view. OK, I forget about PR. Thanks.

Ernest


>
> --
> -Chuck
>