NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/gnu/emacs/help/4104

Internet Message Format | 1992-09-12 | 6.3 KB

Xref: sparky gnu.emacs.help:4104 comp.mail.sendmail:2265
Newsgroups: gnu.emacs.help,comp.mail.sendmail
Path: sparky!uunet!mcsun!sunic!ericom!eua.ericsson.se!erix.ericsson.se!per
From: [e-mail] (Per Hedeland)
Subject: Re: sendmail.el: flags to /usr/lib/sendmail wrong?
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: super.eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 12 Sep 1992 18:34:14 GMT
Lines: 108

In article <[e-mail]> I write:
>Anyway, I can't reproduce your particular problem using OR and the
>context you describe (using /bin/cat rather than 'filter' though), and
>in fact the error message you give doesn't even seem to be produced by
>sendmail, but rather by some other program talking SMTP to sendmail (and
>perhaps, incorrectly, having taken upon itself to lookup .forward files
>before doing so).

Retraction: I can reproduce it, and it is indeed caused by OR, and
doesn't really have anything to do with emacs (except insofar as emacs
uses sendmail -t, but lots of programs do that) - see # 12 on my
(updated) list below. (The part about "other program" is more or less
correct though - it is the special-cased OR code that is doing this.)

Just in case someone from Sun is listening, I have previously on
comp.mail.sendmail suggested a way to achieve the "things work out of
the box w/o configuration" and "the same sendmail.cf can be used on all
hosts" effect that OR tries to do, in a manner that is less at odds with
the sendmail "philosophy", doesn't require anywhere near as much code
modification, and consequently won't have all the bugs/problems that OR
does. I'll be happy to discuss it...

--Per Hedeland
[e-mail]  or
[e-mail]  or
...uunet!erix.ericsson.se!per

Here is a list of the bugs/problems with Sun's braindead 'Remote'
sendmail.cf 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 sendmail.cf 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 sendmail.cf's for this
purpose that has 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
sendmail.cf on non-Sun mail clients.

I have done just this, using a sendmail.cf based on the one that Rich
Salz sent out on comp.mail.sendmail a while back (the smallest one I've
seen so far:-), and all of the problems went away.

NOTE: Just commenting out the OR from a "standard" Sun sendmail.cf 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.