While I don't intend to stir up a hornet's nest, I feel an obligation to point out that an 8Mb email attachment should set off warning bells. I don't believe that SMTP email is very efficient at moving such large files around and that there are other methods for moving them more efficiently. I've found that most email servers are configured to reject email messages that are larger than 2-4Mb. Maybe it is time to back up and look at WHY you even have attachments that are that large? Just a suggestion.
-Larry [EMAIL PROTECTED] wrote: > I'm having troubles with a script that uses the get_payload function. > My script just works perfectly if I use it with attachment up to 8 Mb. > If the attachment are more than 8 Mb large, the script exits with a > TypeError exception. > IMHO when get_payload try to convert the attachment in a single string > it occours in some size limit. > How can I fix it? > > I'm using python-2.3.3 on a SuSE 9.1 distro > > The error raised is > > Traceback (most recent call last): > File "/usr/local/sbin/mailbox2home.py", line 44, in ? > fp.write(part.get_payload(decode=1)) > TypeError: argument 1 must be string or read-only buffer, not None > > and this is the slice of code where the error occours. > > for message in messages: > for part in message.walk(): > # multipart/* are just containers > if part.get_content_maintype() == 'multipart': > continue > # Applications should really sanitize the given filename so > that an > # email message can't be used to overwrite important files > filename = part.get_filename() > if not filename: > ext = mimetypes.guess_extension(part.get_type()) > if not ext: > # Use a generic bag-of-bits extension > ext = '.bin' > filename = 'part-%03d%s' % (counter, ext) > counter += 1 > fp = open(os.path.join(dir, filename), 'wb') > fp.write(part.get_payload(decode=1)) > fp.close() > -- http://mail.python.org/mailman/listinfo/python-list