Red Hat Bugzilla – Bug 213813
emacs's sendmail mangles all the headers
Last modified: 2007-11-30 17:11:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20061027 Fedora/18.104.22.168-8.fc6 Firefox/22.214.171.124
Description of problem:
try sending mail to yourself from emacs with "m-x mail". Notice
what looks like two clumps of headers, one inside the message one as the message header. The problem is that emacs incorrectly tries to use an emacs program called "fakemail" to send the mail. It appears that the emacs rpm's were built on a more or less empty machine where sendmail didn't exist. Some logic in
lisp/paths.el looks for the various places sendmail typically hides and then
as a final fallback supplies an emacs program fakemail qthat probably hasn't worked in 10 years.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.start "emacs -q"
2. type m-x mail
3. compose and send mail to yourself
4. read the mailbox file using more.
one gets a double set of headers, with the topmost one lacking a subject line
and lacking all the user and programatically added headers. Notice that all the
missing headers are included in the message body.
A message with one block of headers and all the user added headers (like subject)
The immediate problem is that the sendmail-program is "fakemail" instead of
"/usr/sbin/sendmail". The only way I can see this happening is if emacs was built on a system that didn't have sendmail on it, so when the file-exists-p test was initially done, it returned nil. This sendmail-program value was then
dumped in the emacs load-up and dump stage. So even if the user later installs the sendmail rpm emacs never tests to see if it exists.
One simple fix would be to hardwire the sendmail path in so even if sendmail doesn't exist at the time emacs is compiled and dumped, the correct path is still stored. Note there are a few similar defconst's in the same file that might also have problems. They haven't bitten me so I haven't looked too hard.
diff -u /usr/share/emacs/21.4/lisp/paths.el.\~1\~ /usr/share/emacs/21.4/lisp/paths.el
--- /usr/share/emacs/21.4/lisp/paths.el.~1~ 2001-07-15 09:15:34.000000000 -0700
+++ /usr/share/emacs/21.4/lisp/paths.el 2006-11-02 19:19:09.000000000 -0800
@@ -161,12 +161,7 @@
"Name of directory used by system mailer for delivering new mail.
Its name should end with a slash.")
- ((file-exists-p "/usr/sbin/sendmail") "/usr/sbin/sendmail")
- ((file-exists-p "/usr/lib/sendmail") "/usr/lib/sendmail")
- ((file-exists-p "/usr/ucblib/sendmail") "/usr/ucblib/sendmail")
- (t "fakemail")) ;In ../etc, to interface to /bin/mail.
+(defconst sendmail-program "/usr/sbin/sendmail"
"Program used to send messages.")
Diff finished at Thu Nov 2 19:19:30
The "minimal buildroots" Fedora policy comes back to bite us in the ass. A
better solution than the proposed patch is just to add a "BuildRequires:
sendmail" to the spec file -- that will cause the brew build system to put
sendmail into the buildroot.
I put some test rpms up at
please download and verify that the bug is fixed.
It looks good. The sendmail-program variable is now correctly set and the sent
mail looks normal too.
*** Bug 217252 has been marked as a duplicate of this bug. ***
*** Bug 219419 has been marked as a duplicate of this bug. ***
I got bit by this too, and wasted an hour or so playing with sendmail.cf before
realizing that the problem was in emacs.
A simple workaround is to add (load-library "paths") to .emacs, which will
re-load the paths.el file and re-set the value of the sendmail-program variable.
It seems to me that it would be worth adding the 21.4-17.2 version to the fc6
updates - I bet more people will encounter this between now and when fc7 is
released in April. But that's just my 2c.
*** Bug 222132 has been marked as a duplicate of this bug. ***
Date: Thu, 11 Jan 2007 17:03:27 -0500
Subject: [Fedora Update] emacs-21.4-17.3 pushed
emacs-21.4-17.3 Testing update has been successfuly pushed for fc6
emacs-21.4-17.3 works fine for me.