From rdmurray at bitdance.com Mon Aug 1 15:49:20 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 01 Aug 2011 09:49:20 -0400 Subject: [Email-SIG] email-6.0.0.a1 In-Reply-To: References: <20110719212139.D5D732500D5@webabinitio.net>

Message-ID: <20110801134921.5A78D2506C6@webabinitio.net> On Sat, 30 Jul 2011 11:14:03 +0200, Axel Rau wrote: > At least seems not to be compatible with my bugs. What am I doing wrong? > https://www.chaos1.de/svn-public/repos/network- > tools/ERDB/trunk/database/erdb_bt.py There's nothing obvious wrong with your code in the vicinity of the error, at a quick look. Can you provide a copy of the email message that is triggering this? A copy of the .as_string output from your syslog would probably be enough. -- R. David Murray http://www.bitdance.com From rdmurray at bitdance.com Tue Aug 2 23:27:06 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Tue, 02 Aug 2011 17:27:06 -0400 Subject: [Email-SIG] [Python-Dev] email-6.0.0.a1 In-Reply-To: <4E38385B.4080201@simplistix.co.uk> References: <20110719212139.D5D732500D5@webabinitio.net> <4E38385B.4080201@simplistix.co.uk> Message-ID: <20110802212706.E6099B14005@webabinitio.net> On Tue, 02 Aug 2011 18:48:11 +0100, Chris Withers wrote: > On 19/07/2011 22:21, R. David Murray wrote: > > The basic additional API is that a 'source' attribute contains the > > text the generator read from the input source, and a 'value' attribute > > that contains the value with all the Content-Transfer-Encoding stuff > > undone so that you have a real unicode string. By changing a policy > > setting, you can have that value as the string value of the header. > > You can also assign a string with non-ASCII characters to a header, and > > the right thing will happen. (Well, eventually it will happen...right > > now it only works correctly for unstructured headers). Further, Date > > headers have a datetime attribute (and accept being set to a datetime), > > and address headers have attributes for accessing the individual addresses > > in the header. Other structured headers will eventually grow additional > > attributes as well. > > This all sounds pretty awesome, congrats :-) > > Has the header wrapping bug that was all part of the big headers mess > been resolved now? If it is the bug I think you are talking about, it was resolved in 3.2.1. If there's still an open header wrapping bug (other than the one about smime and spaces after the ':') please let me know the issue number, as I don't see any in my list. There may still be an issue with whitespace padding in the encoded word context; I haven't tested issue 1467619 since I made my other changes. If it is not fixed in 3.2.1 already, it will be fixed in email6 by the time I finish the new wrapping code for that. --David From xavier.delannoy at cloudmark.com Fri Aug 12 13:33:24 2011 From: xavier.delannoy at cloudmark.com (xavier delannoy) Date: Fri, 12 Aug 2011 13:33:24 +0200 Subject: [Email-SIG] other possible issue with the feedparser (email.message_from_*) Message-ID: <4E450F84.7020201@cloudmark.com> Hi, Before opening a bug report at bugs.python.org, I wish to have your feedback on this: When a "\r\n" is missing between the headers and the body, the feedparser silently fix the issue. The ouput buffer is modified (the \r\n is added, and nothing is appended to the defects list. In my opinion, as the output buffer is modified, this is a bug. In the attachment you'll find files.tgz which contains : - orig.eml : original email - after.eml: output of email.message_from_string - test.py: short test script original email: {{{ Received: from 127.0.0.1 ([192.168.254.1]) by IMP with bizsmtp id 4Z3J1h00102awG001Z3J01; Wed, 06 Jul 2011 11:03:18 +0200 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <4E0AC5F4.1030502 at sample.com> Date: Wed, 29 Jun 2011 14:28:04 +0800 From: test To: to at sample.com Subject: a test subject Here's a wrong email body... \r\n are missing }}} email parsed by the feedparser: {{{ Received: from 127.0.0.1 ([192.168.254.1]) by IMP with bizsmtp id 4Z3J1h00102awG001Z3J01; Wed, 06 Jul 2011 11:03:18 +0200 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <4E0AC5F4.1030502 at sample.com> Date: Wed, 29 Jun 2011 14:28:04 +0800 From: test To: to at sample.com Subject: a test subject Here's a wrong email body... \r\n are missing }}} Xavier -------------- next part -------------- A non-text attachment was scrubbed... Name: files.tgz Type: application/x-compressed-tar Size: 686 bytes Desc: not available URL: From chris at simplistix.co.uk Tue Aug 2 19:48:13 2011 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 02 Aug 2011 17:48:13 -0000 Subject: [Email-SIG] [Python-Dev] email-6.0.0.a1 In-Reply-To: <20110719212139.D5D732500D5@webabinitio.net> References: <20110719212139.D5D732500D5@webabinitio.net> Message-ID: <4E38385B.4080201@simplistix.co.uk> On 19/07/2011 22:21, R. David Murray wrote: > The basic additional API is that a 'source' attribute contains the > text the generator read from the input source, and a 'value' attribute > that contains the value with all the Content-Transfer-Encoding stuff > undone so that you have a real unicode string. By changing a policy > setting, you can have that value as the string value of the header. > You can also assign a string with non-ASCII characters to a header, and > the right thing will happen. (Well, eventually it will happen...right > now it only works correctly for unstructured headers). Further, Date > headers have a datetime attribute (and accept being set to a datetime), > and address headers have attributes for accessing the individual addresses > in the header. Other structured headers will eventually grow additional > attributes as well. This all sounds pretty awesome, congrats :-) Has the header wrapping bug that was all part of the big headers mess been resolved now? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk