Andrew Brown wrote:
> 
> 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.

> i've seen problems like this before, and they're
> relatively easy to fix.
> 
Great!


> > (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.


> >     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.


> >     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.


> 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.


> 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. 

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


> >     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:

<quote>
The sysinst adds a obviously unneccessary duplicate localhost line, 
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>


> >     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.

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. 


> >     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".

Seems that "localhost.dom.ain" is not the same as 127.0.0.1 to me?!?!
(Did I mention that I was in the WG discussion for the earlier drafts?)

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."

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

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!

-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32