>> sendmail likes to fully qualify things, especially for smtp
>> transactions.  if i "echo test | mail root", my fully qualified
>> hostname gets added.  if i "echo test | mail root@localhost", the
>> localhost piece gets removed and replaced with my fully qualified
>> hostname.  it sounds to me like your machine wasn't completely
>> configured.  
>
>You mean "sounds to me like your machine wasn't completely configured 
>BY SYSINST."  Yes, that's why I'm raising the issues.

sysinst isn't something i know all that much about.  i do, however,
know how i want my machines to behave, so i check all sorts of things
and tweak stuff manually all the time.  as to what sysinst does, or
how much it should or should not, i can't say.

>> > (A) PR install/21998
>> >
>> >     Obviously, failing to process the daily and security mail is a
>> >     security flaw.  Also, a pretty bad software bug.
>> 
>> they're queued.  you can get them later.
> 
>Actually, those from only a few days ago are already gone, and the 
>message saying each was discarded is in the queue -- waiting to be 
>discarded.

if they're gone, that's another matter.  there's *no* reason for
something to leave the clientmqueue unless it gets properly passed to
an smtp listener on the loopback interface, period.

>> >     My proposed solution is to abandon sendmail, and use postfix as
>> >     the default install.  Perry Metzger proposed a single line fix.
>> >     This has been controversial.
>> 
>> where was that?
> 
>tech-install list.

ah.  gotta love those spread out discussions.  :)

>> >     Andrew Brown has suggested a somewhat larger patch for the
>> >     sendmail install, instead.
>> 
>> i suggested you read /etc/defaults/rc.conf, 
>
>I'd read it long before I ever posted the question, let alone the PR.

okay, good.  so you must have found and understood the comments about
sendmail, then, yes?

>> so you have two choices.  the first is the one i detailed to you
>> (create your own sendmail.mc from the netbsd-proto.mc, tweak it, build
>> the corresponding cf, and install it), though you could just as easily
>> have tweaked /etc/rc.conf in the manner described above.  either way,
>> you'd have to start the sendmail smtp daemon.
> 
>No, sysinst failed to complete configuration.  The whole point of 
>documenting this software bug is to get it fixed, not to perpetuate 
>the problem with sysinst by manual work-arounds.

it sounds to me like the problem was that your host didn't have a
fully qualified name.  i'm sure that's a point that can be addressed.

>> on the postfix side, if you want, you'd still have to tweak the config
>> file, enable it in /etc/rc.conf, and start it.  you'd also have to
>> tweak another file, and select it via /etc/mailer.conf.  it's about
>> the same amount of work either way, imho.
>> 
>> either way there's configuration to be done.  pick your poison.  :)
> 
>No, the reason for this thread is to debate changing the policy.  
>Whatever needs to be done should be the default install. 

so you also want sysinst to do minor mta configuration and enable the
mta?  i'm not trying to be argumentative here, just trying to pin down
the points of contention.

>The sysinst needs to build a working and secure system.  Running 
>internal security should be part of the default install -- of course!

sure.

>> >     Anyway, I'm thinking my approach would be a marked change of
>> >     policy, timely for a 2.0 release, that warrants wide discussion.
>> >
>> > (B) PR install/21999
>> >
>> >     My proposed solution was to add the "localhost.dom.ain" line to
>> >     /etc/hosts.  I even found the spot where an obsolete duplicate
>> >     localhost line could be replaced cleanly.
>> 
>> it's better to give your host a name.  then you shouldn't have that
>> problem.
> 
>If you'd read the PR, you'd know my host has a name:

i'll admit that i didn't read 21999 as closely as i read 21998.
sorry.

><quote>
>The sysinst adds a obviously unneccessary duplicate localhost line, 

a duplicate localhost line doesn't hurt anyone...

