Dear Mailman-dev,
since I last upgraded I can't make mailman work as it used to!
Most importantly and urgently, the confirmation emails do not trigger subscriptions any more : the user receives her "You are subscribed" email, but she does not appear in the subscribers' roster, and her cookie is still there in data/pending.pck
A secondary issue is that the iso-something subject lines are totally broken ; I think this is related to the impossibility of installing email-2.0.4 on a python 2.1 box (the _compat22.py file fails and exit) but I'm not sure.
What can I do to help track it down/ repair my system?
-- Fil
"F" == Fil fil@rezo.net writes:
F> 1) Most importantly and urgently, the confirmation emails do
F> not trigger
F> subscriptions any more : the user receives her "You are
F> subscribed" email, but she does not appear in the subscribers'
F> roster, and her cookie is still there in data/pending.pck
I'll look into this one.
F> 2) A secondary issue is that the iso-something subject lines
F> are totally
F> broken ; I think this is related to the impossibility of
F> installing email-2.0.4 on a python 2.1 box (the _compat22.py
F> file fails and exit) but I'm not sure.
Wasn't there a report about problems with _compat.py on a Python 2.1 beta? Be sure you're running Python 2.1.3.
There is going to be a new email package shortly, but first I'm trying to finish up MM2.0.12.
-Barry
@ Barry A. Warsaw barry@zope.com :
Wasn't there a report about problems with _compat.py on a Python 2.1 beta? Be sure you're running Python 2.1.3.
I've upgraded python, to no avail:
miel:~/mailman/mailman/misc/email-2.0.4# python -V Python 2.1.3
miel:~/mailman/mailman/misc/email-2.0.4# python setup.py install [snip] skipping byte-compilation of /usr/lib/python2.1/site-packages/email/_compat21.py to _compat21.pyc byte-compiling /usr/lib/python2.1/site-packages/email/_compat22.py to _compat22.pyc File "/usr/lib/python2.1/site-packages/email/_compat22.py", line 21 yield self ^ SyntaxError: invalid syntax
-- Fil
Try this setup.py file, which is part email 2.0.5 -Barry
#! /usr/bin/env python # # Copyright (C) 2001,2002 Python Software Foundation
# Standard distutils setup.py install script for the `mimelib' library, a next # generation MIME library for Python. To install into your existing Python # distribution, run the following at the command line: # # % python setup.py install
import sys from os.path import basename
from distutils.core import setup from distutils.command.install_lib import install_lib
class EmailInstall(install_lib): def byte_compile(self, files): # For Python 2.1.x do not byte compile the _compat22.py file since # that will most definitely fail. Any newer Python can compile # everything. major, minor = sys.version_info[0:2] if major == 2 and minor == 1: files = [f for f in files if basename(f) <> '_compat22.py'] return install_lib.byte_compile(self, files)
setup(name='email', version='2.0.5', description='Next generation MIME library', author='Barry Warsaw', author_email='barry@zope.com', url='http://sf.net/projects/mimelib', packages=['email'], # Because we need to selectively byte-compile cmdclass={'install_lib': EmailInstall}, )
"F" == Fil fil@rezo.net writes:
>> Try this setup.py file, which is part email 2.0.5 -Barry
>> It rocks!
F> I meant "The setup.py rocks!", because it doesn't help mailman
F> deal with the iso-xxx subject lines. Here's what I get:
F> Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?=
Glad the setup.py works.
Now by "doesn't help mailman deal with the iso-xxx buject lines", what exactly does that mean? Is that a problem in the archives? In digests? Some place else?
-Barry
@ Barry A. Warsaw barry@zope.com :
F> Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?=
Glad the setup.py works.
Now by "doesn't help mailman deal with the iso-xxx buject lines", what exactly does that mean? Is that a problem in the archives? In digests? Some place else?
The emails received have this subject line, shown as above. They are not interpreted by 'mutt', nor by a webmail I use (squirrelmail), nor by Eudora, nor by mhonarc (see e.g. http://listes.rezo.net/archives/spip/2002-07/msg00039.html ).
So I guess it's not coming from mutt or the other MUAs being suddenly broken, but rather them being badly formed somewhere in Mailman.
-- Fil
The emails received have this subject line, shown as above.
If some wizards want to see it better, they can download a test message I sent to myself through Mailman and directly. Originals are at http://rezo.net/~fil/mailman/accents.gz ; the mailbox file itself contains:
>>>>> Subject: test =?iso-8859-1?Q?caract=E8res_accentu?= =?iso-8859-1?B?6XMg4Onu9A==?= (nice encoding, shows good in all MUAs)
>>>>> Subject: =?iso-8859-1?q?=5BTest=5D_?= =?iso-8859-1?q?test_=3D=3Fiso-8859-1=3FQ=3Fcaract=3DE8res=5Faccentu=3F=3D?= =?iso-8859-1?q?=0D=0A=09=3D=3Fiso-8859-1=3FB=3F6XMg4Onu9A=3D=3D=3F=3D?= (double encoding, shows bad in all MUAs)
>>>>>
The mail server and my own email are the same machine, so no interference existed.
-- Fil
"F" == Fil fil@rezo.net writes:
> Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?=
F> The emails received have this subject line, shown as
F> above. They are not interpreted by 'mutt', nor by a webmail I
F> use (squirrelmail), nor by Eudora, nor by mhonarc (see e.g.
F> http://listes.rezo.net/archives/spip/2002-07/msg00039.html ).
F> So I guess it's not coming from mutt or the other MUAs being
F> suddenly broken, but rather them being badly formed somewhere
F> in Mailman.
I wouldn't count on it. I believe the header is conformant to RFC 2047:
Ordinary ASCII text and 'encoded-word's may appear together in the
same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any
adjacent 'encoded-word' or 'text' by 'linear-white-space'.
and indeed this header displays just fine in VM/XEmacs.
|
| Subject: test =?iso-8859-1?Q?caract=E8res_accentu?=
| =?iso-8859-1?B?6XMg4Onu9A==?=
| (nice encoding, shows good in all MUAs)
Yup, in mine too.
| Subject: =?iso-8859-1?q?=5BTest=5D_?=
| =?iso-8859-1?q?test_=3D=3Fiso-8859-1=3FQ=3Fcaract=3DE8res=5Faccentu=3F=3D?=
| =?iso-8859-1?q?=0D=0A=09=3D=3Fiso-8859-1=3FB=3F6XMg4Onu9A=3D=3D=3F=3D?=
F> The mail server and my own email are the same machine, so no
F> interference existed.
Hmm. Can you send me the original test message? I'd like to know who in email or Mailman is doing the touble encoding.
But isn't this seems like a different problem than the one you described earlier? In the first case, the mixing of ascii and encoded-words should be legal. In the second, you're getting encoded-words double encoded, which is clearly wrong, but I don't know where that's coming from.
-Barry
"F" == Fil fil@rezo.net writes:
F> 1) Most importantly and urgently, the confirmation emails do
F> not trigger subscriptions any more : the user receives her "You are
F> subscribed" email, but she does not appear in the subscribers'
F> roster, and her cookie is still there in data/pending.pck
FWIW, I can't confirm this with current cvs. Email subscriptions, confirmations, unsubs, confirmations, all seem to work just fine.
-Barry
@ Barry A. Warsaw barry@zope.com :
F> 1) Most importantly and urgently, the confirmation emails do F> not trigger subscriptions any more : the user receives her "You are F> subscribed" email, but she does not appear in the subscribers' F> roster, and her cookie is still there in data/pending.pck
FWIW, I can't confirm this with current cvs. Email subscriptions, confirmations, unsubs, confirmations, all seem to work just fine.
Strangely, the web confirmation works perfectly, only the email confirmations fail. The email confirmation apparently works (the user receives all the correct emails) but the cookie stays in the pending.pck and the user is not subscribed...
I've changed my verify.txt to send everybody to the web confirmation interface, but still, I'm wondering what can be the difference: a lock condition maybe? I've checked permissions, they're all apparently OK...
-- Fil
Dear Barry,
I did a clean install from scratch, and the problem of no-confirm-by-email disappeared. Strangely, I could not see any difference between my two installations, but I might have not seen something.
So we're left with this accentuated subjects problem, which is IMHO linked to a bad install of the email package. i'll wait for the next version ;-)
-- Fil
"F" == Fil fil@rezo.net writes:
F> I did a clean install from scratch, and the problem of
F> no-confirm-by-email disappeared. Strangely, I could not see any
F> difference between my two installations, but I might have not
F> seen something.
Phew! 'Cause I still couldn't reproduce it. :)
F> So we're left with this accentuated subjects problem, which is
F> IMHO linked to a bad install of the email package. i'll wait
F> for the next version ;-)
Ok. I need to do a little more work on email before I tag it and update Mailman. Stay tuned.
-Barry
participants (2)
-
barry@zope.com
-
Fil