>Apparently, for the past couple of months, the default install stopped 
>sending mail to root@localhost.  (I didn't notice until I did a clean 
>install of current recently, having stopped at Oct version.)
>
>Investigating, I found 2 obvious reasons (there may be more): 
> * the mail is queued in /var/spool/clientmqueue/ and never delivered,
>   due to insufficiently tested changes to sendmail in late March.

at least it gets queued and not dropped.

> * the mail is attempting to deliver to "localhost.dom.ain.", instead 
>   of "localhost."

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.  i've seen problems like this before, and they're
relatively easy to fix.

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

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

>     Andrew Brown has suggested a somewhat larger patch for the
>     sendmail install, instead. 

i suggested you read /etc/defaults/rc.conf, which contains this nice
chunk of comments:

    # sendmail can now be run either as a suid root binary or as a sgid
    # smmsp binary.  In the former case, you must not have the file
    # /etc/mail/submit.cf, otherwise sendmail will behave as if it was
    # sgid.  This can result in mail not being delivered.
    #
    # For those people who wish only to send mail (locally or remotely),
    # but not receive mail (via the network) in the sgid case, you must
    # also run the sendmail daemon with one of the following two options:
    #
    #       -ODaemonPortOptions=Family=inet,Addr=127.0.0.1,Name=MTA
    #       -ODaemonPortOptions=Family=inet6,Addr=::1,Name=MTA6
    #
    # The smmsp process is a sendmail helper that periodically flushes the
    # "client" queue in the sgid case.  If you are using sendmail as a
    # suid root program, then smmsp is not needed.

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.

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

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

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

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

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