Bug#283311: mutt: use_from is a bad default, but I forgot why
Point 1) On Wed, 9 Mar 2005, Marco d'Itri wrote: On Mar 09, Bernhard Kaindl [EMAIL PROTECTED] wrote: maybe there was some bug in some configuration earlyer in use_from, but as it's enabled by default in upstream and in othere GNU/Linux packagings too, the reason might have been temporary. No, it was not temporary. Nice that you know. I don't know why you think it is a bad default but you know it was not because of some bug. Again, Why? You should not insist in things you don't know anymore. Point 2) You did not wanswer to this: and also the fcc files are written without a from header. - What is your comment on that? I'd even say that that might violate some RFC about mail, because normally mail programs will assume that there is a from header in the mail, having none in a saved mail folder means lack of function to me because the mailer cannot show the From address since there is none. - And did you check that it does not violate an RFC to not send and save the From header? Again no answer from you. And what is your justification for having a different default than upstream and not even knowing why? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283311: mutt: use_from is a bad default, but I forgot why
Package: mutt Version: 1.5.6-20040907+3 Followup-For: Bug #283311 Hi, maybe there was some bug in some configuration earlyer in use_from, but as it's enabled by default in upstream and in othere GNU/Linux packagings too, the reason might have been temporary. For example also with exim you can end up exim not having add a From header, and also the fcc files are written without a from header. I'd even say that that might violate some RFC about mail, because normally mail programs will assume that there is a from header in the mail, having none in a saved mail folder means lack of function to me because the mailer cannot show the From address since there is none. In exim, it seems to be possible to configure it so that exim requires a From: header or otherwise immediately discard the mail as spam (rightfully..) and if that is configured, it seem to affect even local users of mutt with this default config. I'd propose to ask the upstream maintainers if they have an idea, and if not I think it should be revmoved just for having the same defaults than every other mutt package. Bernhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297184: offlineimap: crash if IMAPD rejects NUL characters
Package: offlineimap
Version: 4.0.9
Severity: important
Tags: patch
Cryrus IMAPD rejects mails with a NUL characters in them,
and offlineimap 4.0.9 crashes in the error from IMAP:
EEKF9 NO Message contains NUL characters
... place of the crash:
offlineimap/folder/IMAP.py:savemessage():
assert(imapobj.append(self.getfullname(),
imaputil.flagsmaildir2imap(flags),
date, content)[0] == 'OK')
Longer description and fix:
As it so happens, my mail server, which puts mail into my
maildir folder happily passes mail with NULL characters
but Cyrus IMAP, where I want to sync the mail to, does
not. Because this could happen anytime again because
of spam for example, I need to fix the crash in offlineimap
instead of working around it - I need to have it working
for unattended operation and my email is critical.
Therefore I looked at a place to fix the crash and did my
change here:
offlineimap/folder/IMAP.py:
ui.debug('imap', 'savemessage: using date ' + str(date))
- content = re.sub((?!\r)\n, \r\n, content)
+ content = re.sub((?!\r)\n, \r\n, content.replace(\0, =00))
ui.debug('imap', 'savemessage: initial content is: ' + repr(content))
works fine - you can choose to replace \0 with also with nothing,
I choose =00 because it's the quoted-printable sequence for \0,
so this does not fix something but clearly shows me that this
message had a replaced \0 character, that's all.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages offlineimap depends on:
ii python2.3 2.3.5-1An interactive high-level object-o
-- no debconf information
PS: Thanks for offlineimap, works great now!
--- offlineimap/folder/IMAP.py
+++ offlineimap/folder/IMAP.py
@@ -207,7 +207,7 @@
date = imaplib.Time2Internaldate(time.localtime())
ui.debug('imap', 'savemessage: using date ' + str(date))
-content = re.sub((?!\r)\n, \r\n, content)
+content = re.sub((?!\r)\n, \r\n, content.replace(\0, =00))
ui.debug('imap', 'savemessage: initial content is: ' +
repr(content))
(headername, headervalue) = self.savemessage_getnewheader(content)
Bug#157873: screen: Solution using sigsetjmp and siglongjmp from Abram Hindle
Package: screen Version: 4.0.2-4.1 Severity: critical Followup-For: Bug #157873 This bug is also reported under the screen web site on savannah: https://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=11610 In comment #1, he gave a solution which adds an alarm. He uses sigsetjmp and siglongjmp to skip over the blocking routines which works fine here. This is a really highly critical problem because it causes that all applications which were running below the hard hanging screen have to be killed since the screen in really dead beyong recovery. Either this or the other fix which was already given must be applied... Bernhard -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages screen depends on: ii base-passwd 3.5.9Debian base system master password ii debconf 1.4.30.11Debian configuration management sy ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libncursesw55.4-4Shared libraries for terminal hand ii libpam0g0.76-22 Pluggable Authentication Modules l ii passwd 1:4.0.3-30.9 change and administer password and -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
