"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > > > No. My thought was only to write a Generator subclass for TMDA > > until email handles it correctly. > > Would it really be that much more work to fix this in email, so > that everyone (including us) benefits? I've tried to do this whenever > possible.
I'll file a bug report with a diff to let the list determine if there are any obvious problems. If Barry will accept it, I'd like to see it in email, too. > > Several other small things were affected by the change to > > HeaderParser and were not updated to take advantage of the fact that > > we use HeaderParser. > > Yeah I know. I had thought about investigating these when I changed > over to HeaderParser, but was so burned out on the email package I > just kept putting it off. It hasn't been a problem. Nothing's broken, just (sometimes) inefficient. In the body_as_raw_text example, the current code gives us a second copy of the entire body. Mostly, that's not a problem, but with large attachments, that's a lot of unnecessary memory use. Message.get_payload, OTOH, returns a reference to the raw body, so there is only one in-memory copy. I can look at this stuff after I make my suggestion to the mimelib group. > > This would allow TMDA to work with valid messages rather than > > bombing out on every attempted delivery of those messages until they > > finally disappear from the queue. > > I assume you meant invalid messages? Actually, no. A message with a Content-Type: of message/rfc822 (and that actually has an embedded email message) is a valid email. Using Parser.Parser.parse on that email creates a Message object successfully and Generator.flatten can turn that Message back into flat text. If you read the same message with Parser.HeaderParser, though, and try to flatten it with Generator, you'll get an exception, causing TMDA to endlessly defer the delivery. Mime types of text/* work with Generator because they're expected to have a string payload. Mime types of multipart/* work accidentally because there is a special case for string payloads; the assumption is that the Message object resulted from a "non-strict parse of a message with no starting boundary"[1]. Mime types of message/* fail because the payload is a string but Generator._handle_message expects it to be a list. So what I was trying to say (obviously not too clearly!) was that both Cory's and Paul's reports were of valid messages (Content-Type: message/*) that TMDA/email choked on and that the correct Generator sub-class would allow them to work. Tim [1] Generator._handle_multipart: comment at line 222 _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
