bin/40614: [dM] mail(1) versus unknown terminal types

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>Number:         40614
>Category:       bin
>Synopsis:       [dM] mail(1) multiply reports unknown terminal types
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 11 16:05:00 +0000 2009
>Originator:     der Mouse
>Release:        5.0_RC1 (also -current as of 2009-02-11)
>Organization:
        Dis-
>Environment:
        First noticed on ftp.netbsd.org, which at the time was running
        (according to uname) 5.0_RC1.  A correspondent said, on
        2009-02-11, that -current has the same issue.
        "what `which mail`" reports nothing useful, just a UCB Regents
        copyright notice.
>Description:
        When starting mail(1) to send mail, with a terminal type which
        has no termcap entry available, a warning is printed (see
        how-to-repeat for details).  There are two problems with this:
        (1) the same warning is printed four times and (2) the warning
        is printed before, as far as I can tell, whatever feature
        causes mail(1) to care about the terminal type is used.
>How-To-Repeat:
        % env TERM=abcdefgh mail destination

        This produces:

        No entry for terminal type "abcdefgh";
        using dumb terminal settings.
        No entry for terminal type "abcdefgh";
        using dumb terminal settings.
        No entry for terminal type "abcdefgh";
        using dumb terminal settings.
        No entry for terminal type "abcdefgh";
        using dumb terminal settings.
        Subject: 
>Fix:
        Unknown.  I see that message nowhere in usr.bin/mail/*.[ch], so
        it is probably coming from some library (which I would asy
        indicates a design bug in the library - it should be returning
        a status or calling an error callback or some such rather than
        printing a message - but that's a separate issue, not what this
        PR is about).  However, I also don't see TERM anywhere in
        mail/*.[ch] either, except for two false hits (references to
        SIGTERM and WTERMSIG), so I have no easy guide to help me
        figure out which library call is responsible.  Since I don't
        have any machines running either 5.0_RC1 or -current, I'm not
        in a position to diagnose this further myself at the moment.