From phd at phd.pp.ru Tue Apr 20 07:18:30 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Tue Apr 20 07:18:32 2004 Subject: [Email-SIG] Non-string headers Message-ID: <20040420111829.GA4081@phd.pp.ru> Hello! from email import MIMEText msg = MIMEText.MIMEText("This is a simple message", _charset="latin-1") msg["Subject"] = "Text" msg["X-Test"] = 1 print str(msg) Traceback (most recent call last): File "./text.py", line 10, in ? print str(msg) File "/usr/local/lib/python2.3/email/Message.py", line 116, in __str__ return self.as_string(unixfrom=True) File "/usr/local/lib/python2.3/email/Message.py", line 130, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/lib/python2.3/email/Generator.py", line 103, in flatten self._write(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 138, in _write self._write_headers(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 184, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/local/lib/python2.3/email/Header.py", line 412, in encode newchunks += self._split(s, charset, targetlen, splitchars) File "/usr/local/lib/python2.3/email/Header.py", line 297, in _split elen = charset.encoded_header_len(encoded) File "/usr/local/lib/python2.3/email/Charset.py", line 341, in encoded_header_len return len(s) TypeError: len() of unsized object Is it a bug or a feature? I personnaly thing it is a feature, but a colleague of mine initiated a discussion trying to convince me this is a bug in email and shoud be fixed by calling str() on every header's name (yes, name) and value. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From barry at python.org Tue Apr 20 15:23:25 2004 From: barry at python.org (Barry Warsaw) Date: Tue Apr 20 15:23:29 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <20040420111829.GA4081@phd.pp.ru> References: <20040420111829.GA4081@phd.pp.ru> Message-ID: <1082489004.7017.66.camel@geddy.wooz.org> On Tue, 2004-04-20 at 07:18, Oleg Broytmann wrote: > Is it a bug or a feature? I personnaly thing it is a feature, but a > colleague of mine initiated a discussion trying to convince me this is a bug in > email and shoud be fixed by calling str() on every header's name (yes, name) > and value. Actually, all header names are converted to strings, via modulo operator. The Generator will basically use print>> to output the value of the header, but it does a couple of conditionals first (whether there's any wrapping, if the value is a Header or an 8-bit string). So it wouldn't be /difficult/ I think to add stringification of other values, I'm just not sure it's a good idea. That you get this specific error is mostly just an accident of implementation than a designed feature. Rather than relax the values that a header can have, I'm inclined to tighten them. The rule could be that the header value must be a Unicode string, or an instance providing a particular interface (which by default Headers would implement). This way, raw 8-bit strings would be out (mixing 8-bit and Unicodes is evil anyway :), and you could always wrap your values in an instance that supported the given interface. Accepting Unicodes would be a convenience for the simple case. Then Message.add_header() and friends would throw a TypeError early if the value didn't conform. Comments? -Barry From phd at phd.pp.ru Tue Apr 20 15:51:16 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Tue Apr 20 15:51:20 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <1082489004.7017.66.camel@geddy.wooz.org> References: <20040420111829.GA4081@phd.pp.ru> <1082489004.7017.66.camel@geddy.wooz.org> Message-ID: <20040420195115.GA16623@phd.pp.ru> On Tue, Apr 20, 2004 at 03:23:25PM -0400, Barry Warsaw wrote: > Rather than relax the values that a header can have, I'm inclined to > tighten them. [snip] > Then Message.add_header() and friends would throw a TypeError early if > the value didn't conform. +1 Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From matt at mondoinfo.com Tue Apr 20 15:59:23 2004 From: matt at mondoinfo.com (Matthew Dixon Cowles) Date: Tue Apr 20 15:59:45 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <1082489004.7017.66.camel@geddy.wooz.org> References: <20040420111829.GA4081@phd.pp.ru> <1082489004.7017.66.camel@geddy.wooz.org> Message-ID: <1082490526.73.533@mint-julep.mondoinfo.com> [Barry] > Rather than relax the values that a header can have, I'm inclined > to tighten them. The rule could be that the header value must be a > Unicode string, or an instance providing a particular interface > (which by default Headers would implement). This way, raw 8-bit > strings would be out (mixing 8-bit and Unicodes is evil anyway :), > and you could always wrap your values in an instance that supported > the given interface. Accepting Unicodes would be a convenience for > the simple case. That makes sense to me as long as plain 7-bit strings are allowed. I assume that falls out of what's above, but I don't quite see it. Regards, Matt From barry at python.org Tue Apr 20 16:08:14 2004 From: barry at python.org (Barry Warsaw) Date: Tue Apr 20 16:08:26 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <1082490526.73.533@mint-julep.mondoinfo.com> References: <20040420111829.GA4081@phd.pp.ru> <1082489004.7017.66.camel@geddy.wooz.org> <1082490526.73.533@mint-julep.mondoinfo.com> Message-ID: <1082491693.7017.91.camel@geddy.wooz.org> On Tue, 2004-04-20 at 15:59, Matthew Dixon Cowles wrote: > [Barry] > > Rather than relax the values that a header can have, I'm inclined > > to tighten them. The rule could be that the header value must be a > > Unicode string, or an instance providing a particular interface > > (which by default Headers would implement). This way, raw 8-bit > > strings would be out (mixing 8-bit and Unicodes is evil anyway :), > > and you could always wrap your values in an instance that supported > > the given interface. Accepting Unicodes would be a convenience for > > the simple case. > > That makes sense to me as long as plain 7-bit strings are allowed. I > assume that falls out of what's above, but I don't quite see it. Maybe, if the value wasn't a Header or a unicode, I'd do a unicode(s, 'ascii') conversion on it and convert any UnicodeError to a TypeError. That's a bit of a slippery slope though because some will argue we should do 'latin-1' and maybe other conversions implicitly too. I'd stop at 'ascii'. -Barry From matt at mondoinfo.com Tue Apr 20 17:01:10 2004 From: matt at mondoinfo.com (Matthew Dixon Cowles) Date: Tue Apr 20 17:01:18 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <1082491693.7017.91.camel@geddy.wooz.org> References: <20040420111829.GA4081@phd.pp.ru> <1082489004.7017.66.camel@geddy.wooz.org> <1082490526.73.533@mint-julep.mondoinfo.com> <1082491693.7017.91.camel@geddy.wooz.org> Message-ID: <1082493870.79.533@mint-julep.mondoinfo.com> [Barry] > Maybe, if the value wasn't a Header or a unicode, I'd do a > unicode(s, 'ascii') conversion on it and convert any UnicodeError > to a TypeError. That's a bit of a slippery slope though because > some will argue we should do 'latin-1' and maybe other conversions > implicitly too. I'd stop at 'ascii'. It seems that there's precedent for not assuming anything beyond ASCII and I don't recall seeing any complaints about it. Regards, Matt From phd at phd.pp.ru Wed Apr 21 03:40:08 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Wed Apr 21 03:40:12 2004 Subject: [Email-SIG] Non-string headers In-Reply-To: <1082489004.7017.66.camel@geddy.wooz.org> References: <20040420111829.GA4081@phd.pp.ru> <1082489004.7017.66.camel@geddy.wooz.org> Message-ID: <20040421074008.GA30579@phd.pp.ru> On Tue, Apr 20, 2004 at 03:23:25PM -0400, Barry Warsaw wrote: > Actually, all header names are converted to strings, via modulo > operator. Huh? from email import MIMEText msg = MIMEText.MIMEText("This is a simple message", _charset="latin-1") msg["Subject"] = "Text" msg[1] = "test" print str(msg) Traceback (most recent call last): File "./text.py", line 10, in ? print str(msg) File "/usr/local/lib/python2.3/email/Message.py", line 116, in __str__ return self.as_string(unixfrom=True) File "/usr/local/lib/python2.3/email/Message.py", line 130, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/lib/python2.3/email/Generator.py", line 103, in flatten self._write(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 138, in _write self._write_headers(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 184, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/local/lib/python2.3/email/Header.py", line 198, in __init__ self._firstlinelen = maxlinelen - len(header_name) - 2 TypeError: len() of unsized object Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From esj at harvee.org Wed Apr 21 15:42:12 2004 From: esj at harvee.org (Eric S. Johansson) Date: Wed Apr 21 15:42:41 2004 Subject: [Email-SIG] bug possibility Message-ID: <4086CE94.8060202@harvee.org> you might not consider this a bug but it certainly is biting me hard. with python 2.2.3 stock e-mail module and the 2.5.4 module, I get the same result (not surprising since I hear they're almost the same anyway) given the following message (shell script for generating message available on request) Received: (from esj@localhost) by redweb.harvee.org (8.12.10/8.12.10/Submit) id i3LJBP3v009690 for root@redweb.harvee.org; Wed, 21 Apr 2004 15:11:25 -0400 Date: Wed, 21 Apr 2004 15:11:25 -0400 From: esj@redweb.harvee.org Message-Id: <200404211911.i3LJBP3v009690@redweb.harvee.org> To: root@redweb.harvee.org 1 2 3 4 . when I retrieve the message with as_string, I get: Traceback (most recent call last): File "/usr/lib/python2.2/site-packages/Milter.py", line 188, in milter.set_eom_callback(lambda ctx: ctx.getpriv().eom()) File "./milter_daemon.py", line 94, in eom if camram_pymilter.do_filter(msg, self.mailfrom): File "./camram_pymilter.py", line 76, in do_filter spamtrap.insert( message ) File "/home/esj/camram_core/modules/camram_utils.py", line 309, in insert self.handle.write(message.as_string(1)) File "/usr/lib/python2.2/site-packages/email/Message.py", line 113, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python2.2/site-packages/email/Generator.py", line 103, in flatten self._write(msg) File "/usr/lib/python2.2/site-packages/email/Generator.py", line 138, in _write self._write_headers(msg) File "/usr/lib/python2.2/site-packages/email/Generator.py", line 184, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/lib/python2.2/site-packages/email/Header.py", line 412, in encode newchunks += self._split(s, charset, targetlen, splitchars) File "/usr/lib/python2.2/site-packages/email/Header.py", line 297, in _split elen = charset.encoded_header_len(encoded) File "/usr/lib/python2.2/site-packages/email/Charset.py", line 341, in encoded_header_len return len(s) TypeError: len() of unsized object however, if I turn off the header wrapping in as_string (g = Generator(fp, maxheaderlen=0) the problem goes away. yes, I have a ugly workaround or two for the problem but it still my opinion that this problem shouldn't happen. The workarounds I have are hack the original code, derive from the original message code and overload the as_string method. I gathered there is some magic one can use with generators that would be useful in fixing this problem but so far, that escapes me. Enlightenment would be appreciated. ---eric From barry at python.org Wed Apr 21 16:21:50 2004 From: barry at python.org (Barry Warsaw) Date: Wed Apr 21 16:21:54 2004 Subject: [Email-SIG] bug possibility In-Reply-To: <4086CE94.8060202@harvee.org> References: <4086CE94.8060202@harvee.org> Message-ID: <1082578909.17274.110.camel@geddy.wooz.org> On Wed, 2004-04-21 at 15:42, Eric S. Johansson wrote: > given the following message (shell script for generating message > available on request) Please submit a SF bug report, assign that to me and attach the message generation script to the report. Send a follow up here with the bug url. I can't promise when I'm going to have time to look at this, but at least that way, it won't get buried in the avalanche which is my inbox. ;) FWIW, I do still plan on getting email 3.0 into Python 2.4. My oldest clone is learning how to feed itself right now, so it won't be long until they are ready to start helping me hack. -Barry From esj at harvee.org Wed Apr 21 16:23:06 2004 From: esj at harvee.org (Eric S. Johansson) Date: Wed Apr 21 16:23:41 2004 Subject: [Email-SIG] bug possibility In-Reply-To: <4086CE94.8060202@harvee.org> References: <4086CE94.8060202@harvee.org> Message-ID: <4086D82A.8090706@harvee.org> Eric S. Johansson wrote: > I gathered > there is some magic one can use with generators that would be useful in > fixing this problem but so far, that escapes me. Enlightenment would be > appreciated. after I wrote this, enlightenment dawned (googled??) in the form of __call__ and a couple of other bits. def message_becomes_string(message, UNIX_from=False): string_file = StringIO() mail_Cuisinart = email.Generator.Generator(string_file, maxheaderlen=0) mail_Cuisinart(message, UNIX_from) return string_file.getvalue() so make that three workarounds. Two ugly, one not quite so bad. ---eric From phd at phd.pp.ru Thu Apr 22 10:57:15 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Thu Apr 22 11:00:03 2004 Subject: [Email-SIG] koi8 and base64 Message-ID: <20040422145714.GA5776@phd.pp.ru> Hello! Why koi8 is declared 'koi8-r': (BASE64, BASE64, None) in Charset.py? What is so special about koi8 that it requires to be base64-encoded? In my opinion there is nothing special, no more than windows-1251, which is not declared at all. There is a minor problem with base64-encoded messages in koi8: SpamBouncer (http://spambouncer.org/) recognizes bease64-encoded messages in koi8 as "unneccessary base64 encoded" and filters them as "suspicious". The author of the SpamBouncer speaks Russian and can read/write koi8, so she knows what she is doing. And I agree with her - most MUAs send koi8 messages unencoded. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From che at debian.org Thu Apr 22 13:03:39 2004 From: che at debian.org (Ben Gertzfield) Date: Thu Apr 22 13:03:54 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <20040422145714.GA5776@phd.pp.ru> References: <20040422145714.GA5776@phd.pp.ru> Message-ID: <0025DC30-947F-11D8-AF93-000393C96166@debian.org> koi8-r is an 8-bit character set; it MUST be encoded either with Quoted-Printable or Base64 in order to make it through 7-bit email gateways. I originally wrote the mappings in Charset.py to show which charsets should be Quoted-Printable or Base64 encoded. The only use for Quoted-Printable is for character sets that are mostly identical to 7-bit US-ASCII; I didn't realize at the time that koi8-r's 7-bit characters were identical to US-ASCII. However, koi8-r messages are usually mostly 8-bit characters, correct? If this is the case, Quoted-Printable encoding is hugely wasteful (3 characters for every single byte!) and we should use Base64 instead (4 characters for every 3 bytes). Can you get me in touch with the SpamBouncer author? I strongly believe flagging koi8-r messages as "suspicious" if they're Base64 encoded is a faulty test. Just because some mail user agents encode koi8-r with Quoted Printable doesn't mean that we should discount those that choose to use Base64. Ben On Apr 22, 2004, at 7:57 AM, Oleg Broytmann wrote: > Hello! > > Why koi8 is declared 'koi8-r': (BASE64, BASE64, None) in > Charset.py? What is so special about koi8 that it requires to be > base64-encoded? In my opinion there is nothing special, no more than > windows-1251, which is not declared at all. > > There is a minor problem with base64-encoded messages in koi8: > SpamBouncer (http://spambouncer.org/) recognizes bease64-encoded > messages in koi8 as "unneccessary base64 encoded" and filters them as > "suspicious". The author of the SpamBouncer speaks Russian and can > read/write koi8, so she knows what she is doing. And I agree with her - > most MUAs send koi8 messages unencoded. > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ > phd@phd.pp.ru > Programmers don't die, they just GOSUB without RETURN. > > _______________________________________________ > Email-SIG mailing list > Email-SIG@python.org > Your options: > http://mail.python.org/mailman/options/email-sig/che%40debian.org > From phd at phd.pp.ru Thu Apr 22 13:15:46 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Thu Apr 22 13:16:04 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <0025DC30-947F-11D8-AF93-000393C96166@debian.org> References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> Message-ID: <20040422171545.GA8965@phd.pp.ru> On Thu, Apr 22, 2004 at 10:03:39AM -0700, Ben Gertzfield wrote: > koi8-r is an 8-bit character set; it MUST be encoded either with > Quoted-Printable or Base64 in order to make it through 7-bit email > gateways. I have not saw a 7-bit gateway for quite a number of years. As I have said, most MUAs/MTAs pass koi8-r (and windows-1251) unencoded. Most spam messages are encoded. And why you haven't added windows-1251, then? > However, koi8-r messages are usually mostly 8-bit characters, correct? Yes. > Can you get me in touch with the SpamBouncer author? http://www.spambouncer.org/ Catherine A. Hampton Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From phd at phd.pp.ru Thu Apr 22 13:25:00 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Thu Apr 22 13:25:33 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <20040422171545.GA8965@phd.pp.ru> References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> <20040422171545.GA8965@phd.pp.ru> Message-ID: <20040422172500.GA9238@phd.pp.ru> On Thu, Apr 22, 2004 at 09:15:46PM +0400, Oleg Broytmann wrote: > On Thu, Apr 22, 2004 at 10:03:39AM -0700, Ben Gertzfield wrote: > > koi8-r is an 8-bit character set; it MUST be encoded either with > > Quoted-Printable or Base64 in order to make it through 7-bit email > > gateways. > > I have not saw a 7-bit gateway for quite a number of years. And, btw, this is a job of smtplib, not email. If two SMTP MTAs announced to each other that they are 8bit clean - there is no need to encode anything. So let the email package don't do unneccessary work. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From che at debian.org Thu Apr 22 14:35:33 2004 From: che at debian.org (Ben Gertzfield) Date: Thu Apr 22 14:35:53 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <20040422171545.GA8965@phd.pp.ru> References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> <20040422171545.GA8965@phd.pp.ru> Message-ID: On Apr 22, 2004, at 10:15 AM, Oleg Broytmann wrote: > On Thu, Apr 22, 2004 at 10:03:39AM -0700, Ben Gertzfield wrote: >> koi8-r is an 8-bit character set; it MUST be encoded either with >> Quoted-Printable or Base64 in order to make it through 7-bit email >> gateways. > > I have not saw a 7-bit gateway for quite a number of years. As I > have > said, most MUAs/MTAs pass koi8-r (and windows-1251) unencoded. Most > spam > messages are encoded. Just because many MTAs understand 8-bit data does not mean you can violate RFC 2822. There are still a lot of legacy email gateways out there that will choke on 8-bit email. I've personally run into several, even recently. > And why you haven't added windows-1251, then? Windows-1251 should be added, I agree. However, as a fallback, we already default to Base-64 for unknown character sets, so Windows-1251 will be treated just like koi8-r. > And, btw, this is a job of smtplib, not email. If two SMTP MTAs > announced to each other that they are 8bit clean - there is no need to > encode anything. So let the email package don't do unneccessary work. I totally disagree. Emails must be completely restructured at the most fundamental level for character set transformation and encoding issues. Look at EUC-JP as input for a good example; it must be converted to ISO-2022-JP, line-wrapped in a 16-bit character sensitive way, etc. This is not the job of an SMTP library! MIME is an issue for the creator of the email to handle; we don't know that a user who needs to send a MIME email will use smtplib; they could just as easily use their local MTA which can't do encoding transformations, so we can't assume we can rely on the SMTP library to change encodings of MIME bodies on the fly. Ben From barry at python.org Thu Apr 22 14:40:46 2004 From: barry at python.org (Barry Warsaw) Date: Thu Apr 22 14:40:53 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> <20040422171545.GA8965@phd.pp.ru> Message-ID: <1082659246.3530.7.camel@anthem.wooz.org> On Thu, 2004-04-22 at 14:35, Ben Gertzfield wrote: > Just because many MTAs understand 8-bit data does not mean you can > violate RFC 2822. There are still a lot of legacy email gateways out > there that will choke on 8-bit email. I've personally run into > several, even recently. In principle, I agree. The email package strives to be compliant with RFC 2822, the MIME RFCs and all other relevant *non-transport* email related RFCs. Perhaps email 3.0 can provide better or different ways of overriding the default transformations, for situations where you know what you're doing and want less magic behind the scenes. This would be useful for people who want to disable line wrapping and other things. I'm not sure how to spell that though. -Barry From che at debian.org Thu Apr 22 14:47:38 2004 From: che at debian.org (Ben Gertzfield) Date: Thu Apr 22 14:47:43 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <1082659246.3530.7.camel@anthem.wooz.org> References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> <20040422171545.GA8965@phd.pp.ru> <1082659246.3530.7.camel@anthem.wooz.org> Message-ID: <8759EF14-948D-11D8-AF93-000393C96166@debian.org> On Apr 22, 2004, at 11:40 AM, Barry Warsaw wrote: > Perhaps email 3.0 can provide better or different ways of overriding > the > default transformations, for situations where you know what you're > doing > and want less magic behind the scenes. This would be useful for people > who want to disable line wrapping and other things. I'm not sure how > to > spell that though. +1 for sure. :) Oleg, if you can come up with a clean interface for people who know that they will always be interfacing with 8-bit clean MTAs, please feel free to submit one. There's no reason to force everyone to use quoted-printable or Base64 if they know there's no reason. Ben From phd at phd.pp.ru Thu Apr 22 15:10:33 2004 From: phd at phd.pp.ru (Oleg Broytmann) Date: Thu Apr 22 15:10:40 2004 Subject: [Email-SIG] koi8 and base64 In-Reply-To: <1082659246.3530.7.camel@anthem.wooz.org> References: <20040422145714.GA5776@phd.pp.ru> <0025DC30-947F-11D8-AF93-000393C96166@debian.org> <20040422171545.GA8965@phd.pp.ru> <1082659246.3530.7.camel@anthem.wooz.org> Message-ID: <20040422191033.GA11830@phd.pp.ru> On Thu, Apr 22, 2004 at 02:40:46PM -0400, Barry Warsaw wrote: > Perhaps email 3.0 can provide better or different ways of overriding the > default transformations, for situations where you know what you're doing > and want less magic behind the scenes. This would be useful for people > who want to disable line wrapping and other things. I'm not sure how to > spell that though. Currently I overcome it just by calling Charset.add_charset("koi8-r", Charset.BASE64) Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.