Package: emacs21-common Version: 21.4a-1 Severity: grave Justification: causes non-serious data loss Tags: sarge, etch
At least M-x vm for GNU Emacs 21 (from the vm package, versions 7.19-4 in Sarge, 7.19-11 in Etch) and M-x mail from GNU Emacs 21 do not report anything if mails which should be sent out are rejected by /usr/sbin/sendmail, e.g. because of their size, even on a virgin account. The user does not have any clue, that the mail didn't go out and wonders why nobody has received the mail. Both use the underlying smtpmail library, and if mail is sent out using smtpmail's SMTP engine, it reports error, but if it's sendmail engine is used, it reports none. This bug is more or less identical to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403930 which also concerns smtpmail, but the version included in xemacs21-basesupport for XEmacs 21. Example / How to reproduce: Start emacs under a virgin user account. Type M-x vm. Type m in the newly popped up window. Set recipient and subject in the again newly popped up window. Type C-c C-a attach one or more files so that in their sum they are bigger than the local MTA is configured to accept. In our case the limit of the local postfix is (IIRC by default) set to 10 MB and we attached an appropriately big tar.gz. Type C-c C-c to send the mail out. The window closes and postfix from Sarge writes to its log file: Dec 20 17:28:49 malfoy postfix/postdrop[30418]: warning: uid=4977: File too large Dec 20 17:28:49 malfoy postfix/sendmail[30417]: fatal: xtaran(4977): Message file too big Postfix from Etch writes instead: Dec 20 17:53:42 ankara postfix/postdrop[31933]: warning: uid=4977: Illegal seek Dec 20 17:53:42 ankara postfix/sendmail[31932]: fatal: xtaran(4977): queue file write error The user who sent the mail did not get any notice about that and therefore doesn't know he just lost that mail. It's even worse on Etch: There vm claims to have sent out the mail by naming a buffer "sent mail to [EMAIL PROTECTED]" (or whereever you planned to send that mail). On the other hand, this means that you have less serious data loss on Etch. :-) Same with M-x mail and big mails. You even don't get any hint in the *Messages* buffer. To check that postfix did not only log the message to the error log, I tried to send out a similar mail using /usr/sbin/sendmail directly (on Sarge): $ /usr/sbin/sendmail [EMAIL PROTECTED] < 20-MB-Test-Mail.txt postdrop: warning: uid=4977: File too large sendmail: fatal: xtaran(4977): Message file too big $ echo $? 69 $ On Etch /usr/sbin/sendmail returns with exit code 75. I have looked through the vm variables and functions but haven't found any which configures how to care about sendmail's return values or messages (as e.g. mutt does). A workaround is to use SMTP instead of /usr/sbin/sendmail. Then you get at least an "SMTP protocol error", although you still get no hint, what exactly went wrong. For using this workaround, add (custom-set-variables '(send-mail-function (quote smtpmail-send-it)) ; change this to your favourite server -- only needed if $SMTPSERVER is not set. '(smtpmail-smtp-server "mail.example.com")) (custom-set-faces) to the end of your ~/.emacs file. -- System Information for Etch: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages emacs21-common depends on: ii dpkg 1.13.24 package maintenance system for Deb ii emacsen-common 1.4.17 Common facilities for all emacsen emacs21-common recommends no packages. -- no debconf information -- System Information for Sarge: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.33.2-1-dphys-k8-smp-64gb Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages emacs21-common depends on: ii dpkg 1.10.28 Package maintenance system for Deb ii emacsen-common 1.4.16 Common facilities for all emacsen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
