Your message dated Mon, 08 Dec 2008 16:24:12 +0100
with message-id <[EMAIL PROTECTED]>
and subject line This is a postfix problem
has caused the Debian Bug report #403953,
regarding emacs21-common: smtpmail silently drops mails if they 
/usr/bin/sendmail rejects them
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
403953: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403953
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
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


--- End Message ---
--- Begin Message ---
After reading the logs of the sibling bug #403930, I'm fairly convinced
that this is a problem in postfix which apparently does not report the
failure back to Emacs.

Axel, feel free to reopen if you disagree, but note that you closed
#403930 (same issue in XEmacs) yourself.

Cheers,
       Sven


--- End Message ---

Reply via email to