SUMMARY: "-t" option for sendmail with NIS alias

Date: Sun May 08 1994 - 00:08:07 CDT

My original request:

    When sending mail from an NIS client using emacs to a destination mail
    alias that is defined in the /etc/aliases file on the NIS master, I
    get a return message from the Mailer-Daemon stating
    "550 ... User unknown". The original message does get delivered
    correctly however.

    When I try the same thing using /usr/ucb/mail, everything
    works correctly (the message gets delivered and I do NOT
    get the "User unknown" error message.

    It also works correctly when I send the message from
    the NIS master.

    I looked at how emacs invokes sendmail and found that it pipes
    the mail message to sendmail as follows:

    cat msg | /usr/lib/sendmail -oi -t -f MY-USER-ID -oem -odb

    where msg contains:
          To: MAIL-ALIAS
          Subject: a test

          <message body>

    The "-t" option is used to read the mail message for recipients. If
    I don't use the "-t" option and instead specify the recipient on the
    command line, I don't have the problem.

    It seems like the problem is with sendmail -- any fixes? I am
    running 4.1.3 on a Sparc 10 Model 30.

Thanks to all who responded. (Per Hedeland)
    Dave Mitchell <> (Edward Resnick - Sys Adm Team (1723))
    Rich Schultz <> (Perry Hutchison)
    epl@Kodak.COM (Gene Loriot (epl@Caps.Kodak.COM.))

I fixed the problem by installing sendmail jumbo patch 100377-15 on the 4.1.3
machines and sendmail jumbo patch 101665-02 on the 4.1.3_U1 machines.
Per Hedeland provided a general list of problems with sendmail.

    From Tue Apr 26 10:25:50 1994
    Return-Path: <>
    Date: Tue, 26 Apr 94 12:28:44 +0200
    From: (Per Hedeland)
    Subject: Re: "-t" option for sendmail with NIS alias
    X-Newsgroups: info.sun-managers
    In-Reply-To: <9404251950.AA02873@phoney.phoney>

    In article <9404251950.AA02873@phoney.phoney>, you write:
    |> It seems like the problem is with sendmail -- any fixes? I am
    |> running 4.1.3 on a Sparc 10 Model 30.

    Canned reply follows below (see #10 in particular) - this *might* have
    been fixed in one of the numerous recent sendmail patches, but...

    Hope this helps...
    --Per Hedeland or or

    Here is a list of the bugs/problems with Sun's braindead 'Remote' option (OR) that I've found to date. Note that some of the
    bugs may have been fixed in recent versions; however, due to the
    apparent nature of the implementation of OR (lots of special-cased code
    separate from the normal sendmail functionality), it is unlikely that
    all known and unknown bugs will ever be fixed.

    1. If the connection between client and server sendmail is broken during
       the DATA phase (i.e when the actual letter is transferred), the letter
       is lost, without any information to user or Postmaster, the only trace
       is a "SYSERR: net hang reading from..." type of message in syslog.

    2. Anyone can fake sender addresses with sendmail -f.

    3. Sendmail -t forgets to remove temp file (fixed post-4.0.3, I believe).

    4. Sendmail -t called from emacs (actually whenever it can't do a
       getlogin()) with a local recipient address will put the *recipient*
       address in the From: line.

    5. If a sendmail deamon is run (e.g. if you want to be kind enough to handle
       the occasional mail mis-addressed to user@client rather than having it
       sit in some queue for several days before being bounced), it will ignore
       the OR option, and happily do local delivery causing /bin/mail to write
       /var/spool/mail via NFS, or send directly to hosts in the YP map while
       setting the sender address to user@client. In addition, the local
       delivery is somehow half-baked, ignoring e.g. .forward files.

    6. Since (in the normal non-deamon case) the apart from OR is
       essentially ignored, it isn't possible to do *any* host-specific
       handling, e.g. splitting up mail to root depending on which client
       generated it.

    7. If the mailhost isn't reachable, each letter sent will cause the
       corresponding sendmail process to sit in a loop doing repeated attempts
       - apart from the load, this means that if the client is shut down or
       rebooted before successful delivery, the mail is lost.

    8. It doesn't work at all if /var/spool/mail is auto-mounted.

    9. Sendmail -t will remove one empty line between header and body, with
       the effect that initial body lines that have leading whitespace, or
       that start with <word>:, are moved to the header.

    10. Sendmail -t where the destination is a local alias will generate a
       "User unknown" error message (although the letter will be delivered
       correctly) - if PostmasterCopy is in effect, there will (of course)
       be an additional "User unknown" for Postmaster.

    11. If a letter without a terminating newline is sent (except when using
       sendmail -t), it will not be transferred to the server, instead the
       connection will time out, and the net result will be as for 1 above
       (this is presumably the major case where those symptoms are observed).

    12. Sendmail -t where the destination is a local user with a .forward
       file readable by the sender and containing a command or file name will
       fail with a "Cannot mail directly to programs" (or files) type of
       message. (In addition, the message doesn't look anything like a normal
       sendmail error message, is delivered directly (i.e. over NFS) with a
       hardwired call to /bin/mail, and doesn't contain the original message,
       even though it claims to do.) Apparently fixed in patch 100377-04.

    I realize that 6 and 7 are consequences of intentional design decisions, and
    that 5 might be considered operator error; I still consider them deficiencies.

    I definitely recommend using one of the minimalist's for this
    purpose that have been floating around the net instead of the OR option. The
    only inconveniences with this are that you have to actually spell out the
    name of the mailhost, and that you have to make sure the client's queue is
    checked - if you don't want to run a deamon (which I think is the best
    solution - the load from this should be neglible), you can have sendmail -q
    run from crontab e.g. hourly. On the other hand, you can use the same on non-Sun mail clients. I have done just this, and all of the
    problems went away (the file I'm using can be found on
    as /pub/unix/mail/

    NOTE: Just commenting out the OR from a "standard" Sun file is
    *not* the right thing to do, in fact it may cause problems that are as bad
    as or worse than those caused by OR.

thanks again,


- - - - - - - - - - - - - - - - - - - - - - -
Chuck Kozak Advanced Computing Technologies
                                                 Boeing Helicopters
MS P28-24 8-7961
Phone: (610) 591-7774 FAX: (610) 591-7524

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:00 CDT