>that probably should be localhost.domain:
> 
>#       $NetBSD: hosts,v 1.6 2000/08/15 09:33:05 itojun Exp $
>#...
>::1                     localhost
>127.0.0.1               localhost
>#...
>#
># Added by NetBSD sysinst
>#
>127.0.0.1       localhost
>141.211.133.36  dreamer.citi.umich.edu dreamer
></quote>

okay, very good.

>> >     An alternative solution was proposed that we find all the bad
>> >     libraries, applications, and scripts, and fix them to always use
>> >     "localhost." (note trailing dot).  Maybe that's the long-term
>> >     solution, but I argue that's a lot of work with no guarantee of
>> >     success, and I've always disliked the piecemeal approach.
>> 
>> that seems like a bad idea.  localhost has some other meanings to
>> certain pieces of code that might be inadvertently broken.
> 
>What seems like a bad idea?  find all and "fix".  I agree in part.

it depends on your definition of "fix" and how the proposed "fix"
works.  there are places where localhost means more to the application
than merely "my local address which is either 127.0.0.1 or ::1".

>Yet, as with any change in specification -- in this case the RFC 
>creation of the TLD "localhost." (trailing dot) -- there are probably 
>some miscoded uses that need to be fixed.  I just don't think the 
>wait-and-see one-at-a-time piecemeal approach is best overall. 

actually, there is already a localhost zone that contains the
localhost name.  if you have another zone you want it in, you'll have
to put it there.  filling the hosts file with stuff works in the short
term for convenience, but it's typically much better to find a better
mechanism for name service.  i've seen horrible things in hosts files,
that break things in the most amazing ways...

>> >     It has been suggested that we don't need to worry about somebody
>> >     else announcing "localhost.dom.ain." and intercepting all our
>> >     root@localhost traffic.  This could even be considered a _feature_
>> >     of RFC-1912, which explicitly allows "localhost.dom.ain." as a
>> >     valid hostname.  I'm not sure that's the kind of security hole
>> >     I'd want to have in my default install.
>> 
>> i think you're overinterpreting rfc1912.  i don't get the sense that
>> they intended for you to literally use "localhost.dom.ain" as a
>> hostname.
> 
>Page 14:
>      Translating 127.0.0.1 into "localhost.dom.ain" can cause some
>      software to connect back to the loopback interface when it didn't
>      want to because "localhost" is not equal to "localhost.dom.ain".

yeah.  that bit.

>Seems that "localhost.dom.ain" is not the same as 127.0.0.1 to me?!?!

particularly if "localhost.dom.ain" isn't in the dns.  it really ought
to be in the dns.

>(Did I mention that I was in the WG discussion for the earlier drafts?)

no, you didn't.  that's good, but i'm not going to give you a cookie.

>Therefore, it is certainly possible (and therefore perversely likely) 
>that the DNS zone "dom.ain." could have a record such as: 
>           localhost      IN      A       10.10.10.10
>
>This would certainly intercept all the localhost traffic for the zone, 
>at least in the current install, which expands all "localhost" to "localhost.dom.ain."

now here's where i'm getting confused.  do you mean literally
"localhost.dom.ain" or localhost.my.domain.name.whatever.it.is?

for what it's worth, i'm much in favor of the latter (the record being
in the dns, but not with the wrong address), but not the latter.

the problem with putting the localhost.dom.ain record in the hosts
file is that if your domain switches (as it will if you shift between
dhcp zones in wireless restaurants and cafes, etc), then your mail
will still suffer.  just not today.  tomorrow.  or the next day.  what
sendmail ought to be doing is converting the "@localhost" portion to
"@fully.qualified.host.name", which it should already know, so that
your local mail gets delivered locally.

>I'm not taking a position whether that's the "fault" of sendmail (as 
>you suggest) or of nsswitch, etc.  Just talking about solutions.

good.  clarification of issues.

>If we have a consensus that the solution is *NOT* to worry about 
>providing a catch-all to prevent leaking to localhost.dom.ain, that's 
>fine.  It just means a lot more work fixing every application!

i'm not sure it will provide 100% completeness.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."