To reproduce, I did this: firstly, create a message by running
vm-mail. I made it look like this:
From: Invalid address <ijackson@chiark.greenend.org.uk>T
To: ping@chiark.greenend.org.uk
Subject: test msg?
X-Mailer: VM 6.75 under Emacs 19.34.1
--text follows this line--
Well ?
Note the `T' at the end of the line. Hitting send (C-c C-c) on this
message produces the minibuffer messages:
Sending...
Sending...done
But, there is no mail. Below is part of an strace I made of emacs
while doing this; it starts just as I press C-c for the 2nd time.
Note that /usr/lib/sendmail died with a SEGV; this is clearly a bug in
the version of Exim that I'm running. If necessary it could be
simulated by writing a simple standin script for Exim that exited
nonzero.
My complaint about VM is that it didn't inform me that my mail had not
been successfully queued. The actual effect of this was that two real
mails I thought I had sent had in fact just vanished, due to this
combination of typo and bugs.
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii vm 6.75-8 A mail user agent for Emacs
ii emacs19 19.34-26.5 The GNU Emacs editor.
Please do not just close my report because emacs19 isn't in testing or
unstable. It should only be closed if you can confirm that no
versions of emacs in testing or unstable have this bug.
Ian.
read(0, "\3", 1) = 1
ioctl(0, FIONREAD, [0]) = 0
sigreturn() = ? (mask now [])
gettimeofday({1002536751, 411046}, {0, 0}) = 0
gettimeofday({1002536751, 411086}, {0, 0}) = 0
gettimeofday({1002536751, 411129}, {0, 0}) = 0
time([1002536751]) = 1002536751
gettimeofday({1002536751, 411553}, {0, 0}) = 0
gettimeofday({1002536751, 411940}, {0, 0}) = 0
write(1, "\33[75dSending...\33[7;1H", 21) = 21
lstat("/u/ijackson/.mailrc", 0xbfffeb4c) = -1 ENOENT (No such file or directory)
lstat("/u/ijackson/.mailrc", 0xbfffea2c) = -1 ENOENT (No such file or directory)
gettimeofday({1002536751, 413418}, NULL) = 0
getpid() = 11314
stat("/tmp/emacs-11314/emacszKFaYa", 0xbfffeb6c) = -1 ENOENT (No such file or directory)
open("/var/lib/emacs/lock/!tmp!emacs-11314!emacszKFaYa", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
chmod("/var/lib/emacs/lock/!tmp!emacs-11314!emacszKFaYa", 0666) = 0
getpid() = 11314
write(3, "11314 ", 6) = 6
close(3) = 0
open("/tmp/emacs-11314/emacszKFaYa", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(3, "MIME-Version: 1.0\nContent-Type: "..., 346) = 346
write(3, "Well ?\n", 7) = 7
close(3) = 0
stat("/tmp/emacs-11314/emacszKFaYa", {st_mode=S_IFREG|0664, st_size=353, ...}) = 0
open("/var/lib/emacs/lock/!!!SuperLock!!!", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
chmod("/var/lib/emacs/lock/!!!SuperLock!!!", 0666) = 0
write(3, "/var/lib/emacs/lock/!tmp!emacs-1"..., 48) = 48
close(3) = 0
open("/var/lib/emacs/lock/!tmp!emacs-11314!emacszKFaYa", O_RDONLY) = 3
read(3, "11314 ", 20) = 6
close(3) = 0
getpid() = 11314
unlink("/var/lib/emacs/lock/!tmp!emacs-11314!emacszKFaYa") = 0
unlink("/var/lib/emacs/lock/!!!SuperLock!!!") = 0
stat("/", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
access("/", X_OK) = 0
open("/tmp/emacs-11314/emacszKFaYa", O_RDONLY) = 3
stat("/usr/lib/sendmail", {st_mode=S_IFREG|S_ISUID|0755, st_size=430772, ...}) = 0
access("/usr/lib/sendmail", X_OK) = 0
open("/dev/null", O_WRONLY) = 4
vfork() = 17141
close(4) = 0
close(3) = 0
unlink("/tmp/emacs-11314/emacszKFaYa") = 0
write(1, "\33[75;11Hdone\33[7;1H", 18) = 18
unlink("/u/ijackson/mail/#mail to ?#q408GG#") = -1 ENOENT (No such file or directory)
gettimeofday({1002536751, 416629}, NULL) = 0
getpid() = 11314
stat("IcHXRE", 0xbfffea9c) = -1 ENOENT (No such file or directory)
stat("/u/ijackson/mail/#mail to ?#q408GG#", 0xbfffec4c) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
gettimeofday({1002536751, 417561}, {0, 0}) = 0
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
fcntl(0, F_SETFL, O_RDWR) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
write(1, "\33[H 4376 N 8 October Ian J"..., 82) = 82
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
write(1, "\r\n 4377 N 8 October Ian Ja"..., 718) = 718
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
write(1, "\33[27mFrom: \"S. Sonwai\" <ss325@he"..., 526) = 526
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
write(1, "\r\n> > please... I have sent you "..., 421) = 421
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
write(1, "\33[74;1H\33[7m -- VM 6.75: INBOX "..., 102) = 102
rt_sigprocmask(SIG_UNBLOCK, [WINCH], [WINCH], 8) = 0
fcntl(0, F_SETFL, O_RDWR|O_ASYNC) = 0
gettimeofday({1002536751, 421618}, {0, 0}) = 0
gettimeofday({1002536751, 421662}, {0, 0}) = 0
gettimeofday({1002536751, 421705}, {0, 0}) = 0
rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
fcntl(0, F_SETFL, O_RDWR) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [WINCH], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [WINCH], [WINCH IO], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [WINCH], [WINCH], 8) = 0
fcntl(0, F_SETFL, O_RDWR|O_ASYNC) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
ioctl(0, FIONREAD, [0]) = 0
rt_sigprocmask(SIG_SETMASK, [], [IO], 8) = 0
gettimeofday({1002536751, 422311}, {0, 0}) = 0
gettimeofday({1002536751, 422354}, {0, 0}) = 0
gettimeofday({1002536751, 422388}, {0, 0}) = 0
select(1024, [0], NULL, NULL, {8, 577612}) = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) ---
wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], WNOHANG|WUNTRACED, NULL) = 17141
rt_sigaction(SIGCHLD, {0x80d2080, [], SA_RESTART|0x4000000}, {0x80d2080, [], SA_RESTART|0x4000000}, 8) = 0
sigreturn() = ? (mask now [])
gettimeofday({1002536751, 424928}, {0, 0}) = 0
gettimeofday({1002536751, 424973}, {0, 0}) = 0
gettimeofday({1002536751, 425010}, {0, 0}) = 0
select(1024, [0], NULL, NULL, {8, 574990} <unfinished ...>
Hi,
vm-mail-send merely flags the appropriate message(s) as
replied to, forwarded, etc, and then sends the mail using standard
emacs mechanism mail-send. If these do not report errors, then VM has
no way of correcting the error.
manoj
reassign 114849 emacs20
Hi Ian, is this issue you reported (Emacs and VM can lose mail if sendmail fails !) still present in emacs21? TIA Adrian
Adrian Bunk writes ("Is this issue still present in emacs21?"):
emacs21 -q
[in the *scratch* buffer]
(setq sendmail-program "/bin/false") C-j
M-x vm-mail RET
check that sendmail-program has right value with C-h v
fill in a short test message
C-c C-c
emacs says `Sending...done'
(no mail has been sent, of course)
10924 vfork() = 11022
...
11022 execve("/bin/false", ["/bin/false", "-oi", "-oem", "-odb", "-t"], [/* 33 vars */]) = 0
...
10924 --- SIGCHLD (Child exited) ---
10924 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 1], WNOHANG|WUNTRACED, NULL) = 11022
...
10924 write(1, "\33[82d\33[?25lSending...done\33[K\33[H\33"..., 137) = 137
Ian.
reassign 114849 emacs21 thanks Thanks for ths information. Since emacs20 is no longer in unstable, I'm reassigning this bug to emacs21. cu Adrian
Adrian Bunk writes ("Re: Is this issue still present in emacs21?"):
Thanks. If you manage to get a reasonably small fix, would you
consider backporting it for stable-proposed-updates ? It's a pretty
nasty bug IMO.
Ian.
tag 114849 patch thanks emacs already checked the exit status of sendmail-program if mail-interactive was non-nil; the attached dpatch makes it check even if mail-interactive is nil.
Quoting Matt Kraai <kraai@ftbfs.org>: ftbfs.org :-) Thanks Matt!
Matt Kraai <kraai@ftbfs.org> writes: After poking around and seeing the documentation of mail-interactive, I checked with emacs-devel@gnu.org (see the post entitled "sendmail.el bug or expected behavior?"). Apparently the current behavior is intentional. See below for Simon Josefssons reply. I'll leave this bug open for the moment in case any of us wants to pursue it, but unless the upstream position changes, I'll plan to close this in a while. Rob Browning <rlb@defaultvalue.org> writes: > Emacs doesn't always check for a non-zero exit status from sendmail, > which can lead to silent mail lossage. For example: > > emacs21 -q > [in the *scratch* buffer] > (setq sendmail-program "/bin/false") C-j > M-x vm-mail RET > check that sendmail-program has right value with C-h v > fill in a short test message > C-c C-c > emacs says `Sending...done' > (no mail has been sent, of course) > > Although from reading mail-interactive's description, I wasn't sure if > this behavior was a bug or intentional: > > mail-interactive's value is nil > Documentation: *Non-nil means when sending a message wait for and > display errors. nil means let mailer mail back a message to report > errors. It is intentional. I'm not sure it is a good idea, but it has been discussed before. > If this isn't just expected behavior, then someone suggested this as a > fix: I think the proper fix is to change the default value of `mail-interactive' to t instead, but I'm not sure there is agreement to do that. If you don't like the default behaviour of silently ignoring exit codes, you can customize the variable as well, no need to patch the code. IIRC, the motivation for this is that waiting for /usr/sbin/sendmail to exit, and thus return an exit code, can take hours with some MTAs if there is no network connectivity.
Quoting Rob Browning <rlb@defaultvalue.org>: Shall we downgrade the bug severity to something more reasonnable?
severity 114849 normal thanks Jérôme Marant <jerome@debian.org> writes: Sounds like a good idea for now.
I'm not the maintainer of Emacs, I'm only going through the bugs after
there was a mail on debian-devel that asked for people going through the
bugs of the removed emacs20 package.
It's Rob who was to answer this question.
Adrian
BTW: It seems a short patch plus some discusion took place in the
bug in the near past.
Rob Browning writes ("Re: Bug#114849: tag 114849 patch"):
Thanks. I feel a bit better now I understand the reasons behind the
abhorrent behaviour :-).
The correct way for a MUA to invoke sendmail is
/usr/sbin/sendmail -odb -oee ...
This is supposed to
(a) queue the message, exiting non-0 if unsuccessful
(b) fork off a detached delivery attempt, which will
deliver the message, leave it queued, or bounce it,
as appropriate
(c) exit 0
Is there some way to configure Emacs to use -odb -oee ? If so we
(FSF, or failing that, Debian) should change the default.
The problem that RMS alludes to happens if you don't give any -odX
options: usually that means you'll get `foreground' delivery, which
typically means that the MTA will try one delivery attempt now.
This is even more unhelpful when combined with -oem (also usually the
default), which (AIUI) exits 0 on success or if the first delivery
attempt fails but the message is queued, but exits nonzero if the
delivery failed straight away even if the message was successfully
bounced.
Emacs needs, from the MTA, the behaviour I specify above for
-odb -oee. Ie, exit status 0 from sendmail should mean the same as
`250 OK' does after SMTP DATA final dot.
If it is difficult to get this behaviour portably (which seems
unlikely nowadays although may have been much harder in times past)
then I think it's still worth doing. In any case any other behaviour
by the MTA will always result in at least one or more of these
symptoms:
* Excessive delay when sending mail interactive.
* Silently vanishing mail. (`Mail sent' but not actually sent.)
* Interactive report of a problem sending mail (`Mail could
not be sent') followed _also_ by a bounce.
* Interactive report of a problem sending mail (`Mail could
not be sent') but in fact the mail is also later delivered.
Ian.
Rob Browning writes ("Re: Bug#114849: tag 114849 patch"):
I disagree about that. This bug (configuration error, whatever)
causes data loss, which is the usual criterion for grave. You might
argue that the data isn't really lost because the sender probably kept
a copy (although that only works if they used FCC and not [B]CC), but
lost mail is typically thought of as a pretty serious problem !
This bug has bitten me on at least three occasions - that I know
about. Plenty of people must have had mail silently vanish.
As an added bonus, because the failure is between MTA and MUA before
the message is queued, the MTA typically doesn't make any log entries
about the problem. So the mail doesn't show up in logs and there's
nothing to help you know what happened to it. The symptoms are
indistinguishable from the user having finger trouble and killing the
mail instead of sending it.
Ian.
Ian Jackson <ijackson@chiark.greenend.org.uk> writes: Ian, the rest of your post was really good, and RMSs post indicates he's interested in a better answer. Would you have time to re-post your message to the emacs-devel thread and discuss the issue with them a bit?
Ian Jackson <ijackson@chiark.greenend.org.uk> writes: I don't disagree with that, but I'd be a little hesitant to change a documented upstream behavior unless they're OK with it. However, if nothing else, I suspect there's a reasonable chance they'd be comfortable with a change in the default for mail-interactive. I agree. Noticing mail losssage (usually only later) is one of the more unpleasant sensations. First, though, I'd like to see what emacs-devel has to say, esp regarding your suggestion about sendmail invocation, and go from there. Thanks
Rob Browning writes ("Re: Bug#114849: tag 114849 patch"):
Sure.
Ian.
This just happened to me again. Sadly I'm too busy (amongst other things, fighting fires caused by lost email!) to do as I promised in January 2004 and take it to emacs-devel. In the mean time I propose that we: * Change mail-interactive to t * Change emacs to invoke the MTA with -odb -oee If any MTAs can't cope with that then at least the symptoms (definite failure or long delays) are less bad than random mail lossage. Ian.
Hi! I'm closing this bug, since it affected emacs21, and the current version is 23. If you still encounter this problem, please feel free to re-open it and move it to the appropriate package, or ask me to do it. Solveig
Note that the default value of mail-interactive changed from nil to t in Emacs 23.1. If you still feel there is something more that needs to be done, I'd suggest reporting it directly to bug-gnu-emacs@gnu.org (and closing this Debian report).
Note that the default value of mail-interactive changed from nil to t in Emacs 23.1. If you still feel there is something more that needs to be done, I'd suggest reporting it directly to bug-gnu-emacs@gnu.org (and closing this Debian report).
Dear submitter, as the package emacs23 has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/753885 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
reopen 114849
reassign 114849 emacs24
found 114849 24.4+1-4
retitle 114849 Invoke sendmail with -odb -oee
thanks
I have just reproduced this with emacs24 in sid.
I did this:
* Install emacs and exim4-daemon-light
* Ran emacs -nw -f mail
* Started an (as root) an strace -ff of the relevant pid
* Filled in an email address and subject and body and sent the mail
I observed emacs doing this:
execve("/usr/sbin/sendmail", ["/usr/sbin/sendmail", "-oi", "-oep", "-odi", "-t"], [/* 50 vars */]) = 0
Emacs should use -odb -oee.
Dear Customer, We can not deliver your parcel arrived at January 20. Please review delivery label in attachment! Kind regards, Fernando Conrad, USPS Senior Operation Agent.
Dear submitter, as the package emacs24 has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/871627 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
reassign 114849 emacs found 114849 1:27.1+1-3.1 thanks Oops, wrong package, thanks to Lars for spotting that.
reopen 114849 reassign 114849 emacs24 found 114849 1:27.1+1-3.1 thanks I used the same steps to reproduce as in October 2014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114849#134 I started with a blank HOME directory, and I had to tell emacs to use "transport". I saw this: t.24009:execve("/usr/sbin/sendmail", ["/usr/sbin/sendmail", "-oi", "-oep", "-odi", "-t"], 0x7ffd88982e40 /* 31 vars */) = 0 The effect of -odi is that emacs will wait for a delivery attempt, which is not desirable. The correct option is -odb. The effect of -oep is that message sending will fail interactively in emacs *even if* the message was queued and a bounce was generated. The correct option is -oee. I have also verified (by copying /bin/false over the exim binary) that mail is no longer lost in the default configuration. I think this is due to the change to the default value of mail-interactive, which, misleadingly, also controls[1] whether emacs cares about failure of the sendmail program. Ian. [1] At least, it did in 2014.
Control: tags -1 + upstream [..] Just tagging this upstream, as this is an upstream behaviour. Maybe Ian can find the time to post the changes to emacs-devel as promised earlier. Best, Chris