From: Erich <[EMAIL PROTECTED]>
   Date: Wed, 19 Apr 2000 21:17:52 -0700 (PDT)

   > I assume you mean your return address?  What is the value of the
   > user-mail-address emacs variable? . . .

   Well, that did the trick.  However, that line shouldn't be necessary.
   I still feel that if emacs is using the system MTA, which as you point
   out is sendmail, which is actually a link to qmail/bin/sendmail, then
   sendmail should do the right things to put in the correct From: and
   Return-Path: lines.

Well, to my mind, the "right thing" is to leave them alone, since I want
to set them in emacs; a user's preferred "From:" address often has
nothing to do with her user ID or the name of the local host.  In fact,
at the point where the sendmail-send-it function actually calls
sendmail, there is this comment:

        ;; Always specify who from,
        ;; since some systems have broken sendmails.
        ;; unless user has said no. 

So, by default, emacs sets up the "From:" header and envelope sender,
and tells sendmail to leave them alone.

   But the "unless user has said no" part reflects a hook:  If you put
in your .emacs file

        (setq message-from-style 'system-default)

then sendmail-send-it will give sendmail free rein.  So the usual
qmail-inject environment variables should work (though I haven't tried
this).

   I haven't customized emacs at all.

Then you don't know what you're missing.  ;-}

   This work-around is fine, but I really think I'm missing some part of
   the configuration.

I don't consider this a workaround; this is an important step in
configuring emacs as your MUA.  The fact that emacs has a default that
works for some people, so the step is sometimes optional, doesn't change
the nature or the importance of the step.  After all, you have to tell
Netscape who you are (user name & email address) before Netscape will
let you send email.  You are taking the default behavior of sendmail as
gospel, and it just ain't so.

   There was a discussion on this list about a month ago about the
difference between "injection agents" and "transport agents", and what
they were allowed to do to headers.  In my opinion, the MUA should take
full responsibility for the headers, and transport/injection agents
should only supply defaults for the benefit of low-powered MUAs.  RFC822
appears to imply that this is the right thing.

   Also, there should be some kind of functioning executable in
   /bin/mail.  I just don't know what to put there on this system.

   Maybe I should have gotten Correl Linux, which comes with qmail
   instead of rotten old sendmail.

   e

That would have left you in the same boat, or worse, since this is
really an MUA configuration issue than an MTA configuration issue
(ignoring religious skirmishing over who's responsible for what).
Besides, somebody said Corel doesn't ship qmail configured anyway.

                                        -- Bob Rogers

Reply via email to