[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2012-03-26 Thread R. David Murray
R. David Murray added the comment: Looking at this again, as_string defaults to maxheaderlen=0, which means no wrapping. In Python 3.2 you can pass it a maxheaderlen of 78 to get the correct behavior for passing the message to smtp. -- resolution: -> invalid stage: -> committed/rej

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread R. David Murray
R. David Murray added the comment: Yes, exactly. It is a valid ascii token so MTA's pass it through. It's the receiving system that needs to be willing to decode it. -- ___ Python tracker __

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread dandre
dandre added the comment: Erm, sorry. The header, of course, does not have much to do with the address the email is to be delivered to. With my provider's setup, the mailer will reply that =?utf-8?q?my?= is not a known user. Which could change, of course... -- ___

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread dandre
dandre added the comment: I made a test and, interestingly, I /can/ send an email to myself setting up the header like this: h.append(b'My Name', charset='utf-8') h.append(b' < ', charset='us-ascii') h.append(b'my', charset='utf-8') h.append(b'@email.address>',

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread R. David Murray
R. David Murray added the comment: Interesting thread. I have my eye on supporting 5335 in the revised email package, but it is secondary goal to getting an improved API for the already-accepted RFCs. You will note that the encoded word local part is *not* standard. I think the email packa

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread dandre
dandre added the comment: Thanks again for the clarification. I may not look like it ;), but my fanciness has to go even further. So, for the sake of completeness, it appears that the world is now up to UTF-8 local parts of email addresses, and punycode for the domain? https://bugzilla.mozil

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread R. David Murray
R. David Murray added the comment: They probably ought to be discussed in our docs :( The only thing that may be encoded in an address is the "display name" (the first part returned by parseaddr). (Actually the domain name could be IDNA encoded, but we don't support that directly in email.

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread dandre
dandre added the comment: Thank you for pointing out my wrong usage of Header. Does this mean I should call Header.append() for each token, with tokens being separated by WS, or probably rather COMMASPACE in the case of To:? Or does it mean I should call Header.append() for each "logical" tok

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread R. David Murray
Changes by R. David Murray : -- assignee: -> r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue12649] email.Header ignores maxlinelen when wrapping encoded words

2011-07-28 Thread R. David Murray
R. David Murray added the comment: You are using Header incorrectly. It should look more like this: th = _e_header.Header(maxlinelen=200, header_name='To') th.append(tfc[:-1]) th.append(wtc[:-1], charset='utf-8') th.append(tem) This results in: To: ABCDEFGH =?utf-8?b?0ILYg